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

On 2012-06-21 01:55, Mark Nottingham wrote:
>
> 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.

Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1682>.

(I have opened a separate ticket as a reminder to re-align P1 with the 
other parts).

Best regards, Julian

Received on Thursday, 21 June 2012 09:04:16 UTC