* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #186 (closed design: fixed)

Opened 5 years ago

Last modified 3 years ago

Document HTTP's error-handling philosophy

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: urgent Milestone: 17
Component: non-specific Severity: Active WG Document
Keywords: Cc:
Origin: #93

Description

Questions often come up as to why HTTP doesn't define error handling in a detailed way.

A short explanation of the reasons would help readers understand HTTP's approach. e.g.,:

  • Error conditions are numerous; addressing every one would make the specification much more complex and therefore harder to implement correctly, bringing yet more potential errors.
  • Error handling is often dependant upon the use case, not generic

Change History

comment:1 Changed 4 years ago by mnot@pobox.com

  • Priority changed from normal to urgent

comment:2 Changed 4 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com

comment:3 Changed 4 years ago by mnot@pobox.com

Proposal: replace "Requirements" sections with the following.

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 definition of each.

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, and SHOULD NOT reject the message outright.

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 Content-Type header doesn't match the body, whereby in a systems control protocol using HTTP, this type of error recovery could lead to dangerous consequences.

comment:4 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 15

comment:5 Changed 3 years ago by julian.reschke@gmx.de

  • Milestone changed from 15 to unassigned

comment:6 Changed 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 16

Assigning to milestone 16; we have consensus (see http://www.w3.org/mid/C53E7A36-FEA2-47F7-93C7-615BF364ACF1@mnot.net ), just waiting for it to be incorporated.

comment:7 Changed 3 years ago by julian.reschke@gmx.de

  • Milestone changed from 16 to 17

comment:8 Changed 3 years ago by julian.reschke@gmx.de

comment:9 Changed 3 years ago by julian.reschke@gmx.de

From [1452]:

Rephrase description of conformance; explain how the spec handles error handling (see #186)

comment:10 Changed 3 years ago by julian.reschke@gmx.de

  • Status changed from new to closed
  • Resolution set to incorporated

comment:11 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:12 Changed 3 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.