W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 23 Oct 2011 22:22:23 +0200
Message-ID: <4EA4777F.4040702@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: httpbis Group <ietf-http-wg@w3.org>
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",
> 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 

Best regards, Julian
Received on Sunday, 23 October 2011 20:23:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:48 UTC