On Fri, Mar 15, 2013 at 7:51 AM, Reinaldo Penno (repenno) <[email protected]
> 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.
>
> 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. "
>
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.
>
> 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."
>
>
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.
>
>
>
> 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.
>
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 protected]>
> Date: Fri, 15 Mar 2013 07:34:53 -0700
> To: "[email protected]" <[email protected]>
> 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 protected] https://www.ietf.org/mailman/listinfo/alto
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
