W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: i37: Vary and non-existant headers

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 7 May 2009 14:08:23 -0700
Message-Id: <C4801F64-6D36-4FAD-810B-58928FAC6E4F@gbiv.com>
Cc: Brian Smith <brian@briansmith.org>, 'Mark Nottingham' <mnot@mnot.net>, 'HTTP Working Group' <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>
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.

Received on Thursday, 7 May 2009 21:08:27 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC