Proposal for an HTTP ERR method

SUMMARY:
  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.

BACKGROUND:
   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 to 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]. 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:
Note this is a fledgling proposal, and will clearly need some growing  
up.

When a client receives a malformed server response it SHOULD(CAN?)  
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:
	-Error-Message: a human readable error message
     -Error-Date: the date the request was initially sent
     -Error-Method: the method (GET, POST, ...) of the original request.

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...

EXAMPLE:

GET /index.xml HTTP/1.x
Content-encoding: text/xml; charset=UTF-8
Accept: */*
Accept-Encoding: gzip, deflate;q=1.0, identity;q=0.5, *;q=0
Accept-Language: en-us, ja;q=0.62, de-de;q=0.93, de;
...

<?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.  
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
Content-encoding: text/xml; charset=UTF-8
Accept: */*
Accept-Encoding: gzip, deflate;q=1.0, identity;q=0.5, *;q=0
Accept-Language: en-us, ja;q=0.62, de-de;q=0.93, de;
Error-Message: XML is of incorrect content type
Error-Code: XXXX
Error-Date:  Saturday 19 June 2004, 18:05:30 GMT (whatever encoding)
Error-Method: GET
...


ADVANTAGES:

1. RESTfulness

Proxies and other intermediaries can join in to make the Web a more  
standard place.

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 the 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 ERROR /index.html HTTP/1.1


REFERENCES

This came out of a discussion on the atom mailing list.

-a concise explanation for the need for the ERR method:
        http://www.imc.org/atom-syntax/mail-archive/msg05146.html
-originally proposed here:
        http://www.imc.org/atom-syntax/mail-archive/msg05112.html
-a long discussion on #rdfig where I try to respond to all the  
questions thrown at me
         
http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-06 
-19.html#T14-48-59

Received on Saturday, 19 June 2004 13:56:46 UTC