Re: ERROR verb

[Ryan Tomayko <rtomayko@xxxxxxxxx>]

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