> 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.
Henrik is trying to make it sound like it is all Apache's fault. It is not. SQUID is screwing up, too. "...shared caches that use the etag as a variant identifier." To ONLY ever use ETag as a the end-all-be-all for variant identification is, itself, a mistake. If the "Vary:" field is present... then THAT is what the entity (also) "Varies:" on and to ignore that and only rely on "ETag" is a screw-up. I had this argument years ago with folks at the SQUID forum. It was just prior to when they ( finally ) got around to adding any support for "Vary:" at all but (limited) support for "ETag:". Regardless of whether it's DCC ( Dynamic Content-Encoding ) or not... if the entity "Varies:" on "Content-encoding:" but some cache software is ignoring that just because it's ETag matches some other stored "variant"... well... that's just WRONG. Both pieces of software ( SQUID and Apache ) need just a little more code to finally "get it right". Don't forget about "Content-Length", either. If 2 different responses for the same requested entity come back with 2 different Content-Lengths and there is no "Vary:" or "ETag" then regardless of any other protocol semantics the only SANE thing for any caching software to do is to recoginze that, assume it is not a mistake, and REPLACE the existing entity with the new one. Yea.. sure... you might get a lot of cache bounce that way but at least you are returning a fresh copy. It is not possible for 2 EXACTLY identical reprsentations of the same requested entity to have different content lengths. If the lengths are different, then SOMETHING is different with regards to what you have in your cache. To ignore that "reality" as well ( which most caching software does ) is just kinda stupid. No protocol ( sic: set of rules ) can ever cover all the realities. ( Good ) software knows how to make "common sense" as well. Yours... Kevin Kiley In a message dated 12/8/2006 11:45:44 AM Pacific Standard Time, [EMAIL PROTECTED] writes: Argh, my stupid ISP is losing apache email again because they use spamcop. On Dec 7, 2006, at 2:45 PM, Henrik Nordstrom wrote: > tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz: > >> -1 on adding semantic junk to the existing ETag (and keeping it >> strong); that's blatantly uncool. Any generated ETag from >> mod_deflate >> should either be the original strong version or a weak version of any >> previous etag. mod_deflate by *definition* is just creating a weak >> version of the prior entity. No, it is changing the content-encoding value, which is changing the entity. The purpose of etag for caching is two-fold: 1) for freshness checks, and 2) handling conditional range/authoring requests. That is why the spec is full of gobbledygook on etag handling -- it was stretched at the last minute to reuse a very simple freshness check as a form of variant identifier. 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. 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. ....Roy
