Re: if-range requests and compressed response

Thanks again Brian.

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.

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

> On Thu, Jul 28, 2011 at 10:45 PM, Ashok Kumar <ashokkumar.j@gmail.com>
> wrote:
>
> > So this also implies that for dynamically generated gzip compressed
> response, when server
> > receives an If-Range, then server can only respond with 200 with
> uncompressed response?
>
> I think there are two situations where the server could respond with a 206:
>
> 1. The If-Range request specifies an entity-tag, and the server knows
> (via implementation-specific means) that this entity-tag is the same
> as the ETag the server would use for the response at the present time.
>
> 2. The If-Range request specifies an HTTP-date, and the server knows
> (via implementation-specific means) that the Last-Modified date it
> would use for the response at the present time is no later than the
> specified HTTP-date.
>
> > This begs another question. Though not specific to HTTP WG, but just to
> make sure my
> > understanding is correct. IIRC, Apache mod_gzip fixed the E-Tag
> generation problem
> > by appending "-gzip" or similar to end of E-tag of the original content.
> If two runs of
> > gzip compression don't produce the same output, isn't the E-Tag generated
> wrong?
>
> If it's a weak ETag, then it's okay to use the same ETag value even if
> two applications of compression yield outputs that aren't bytewise
> equal.  If it's a strong ETag, like you'd need in order to support
> If-None-Match or If-Range, then yes, the generated ETag would be wrong
> in this situation; however... 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?  I can only think of a couple of ways to
> cause the output to differ while still producing a response the client
> can uncompress:
> - Change gzip's compression level between the two runs, or
> - Swap in a different compression implementation (that produces
> different but still valid gzip-formatted output) between the two runs.
> Neither of those is impossible, but I don't imagine that they're
> common cases either.  Am I missing any other use case?
>
> Thanks,
> -Brian
>
>


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