Re: [alto] Error codes in ALTO

Hi all,

After a while, IETF seems to catch up on errors. Here is a just-posted
document related with HTTP error codes:
http://www.ietf.org/id/draft-nottingham-http-problem-05.txt

Richard

On Tue, May 7, 2013 at 3:41 AM, Ben Niven-Jenkins
<ben@niven-jenkins.co.uk>wrote:

> Michael,
>
> > A reasonable design of an ALTO (client) implementation separates HTTP
> processing from the ALTO protocol engine. The former is mostly a generic
> HTTP instance (e.g., interfacing the well-known curl library), while the
> latter realized the ALTO message parsing etc. In normal operation, both
> "layers" are mostly independent.
> >
> > However, the RESTful design requires that ALTO error messages have to be
> handled both in the HTTP layer as well as in the ALTO layer. Specifically,
> the HTTP layer will have to decide based on the HTTP error code whether to
> pass a response to the ALTO layer for further ALTO error message
> processing, whether to do something else, or whether to consider the query
> as an entire failure.
>
> It could also use the presence of an app/alto-error (or whatever the media
> type is) message body & punt that to the ALTO layer.
>
> Without an ALTO specific error response in the message body HTTP doesn't
> give much room for providing rich error responses anyway, so the ALTO layer
> would be rather constrained with what it can do with just a HTTP status of
> 4xx or 5xx as there is unlikely to be a 1:1 mapping between ALTO errors and
> HTTP status codes.
>
> Ben
>
> > That distinction is much simpler if the implementor knows the HTTP error
> codes that require further processing not only by the HTTP logic, but also
> by the ALTO logic.
> >
> > Thus, for interoperability it seems indeed useful that the ALTO protocol
> spec exactly defines the HTTP error codes for any ALTO error type (i.e.,
> error code 400 in spec -14). I don't see a good reason to change that - it
> would make the HTTP logic in an ALTO implementation more complex and less
> interoperable, because the implementor of a client has to guess what a
> server might return.
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>

-- 
-- 
 =====================================
| Y. Richard Yang <yry@cs.yale.edu>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================