- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 07 May 2009 21:43:15 +0200
- To: Brian Smith <brian@briansmith.org>
- CC: '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. 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