W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Additional HTTP Status Codes - draft-nottingham-http-new-status-02

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 20 Oct 2011 20:46:31 +0200
To: Dan Anderson <dan-anderson@cox.net>
Cc: "Thomson, Martin" <Martin.Thomson@commscope.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20111020184631.GE21051@1wt.eu>
Hi Dan,

On Wed, Oct 19, 2011 at 11:34:27PM -0500, Dan Anderson wrote:
> Hi,
> 
> Thanks for your responses and insights.
> 
> On Wed, Oct 19, 2011 at 5:00 PM, Thomson, Martin
> <Martin.Thomson@commscope.com> wrote:
> > My guess: because there is nothing inherently wrong with the _HTTP_ request, a 4xx response might be misconstrued as an indication that it needs modification somehow.
> 
> With a 5xx it might be misconstrued to indicate that something is
> wrong with the server.
> 
> At least with a 4xx it points back to the client.  Who is, in this
> scenario, the one who has to go do something to fix the situation.
> 
> http://www.ietf.org/rfc/rfc2616.txt:
> 
> 10.4 Client Error 4xx - The 4xx class of status code is intended for
> cases in which the client seems to have erred. ...
> 10.5 Server Error 5xx - Response status codes beginning with the digit
> "5" indicate cases in which the server is aware that it has erred or
> is incapable of performing the request. ...

That's exactly what I was going to ask too. With 4xx, the client knows
it's the one who has to change something. With 5xx, it knows something
went bad on the server side (generally timeouts, connection errors,
lack of resource, etc).

BTW, any unknown 5xx will be treated as 500 (Server Error) which makes
it pretty clear to the client that the 511 is an uncaught error one the
server side. I find this quite confusing :-/

In my opinion, everything related to client authentication easily falls
in the 4xx class. It means "I won't perform this request unless you do
something on your side", which is the case.

There are many places where 5xx are actively monitored to proactively
detect a faulty server, here it could start to generate a number of
false-positives, or at least make the analysis and troubleshooting more
complicated.

Just my 2 cents,
Willy
Received on Thursday, 20 October 2011 18:47:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:48 GMT