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 <[email protected]>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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
