Re: HTTP 503 Clarification

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" <justin@chapweske.com>
To: "Kumar C." <kumarc@jataayusoft.com>
Cc: "Mark Nottingham" <mnot@mnot.net>; <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" <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 Thursday, 16 June 2005 04:07:30 UTC