- From: Jamie Lokier <jamie@shareable.org>
- Date: Fri, 8 May 2009 16:07:02 +0100
- To: Brian Smith <brian@briansmith.org>
- Cc: 'Julian Reschke' <julian.reschke@gmx.de>, 'Mark Nottingham' <mnot@mnot.net>, 'HTTP Working Group' <ietf-http-wg@w3.org>
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