On ons, 2007-10-03 at 12:10 -0700, Roy T. Fielding wrote: > > 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.
By protocol semantic equivalence I mean responses being acceptable to requests. Example: Two negotiated responses with different Content-Encoding is not semantically equivalent at the HTTP level as their negotiation properties is different, and one can not substitute one for the other and expect that HTTP works. But two compressed response entities with different compression level depending on the CPU load is. Note: Ignoring transfer-encoding here as it's transport and pretty much irrelevant to the operations of the protocol other than wire message encoding/decoding. > > 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. I am not. I am talking about If-None-Match, not If-Range. And specifically the use of If-None-Match in 13.6 Caching Negotiated Responses. It's a very simple and effective mechanism, but requires servers to properly assign ETags to each (semantically in case of weak) unique entity of a resource (not the resource as such). Content-Encoding is no different in this than any of the other negotiated properties (Content-Type, Content-Language, whatever). Regards Henrik
signature.asc
Description: This is a digitally signed message part
