W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 21 Jun 2012 09:55:24 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D62C6AA9-BAC4-4709-8D41-05657C543F94@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 June 2012 23:56:12 GMT