Re: HTTP 503 Clarification

I guess we should consider it for the URI rather than for the full service. 
It is upto the application to apply the logic whether the server is busy or 
specific URI is busy.

----- Original Message ----- 
From: "Mark Nottingham" <mnot@mnot.net>
To: "Justin Chapweske" <justin@chapweske.com>
Cc: <www-talk@w3.org>
Sent: Wednesday, June 15, 2005 5:10 AM
Subject: 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 Thursday, 16 June 2005 01:31:09 UTC