httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <>
Subject Re: ETag and Content-Encoding
Date Wed, 03 Oct 2007 22:47:53 GMT
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

All I am trying to say is that the responses

[no Content-Encoding]
Content-Encoding: gzip

from the same negotiated resource is two different variants in terms of
HTTP and must carry different ETag values, if any.


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

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.


View raw message