Re: i37: Vary and non-existant headers

On Wed, 6 May 2009, 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.
>
>
>
>>> 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.

Yes, when used internally by a cache, it is valid to canonicalize, 
however, ticket 147 raises one question,
is Accept-Encoding: gzip equivalent to Accept-Encoding: gzip, identity and 
Accept-Encoding: identity, gzip

So while not talking about canonicalization of all headers, we may need to 
have a story for such defaulted values, at least an advice for 
implementors.

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

How about:
"Implementations might define header matching as the equivalence of their 
internal representations".



-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 6 May 2009 07:33:18 UTC