- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 6 May 2009 03:33:01 -0400 (EDT)
- To: Mark Nottingham <mnot@mnot.net>
- cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
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