I've always interpreted the HTTP as talking to a server about a resource - the response codes come from 'the server', so 'server unavailable' means the entire server. Why wouldn't a 40x response code be sufficient for the availability of individual resources? A system of "/servlet/search?query=foo" could be separated from "/servlet/login?user=foo" via a resource specific 40x or 307 (temporary redirect) response.
----- Original Message ----- From: "Justin Chapweske" <[EMAIL PROTECTED]> To: "Kumar C." <[EMAIL PROTECTED]> Cc: "Mark Nottingham" <[EMAIL PROTECTED]>; <www-talk@w3.org> Sent: Wednesday, June 15, 2005 6:15 AM Subject: Re: HTTP 503 Clarification > > 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]> > > >
