I also agree that the the following methods are probably quite compatible, and could each be used, in a certain default order perhaps:
- A response header specifying the location of an error URI
- ERRing the resource itself
On 4 Nov 2004, at 23:33, Asbj�rn Ulsberg wrote:
On Thu, 04 Nov 2004 16:50:07 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
Also, the utility of sending a request to the resource that's known to be busted could be nil.
In some cases, yes. But just because i.e. the XML is ill-formed, that doesn't mean the script that serves the XML document is completely broken.
I would like to add here that the fact that the resource may be broken won't stop the ERR message reaching the correct destination.
It will probably rarely be the resource itself that deals with the ERR message itself. Currently if you send such a message to an Apache web server, it will simply log a message in its log file. Similarly a slightly more intelligent web service would be able to send the messages for specific groups of urls to log files readable by the owner of the resources.
The ERR message is a flag that something is wrong with the resource. That can be useful information not just for the process that created the resource, but for all the caches along the way. It may be these caches after all that may have corrupted a perfectly good initial response. Automatically sending the response to some third URI is in that respect less RESTful.
Also, in many situations where the feeds are served dynamically, it's the same service that will receive the ERR as the one which is serving the feed. And since the service is the same, it doesn't matter whether you ERR the resource's URI or another one. It's simpler to just err the resource URI, though.
Also, if the client don't receive an expected result from the ERRed resource, it can maybe fall back to another ErrorURI (if defined at several levels). Just an idea.
-- Asbj�rn Ulsberg -=|=- [EMAIL PROTECTED] �He's a loathsome offensive brute, yet I can't look away�
Henry
