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",
> "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
Received on Sunday, 23 October 2011 20:23:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:48 GMT