Thank you Igor, I will patch FAQ with this shortly.
Slava ----- Original Message ----- From: "Igor Sysoev" <[EMAIL PROTECTED]> To: "Slava Bizyayev" <[EMAIL PROTECTED]> Cc: "Stas Bekman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, July 21, 2003 5:19 AM Subject: Re: Content compression FAQ > On Sat, 19 Jul 2003, Slava Bizyayev wrote: > > Here is small correction to Web Content Compression FAQ. > What does HTTP/1.0 only support mean in this answer: > > ------------ > Q: Are there any content compression solutions for vanilla Apache 1.3.X? > > A: Yes, There are two compression modules written in C that are available > for vanilla Apache 1.3.X: > > * mod_deflate > an Apache handler written in C by Igor Sysoev (Russia). > > * mod_gzip > an Apache handler written in C. Original author: Kevin Kiley, > Remote Communications, Inc. (U.S.) > > Both of these modules support HTTP/1.0 only. > ------------ > > mod_deflate does not care about chunks at all - Apache does it. > If Apache's responses is HTTP/1.1 then Apache send it in chunks > because mod_deflate always deletes "Content-Length" header. > > mod_deflate compresses content using 8K buffer. When the buffer > is filled mod_deflate passes the compressed data to Apache. > If an upstream module calls ap_bflush() to flush a pending data > then mod_deflate asks zlib to flush a compressed stream and > then passes a partially filled buffer to Apache. Since flushing > a compressed stream descreases a compression ratio so mod_deflate has > "DeflateIgnoreFlush" to ignore the ap_bflush() calls of an upstream module. > It can be used for example with Chili!Soft ASP that calls ap_bflush() > after any output even after an output of several bytes. > > So mod_deflate as well as "Apache::Dynagzip are the only handlers > to date that begins transmission of compressed data as soon as > the initial uncompressed pieces of data arrive from their source, > at a time when the source process may not even have completed > generating the full document it is sending. Transmission can therefore > be taking place concurrent with creation of later document content". > > > Igor Sysoev > http://sysoev.ru/en/ > >
