UserPreferences

PaceServiceError


Abstract

This proposal specifies a new Atom protocol endpoint by which Atom clients may report invalid Atom documents to a server.

Status

withdrawn

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

Add Section 5.6 to the [WWW]Atom Protocol Specification as follows

5.6 ErrorURI

The ErrorURI is used to report violations of the Atom Format Specification for documents identified with the application/atom+xml media type. The error triggering the report MUST be a direct violation of the Atom Format Specification and/or a [WWW]fatal error reported by a compliant [WWW]XML Processor. The error MUST NOT concern any extension to the specification, any enclosed media type, or any violation of the protocol specified in this document.

5.6.1 Locating

Resources served with an application/atom+xml media type SHOULD be served with an X-Atom-Error HTTP header, whose value is the ErrorURI for that resource. The value of the X-Atom-Error header MUST be a URI. Atom documents MUST NOT be served with more than one such header. Note that the server might change this URI frequently--with each update of an Atom feed, for example.

In addition to an X-Atom-Error HTTP header, Atom documents MAY include a <link> element with a @rel of 'service.error'. Although servers SHOULD include an X-Atom-Error HTTP header, an ErrorURI given solely in a <link> element may be used in its absence. If both an X-Atom-Error HTTP header and a <link> element are present, the value of the header and the <link> element's @href MUST be identical.

The <link> element SHOULD be placed as close as possible to the beginning of the document.

Atom resources MUST NOT use the HTTP Link header for advertising ErrorURIs.

5.6.2 Client Processing Model

  1. Request Atom resource. If an X-Atom-Error HTTP header is present in the response, its value is considered to be the ErrorURI. Continue to 2.

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

  3. If the XML Processor reports a [WWW]fatal error prior to encountering an optional <link> element with @rel "service.error", a request(5.6.3) SHOULD be sent to the ErrorURI, if present. In the absence of an X-Atom-Error HTTP header, a report MUST NOT be sent. Otherwise, continue to 4.

  4. If the XML Processor encounters a <link> element with @rel "service.error", compare the value of @href to the value given in the X-Atom-Error HTTP header, if present. If the URI given in the <link> element is not identical to that of the X-Atom-Error HTTP header (if present), a report MUST NOT be sent. Otherwise, continue to 5.

  5. If the resource was not served with an X-Atom-Error HTTP header, the value of the <link> element's @href is considered to be the ErrorURI. Continue to 6.

  6. If the XML Processor encounters any additional <link> elements with @rel "service.error", and their values are identical to the values of all other <link> elements with @rel "service.error" and the X-Atom-Error HTTP header (if present), a request(5.6.3) SHOULD be sent to the ErrorURI. If the values are not identical, a report MUST NOT be sent. Otherwise, continue to 7.

  7. If the XML Processor reports a [WWW]fatal error, a request(5.6.3) SHOULD be sent to the ErrorURI. Otherwise, continue to 8.

  8. If the Atom Document violates any validity constraints of the Atom Format Specification, a request(5.6.3) SHOULD be sent to the ErrorURI. Otherwise, a report MUST NOT be sent.

5.6.3 Request

The request SHALL be a GRUMBLE. No other methods are currently specified for this URI.

The request MUST include a User-Agent HTTP header. The request SHOULD include a Referer HTTP header.

Information concerning the specific error encountered SHALL NOT accompany the request.

Once one ErrorURI request has been sent, another SHOULD NOT be sent until the feed in question has been requested and returned with HTTP status 200.

5.6.4 Response

The expected status codes from a GRUMBLE are 204, 400, 410, 500. 401, 404, and 503 are also possible.

5.6.4.1 204

The server has acknowledged the report. The 204 response MUST NOT include a message-body, even in versions of HTTP that do not prohibit it.

5.6.4.2 400

Indicates that the server believes that that data sent constitutes an invalid request. A short description of the error MAY appear on the status line itself. A longer description MAY appear in the body.

5.6.4.3 410

The server is no longer accepting error reports to this URI, and will not resume accepting reports in the future. The client SHOULD NOT send any further requests to this URI.

5.6.4.4 500

Indicates that the server detected an internal error on the server processing this request (such as an unhandled exception). A short description of the error MAY appear on the status line itself. A longer description MAY appear in the body.

Examples

Interaction of a server with three clients ('Client A','Client B', and 'Client C') over time

Client A to Server

GET /foo/bar HTTP/1.1
Accept: application/atom+xml

Server to Client A (failing to close <feed> element)

HTTP/1.1 200 OK
Content-Type: application/atom+xml
X-Atom-Error: http://example.com/errors/foo/bar/2004/05/01/17/09/30

<?xml version="1.0" encoding="UTF-8"?>
<feed>
...
<entry>...</entry>

Client B to Server

GET /foo/bar HTTP/1.1
Accept: application/atom+xml

Server to Client B (failing to close <feed> element)

HTTP/1.1 200 OK
Content-Type: application/atom+xml
X-Atom-Error: http://example.com/errors/foo/bar/2004/05/01/17/09/30

<?xml version="1.0" encoding="UTF-8"?>
<feed>
...
<entry>...</entry>

Client A to Server ErrorURI

GRUMBLE /errors/foo/bar/2004/05/01/17/09/30 HTTP/1.1
User-Agent: Client-A/1.0

Server to Client A

HTTP/1.1 204 No Content
...

[Publisher fixes problem]

Client C to Server

GET /foo/bar HTTP/1.1
Accept: application/atom+xml

Server to Client C (valid Atom document)

HTTP/1.1 200 OK
Content-Type: application/atom+xml
X-Atom-Error: http://example.com/errors/foo/bar/2004/05/01/17/10/23

<?xml version="1.0" encoding="UTF-8"?>
<feed>
...
<entry>...</entry>
</feed>

Client B to Server ErrorURI

GRUMBLE /errors/foo/bar/2004/05/01/17/09/30 HTTP/1.1
User-Agent: Client-B/1.0

Server to Client B (feed updated, no longer accepting reports to this URI)

HTTP/1.1 410 Gone
...

Impacts

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

Notes

Much of Section 5.6.1 was cribbed from the [WWW]Pingback 1.0 specification. Stuart Langridge and Ian Hickson, editors.

See [WWW]Mozilla Link Prefetching for another link type that automatically generates requests to arbitrary URIs.

Changed GET to GRUMBLE for ErrorURI requests, per discussion on Atom-Syntax w/ Greg Stein, Bill de HÓra, Julian Reschke, Henry Story, Mark Baker, Asbjørn Ulsberg, Tim Bray, Ken MacLeod, and others. The Pace may now be considered reconciled with PaceErrVerb.

Discussion

Discussion takes place on the mailing list.

Initial discussion, concerning client behavior in the face of errors: [WWW]Old story, a postscript

Initial announcement: [WWW]PaceServiceError (was: Old story, a postscript)

Revision based on comments from the Atom community: [WWW]PaceServiceError revised

Response to revisions: [WWW]Re: PaceServiceError revised;

This thread prompted changes to the client request: [WWW]PaceServiceError: Opportunity for DDoS attack

Compare with ebXML's Error Reporting Module:

[WWW]ebXML Message Service Spec: Implementing Error Reporting and Handling [PDF]

4.2.4.2 Identifying the Error Reporting Location

"The Error Reporting Location is a URI specified by the sender of the message in error that indicates where to send a message reporting the error."



CategoryProposals