Re: i37: Vary and non-existant headers

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.



>> I don't see consensus to add language about canonicalising request  
>> headers (beyond the process described in p6 2.6).
>
> That's issue <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/ 
> 147>, right? Do we expect consensus to emerge in the future (that  
> is, do we leave the issue open)?

My reading of *this* thread was that doing so would violate the  
prohibition against changing headers by intermediaries, but now that  
you remind me, IIRC there was also a subsequent view expressed that as  
long as the component the cache resided in didn't change them on the  
wire (i.e., it was only for purposes of caching), this was OK.

However, the wording would need to be very careful, and we'd risk  
having to define canonicalisation for all possible headers, something  
that I'm loathe to do... at some point, it's better to just design a  
new, better function for doing this (as has been discussed before).

Do you have proposed text?




--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 6 May 2009 06:56:30 UTC