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

From: Dan Anderson <[email-masked]>
Date: Wed, 19 Oct 2011 13:05:33 -0500

Hi,

I read this draft this morning and I have a couple of questions.

1.  Section 6:  Why is this a 5xx status code and not a 4xx status
code?  It seems to me like a client problem (failure to present
appropriate credentials) and thus more appropriate as a 4xx status
code.
2.  Section 3:  How does this relate to 409 and 412?
3.  Sections 3,4,5,6.1:  The HTML examples in these sections seem like
they should be left out in keeping with RFC2616 which, IMO more
appropriately, specifies only the status code and other optional and
required data items - not what the return page might look like.

Thank you for the opportunity to comment.

Thanks
Dan

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 Oct 2011 06:00:08 +0800

> appropriate credentials) and thus more appropriate as a 4xx status 

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.

I wonder if a 3xx response was considered.  Since the typical scenario involves redirection, it's not that much of a stretch to imagine 3xx.

I'm sure you could skin this particular cat any number of ways.

--Martin

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 19 Oct 2011 15:35:55 -0700

> 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.

Yes, plus the response is not authoritative (not from the server that the
client is expecting a response).

> I wonder if a 3xx response was considered.  Since the typical scenario involves redirection, it's not that much of a stretch to imagine 3xx.

I am not sure if we considered it or not -- it would be nice to make use
of the Location header field.  Mark?

....Roy

---

From: James Snell <[email-masked]>
Date: Wed, 19 Oct 2011 16:44:07 -0700

+1 on this... but... I'm wondering if the spec should take some care
to differentiate the "511 Network Authentication Required" and "407
Proxy Authentication Required" response codes. Strictly off the
language in the spec, the two responses are virtually identical, with
the only exception that the 511 Response does not require the use of
the Proxy-Authenticate header. It would seem to me that a 407 with a
Proxy-Authenticate using a hypothetical "form" auth scheme and a
Location header could be applied to the same purpose without requiring
the introduction of a new response code... e.g.

HTTP/1.1 407 Proxy Authentication Required
Location: http://foo.example.com/proxy_login
Proxy-Authenticate: form

Just a thought...

- James

On Wed, Oct 19, 2011 at 3:35 PM, Roy T. Fielding <[email-masked]> wrote:
> [snip]

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Oct 2011 13:48:40 +1100

> of the Location header field.  Mark?

I think it was discussed a long time ago, in the previous draft. We can't assume that existing clients will treat a 3xx with a Location as a redirect, so it's of limited value (now) to use 3xx.

Also, redirection status codes currently all have a semantic of "the thing you're looking for is over there." In this case, that wouldn't be true. I know that's not a codified semantic of 3xx, but it does lead to a one-of-these-things-is-not-like-the-other situation.

And, of course, we can always specify the use of Location on 511 (for what good it will do).

I'm not against 3xx, BTW -- just trying to reconstruct how we got here.

--
Mark Nottingham   http://www.mnot.net/

---

From: Dan Anderson <[email-masked]>
Date: Wed, 19 Oct 2011 23:34:27 -0500

Hi,

Thanks for your responses and insights.

> 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 <[email-masked]> 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

---

From: Dan Anderson <[email-masked]>
Date: Thu, 20 Oct 2011 00:15:42 -0500

Hi,

I kind of like that idea.

OT: It makes me wonder if something similar could be done to 401.

Thanks
Dan

On Wed, Oct 19, 2011 at 6:44 PM, James Snell <[email-masked]> wrote:
> It would seem to me that a 407 with a

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Oct 2011 16:18:42 +1100

I don't think that would be workable; 407 is specifically for proxies -- i.e., intermediaries interposed with the involvement of the client, not intercepting proxies. I have a suspicion that there will be clients whose code paths for 407 will behave badly if they're not expecting it on the wire. 

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 20 Oct 2011 20:46:31 +0200

Hi Dan,

> 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

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 21 Oct 2011 06:43:25 +0800

On 2011-10-21 at 05:46:31, Willy Tarreau wrote:
> 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.

The problem with 4xx is that it implies an error in the client.  But to imply that the "client" in this case - an _HTTP_ client - can do anything about the network authentication situation is where this line of reasoning falls down.  To infer fault in either HTTP client or HTTP server is disingenuous.

What we are looking for an "act of god" series (c.f. insurance contracts): 

  Nothing in inherent in the request (client) or the identified resource (server) caused this request to fail.

I'm reluctant to open the 6xx series for this sort of marginal case.  Looking at the commonly induced behaviour in these cases suggests 3xx (with or without Location:).  I'll freely admit that it's still weak, but it does avoid the more obvious pitfalls.

--Martin

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 21 Oct 2011 15:30:02 -0700

> I think it was discussed a long time ago, in the previous draft. We can't assume that existing clients will treat a 3xx with a Location as a redirect, so it's of limited value (now) to use 3xx.

I don't see why that matters -- if they don't redirect, then the content
will be displayed (just like 511).

> Also, redirection status codes currently all have a semantic of "the thing you're looking for is over there." In this case, that wouldn't be true. I know that's not a codified semantic of 3xx, but…

That wasn't true in the past.  I guess it might be now that we removed
305 (and ignored 306).  3xx was defined as "The client must take additional
action to complete the request."

> And, of course, we can always specify the use of Location on 511 (for what good it will do).

Not much.  The advantage of 511 could be that an authentication form
can be in the 511 content and not require an additional redirect,
though I personally prefer the redirect because it allows the
browser to use stored credentials or form-filling features to
quickly satisfy the portal.  OTOH, that does have some security
problems of its own.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Oct 2011 11:39:12 +1100

Like I said, I'm not necessarily against 3xx.

I'm a *bit* concerned that we've had a fair amount of attention on the latest draft, and there's a certain amount of momentum as a result.

If there's a tangible benefit to switching, that's great; however, it *looks* like there are arguments / reasons for all of the status codes (we started at 4xx, now 5xx, next 3xx? Perhaps we should consider 1xx too? ;)  So, all else equal, I'd rather just leave it as-is. 

In any case, if we are going to change, it should be done soon.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 21 Oct 2011 18:53:14 -0700

> In any case, if we are going to change, it should be done soon.

Yep... any chance you could add a few pages to redbot that responds
using different statuses, so we can see which pukes less on browsers?
I'd do it locally but am strapped for time at the moment.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 23 Oct 2011 16:49:08 +1100

> I'd do it locally but am strapped for time at the moment.

Not really a redbot thing, just a couple of .asis pages, I think.

  http://www.mnot.net/tmp/311.asis
  http://www.mnot.net/tmp/511.asis

I tested IE6/8/9, Safari 5.1.1, FF7.0.1, Opera 11.50 and Chrome (whatever it is now).

All of them displayed the text/plain of the 511 response.

All *except* Safari displayed the text/plain of the 311 response; it followed the Location header as if it were a redirect.

So, I don't think we can put this on 3xx with a Location header -- automatically following it without understanding the semantics is what we don't want, and if Apple's HTTP stack makes that assumption, pretty much an OSX program using HTTP won't see the benefit of this new status code.

It's a bit of a pity, as I agree it would be nice to surface this in the Location header. We (httpbis now) might want to tighten up the semantics of Location to make it clear that its semantics are attached to / activated by the status code; it alone doesn't signify a redirect.

Back to the status code, I think our options are:

511 + Location or a Link header (if we want to surface the link in headers)
311 + Link header (if we want to surface the link in headers)

As before, I'm slightly inclined towards 511 (could go either way on the link relation), but don't mind 311 (as long as we do so soon).

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 23 Oct 2011 00:05:02 -0700

> All *except* Safari displayed the text/plain of the 311 response; it followed the Location header as if it were a redirect.

Well, it is a redirect, so Safari is the only one not broken there.

> So, I don't think we can put this on 3xx with a Location header -- automatically following it without understanding the semantics is what we don't want, and if Apple's HTTP stack makes that assumpt…

Eh?  But I thought that is what we wanted.  In any case, an unknown 3xx code
is defined as falling back to 300, which has defined semantics for Location.
That was the whole point of suggesting 311.  But I guess it only works on Safari.

> It's a bit of a pity, as I agree it would be nice to surface this in the Location header. We (httpbis now) might want to tighten up the semantics of Location to make it clear that its semantics are…

3xx + Location was intended to signify a redirect -- the additional semantics
just explain why the redirection is occurring.  If a 3xx code does not want
an automatic redirect fallback, then it doesn't use Location.

> As before, I'm slightly inclined towards 511 (could go either way on the link relation), but don't mind 311 (as long as we do so soon).

Let's stick with 511.  I don't think we need a header if we don't want
the client to autoredirect.

Clearly, I have to spend some time writing a new explanation of the
status code classes.  I've received more feedback on the 5xx/4xx distinction
this week than for any of our other changes.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 23 Oct 2011 18:06:59 +1100

> this week than for any of our other changes.

Nice to see some good come from it, then.

Cheers,