Re: ERROR verb

[Bill de hÓra <bill@xxxxxxxxxx>]

Henry Story wrote:

> So let me make a first attempt at a rock solid case:
> [...]


> Why this over a specialized solution with a URL for reporting problems? 
> This solution is the most conformant to the REST architecture of the 
> web. Not only can clients send ERR messages, proxies could also do this, 
> leading to a virtuous circle of compliance.

As I've said I don't believe this solution is RESTful. It relies on 
server sided magic and breaks at least two REST tenets - visibilty 
and uniformity, never mind a dubious programming technique!


> Furthermore ERR already works by default. 
> An ERR request will already 
> log an error in the error log of the most popular web server, as 
> expected. Empirical research is needed for other servers. But I no of no 
> server that does not generate log files!

Not the point at all - the point is the extra-protocol assumptions 
you need to make to get this to work as per design. It doesn't 
matter whether every web server on the planet actually has log files 
- what matters is that you've extended web architecture by claiming 
every web server must have log files.

On one hand the claim is the solution is RESTFul - but visibilty and 
uniformity have been broken. On the other hand ERR relies completely 
on assumptions about how HTTP servers are implemented, how people 
manage their HTTP servers and so on - but not on HTTP. Whether you 
agree or disagree with me on the details is beside the point, these 
are not mutually consistent positions!

Lump programming with gotos on top of all that and I'm not sold on 
this.

Would you consider an X- header pointing to an error resource 
instead of ERR?

cheers
Bill