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

Re: if-range requests and compressed response

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 30 Jul 2011 08:23:41 +0200
To: Brian Pane <brianp@brianp.net>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20110730062341.GA19184@1wt.eu>
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 GMT

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