- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 7 May 2009 14:08:23 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Brian Smith <brian@briansmith.org>, 'Mark Nottingham' <mnot@mnot.net>, 'HTTP Working Group' <ietf-http-wg@w3.org>
On May 7, 2009, at 12:43 PM, Julian Reschke wrote: > 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. Because the origin server just told the cache to deliver "A" in (3). The origin server is authoritative. We've had this discussion before. ....Roy
Received on Thursday, 7 May 2009 21:08:27 UTC