[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ERROR verb


That is exactly why I would specify that all the original headers of the request should be sent along in the ERR request and a special header
Error-Method: GET

needs to be added.

Henry

On 19 Jun 2004, at 21:24, Ryan Tomayko wrote:


I would like to add to Bill's remarks and suggest that discussion
around ERR thus far has assumed that a single resource maps to a
single representation. The Accept, Accept-Charset, Accept-Language,
and User-Agent request headers can all be used by the server to
respond with varying representations of the resource identified by the
requested URI. The URI alone may not be sufficient to notify the
server of the problem. For instance, if the application/atom+xml,
Shift_JIS, ja version of http://bla.com/feed is invalid, how does ERR
specify that? It might be possible to send the Content-Type and
Content-Language header values as request headers with ERR but now
we're really redifining the semantics of those headers within this
context.

Ryan

On Sat, 19 Jun 2004 18:05:14 +0100, Bill de hÓra <bill@xxxxxxxxxx> wrote:


Henry Story wrote:


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

REST is quite specific.

How does sending an ERR differ from the HEAD query as far as restfulness
goes.

Ok, I'll try

HEAD semantics are specified in HTTP, any web-accessible resource
will respond to it as specified; thus its uniform.

Note that this is not the same as saying; "X" is not in HTTP, but
because it's not, any web accessible resource will respond to it
uniformly, thus it's uniform. Oh and by the way, given what we know
about web servers this is a neat trick to stuff diagnostics into
their log files and whatnot - people can look there for issues
around borked Atom over HTTP encodings.

The latter part is what I mean by programming with gotos/side
effects or "magic". This is fragile imo.


It is uniform: it works for all resources. 

ERR does not work for all resources. If you claim that you can claim
*any* unspecified method is uniform - which is certainly a clever
play on words. But - it hasn't been even established it will work
for all web servers. And really, when we cut to it, this is a method
targetted at web servers not resources.


It is visible: all the intermediaries can understand it. 

No it is not visible - in fact its intended effect relies on it not
being visible. It depends on side effects and implementation details
of web servers. ERR is closer to cookies than HEAD in that respect.

But it helps. 

It helps an *Atom* use case. There are perhaps other less intrusive
and less fragile ways to help. I said earlier that this approach
(new method) is one of last resort and I asked if we thought we are
that point. Are we?


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.

I've tried to explain that it is not RESTful above.


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?

(You mean representation) This is what HEAD is for.

cheers
Bill