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
