httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Wrong etag sent with mod_deflate
Date Fri, 08 Dec 2006 19:44:25 GMT
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

Mime
View raw message