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

On 21/06/2012, at 3:23 AM, Julian Reschke wrote:

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


Looks good to me.

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

Received on Wednesday, 20 June 2012 23:56:01 UTC