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

[Julian Reschke <[e-mail]>]

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