Re: i37: Vary and non-existant headers

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."

?

That at least makes it a bit clearer that what's relevant is the set in 
the stored request. It also fixes the problem that the set of "selecting 
request header" is only defined once you have the origin server's 
response for that request.



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...

> ...

BR, Julian

Received on Wednesday, 6 May 2009 08:08:46 UTC