httpd-dev mailing list archives

sön 2006-12-10 klockan 01:33 -0500 skrev TOKILEY@aol.com:
> 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
RFC.
> I am going to go back to 3 posts ago and say again that I really do
> AGREE
> 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
while:
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.
Regards
Henrik