[As individual.]

On 05/11/2011 10:25 AM, Richard Alimi wrote:
[...]
Plus, Table 1 in draft-ietf-alto-protocol could be updated to
match the requirement as follows:

   | E_OVERLOAD           | 503              | ALTO server overloaded  |

This is certainly possible, but I'm not sure whether this is a good
idea.  Up to now, the status code here was intended to be for the
ALTO-layer only (e.g., problems with the request syntax, asking for an
invalid cost type even though the client was told that it was not
available).  It seems to me like the overload case is more of an
server concept that we should handle purely in HTTP if at all
possible.

Richard: Sure, sounds reasonable.  More inline.

I see no mention that Location can't appear in a 5xx response:
   http://tools.ietf.org/html/rfc2616#section-14.30

Under the spec for the 5xx error codes (and 503 in particular), I
don't see anything that says one can't use a Location header:
   http://tools.ietf.org/html/rfc2616#section-10.5
Indeed, for 503 it suggests that a server can use the Retry-After
header to indicate when it should be retried. It doesn't seem that far
of a leap to suggest an alternate location as well.

Let's make sure; simply putting a Location header in the 503 may
not cause browsers to follow it.  Probably best to see what Ben
or Martin say.

Regarding the Retry-After header, I don't know whether or not the
HTTP user agents (browsers) honour it uniformly.  In a certain sense,
the Retry-After header leads to a sawtooth behaviour at a server,
with the server alternating between large incoming traffic load
and no incoming traffic load.  This has been shown to cause problems
in SIP, but I am not sure whether I can simply attribute the
same problems to HTTP as well.  We should seek the counsel of
some HTTP folks on this, too.

I would tend to think that 307 is more of an HTTP-layer concern, and
that we don't need to mention it in the status code table.  The
dependency on RFC2616 should be enough to advise clients that they
should follow redirects.

OK; sounds good.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email protected]
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to