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.
> 
> 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.

That's a very interesting point.

Here's another:

  4. Another client sends a request whose headers match the stored request
     from step 1 (_not_ the originally stored request), over the same Vary.

Can the cache return the response with Etag "A" without consulting the
server?

I'm thinking the only useful and sensible answer is yes, it fits the
obvious intentions of the caching model, and that is probably what
good cache implementations do.

But that means the cache is allowed to store the request from step 1
associated with the response that the cache sent, with Etag "A".  (Or
equivalently, as an internal implementation detail, it's allowed to
create an additional "cache key" for the same response with Etag "A").

And I'm not sure that's permitted by the RFC text.

Assuming that is permitted, should the newly stored response with Etag
"A", associated with the response's Vary and the Vary-selected
requesting headers for the second request (step 1) - should it use the
original response's Vary, or the Vary that comes with the "304 Not
Modified" response?

I'm thinking the Vary that comes with the "304 Not Modified" if there
is one, otherwise the Vary that came with the originally stored
response, is the safest conservative combination.

Always using the Vary that came with the originally stored response is
wrong, because it is not always sufficient to encode the dependencies
that were used to make the decision that Etag "A" is suitable for the
second request at step 1.

-- Jamie

Received on Friday, 8 May 2009 15:07:40 UTC