W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: if-range requests and compressed response

From: Brian Pane <brianp@brianp.net>
Date: Fri, 29 Jul 2011 10:49:36 -0700
Message-ID: <CAAbTgTtfGgTYkdaGoBj5jQpwYhM4az9wF5fJB7hCuSSh2MgKzQ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:46 GMT