httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <>
Subject Re: Wrong etag sent with mod_deflate
Date Sun, 10 Dec 2006 09:31:54 GMT
sön 2006-12-10 klockan 01:33 -0500 skrev

> As I think I told you years ago when we argued the whole Vary:
> compression
> deal with regards to how broken client browsers really are... I admire
> someone
> who can "stick to their guns".

Despite what has been claimed by others in this thread I do care for the
> I am going to go back to 3 posts ago and say again that I really do
> with you ( and Roy ).

I know. But you still seem to be somewhat unsure on why it's important,
and I know you are not happy about having something implemented contrary
to how you think it should be done.
> However... I am going to also stand by my original statement that if
> any
> cache software has information available to it that it can use to
> handle
> confusing results from a COS ( Content Origin Server ) and still 
> "do the right thing" then that ( in my opinion ) can/should be a MUST 
> requirement that is still missing from the RFC respects.

Let me puncture that belief here and now. The knowledge you think is
there is in fact the exact opposite of your claims. Explanation below.
> I know, I know... I've already lost you... but as long as I'm
> wandering
> in the woods, then... let me do breakdown on your "Chain of Events"
> that takes things farther into the backwoods just on the chance you
> might see my point of view on all of this.

The core thing this is circulating around is the actual meaning of the
304 in response to If-None-Match. This says in plain english:

The cached response entity with ETag X is valid to use as in response to
THIS request, with updated freshness information from the 304 response.

See RFC 2616 13.6  Caching Negotiated Responses for full details.

The purpose of this section is to allow caches to avoid storing a unique
copy of the same entity for each slight variation in Vary related
headers, and to ensure cache correctness.

In particular read the following paragraph and let it sink in for a

   If the selecting request header fields for the cached entry do not
   match the selecting request header fields of the new request, then
   the cache MUST NOT use a cached entry to satisfy the request unless
   it first relays the new request to the origin server in a conditional
   request and the server responds with 304 (Not Modified), including an
   entity tag or Content-Location that indicates the entity to be used.

then the next paragraph from the same section which builds on the above

   If an entity tag was assigned to a cached representation, the
   forwarded request SHOULD be conditional and include the entity tags
   in an If-None-Match header field from all its cache entries for the
   resource. This conveys to the server the set of entities currently
   held by the cache, so that if any one of these entities matches the
   requested entity, the server can use the ETag header field in its 304
   (Not Modified) response to tell the cache which entry is appropriate.
   If the entity-tag of the new response matches that of an existing
   entry, the new response SHOULD be used to update the header fields of
   the existing entry, and the result MUST be returned to the client.


View raw message