Re: Atom error pages

[James M Snell]

Bill de hÓra wrote:


James M Snell wrote:
 


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
   



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



 


Ok, ok, I get it... ;-) Not sure I like it tho, but... ah well.

- James

Re: Atom error pages

[Bill de hÓra]

James M Snell wrote:
> 
>  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

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

Re: Atom error pages

[James M Snell]

A. Pagaltzis wrote:


* James M Snell <[EMAIL PROTECTED]> [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,
 

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

Re: Atom error pages

[Julian Reschke]

A. Pagaltzis wrote:

* James M Snell <[EMAIL PROTECTED]> [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.
...


1

Best regards, Julian

Re: Atom error pages

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [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,
-- 
Aristotle Pagaltzis // 

Re: Atom error pages

[James M Snell]

Graham wrote:


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

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.



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

Re: Atom error pages

[James M Snell]

Bill de hÓra wrote:


James M Snell wrote:

 


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


  {scheme defined
error code}
  {human readable summary of the error
  {URI indicating an action taken by the server in response to
the error}
  {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.

 

Yes, I'm struggling with this also.  Part of my brain wants to make 
 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  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  MUST NOT be returned when 
the HTTP response code is anything but 4xx or 5xx?


- James

Re: Atom error pages

[Julian Reschke]

Thomas Broyer wrote:

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


You may want to check...




Best regards, Julian

Re: Atom error pages

[Thomas Broyer]

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?


Graham


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

Re: Atom error pages

[Graham]

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

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.


The HTTP code?

Graham

Re: Atom error pages

[James M Snell]

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.


Robert Sayre wrote:


On 7/25/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
 


James M Snell wrote:
   


Does it make sense to require that  MUST NOT be returned when
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.
   



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

Robert Sayre


 

Re: Atom error pages

[Robert Sayre]

On 7/25/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> 
> James M Snell wrote:
> > Does it make sense to require that  MUST NOT be returned when
> > 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.

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

Robert Sayre

Re: Atom error pages

[Bill de hÓra]

James M Snell wrote:
> Bill de hÓra wrote:
> 
>> James M Snell wrote:
>>
>>  
>>
>>> HTTP/1.1 5xx Some Error
>>> Content-Type: application/error+xml
>>> Content-Length: 
>>>
>>> 
>>>   {scheme defined
>>> error code}
>>>   {human readable summary of the error
>>>   {URI indicating an action taken by the server in response to
>>> the error}
>>>   {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.
>>
>>  
>>
> Yes, I'm struggling with this also.  Part of my brain wants to make
>  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.  

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

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?


> Does it make sense to require that  MUST NOT be returned when
> 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

Re: Atom error pages

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [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 
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,
-- 
Aristotle Pagaltzis // 

Re: Atom error pages

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2005-07-25 20:11]:
> 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,
-- 
Aristotle Pagaltzis // 

Re: Atom error pages

[Bill de hÓra]

James M Snell wrote:

>  HTTP/1.1 5xx Some Error
>  Content-Type: application/error+xml
>  Content-Length: 
> 
>  
>{scheme defined
> error code}
>{human readable summary of the error
>{URI indicating an action taken by the server in response to
> the error}
>{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

Re: Atom error pages

[James M Snell]

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: 

 
   {scheme defined 
error code}

   {human readable summary of the error
   {URI indicating an action taken by the server in response to 
the error}

   {namespaced extension elements}*
 

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

Graham wrote:




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?



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

Re: Atom error pages

[Robert Sayre]

On 7/25/05, Graham <[EMAIL PROTECTED]> wrote:
> 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).

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

some text...

We could have them return Atom entries instead. *shrugs

Robert Sayre

Re: Atom error pages

[Graham]

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?


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

Re: Atom error pages

[Bill de hÓra]

A. Pagaltzis wrote:
> * Graham <[EMAIL PROTECTED]> [2005-07-25 12:20]:
> 
>>And what should the client do?
>>
>>(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.

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

Re: Atom error pages

[A. Pagaltzis]

* Graham <[EMAIL PROTECTED]> [2005-07-25 12:20]:
> And what should the client do?
> 
> (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 // 

Re: Atom error pages

[Bill de hÓra]

Graham wrote:
> On 25 Jul 2005, at 10:51 am, Bill de hÓra 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?
> 
> 
> 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

Re: Atom error pages

[Graham]

On 25 Jul 2005, at 10:51 am, Bill de hÓra 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?


And what should the client do?

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

Graham

Re: Atom error pages

[Bill de hÓra]

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

Atom error pages

[Graham]

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