Re: "Too Busy" Error Needed

"Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 9 Jun 1994 23:49:22 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406091446.aa23282@paris.ics.uci.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: fielding@simplon.ICS.UCI.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: "Too Busy" Error Needed 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

Kevin Altis wrote:
> 
> I believe a fundamental difference between the 500 and 503 error response
> is that the 503 response is machine readable regardless of any extra text
> or html the server might return with the response as content. That is, a
> client or proxy that receives a 503 message knows that the remote server is
> currently unavailable because it is too busy. If you just wanted a human
> readable response, then a 500 response would suffice as long as the Web
> client displayed that message to the user, not all clients do.

Absolutely!  I know my client doesn't because it passes the response code
between routines as a number and saves it for later referral.
For my application, the actual text response is useless.

> While, I don't wish to create a separate server response for every
> eventuality (Henrik's point is well taken) I do believe that we need some
> way of conveying machine readable semantics in the server response as a
> fundamental piece of quality of service.
> 
> Since the headers are currently a flat information space, the obvious thing
> to do is create a new header response for something like a busy remote
> server. Perhaps the guideline for adding a new response should be whether
> making the response machine readable makes any sense versus just displaying
> a response to the user which requires them to take some action. This
> implies that clients always display a 5xx response to the user if an
> automatic action is not possible. This fits with our current model for
> response codes in the 2xx, 3xx, and 4xx classes as well.

That brings up a question I was grappling with yesterday...

I am building the start of a generic WWW library for Perl (i.e. given
any URL and method name, it will perform that method using that URL's
scheme and return the response as if it was an HTTP response).  The library
will start with support for HTTP and FILE and more schemes will
be added (collaboratively, I hope) over time.

The question is:  what error code should be passed back if a particular
scheme has not yet been implemented?  This is similar to the
"501 Not Implemented" response from a server, but it needs to be clear
that the error is due to a limitation of the client.

Currently, I am using "601 Not Implemented".  Would 101 be better?
Should there be a block of numbers set aside for internal client responses?
How do other clients handle this?


...Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                   (fielding@ics.uci.edu)
    <A HREF="http://www.ics.uci.edu/dir/grad/Software/fielding">About Roy</A>