Re: #147: header-specific canonicalisation

On Wed, 3 Mar 2010, Julian Reschke wrote:

> On 03.03.2010 10:49, Yves Lafon wrote:
>> 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/
>
> This *almost* works for me:
>
> Section 2.6 would become:
>
> -- snip --
>   When a cache receives a request that can be satisfied by a stored
>   response that has a Vary header field (Section 3.5), it MUST NOT use
>   that response unless all of the selecting request-headers nominated
>   by the Vary header match in both the original request (i.e., that
>   associated with the stored response), and the presented request.
>
>   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:
>
>   o  adding or removing whitespace, where allowed in the header's
>      syntax
>
>   o  combining multiple message-header fields with the same field name
>      (see Section 3.2 of [Part1])
>
>   o  normalizing both header values in a way that is known to have
>      identical semantics, according to the header's specification
>      (e.g., re-ordering field values when order is not significant;
>      case-normalization, where values are defined to be case-
>      insensitive)
>
>   If a header field is absent from a request, it can only match another
>   request if it is also absent there.
>
>   A Vary header field-value of "*" always fails to match, and
>   subsequent requests to that resource can only be properly interpreted
>   by the origin server.
>
>   The stored response with matching selecting request-headers is known
>   as the selected response.
>
>   If no selected response is available, the cache MAY forward the
>   presented request to the origin server in a conditional request; see
>   Section 2.4.
> -- snip --
>
> Note:
>
>   If a header field is absent from a request, it can only match another
>   request if it is also absent there.
>
> Is that still true? I don't think; maybe we can remove the sentence 
> completely?

I don't remember where we left this one last time we discussed this, and I 
am wondering what caches are doing in this specific case.

>
> I would also add this to the Changes-from-2616 section (A.2) as:
>
> -- snip --
>   Clarify that matching request headers allows header-specific
>   normalization.  (Section 2.6)
> -- snip --
>
> (proposed draft patch attached to the ticket, see 
> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/147/i147.diff>)
>
> Best regards, Julian
>

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

         ~~Yves

Received on Wednesday, 3 March 2010 20:52:16 UTC