httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <hen...@henriknordstrom.net>
Subject Re: ETag and Content-Encoding
Date Wed, 03 Oct 2007 21:27:45 GMT
On ons, 2007-10-03 at 07:53 -0700, Justin Erenkrantz wrote:

> As before, I still don't understand why Vary is not sufficient to
> allow real-world clients to differentiate here.  If Squid is ignoring
> Vary, then it does so at its own peril - regardless of ETags.

See RFC2616 13.6 Caching Negotiated Responses and you should understand
why returing an unique ETag on each variant is very important. (yes, the
gzip and identity content-encoded responses is two different variants of
the same resource, see earlier discussions if you don't agree on that).

But yes, thinking over this a second time converting the ETag to a weak
ETag is sufficient to plaster over the problem assuming the original
ETag is a strong one. Not because it's correct from a protocol
perspective, but becase Apache do not use the weak compare function when
processing If-None-Match so in Apache's world changing a strong ETag to
a weak one is about the same as assigning a new ETag.

However, if the original ETag is already weak then the problem remains
exactly as it is today..

Also it's also almost the same as deleting the ETag as you also destroy
If-None-Match processing of filtered responses, which also is why it
works..

> The problem with trying to invent new ETags is that we'll almost
> certainly break conditional requests and I find that a total
> non-starter.

Only because your processing of conditional requests is broken. See
earlier discussions on the topic of this bug already covering this
aspect.

To work proper the conditionals needs to (logically) be processed when
the response entity is known, this is after mod_deflate (or another
filter) does it's dance to transform the response headers. Doing
conditionals before the actual response headers is known is very
errorprone and likely to cause false matches as you don't know this is
the response which will be sent to the requestor.

> Your suggestion of appending ";gzip" leaks information
> that doesn't belong in the ETag - as it is quite possible for that to
> appear in a valid ETag from another source - for example, it is
> trivial to make Subversion generate ETags containing that at the end -
> this would create nasty false positives and corrupt Subversion's
> conditional request checks.

Then use something stronger, less likely to be seen in the original
etag. Or fix the filter architecture to deal with conditionals proper
making this question ("collisions") pretty much a non-issue.

Or until conditionals can be processed correctly in precense of filters
drop the ETag on filtered responses where the filter do some kind of
negotiation.

> Plus, rewriting every filter to append or
> delete a 'special' marker in the ETag is bound to make the situation
> way worse.  -- justin

I don't see much choice if you want to comply with the RFC requirements.
The other choice is to drop the ETag header on such responses, which
also is not a nice thing but at least complying with the specifications
making it better than sending out the same ETag on incompatible
responses from the same resource.

Regards
Henrik

Mime
View raw message