Re: TICKET 259: 'treat as invalid' not defined

On 09.11.2010 03:13, Mark Nottingham wrote:
> My inclination here is to (as with the others) punt the issue of actually defining 'invalid' in the 'core' specification; it can be either an appendix or a separate document.
>
> However, I'm wondering if we can at least identify those places where errors may occur consistently; e.g., by saying things like:
>
> "Header values with multiple instances are considered invalid."
> "Header values that do not match the ABNF are considered invalid."
> "..."
>
> and then something like
>
> "A header value that is considered invalid MAY be ignored, or MAY have error handling algorithms applied to attempt to recover the intent of the message."
>
> Thoughts?

Here's a rough proposal 
(<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/259/i259.diff>) 
how this could look like:

-- snip --
5.  Parsing

    This document does not require any specific handling of invalid
    header field values.  With this in mind, the text below describes a
    simple strategy for parsing the header field and detecting problems
    in general, or in specific parameters.

5.1.  Combine Multiple Instances of Content-Disposition

    If the HTTP message contains multiple instances of the Content-
    Disposition header field, combine all field values into a single one
    as specified in Section 4.2 of [RFC2616].

5.2.  Parsing for Disposition Type and Parameters

    Using the simplified grammar below:

      field-value = disp-type *( ";" param )
      disp-type   = token
      param       = token "=" value

    ...parse the field value into a disp-type (disposition type) and a
    sequence of parameters (pairs of name (token) and value).

    If the field value does not conform to the grammar (such as when not
    exactly one disposition type is specified), ignore the whole header
    field.

5.3.  Checking Cardinality Constraints

    If the parameter sequence contains multiple instances of the same
    parameter name, ignore the whole header field.

5.4.  Post-Process Parameter Values

    For each parameter, post-process the associated value part according
    to the grammar:

    o  According to Section 3.2.1 of [RFC5987] for parameters using the
       RFC 5987 syntax (such as "filename*").  If this fails, just ignore
       this parameter.

    o  According to the grammar for quoted-string (Section 2.2 of
       [RFC2616]) for values starting with a double quote character (").

    o  Verbatim otherwise.

    Note that this step starts with an octet sequence obtained from the
    HTTP message, and results in a sequence of Unicode characters.
-- snip --


Best regards, Julian

Received on Tuesday, 9 November 2010 14:34:46 UTC