Re: Open Questions on using the Atom Feed Format for search results

[Robert Sayre <sayrer@xxxxxxxxx>]

On 9/28/05, Darrick Brown <dbrown@xxxxxxxxxxxxxx> wrote:
> For example, what error should I expect back from an APP
> server if I PUT an updated Entry to a previously existing entry URI that
> has since been deleted?  Should I expect "400 Bad Request", "404 Not
> Found", or "406 Not Acceptable"?

400 would mean the request was syntactically invalid, so that's out.
406 would mean an 'Accept*' header was sent that the server can't
match. For example, the client sends "Accept: image/svg" to a resource
which only has a jpeg representation.

> 2616 certainly does not cover this.

I suggest that it does, and the response should be 404 or 410,
depending on whether the server wants to communicate that an entry
previously existed at that location (the spec cannot make that
decision, because it's not a technical one). I wouldn't expect it to
be different than the response to a GET if there is nothing located at
the address.

> Are any other client developers concerned about this or do most everyone
> feel that section 4.5 of the APP draft is sufficient?

In the example Darrick gives above, I can't think of anything my
client could accomplish /automatically/ from a specific 4xx status
code in this case. 4xx or 5xx is all I need to know.

Having a coherent message to present to the user would be nice, and I
have found there is need for standardized error messages intended for
the end-user. For example, "this server can't accept entries with
category FOO (unless you add it)". This is resolvable by the user, but
I wouldn't look to communicate that the HTTP control data. I would
look for a place to communicate errors in the message body:

http://www.franklinmint.fm/2005/09/03/draft-sayre-atompub-xhtml-micro-00.html#herror

Darrick, is there a capability you're looking to automate here, or is
more of key to look up a message to display to an end-user (if there
is one).

Robert Sayre