On ons, 2007-10-03 at 23:52 +0200, Henrik Nordstrom wrote: > > 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.
To clarify, I do not care much about strong/weak etags. This is a property of how the server generates the content with no significant relevance to caching other than that the ETags as such must be sufficiently unique (there is some cache impacts of weak etags, but not really relevant to this discussion) It anything I said seems to imply that I only want to see strong ETags then that's solely due to the use of poor language on my part and not intentional. All I am trying to say is that the responses [no Content-Encoding] and Content-Encoding: gzip from the same negotiated resource is two different variants in terms of HTTP and must carry different ETag values, if any. End. The rest is just trying to get people to see this. Apache mod_deflate do not do this when doing it's dynamic content negotiation driven transformations, and that is a bug (13.11 MUST) with quite nasty implications on caching of negotiated responses (13.6). The fact that responses with different Content-Encoding is meant to result in the same object after decoding is pretty much irrelevant here. It's two incompatible different negotated variants of the resource and is all that matters. I am also saying that the simple change of making mod_deflate transform any existing ETag into a weak one is not sufficient to address this proper, but it's quite likely to plaster over the problem for a while in most uses except when the original response ETag is already weak. It will however break completely if Apache GET If-None-Match processing is changed to use the weak comparison as mandated by the RFC (13.3.3) (to my best knowledge Apache always uses the strong function, but I may be wrong there..). Negotiation of Content-Encoding is really not any different than negotiation of any of the other content properties such as Content-Language or Content-Type. The same rules apply, and each unique outcome (variant) of the negotiation process needs to be assigned an unique ETag with no overlaps between variants, and for strong ETag's each binary version of each variant needs to have an unique ETag with no overlaps. This ignoring any out-of-band dynamic parameters to the negotiation process such as server load which might affect responses to the same request, only talking about negotiation based on request headers. For out-of-band negotiation properties it's important to respect the strong ETag binary equivalence requirements. Note: Changed language to use the more proper term "variant" instead of "entity". Hopefully less confusing. Regards Henrik
signature.asc
Description: This is a digitally signed message part
