Re: "Too Busy" Error Needed

• Mail folder: WWW Talk Apr 94-present
• Next message: Michael LaTorra: "Help!"
• Previous message: Nick Arnett: "Re: ADMINISTRIVIA"
• Maybe in reply to: Robert Denny: "Re: "Too Busy" Error Needed"

Errors-To: listmaster@www0.cern.ch
Date: Thu, 9 Jun 1994 19:35:06 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <m0qBnfu-0003diC@ibeam.intel.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: altis@ibeam.jf.intel.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: altis@ibeam.jf.intel.com (Kevin Altis)
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
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0

At  6:32 PM 6/9/94 +0200, Robert Denny wrote:
>If the user gets back some obscure "connection refused" message, he's gonna
>think maybe the server's broken, the network is broken, his client is
>broken, the URL is broken, he is broken, who knows?  I hate that. Kinda
>like "SYNTAX ERROR".
>
>My approach tries its hardest to deliver a rational, easy to understand
>alert message, and do it quickly so the incoming connection requests won't
>pile up to the network package's limit and cause an ugly network failure
>message to be delivered to the client.

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.

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.

ka