Re: if-range requests and compressed response

On Fri, Jul 29, 2011 at 12:11:20AM -0700, Brian Pane wrote:
> 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?

Well, even worse, a server (or an intermediary) might dynamically adjust
its compression level depending on CPU usage, which means that a single
compressed stream might be built from different compression levels.

Regards,
Willy

Received on Saturday, 30 July 2011 06:24:19 UTC