- From: Brian Pane <brianp@brianp.net>
- Date: Fri, 29 Jul 2011 10:49:36 -0700
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Fri, Jul 29, 2011 at 1:56 AM, Ashok Kumar <ashokkumar.j@gmail.com> wrote: > Brian Pane wrote >> what's the use case in which two runs of >> gzip, both starting with freshly initialized state (as is the case >> when gzip is invoked dynamically on a per-response basis in every >> server and proxy implementation I've seen), will produce different >> output from the same input? > for a proxy, won't gzip bytestream change because of the MTIME change (since > the proxy will fill in compression start time instead of original file > modification time because its working on a stream rather than a file?). For > ZLIB/Deflate, this should be fine. Ah, thanks, now I see the use case where there's a potential problem. The simplest solution is to set the MTIME in the gzip header to zero when doing dynamic compression. And, based on a quick check of the code, that's exactly how it's done in nginx, Apache, and Varnish (the first three open source proxies with gzip support that I could think of). These implementations call a function named deflateInit2 in zlib to initialize their gzip state. According to the comments in the zlib source, this function sets up a gzip stream with a header suitable for streaming compression of dynamic content: "The gzip header will have no file name, no extra data, no comment, no modification time (set to zero), no header crc, and the operating system will be set to 255 (unknown)." -Brian
Received on Friday, 29 July 2011 17:50:05 UTC