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

I'm confused. I thought that we were going to talk about error handling in an appendix, but it appears you're starting to talk about it here.

On 10/11/2010, at 1:34 AM, Julian Reschke wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 12 November 2010 04:59:13 UTC