Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <4703A242.9050806@apache.org>
Date: Wed, 03 Oct 2007 16:08:02 +0200
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: ETag and Content-Encoding
References: <20071003142304.7e7228b8@grimnir>
In-Reply-To: <20071003142304.7e7228b8@grimnir>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


On 10/03/2007 03:23 PM, Nick Kew wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
> 
> 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.


Regards

Rüdiger