Re: Proposal for an HTTP ERR method

Whether this method is unnecessary is what we are trying to determine.

Is there a standard for finding a bug reporting uri? Because the Atom 
community is developing one [1]. And we would like to avoid every 
service having to re-invent error reporting, as this is keeping us off 
our task of specifying the Atom Syntax and API. Since every consumer of 
XML is faced with the ietf and w3c standards that state that one should 
*not* consume badly formed responses, everyone is going to need to be 
able to report errors if we don't want market pressures to lead us down 
the path of incompatible and broken implementations as html did.

The problem with having to find a specific error service uri, is that 
this requires one or more extra requests to other uri, many of which 
may themselves be broken. The advantage of ERR is that I don't need to 
know about any other URI to be able to notify it of the problem. I have 
already communicated with it, so I just need to notify it of the ERR.

There is currently a fundamental asymmetry in error reporting between 
the client and the server. Every request allows the server to report an 
error, but none allow the client to report an error back to the server. 
This is one reason this seemed like this proposal might help restore 
the imbalance.

Henry

[1] http://www.intertwingly.net/wiki/pie/PaceServiceError
On 23 Jun 2004, at 18:47, Justin Chapweske wrote:

> Why introduce a new unnecessary method when you could simply issue a
> POST to some bug-reporting URI associated with the server?
>
> If you're going to specify anything, submit a proposal to advertise
> feedback URIs using a RESTful approach, perhaps in HTTP response 
> headers
> such as Link, or within the (x)html itself as a <link> tag.
>
>> Fixing the problem will most probably require some human intervention.
>> But if you have just downloaded some broken XML and still have an open
>> connection to the server, why not just send an ERR at that moment to
>> the server. Then it can be clearly logged, and it is also clear what
>> the problem is about.
>
> -- 
> Justin Chapweske - Founder, Onion Networks
> http://onionnetworks.com/
> 651-340-8787
>
> Transfer large files 10x faster than FTP with Onion Networks' WAN
> Transport(tm).  http://onionnetworks.com/products_wantransport.php
>

Received on Wednesday, 23 June 2004 13:13:13 UTC