httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: ETag and Content-Encoding
Date Wed, 03 Oct 2007 14:08:02 GMT

On 10/03/2007 03:23 PM, Nick Kew wrote:
> We have some controversy surrounding this bug, and bugzilla
> has turned into a technical discussion that belongs here.
> Fundamental question:  Does a weak ETag preclude (negotiated) 
> changes to Content-Encoding?
> Summary:
> Original bug: mod_deflate may compress/decompress content
> but leave an existing ETag in place.
> [ various discussion followed ]
> Yesterday: I committed a fix to /trunk/, assuming it would
> be uncontroversial.  The fix is that any existing ETag should
> be made a weak ETag if mod_deflate either inflates or
> deflates the contents.  Rationale: a weak ETag promises
> equivalent but not byte-by-byte identical contents, and
> that's exactly what you have with mod_deflate.
> Henrik Nordstrom commented:
>   "Not sufficient. The two versions is not semantically equivalen as one
>   can not be exchanged for the other without breaking the protocol. In
>   the context of If-None-Match the weak comparator is used in HTTP and
>   there a strong ETag is equal to a weak ETag."
> Further discussion followed.  I won't repost it here in full, but
> since there clearly is an issue, it needs discussing here.

Currently I share your opinion that a weak etag should fix the issue
(besides ap_meets_condition currently does not work correctly with
weak etags, but this is another story).
OTOH I try to understand why Henrik thinks it is not sufficient.

Ok, before the patch we had the following situation:

Depending on the client httpd sent an uncompressed or an compressed
response with the *same* (possibly) strong ETag and a Vary: Accept-Encoding header.
A cache in the line stored the response and because both responses had
the *same* (possibly) strong ETag it only stored it *once* (either the compressed or
uncompressed version) and in fact ignored the Vary header. So if a client
requested that resource from the cache either conditional (If-none-match) or
unconditional it delivered what it had in stock ignoring the Accept-Encoding
header of the client.

Now after the patch we have the following situation:

Depending on the client httpd sends an uncompressed or an compressed
response with the original ETag if it does not modify the response and
with a weak version of the ETag if does compress / uncompress the response.
In any case it sets a Vary: Accept-Encoding header.
Ok, sending the original ETag if we do not alter the response might be an
error, but lets assume we do not and sent a weak version of the original
ETag in both cases (altering the response / not altering the response).
Does this allow the cache in the line to store it only *once* and ignoring
the Vary header?
If yes, then the fix is not sufficient, but if a weak ETag forces the cache
to store each variant based on the Vary header than it should work.



View raw message