Re: i37: Vary and non-existant headers

Brian Smith wrote:
> Julian Reschke wrote:
>> "When a cache receives a request that can be satisfied by a stored
>> response that includes a Vary header field (Section 3.5), it MUST NOT
>> use that response unless all of the selecting request-headers nominated
>> by the *stored* Vary header match in both the original request
>> associated with the stored response, and the presented request."
> 
> This is wrong, but not for the reason Jamie stated.
> 
> Consider this:
> 
> 1. Client requests "GET /foo"
> 2. Cache forwards the request to the server "GET /foo" with
>    an If-None-Match: "A", "B", "C"
> 3. Server returns "304 Not Modified" with ETag "A".
> 
> According to the statement above, the cache could only return the cached
> response with ETag "A" if the Vary'd headers match; otherwise, it couldn't
> return any response at all. However, the cache must be able to return the
> response with ETag "A" regardless of whether the Vary'd headers match.

Why?

What you describe sounds like a bug. If the selecting headers that 
resulted in the response with entity tag "A" had a "Accept-Encoding: 
gzip", then the response can't be used for a request without 
"Accept-Encoding", even if it may be fresh.

> If all of the Vary'd headers match, then the cache can satisfy the request
> without forwarding it on (if it is fresh enough), but otherwise the cache
> must forward the request on; which cached response (if any) the cache can
> return will be decided by the upstream servers.

I do not disagree with this part, but it doesn't seem to be related to 
the stuff above...

BR, Julian

Received on Thursday, 7 May 2009 19:44:00 UTC