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
