Re: #147: header-specific canonicalisation

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

Received on Wednesday, 3 March 2010 13:06:33 UTC