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: Dan Anderson <dan-anderson@cox.net>
Date: Wed, 19 Oct 2011 23:34:27 -0500
Message-ID: <CAN5uf-SzNmeV7b75-ML4vVbG9U3QZkexPdL3rW0bPK+6BHeSHA@mail.gmail.com>
To: "Thomson, Martin" <Martin.Thomson@commscope.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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. ...

I'm not sure about 3xx (that might be better - interesting at least),
but between these two, it seems more like the client erred by talking
before it was authenticated.  The server hasn't erred (this is its
function) and when it receives a valid request from an authenticated
client it is presumably perfectly capable of fulfilling it.  The
scenario doesn't seem that different, to me, from a 407 (different
baggage - same story).

On Wed, Oct 19, 2011 at 5:35 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> Yes, plus the response is not authoritative (not from the server that the client is expecting a response).

I agree, but I'm not sure why this makes 5xx appropriate.  502 and 504
on the surface kind of point in that direction - but, IMO, those are
specific cases where the client can do nothing to address the issue.
This is different, IMO, in that appropriate action by the client can
rectify this situation.

As Martin says, I'm sure that there are multiple ways to skin this cat
- but, IMO, in real world usage/troubleshooting scenarios it is more
useful to point the finger at the client instead of at the server.

Thank you
Dan
Received on Thursday, 20 October 2011 04:35:04 GMT

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