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" <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/
> >
> >
> > 
> 
> 
-- 
Justin Chapweske <justin@chapweske.com>

Received on Wednesday, 15 June 2005 13:18:45 UTC