HTTP 503 Clarification

RFC 2616 says the following:

"10.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a temporary
overloading or maintenance of the server. The implication is that this
is a temporary condition which will be alleviated after some delay. If
known, the length of the delay MAY be indicated in a Retry-After header.
If no Retry-After is given, the client SHOULD handle the response as it
would for a 500 response.

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection."

I'm hoping you guys can help clarify the semantics of 503.  I see two
different ways that it can be interpreted:

1) A 503 response on a URI indicates that the particular URI is
currently unavailable and to retry after a certain period of time.
Other URIs on the same host may still be accessed by the requesting
client, just not the one that returned the 503.

2) A 503 response on a URI indicates that the entire server is
unavailable, and the client should not try to contact any URIs on that
servers until the retry after period has expired.

Each of these definitions has their own set of problems.  I would assume
that the authors had #2 in mind when they wrote the RFC, but since that
time, servlet and scripting environments have become widely deployed, so
you can often have scenarios where one application (such as search) may
be overloaded while another application on the same box may be just
fine.  If you interpret 503 as #2, then any application that is
overloaded will effectively cause a denial of service on other
applications on the same box.

Thus #1 seems like a safer assumption, because a given URI should really
only speak for itself.  But then a new issue arises: How does the server
indicate that it actually is fully overloaded and that requests to any
URI on the host should back off?  

One could do a heuristic backoff where if you receive consecutive 503's
from multiple URIs on the host, then you should back off.  Another
approach would be to do a temporary redirect to a resource like /503
that always returns a 503 with a retry-after, but I don't see anything
in the Retry-After semantics that would actually cause the client to
retry the original source that performed the redirection.

I appreciate any ideas you folks have for clarifying this situation.

-Justin

Received on Tuesday, 14 June 2005 19:00:12 UTC