On 12/8/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
What we should be doing is sending transfer-encoding, not content- encoding, and get past the chicken and egg dilemma of that feature in HTTP. If we are changing content-encoding, then we must behave as if there are two different "files" on the server representing the resource. That means tweaking the etag and being prepared to handle that tweak on future conditional requests.
There's just no way to know how to handle any ETag modification on future requests. So, that's a non-starter. Therefore, any fix for this edge case which breaks cacheability in the common case of real browsers I would find unacceptable.
In other words, Henrik has it right. It is our responsibility to assign different etags to different variants because doing otherwise may result in errors on shared caches that use the etag as a variant identifier.
As Kevin mentioned, Squid is only using the ETag and is ignoring the Vary header. That's the crux of the broken behavior on their part. If they want to point out minor RFC violations in Apache, then we can play that game as well. (mod_cache deals with this Vary/ETag case just fine, FWIW.) The compromise I'd be willing to accept is to have mod_deflate support the 'TE: gzip' request header and add 'gzip' to the Transfer-Encoding bit - and to prefer that over any Accept-Encoding bits that are sent. The ETag can clearly remain the same in that case - even as a strong ETag. So, Squid can change to send along TE: gzip (if it isn't already). And, everyone else who sends Accept-Encoding gets the result in a way that doesn't pooch their cache if they try to do a later conditional request. Is that acceptable? -- justin
