On Oct 3, 2007, at 7:20 AM, Henrik Nordstrom wrote:
On ons, 2007-10-03 at 14:23 +0100, Nick Kew wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
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,
....Roy
