Subject: [alto] Error codes in ALTO

From: Richard Alimi <[email-masked]>
Date: Fri, 15 Mar 2013 07:34:53 -0700

There is a discussion as to whether the ALTO client needs to interpret HTTP
status codes.  I've started this thread to discuss that.

Here's my view:

We now have a REST-ful protocol and made a conscious decision to go this
way.  REST-ful protocols are built upon making requests and following links
to other resources. (This is why we restructured the existing protocol to
remove all references to "ALTO Request" and "ALTO Response".)

Therefore, the ALTO protocol is *not* a traditional client-server protocol
like TCP, but is instead an encoding for HTTP resources that allow clients
to discover the type of information described in the initial problem
statement.

Replicating HTTP status codes to the ALTO layer sounds like we are
replicating a lot of what HTTP does already.

I understand that someone using ALTO should not be burdened with HTTP
status codes.  My difference in opinion is that I think that should be an
implementation detail hidden behind the API an ALTO Client exposes.

Thanks,
Rich

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 15 Mar 2013 14:51:08 +0000

Rich,

I also would like not to replicate and, for the sake of discussion, say, return (-1) or bytes read to the ALTO layer.

But the current status is more complicated. We already have a mixed bag of things crossing layers.

We already replicate ALTO error codes into HTTP (ALTO->HTTP direction)

"   The HTTP status codes corresponding to each ALTO Error Code are
   defined to provide correct behavior with HTTP intermediaries and
   clients.  When an ALTO Server returns a particular ALTO Error Code,
   it MUST indicate one of the corresponding HTTP status codes in

Table 1 in the HTTP response. "

And we ask clients to interpret HTTP status codes  (HTTP->ALTO direction)

"  o  Return an HTTP 503 ("Service Unavailable") status code to the ALTO
      Client.  As indicated by [RFC2616<http://tools.ietf.org/html/rfc2616>], a the Retry-After HTTP header
      may be used to indicate when the ALTO Client should retry the
      request."

As far as your last point…

"My difference in opinion is that I think that should be an implementation detail hidden behind the API an ALTO Client exposes."

If something does not change the on the wire protocol or reaction to it (such as, e.g., congestion control) would be okay to categorize it as an implementation  issue. But in this case it does, and that's why we are having this discussion.  Otherwise, yes, I agree with you.

Let's find some wording.

Thanks,

Reinaldo

From: Richard Alimi <[email-masked]<mailto:[email-masked]>>
Date: Fri, 15 Mar 2013 07:34:53 -0700
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [alto] Error codes in ALTO

There is a discussion as to whether the ALTO client needs to interpret HTTP status codes.  I've started this thread to discuss that.

Here's my view:

We now have a REST-ful protocol and made a conscious decision to go this way.  REST-ful protocols are built upon making requests and following links to other resources. (This is why we restructured the existing protocol to remove all references to "ALTO Request" and "ALTO Response".)

Therefore, the ALTO protocol is *not* a traditional client-server protocol like TCP, but is instead an encoding for HTTP resources that allow clients to discover the type of information described in the initial problem statement.

Replicating HTTP status codes to the ALTO layer sounds like we are replicating a lot of what HTTP does already.

I understand that someone using ALTO should not be burdened with HTTP status codes.  My difference in opinion is that I think that should be an implementation detail hidden behind the API an ALTO Client exposes.

Thanks,
Rich
_______________________________________________ alto mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Fri, 15 Mar 2013 12:44:50 -0700

On Fri, Mar 15, 2013 at 7:51 AM, Reinaldo Penno (repenno) <[email-masked]
> wrote:

>  Rich,
>
>  I also would like not to replicate and, for the sake of discussion, say,
> return (-1) or bytes read to the ALTO layer.
>

Right.  So one other way would be to not specify this, and leave it up to
servers to pick an HTTP status that seems reasonable.  The general idea
here was "make sure we still get reasonable behavior when we talk through
intermediaries", but if there are better ways to handle this than that
would be great.

>       Client.  As indicated by [RFC2616 <http://tools.ietf.org/html/rfc2616>], a the Retry-After HTTP header
Yes.  I tend to disagree with having this statement in here for exactly the
reasons you point out, but it was added after AD feedback saying it was
needed to meet the ALTO requirements.

>  "My difference in opinion is that I think that should be an
> implementation detail hidden behind the API an ALTO Client exposes."
>
>  If something does not change the on the wire protocol or reaction to it
> (such as, e.g., congestion control) would be okay to categorize it as an
> implementation  issue. But in this case it does, and that's why we are
> having this discussion.  Otherwise, yes, I agree with you.
>

In general, HTTP isn't as cut-and-dry as TCP (to which you are drawing an
analogy).  HTTP is more expressive in terms of flexibility for the server
and gives a richer set of status codes.  In other words, the standard
socket API can tell you whether something was successfully delivered to the
OS for delivery, or you successfully received something from the OS.   HTTP
allows applications built on top of it to say things like "try again
later", "Here are some other URIs you might try instead", "access denied",
etc.  ALTO (via HTTP) allows servers to be more flexible, and thus allows
more flexible deployment scenarios.

Rich

>
>  Let's find some wording.
>
>  Thanks,
>
>  Reinaldo
>
>
>
>
>   From: Richard Alimi <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>  There is a discussion as to whether the ALTO client needs to interpret
> HTTP status codes.  I've started this thread to discuss that.
>
>  Here's my view:
>
>  Therefore, the ALTO protocol is *not* a traditional client-server
> protocol like TCP, but is instead an encoding for HTTP resources that allow
> clients to discover the type of information described in the initial
> problem statement.
>
>  _______________________________________________ alto mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/alto
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 22 Mar 2013 20:19:26 +0100

Coming back to this, after some research...

> -----Original Message-----
> 	I also would like not to replicate and, for the sake of 
> discussion, say, return (-1) or bytes read to the ALTO layer.
> 
> 	But the current status is more complicated. We already 
> have a mixed bag of things crossing layers. 
> 
> Right.  So one other way would be to not specify this, and 
> leave it up to servers to pick an HTTP status that seems 
> reasonable.  The general idea here was "make sure we still 
> get reasonable behavior when we talk through intermediaries", 
> but if there are better ways to handle this than that would be great.

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

=> Spec -14 seems fine regarding that detail.

> 	      Client.  As indicated by [RFC2616 
> <http://tools.ietf.org/html/rfc2616> ], a the Retry-After HTTP header
> Yes.  I tend to disagree with having this statement in here 
> for exactly the reasons you point out, but it was added after 
> AD feedback saying it was needed to meet the ALTO requirements.

In addition to error HTTP 400, the ALTO spec right now further requires special actions on HTTP 503 ("Service Unavailable") and HTTP 307 ("Temporary Redirect") status codes.

For HTTP 307, the ALTO spec must exactly define whether the redirection URI provides the same resource type, or whether it is possibly different (e. g., it could be the resource directory of another server with other maps). From an implementation perspective, both variants are very different. In the former case, the HTTP library can internally realize the redirect (e. g., using CURLOPT_FOLLOWLOCATION in the curl library); this is probably the simpler variant because it is totally transparent. Alternatively, the redirection has to be handled by the ALTO logic, which is more heavyweight. Both variants are possible, but an implementor must know whether to activate automatic redirect support in HTTP libraries such as curl, or not. 

=> The ALTO spec must specify exactly what type of URI HTTP 307 returns.

For HTTP 503, my current understanding is that an automatic "retry-after" is not supported by several HTTP libraries or clients, i. e., an ALTO implementation will possibly have to implement the retry timer etc. on its own. Still, it seems reasonable to me to rely on a standard HTTP error code for that. The motivation is as follows: If more HTTP libraries support this error code internally in future, this would at least simplify the design of future ALTO implementations.

=> Using HTTP error code 503 as in spec -14 seems reasonable to me.

Michael