This was my conclusion as well. Can anyone think of any best practices for indicating that an entire server is busy?
-Justin On Wed, 2005-06-15 at 17:59 -0700, Kumar C. wrote: > 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" <[EMAIL PROTECTED]> > To: "Justin Chapweske" <[EMAIL PROTECTED]> > 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/ > > > > > > > > -- Justin Chapweske <[EMAIL PROTECTED]>
