httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: ETag and Content-Encoding
Date Wed, 03 Oct 2007 19:10:56 GMT
On Oct 3, 2007, at 7:20 AM, Henrik Nordstrom wrote:

> On ons, 2007-10-03 at 14:23 +0100, Nick Kew wrote:
>> 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?
> A weak etag means the response is semantically equivalent both at
> protocol and content level, and may be exchanged freely.
> Two resource variants with different content-encoding is not
> semantically equivalent as the recipient may not be able to understand
> an variant sent with an incompatible encoding.

That is not true.  The weak etag is for content that has changed but
is just as good a response content as would have been received.
In other words, protocol equivalence is irrelevant.

> Sending a weak ETag do not signal that there is negotiation taking  
> place
> (Vary does that), all it signals is that there may be multiple but  
> fully
> compatible versions of the entity variant in circulation, or that each
> request results in a slightly different object where the difference  
> has
> no practical meaning (i.e. embedded non-important timestamp or  
> similar).

Yes.  Compression has no practical meaning.

>> 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.
> I disagree. It's two very different entities.

That is irrelevant.  What matters is the resource semantics, not the
message bits.  Every bit can change randomly and still be semantically
equivalent to a resource representation of random bits.

> Note: If mod_deflate is deterministic and always returning the exact
> same encoded version then using a strong ETag is correct.
> What this boils down to in the end is
> a) HTTP must be able to tell if an already cached variant is valid  
> for a
> new request by using If-None-Match. This means that each negotiated
> entity needs to use a different ETag value. Accept-Encoding is no
> different in this any of the other inputs to content negotiation.

That is not HTTP.  Don't confuse the needs of caching with the needs
of range requests -- only range requests need strong etags.

> b) If the object undergo some transformation that is not deterministic
> then the ETag must be weak to signify that byte-equivalence can not be
> guaranteed.
> Note regarding a: The weak/strong property of the ETag has no
> significance here. If-None-Match uses the weak comparision function
> where only the value is compared, not the strength. See 13.3.3  
> paragraph
> "The weak comparison function".

As intended,


View raw message