Re: ERROR verb

[Henry Story <henry.story@xxxxxxxxxxx>]

On 19 Jun 2004, at 17:16, Bill de hÓra wrote:

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

I guess I don't yet agree with you on this one.
How can we resolve the question of whether it is RESTfull or not? REST 
are some very general architectural principles...

How does sending an ERR differ from the HEAD query as far as 
restfulness goes.
It is uniform: it works for all resources.
It is visible: all the intermediaries can understand it.

I do notice now that one would have to add a special header to mention 
what the original Method was that returned the faulty representation:
Error-Method: GET

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

But it helps. We are  not going against the grain of the web. (If I am 
right and it is RESTful of course)

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

Yes. We need a good document to help our discussion of RESTfulness . I 
just read Fielding's Phd thesis, quickly I admit, but it does not 
strike me that this is not RESTfull.

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

Would you put that in a GET request? We don't want to GET the resource 
again. What if the resource we downloaded was just 100MB long?

> cheers
> Bill