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

Re: i37: Vary and non-existant headers

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 7 May 2009 09:47:33 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <4FFF1485-7A7B-4096-B27B-7947D0C08EE1@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

On 06/05/2009, at 6:08 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> On 06/05/2009, at 4:43 PM, Julian Reschke wrote:
>>> Mark Nottingham wrote:
>>>> Looking back at this discussion, I think we have agreement to  
>>>> drop 'present' (as per Roy), and add the "When a resource's  
>>>> representations..." sentence.
>>>
>>> The current text in draft 06 is different from the one that was  
>>> discussed in earlier emails; so I'll have to re-read the thread  
>>> and compare what's in now with what's in RFC 2616...
>> Good point. Current text:
>>> 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  
>>> in the presented request match the corresponding stored request- 
>>> headers from the original request.
>
> "...selecting request-headers in the presented request..."
>
> What's essential is that this includes also headers *not present* in  
> the request, if the cached response varied on them. For instance, if  
> the cache as a response for a previous request with "Accept- 
> Encoding: gzip", it MUST NOT use that for a subsequent request that  
> lacks an "Accept-Encoding" header.
>
> How about:
>
> "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  
> stored from the original request match those in the presented  
> request."

Possibly.

How about:

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 Vary header match in both the original request  
associated with the stored response, and the presented request.

and adding this to the subsequent paragraph (defining what it means to  
match):

If a header field is absent from a a request, it can only match  
another request if it is also absent there.

> Also, I just noticed that the definition of "selecting headers" now  
> is down in the definition of "Vary". Maybe we should undo this, add  
> a forward reference, or move it into the Terminology section...

Yes, that needs some massaging.


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 6 May 2009 23:48:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:02 GMT