W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Re: #147: header-specific canonicalisation

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 3 Mar 2010 04:49:12 -0500 (EST)
To: Mark Nottingham <mnot@mnot.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.1.10.1003030446260.23173@wnl.j3.bet>
On Wed, 3 Mar 2010, Mark Nottingham wrote:

> This has been discussed on-list and in meetings sporadically, but I don't think we've ever focused on it exclusively.
>
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147>
>
>
> Current text at <http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-08#section-2.6>:
>
>>    The selecting request-headers from two requests are defined to match
>>    if and only if the selecting request-headers in the first request can
>>    be transformed to the selecting request-headers in the second request
>>    by adding or removing linear white space [[anchor8: [
>> ref
>> ]]] at places
>>    where this is allowed by the corresponding ABNF, and/or combining
>>    multiple message-header fields with the same field name following the
>>    rules about header fields in
>> Section 3.2 of [Part1].
>
> Proposed replacement:
>
>  The selecting request-headers from two requests are defined to match
>  if and only if those in the first request can be transformed to those in the
>  second request by applying any of the following:
>    - adding or removing whitespace, where allowed in the headers' ABNF
>    - combining multiple message-header fields with the same field name (see
>       Section 3.2 of [Part1])
>    - canonicalising both headers' values in a way that is known to have identical
>       semantics, according to the headers' specification (e.g., re-ordering field values
>      when order is not significant; case-normalisation, where values are defined to be
>      case-insensitive)

Friendly amendment: s/Canonicalising/Normalizing/

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

         ~~Yves
Received on Wednesday, 3 March 2010 09:49:14 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:21 UTC