Subject: Atom error pages

From: Graham <[email-masked]>
Date: Mon, 25 Jul 2005 10:32:11 +0100

It's far too late for this, but how should Atom servers produce/ 
clients deal with error pages? Feedster regularly changes its search  
results feed to a single entry "Search results temporarily offline"  
feed document (RSS guid "http://www.feedster.com/"), and I think  
served with HTTP status 200. This seems the wrong behavior for so  
many reasons. What should they be doing in Atom?

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 25 Jul 2005 10:51:47 +0100

Graham wrote:
> 
> It's far too late for this, but how should Atom servers produce/ clients
> deal with error pages? Feedster regularly changes its search  results
> feed to a single entry "Search results temporarily offline"  feed
> document (RSS guid "http://www.feedster.com/"), and I think  served with
> HTTP status 200. This seems the wrong behavior for so  many reasons.
> What should they be doing in Atom?

Serving it with a 503.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Mon, 25 Jul 2005 11:05:06 +0100

On 25 Jul 2005, at 10:51 am, Bill de hÓra wrote:

>> clients

And what should the client do?

(assuming a rich client that keeps an archive of entries)

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 25 Jul 2005 11:19:51 +0100

> And what should the client do?

Ah. Display the returned entity body + the retry-after header. Or show a
default from the client if there's none.

cheers
Bill

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 25 Jul 2005 13:38:45 +0200

> (assuming a rich client that keeps an archive of entries)

It should not consider the archive affected in any way. 5xx are
transient errors. If it keeps a record of such failures at all,
they are not to be considered part of the feed content. There is
nothing that 5xx has to do with the content of pages that might
at other times be available at the same URL.

It should just indicate to the user (or whatever is downstream)
that an HTTP-level error occured, via whatever means would be
appropriate. As Bill says, a desktop aggregator would usually
show the HTML page returned with the error or a default – but of
course it should under no circumstances appear as if this was
part of the feed content.

This is really just ordinary interpretation of HTTP.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 25 Jul 2005 12:49:01 +0100

> This is really just ordinary interpretation of HTTP.

I might see where Graham is coming from. Graham are you talking a case
where the feed/entries are being elided with not-available messages?

cheers
Bill

---

From: Graham <[email-masked]>
Date: Mon, 25 Jul 2005 13:29:58 +0100

> where the feed/entries are being elided with not-available messages?

I think so. The problem with using HTTP error codes is that in many  
clients the result is far less pretty. For example, in Shrook you get  
a warning sign next to the feed name, which when clicked produces a  
generic error message for the HTTP code.

The thing is, publishers want errors to be prettier and better  
explained. Returning a 200 and a feed document containing an error  
message entry produces predictable results in all clients, with the  
side effect of polluting the feed history.

The results of doing both (an HTTP error code and a custom Atom error  
document) need to be predictable. Whereas most web browsers will  
display a custom HTML error page (IE excepted), most Atom clients  
won't do anything with the body of a non-200 response (I think).

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Jul 2005 09:20:25 -0400

> won't do anything with the body of a non-200 response (I think).

The same problem exists in the protocol. Right now, you'll see
typepad.com return a document that looks like this:

<error>some text...</error>

We could have them return Atom entries instead. *shrugs

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Jul 2005 10:56:51 -0700

This is a problem that is easily generalizable to a lot more than just 
Atom apps.  I've been thinking lately that a somewhat generic "standard" 
XML format for reporting errors associated with a common stylesheet for 
rendering may be a good approach to handle error responses rather than 
false entries in the feed or the rather ad hoc approaches I've been 
seeing.  Perhaps something along the lines of:

  HTTP/1.1 5xx Some Error
  Content-Type: application/error+xml
  Content-Length: nnnn

  <error xmlns="urn:some-namespace">
    <code scheme="{URI indicating error code scheme}">{scheme defined 
error code}</code>
    <summary>{human readable summary of the error</summary>
    <action>{URI indicating an action taken by the server in response to 
the error}</action>
    {namespaced extension elements}*
  </error>

Examples of action element values could include URI's that indicate that 
the failure was logged, the IP address of the requester was recorded, 
related activities were rolled back, the Earth exploded, etc

Thoughts?

- James

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 25 Jul 2005 19:20:52 +0100

>    {namespaced extension elements}*

What should happen:

 - when the http response is 200 and the code in the XML is '503'?

 - when the http response is 200 and the code in the XML is 'snafu'?

 - when the http response is 400 and the code in the XML is
'java.lang.ClassNotFoundException'?

Putting codes in two places and/or two layers in a response raise
similiar issues to putting methods in two places and/or two layers in a
request. In the general case - what should happen when the http response
is X and the code in the XML is 'Y' - I think is a non-trivial problem.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Jul 2005 11:57:34 -0700

>is X and the code in the XML is 'Y' - I think is a non-trivial problem.
Yes, I'm struggling with this also.  Part of my brain wants to make 
<code /> optional and strictly informational in favor of the HTTP 
response code.  However, another part of my brain wants this mechanism 
to be generally reusable across other transports (e.g. XMPP) making it 
difficult to rely on consistent error codes in the lower layers.  I 
think the clear solution is that the HTTP response code should take 
precedence in this case.  If the <code /> value does not match up with 
that code, then the content producer is just being silly and the 
consumer has to figure out on their own what to do.

Does it make sense to require that <error /> MUST NOT be returned when 
the HTTP response code is anything but 4xx or 5xx?

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 25 Jul 2005 20:58:38 +0200

> Thoughts?

I kind of like it, but I’m not sure it would be the best choice
in all cases, and thus doubt it would gain much traction.

In the case of Atom, I think it would be nice if we could have
producers generate Atom Entry Documents to go with the response,
and have consumers treat this as a transient entry, to be
remembered only until they next refresh the feed. The entry and
its associated HTTP status should be quite enough for most use
cases.

Heck, even having user agents allow viewing the (usually HTML)
document currently commonly returned with an error response would
be adequate for probably the majority of cases.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 25 Jul 2005 21:30:23 +0200

* James M Snell <[email-masked]> [2005-07-25 21:06]:
> However, another part of my brain wants this mechanism to be
> generally reusable across other transports (e.g. XMPP) making
> it difficult to rely on consistent error codes in the lower
> layers.  I think the clear solution is that the HTTP response
> code should take precedence in this case.

And then you get a mess like we now have with the charset of an
HTML document served over HTTP. Admittedly, that is complicated
particularly by the existence of the ill-begotten <meta>
abomination. But the lesson we learned is that the accuracy of
metadata is inversely proportional to its distance from the data,
and I don’t think there are exceptions to this. Whenever you
duplicate things in multiple layers, the most application-
specific layer should always have highest precedence; all else is
asking for endless headaches.

Regards,

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 25 Jul 2005 20:51:09 +0100

James M Snell wrote:
> precedence in this case.  

Precedent: That didn't work out for content-encoding.

I think SOAP faulting enables clients to ignore the HTTP code altogether.

I don't know how valuable reusable error codes of this kind are - my
assumption has been they're specific to application protocols (which is
wandering into protocol neutrality transport/transfer territory).

> If the <code /> value does not match up with

My guess is that they'll take the served XML at face value and drop the
HTTP code. In any case, putting consumers in a position to have to
figure out what to do, by design, is not sound, I would want to be able
to emit an 'Indecipherable Architecture Error' - but to who?

> the HTTP response code is anything but 4xx or 5xx?

It does, but it doesn't give enough constraints to narrow the problem.
The problem is still "what should happen when the http response is X and
the code in the XML is 'Y'?"  You only need one value for each to reduce
robustness.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Jul 2005 16:16:02 -0400

> the code in the XML is 'Y'?"  You only need one value for each to reduce

There's no special version of HTML for error pages. Let's use an Atom
Entry Document.

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Jul 2005 13:26:15 -0700

Returning an atom entry document would likely work fine when one is 
requesting an Atom feed document, but it could lead to confusion if the 
expected non-error result is itself an atom entry document.  How does 
one differentiate the expected non-error result from the error result.

---

From: Graham <[email-masked]>
Date: Mon, 25 Jul 2005 22:10:47 +0100

On 25 Jul 2005, at 9:26 pm, James M Snell wrote:

> requesting an Atom feed document, but it could lead to confusion if  
> the expected non-error result is itself an atom entry document.   
> How does one differentiate the expected non-error result from the  
> error result.

The HTTP code?

Graham

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 25 Jul 2005 23:40:58 +0200

> many reasons. What should they be doing in Atom?
I think there are two cases here:

    * when publishing Atom feeds or entries through HTTP, an HTTP error
      code with an Atom body is fine (at least for me). As far as
      aggregator behavior is concerned, I think they could show the
      entry as part of the feed but discard it as soon as the feed can
      be retrieved without error.
    * when using the Atom Publishing Protocol's POST or PUT, it might be
      worth defining an error document type to tell the client why its
      document has been refused (e.g. POSTing an Atom Entry with a
      base64-encoded MSWord content and the server only accepts the
      three "basic" content types; or an Atom Entry with more than one
      category to a server supporting only one category per entry; or
      using an extension "control information" not supported by the
      server: it should be able to tell the client which one has been
      refused; etc.)

-- 
Thomas Broyer

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 Jul 2005 23:45:11 +0200

Thomas Broyer wrote:
> ...

You may want to check...

	<http://greenbytes.de/tech/webdav/rfc3253.html#method.preconditions.and.postconditions>

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Jul 2005 15:47:48 -0700

Graham wrote:

>> the expected non-error result is itself an atom entry document.   How 
>> does one differentiate the expected non-error result from the  error 
>> result.
>
>
> The HTTP code?
>
> Graham
>
Well yeah... there's obviously that, but part of the issue was what 
happens if the http response is 200 but the payload is trying to 
communicate that an error occurred.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 26 Jul 2005 06:48:04 +0200

* James M Snell <[email-masked]> [2005-07-26 01:00]:
> part of the issue was what happens if the http response is 200
> but the payload is trying to communicate that an error
> occurred.

Nothing happens. 200 means no error occured. Returning 200 when
an error did occur is broken and should be fixed on the producer
end. Period. I don’t want to see any compromise on this, ever.

If you want to serve over HTTP, it’s your responsibility to be a
good citizen. There are a lot of people who aren’t, of course;
and some have fair, if invalid reasons for their misbehaviour.
In those cases, there’s good reason to listen to them and try
to accomodate them; but the way to do that is not by legalizing
their transgressions.

Remember the Web Accelerator bruhaha? There are fair reasons for
service implementors to want non-idempotent GETs; but legalizing
non-idempotent GETs is not the way to accomodate them.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Jul 2005 06:51:52 +0200

> end. Period. I don’t want to see any compromise on this, ever.

++++1

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Jul 2005 22:20:32 -0700

>non-idempotent GETs is not the way to accomodate them.
;-) works for me.  I'm really not advocating one way or the other on 
this stuff... just throwing things out there to help develop the 
conversation a bit.  In that vein, what would an example error entry 
response look like? just a simple basic entry with no fancy schmancy 
extension elements required? 

- james

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Jul 2005 09:44:12 +0100

James M Snell wrote:
> 
>  In that vein, what would an example error entry

Something that contains nothing a machine might be able to automatically
process or use as a control flag, say like, a response code... ;)

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Wed, 27 Jul 2005 22:33:01 -0700

>process or use as a control flag, say like, a response code... ;)
Ok, ok, I get it... ;-) Not sure I like it tho, but... ah well.

- James