Re: if-range requests and compressed response

On Sat, 30 Jul 2011, Willy Tarreau wrote:

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

As always, compression at the "connection" level (aka 
TE/Transfer-Encoding) won't suffer the issue of having to weaken the ETag 
or create different strong ETag per compression level/dictionnary update, 
needing to change Vary etc... but it's not that much implemented as it is 
hop-by-hop and not end-to-end (curl implemented it recently, thanks!)

For Willy, see also the warning '214 Transformation applied'. [1] when 
compression is done at the representation level at an intermediary.

To get back at the original question, If-Range can be applied only using a 
strong validator, meaning that it needs to be the exact same 
representation (something that on-the-fly compression can provide, of 
course but only if clearly set validators, content-*, but being 
compressed is a property of the representation in that case, and the 
range request applies to bytes of the representation, so in your case 
something compressed).

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-15#section-3.6


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Monday, 1 August 2011 13:03:44 UTC