UserPreferences

PaceErrVerb

Author

HenryStory

Contributors

[GregStein] why ERR instead of ERROR? I don't understand the desire to save a couple characters.
[HenryStory] answer: GET, PUT, POST, are verbs. This was to continue along that line. But come to think of it HEAD is not. ([anonymous]ROTFL!)
[HenryStory] AntoneRoundy proposed REPORT, as it is transitive and people can say "REPORT that page to be broken", but [WWW]it's taken

Abstract

There is currently an asymmetry in reporting errors between the client and the server. The server can return an error status to the client on its request, but the client cannot tell the server that it has returned an invalid response. This proposal rectifies this by proposing a RESTful easily implementable and backward compatible solution to this asymmetry.

Status

This was sent to the [WWW]W3C TAG e-mail list A lot more work needs to be done to flesh out the details of how this works, how error messages are sent, etc...
HenryStory: Closed for this list, Open for the World

Rationale

The W3C is requiring strict adherence to many new standards. XML for example has to be well formed. The well formedness of an XML response depends on the XML payload as well as the HTTP headers (such as mime types) that accompany the response. If these are broken, as can happen all too easily when a web server is improperly configured, the client has no simple and automatic way of notifying the resource that it is broken. For B2B applications this is not too much of an issue, as a lot of resources and many channels are available between the consumer of a resource and its producer. In the consumer world the dynamics are very different, and will lead to a widening gap between specification and implementation. This is why this issue has appeared on the Atom mailing list [1][2]. But I believe the solution to that problem can be generalised in such a way as to help the forces of standardisation across the whole web.

Proposal

When a client receives a malformed server response it MAY (SHOULD?) notify the resource that it is broken, by sending a ERR request, identical in all ways except for the ERR method to the original request, plus a couple of extra ERR specific headers:

ERR should probably be limited to certain specific types of errors, including things like broken XML, XML encoding incorrectly specified in the header, etc. This is to be fleshed out...

[GregStein] I would recommend using XML-element-style naming for the error code. For example: atomerr:invalid-xml. It is also highly inadvisable to put human-readable text into the HTTP headers. There are strict length limits, and the headers also have a restricted character set. Instead, the body should be an XML document specifying all the information. (that is: lose all the custom headers) [HenryStory] added Error-ContentLength, to allow for a message body.

EXAMPLE:

Imagine the following request: 

GET /index.xml HTTP/1.1
Host: example.com
Connection: keep-alive
User-Agent: BlogEx
Accept: text/xml

for which the broken response happens to be 

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/xml
Server: SomeServer/2.1
Content-Length: 55
Date: Wed, 23 Jun 2004 15:36:05 GMT

<?xml version="1.0" encoding="iso-8859-1" ?>
<pløtz/>

The response is broken though clearly interpretable. Clients will therefore attempt to accommodate the standards due to market pressure. Market pressures are close to physical laws in their ferocity. We cannot change them. As a result more an more such breakages will occur, and the standards will be left in the dust of this vicious whirlwind [2]. In any case fighting against it is going to be very tiresome.

Much easier is to require clients to at least send an ERR response to the resources if they are going to bypass the standards. If you allow us to imagine a future where resources are intelligent enough to fix themselves, we can see how this can help the web heal itself.

Here is an example of the clients message: 

ERR /index.xml HTTP/1.x
Host: example.com
Connection: keep-alive
User-Agent: BlogEx
Accept: text/xml
Error-Message: XML is of incorrect content type
Error-Content-Type: text/simple
Error-Code: XXXX
Error-Spec: RFCXYZ,sec 3; RFCXXX, sec54
Error-Date:  Saturday 19 June 2004, 18:05:30 GMT (whatever encoding)
Error-Method: GET
Error-ContentLength: 52

The Mime type of the content was text/xml. This requires the content to be in ASCII format, but we found some UTF-8 characters in the message. 
We could interpret the message at present but will not necessarily be able to do so in the future. Please refer to RFCXXX for more information.

Impacts

  1. More general than PaceServiceError

  2. Backward compatible

This proposal could very well already work with the current web architecture, without any problem. I have tried it myself: 

hjs@bblfish:0$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ERR /index.html HTTP/1.1
Host: bblfish.localhost
Message: invalid XML

HTTP/1.1 501 Method Not Implemented
Date: Sat, 19 Jun 2004 10:10:37 GMT
Server: Apache/1.3.29 (Darwin)
Vary: accept-language,accept-charset
Allow: GET, HEAD, OPTIONS, TRACE
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

14c
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>501 Method Not Implemented</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
ERROR to /index.html not supported.<P>
Invalid method in request ERROR /index.html HTTP/1.1<P>
<HR>
<ADDRESS>Apache/1.3.29 Server at bblfish.local Port 80</ADDRESS>
</BODY></HTML>

Clearly this is not the response we want in a web that has adopted this proposal, but it allready has a correct side effect: namely it adds an error message in my apache error log. 

[Sat Jun 19 12:10:45 2004] [error] [client 127.0.0.1] Invalid method in request ERR /index.html HTTP/1.1
This probably not the only thing future web servers will do, but it is compatible with the spirit of the request.
[GregStein] actually, the resource responded quite properly. It told you in the Allow: header what methods it accepted, and you went and sent something else :-) When you initially perform an action on the reosurce (a GET or a PROPFIND or whatever), then an Allow: header will be sent, which then tells you whether you can bother dealing with reporting an error.
[HenryStory] good point. That demonstrates the opt in nature of the service. Servers don't have to accept the ERR method if they don't want to know. My guess is that it will prove such a small price to pay, that nobody will want to switch it off, once generally in place.

Pros

Cons

Notes

Note this is a fledgling proposal, and will clearly need some growing up. Currently the proposal is in a general form that applies to all the web. It could also be narrowed down to work for Atom only. In the mean time whether it is general or Atom only is indeterminate.

CategoryProposals