Subject: Re: #186: Document HTTP's error-handling philosophy

From: Julian Reschke <[email-masked]>
Date: Sun, 23 Oct 2011 22:22:23 +0200

On 2011-07-24 20:11, Julian Reschke wrote:
> On 2011-05-24 08:39, Julian Reschke wrote:
>> ...
>
> Revised proposal from the IETF 81 terminal room:
>
> "Conformance and Error Handling
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
>
> This document defines conformance criteria for several roles in HTTP
> communication, including Senders, Recipients, Clients, Servers,
> User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
> [ref to Terminology] for a definitions of these terms.
>
> An implementation is considered conformant if it complies with all of
> the requirements associated with its role(s). Note that SHOULD-level
> requirements are relevant here, unless one of the documented exceptions
> is applicable.
>
> This document also uses ABNF to define valid protocol elements. In
> addition to the prose requirements placed upon them, Senders MUST NOT
> generate protocol elements that are invalid.
>
> 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."
>
> Changes:
>
> - Simplified the first sentence of the last paragraph
>
> - Changed the example to use the Location header field
>
> ...and we're going to put this into the Introductions for all seven parts.
>
> Feedback appreciated,
>
> Julian

...incorporated as proposed 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1452>.

Best regards, Julian