Re: #361: ABNF requirements for recipients [was: #307 untangle Cache-Control ABNF]

On 2012-06-19 10:10, Mark Nottingham wrote:
>
> On 19/06/2012, at 5:57 PM, Julian Reschke wrote:
>
>> So, for consistency, we should insert:
>>
>> "Recipients MUST accept all protocol elements matching the ABNF rules defined for them."
>
> "accept" is ambiguous here. "Be able to parse" is more specific, I think.
>
>> Maybe we need "Unless otherwise noted" because of some special cases for "obs-*".
>
> yes.

Proposed change:

339,347c339,349
<  Unless noted otherwise, Recipients MAY take steps to recover a usable
<  protocol element from an invalid construct.  However, HTTP does not
<  define specific error handling mechanisms, except in cases where it
<  has direct impact on security.  This is because different uses of the
<  protocol require different error handling strategies; for example, a
<  Web browser may wish to transparently recover from a response where
<  the Location header field doesn't parse according to the ABNF,
<  whereby in a systems control protocol using HTTP, this type of error
<  recovery could lead to dangerous consequences.
---
 >  Unless noted otherwise, Recipients MUST be able to parse all protocol
 >  elements matching the ABNF rules defined for them and MAY take steps
 >  to recover a usable protocol element from an invalid construct.
 >  However, HTTP does not define specific error handling mechanisms,
 >  except in cases where it has direct impact on security.  This is
 >  because different uses of the protocol require different error
 >  handling strategies; for example, a Web browser may wish to
 >  transparently recover from a response where the Location header field
 >  doesn't parse according to the ABNF, whereby in a systems control
 >  protocol using HTTP, this type of error recovery could lead to
 >  dangerous consequences.

(Change is just in the first sentence)

Best regards, Julian

Received on Wednesday, 20 June 2012 17:24:14 UTC