Re: HTTP 503 Clarification

I think your reading is about right. There are many instances in 2616 
where the scope of metadata (e.g., headers, status) are not 
well-defined, leading to this kind of problem.


On Jun 14, 2005, at 8:56 PM, Justin Chapweske wrote:

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

--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 15 June 2005 12:11:26 UTC