Re: if-range requests and compressed response

Thanks Brian.

>"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)."

That should solve the problem.

On Fri, Jul 29, 2011 at 11:19 PM, Brian Pane <brianp@brianp.net> wrote:

> 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
>
>


-- 
.- ... .... --- -.-