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

Re: i37: Vary and non-existant headers

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 07 May 2009 21:43:15 +0200
Message-ID: <4A0339D3.3050402@gmx.de>
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:40 UTC