UserPreferences

ErrorReportingMechanism


Abstract

This proposal specifies a generic error reporting mechanism to be used in all HTTP based applications. It is indeed outside the scope of Atom, and is therefore not a Pace for Atom either. Those not interested in out-of-Atom-scope issues, move along, please! :-)

Status

Closed

Rationale

The debate surrounding client behavior in the face of invalid Atom documents has been frustrating and circular. At the center, there are (at least) two competing concerns:

  1. The Atom Format Specification should not dictate application behavior in the face of fatal XML errors, since the needs and uses of such applications will hopefully be quite diverse.

    vs.

  2. All Atom clients must turf invalid feeds, otherwise Atom will cross the Rubicon and become another tag soup format like RSS and HTML.

Note that both points of view imply inadequate tools for generation. Furthermore, consumers are sometimes producers (this is a syndication format, after all). A feed turfed by a single request from a search engine or syndication service results in an unknown lost number of readers. It is in the best interests of consumers and publishers that publishers are notified of interoperability problems with the most obscure custom user agents.

This Pace posits that notifying publishers of invalid/incompatible feeds is the best remedy for this issue, since the validity of Atom over HTTP is at best a gray area.

Proposal

Create a specification that adds a new header to the HTTP specification stack, to be used in all web applications serving content that might have some chance of being erronous (which basically means all web applications).

Client Processing Model

  1. Request Atom resource. If an Error-URI HTTP header is present in the response, its value is considered to be the URI of the resource the error report should be POSTed to.

  2. Attempt to process the response's message-body with a conformant XML Processor.

  3. If the HTTP library, XML Processor or something in the stack reports something to be considered a [WWW]fatal error, a POST SHOULD be done on the Error-URI acquired in 1.

  4. If the Atom Document violates any validity constraints of the Atom Format Specification, a POST SHOULD be done on the Error-URI acquired in 1. Otherwise, a report MUST NOT be sent.

Say something more about the body, the format of the body, what the server should do with the report, and so on.

Examples

Provide some useful examples.

Impacts

This is an opt-in feature for client and server.

Notes