
New HTTP Codes - alcuadrado
https://tools.ietf.org/html/draft-nottingham-http-new-status-02
======
ck2
Summary:

    
    
      428 Precondition Required
      429 Too Many Requests
      431 Request Header Fields Too Large 
      511 Network Authentication Required
    

I've been using _414 Request-URI Too Long_ for 431 and _503 Service
Temporarily Unavailable_ for 429

~~~
ra
Apart from the obvious semantics, what's the difference between 428 and 412?
(412 - precondition failed)

~~~
jsn
AFAICS, 412 is only meaningful when the request did specify a precondition
(which failed), while 428 means that the request didn't specify some
precondition (which was required by server).

------
pavpanchekha
These all seem immediately practical status codes that add semantics I've been
wanting. Great! In particular I am happy about the 429 Too Many Requests
header, as every time I've done rate throttling I've had to quibble over what
code to actually send back.

~~~
i386
What code did you use? I've typically used a 408 in a throttling use case but
it never seemed to fit well (our client handled this response from our server
with an exponential back off so we were not relying on another client to
handle it correctly).

~~~
caf
503 seems the most appropriate of the current codes ("The server is currently
unable to handle the request due to a temporary overloading or maintenance of
the server. The implication is that this is a temporary condition which will
be alleviated after some delay.")

~~~
catwell
Twitter uses "420 Enhance Your Calm" (...)

A new error code is definitely needed.

~~~
marcomonteiro
This made me lol...literally!

------
stygianguest
A bit offtopic, but does anybody know what typesetting system was used to
produce this document? It looks like troff manpages. Is that what is used for
RFC documents as well? I love the oldschool look of it.

~~~
p4bl0
It was created using rfcmarkup[1], a tool made by the ietf. A quick look at
the source of the page in the "generator" meta tag would have told you that
(that's how I just found out) :-).

[1] <https://tools.ietf.org/tools/rfcmarkup/>

------
antimora
I wish HTTP requests submitted time zone information.

~~~
zb
It has been proposed several times. 2008: <http://tools.ietf.org/html/draft-
sharhalakis-httptz-05>

1995 - shot down because (paraphrasing) "I don't need this so neither should
you":
[http://www.hpl.hp.com/personal/ange/archives/archives-95/htt...](http://www.hpl.hp.com/personal/ange/archives/archives-95/http-
wg-archive/0521.html)

The general consensus seems to be that since this can never be all things to
all people, we can't ever implement it. To me it seems like this is crying out
for a Worse is Better solution.

~~~
mnot
I think we'll see this discussion come around again soon; maybe it'll stick
this time.

------
Robin_Message
511 seems a little pointless -- browsers can treat it differently, but if the
intermediate gateway intends to be malicious, then it won't return 511 anyway.
The only useful thing I can see is avoiding accidents/attacks on the gateway
compromising its clients.

~~~
modeless
It has nothing to do with security, but it's not pointless. It tells the
client that this response did not come from the server it attempted to
contact. This is especially useful for non-browser clients that will otherwise
simply choke on the 302 redirect normally used for this purpose, but it could
also be useful for browsers to present a better UI for signing on to the
internet.

My only concern is that 511 could be seen as legitimizing the practice of
putting silly click-through terms-of-service roadblocks on free wi-fi (making
it impossible for devices to connect without a human operating a web browser),
but since people are doing it anyway we might as well support it properly.

~~~
Robin_Message
Ah, I get it. Thanks to you and bostonvaulter2.

It'd be interesting to see whether adding authentication/sign on to a protocol
like DHCP would fit better. The hijacking of HTTP, while it obviously works
well in the default case, seems nasty and this error code fixes the wrong
problem. Better to have a DHCP field that tells you to visit a specific
website to log in; then the OS could display that website when you connect to
the wireless. A further advantage of putting it into the connectivity
protocols is it makes automatic payment and negociation by the client's
software possible—for example, connecting to the cheapest wifi in range.

~~~
deno
This seems rational, but it’s too much complexity for too little gain. If no
one have solved this problem in the last 10 years, it won’t happen now.

~~~
nitrogen
There are some problems worth solving that take longer than 10 years to figure
out. Given time, a standard for discovering and connecting to a commercial
network will emerge. Cell phones already have something like this with their
preferred roaming lists, and AIUI long-haul telecoms will switch call routing
and pricing on the fly based on other telecoms' pricing and routing changes.
It's a matter of getting the standard designed, ratified (optional step),
widely adopted by commercial access point manufacturers, then deployed on end-
user devices.

------
aninteger
Isn't this something that the http server handles? I am not in web development
except for basic php and cgi scripts. Are people actually writing web app code
to dictate what http code comes back on each request?

~~~
politician
Yes, sometimes the correct response is not an HTML page, but an error code
(e.g. 301 Moved Permanently, 302 Found are used to implement redirects).

~~~
ataggart
And sometimes the correct response is an error code _and_ an HTML page, e.g.,
401 Unauthorized and an ajax login page that reloads the current URL.

------
ericmoritz
Whelp I guess this needs updating now,
[https://github.com/basho/webmachine/raw/master/docs/http-
hea...](https://github.com/basho/webmachine/raw/master/docs/http-headers-
status-v3.png)

------
rwolf
Today I learned about If-Match. 428 Precondition Required looks great!

------
afhof
429 looks to me as if it might be addressing aggressive http pipelining, but I
was under the impression that most browsers have pipelining turned off.

~~~
_pdeschen
Both Firefox and opera offer pipelining while it is deactivated on chrome
(next release will have it on by default).

------
billpg
Shouldn't 429 (Too many requests) be a 5xx code?

~~~
snorkel
In general 4xx errors are problems with the request, and 5xx errors are
operational issues with the server/network

~~~
njharman
Too continue. It's "you're sending ttoo many requests" not "server is
overloaded/getting too many requests". Hence it's a client error 4xx, and not
server 5xx.

~~~
billpg
Put that way, it makes sense. Thanks.

------
edoloughlin
One quibble. Perhaps I don't quite get the philosophy behind these, but
wouldn't it be more useful to have a uniform structure to the responses. E.g.,
how useful is it to the average user to get a human-readable response for 428
when it's likely to be consumed by an app (i.e., JS) which would have to parse
the suggested <p> tag?

~~~
johns
You can return any content type you want and you should use content
negotiation to return the type the client is expecting. The HTML descriptions
are only suggestions.

------
netghost
429 Too Many Requests is really great for APIs, hopefully http clients start
supporting this.

------
a5seo
428 seems interesting as a way to serialize objects and store them client-
side, but assure the version stays consistent with the server. Or am I
overthinking it?

------
worldimperator
Can't wait to set browser dependent status codes :-D

------
textgoeshere
Can I start using any of these codes right now? It looks like this is still a
draft. Thanks!

------
dochtman
What happened to 430?

~~~
dochtman
Asked Mark Nottingham on Twitter, 430 is used in this other draft RFC:

<http://tools.ietf.org/html/draft-nottingham-http-pipeline-01>

(It's 430 Would Block.)

------
afdssfda
511: 'Unknown clients then have all traffic blocked, except for that on TCP
port 80, which is sent to a HTTP server (the "login server") dedicated to
"logging in" unknown clients, and of course traffic to the login server
itself.'

Ugh. Couldn't this be more generic?

~~~
gwillen
That section is descriptive of current practice. The semantics of 511 are the
previous section.

------
bromagosa
OMG really? Do we want to make HTTP even bigger? Don't we want to dump it for
good and look for something more suitable to what the modern web needs
instead?

~~~
Hoff
Rewriting a large and complex enterprise-class application is tough enough,
and a task that can variously (and expensively) fail.

Rewriting the whole of the World Wide Web?

Your replacement had better have a solid compatibility and migration path with
"legacy" HTTP, and provide a substantial improvement over what HTTP and the
existing tools provides, and clients and a migration path for a majority of
the platforms and tools and browsers and embedded browsers and embedded web
servers in use, and the budget and the time to make the replacement push.

~~~
sanxiyn
Google is trying: <http://www.chromium.org/spdy>

~~~
stanleydrew
SPDY isn't really intended to replace HTTP I don't think, it's just speeding
it up quite a bit. All the messages exchanged between client and server are
still HTTP when using SPDY.

~~~
wvenable
No, SPDY replaces HTTP but keeps many of the same high-level semantics. The
messages are not HTTP; for example, the headers are a binary format and
compressed which isn't possible with HTTP.

~~~
stanleydrew
Well technically HTTP as an application-layer protocol is unchanged. So I
don't really understand your comment. The messages are HTTP. Whether the
headers are compressed by an underlying protocol (such as SPDY) doesn't seem
to be relevant.

~~~
wvenable
An application layer protocol is the layer above TCP and defines the formats
of those messages over that transport. Other application layer protocols are,
for example, FTP, DNS, and SMTP. SPDY and HTTP have completely different (and
incompatible) message formats even though they are meant for the same task.
And it isn't HTTP tunneled through SPDY; there are significant differences.

For example, although SPDY supports HTTP methods (GET, POST, PUT) the method
and parameters are specified as headers in the request. Also, all the header
names are lower-cased in SPDY. The client and server don't communicate by a
single stream as in HTTP but instead communicate in frames over the stream
that can contain multiplexed requests and responses.

At the very high level, you might be able to build an API that could handle
web requests and responses over HTTP or SPDY interchangeably but that API
isn't "HTTP".

~~~
stanleydrew
I don't really want to argue about the semantics of OSI and what is or isn't
an application layer protocol. I'll just point you to Google's own diagram of
where SPDY fits in which is in the "SPDY design and features" section of the
whitepaper here: <http://www.chromium.org/spdy/spdy-whitepaper>.

Here's the text from that section:

"SPDY adds a session layer atop of SSL that allows for multiple concurrent,
interleaved streams over a single TCP connection.

"The usual HTTP GET and POST message formats remain the same; however, SPDY
specifies a new framing format for encoding and transmitting the data over the
wire."

~~~
wvenable
That is an old (and obviously inaccurate) summary. You can read the protocol
document here:

[http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-
dra...](http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1)

Check out the "Main differences from HTTP" section. It's clearly _not_ the
same format as HTTP. Whatever they mean by "GET and POST message formats
remain the same" it's not what you're thinking it means.

There's no confusion about the "semantics of OSI" -- you can't take a client
that talks only HTTP and get it talk to a server that talks only SPDY (and
vice-versa). They are different application level protocols, period.

~~~
stanleydrew
The "Main differences from HTTP" section says this:

"SPDY is intended to be as compatible as possible with current web-based
applications. This means that, from the perspective of the server business
logic or application API, nothing has changed. To achieve this, all of the
application request and response header semantics are preserved. SPDY
introduces a "session" which resides between the HTTP application layer and
the TCP transport to regulate the flow of data."

This even explicitly says that SPDY resides underneath the HTTP application
layer.

So from the point of view of e.g. GMail, it is making HTTP requests via
XmlHttpRequest still is it not? And from the point of view of my Django
application sitting behind some future apache/nginx SPDY module I will still
be accepting HTTP requests and responding with HTTP responses will I not?

It seems like SPDY sits in the same layer as SSL/TLS in HTTPS. It doesn't
replace HTTP, merely changes how the messages are transported over the wire.
To use your logic, you can't point an HTTPS-only client at an HTTP server and
have it work or vice-versa, and yet I quote from wikipedia:

"HTTP operates at the highest layer of the OSI Model, the Application layer;
but the security protocol operates at a lower sublayer, encrypting an HTTP
message prior to transmission and decrypting a message upon arrival.
__Strictly speaking, HTTPS is not a separate protocol __, but refers to use of
ordinary HTTP over an encrypted SSL/TLS connection."

~~~
wvenable
> So from the point of view of e.g. GMail, it is making HTTP requests via
> XmlHttpRequest still is it not?

No, it's making SDPY requests. It is, however, making that difference
insignificant to the application developer using the xmlHttpRequest API. HTTP
is a protocol not an API. This is exactly what the paper says; the protocol is
designed to make the API differences very minimal.

> And from the point of view of my Django application sitting behind some
> future apache/nginx SPDY module I will still be accepting HTTP requests and
> responding with HTTP responses will I not?

No, Django doesn't talk HTTP -- Django talks WSGI or CGI. That hides many of
the details of the protocol in use -- I imagine that you could run Django with
a server that sends/receives web requests over FTP. That doesn't make FTP into
HTTP.

SPDY does not sit in the same level as SSL. With SSL, HTTP packets are
tunneled through it. SDPY replaces HTTP; there is no fully formed HTTP message
inside. If SPDY was merely multiplexing and compressing HTTP streams in
frames, I would agree that it would be like HTTPS. But SPDY doesn't contain
HTTP streams; it's all right there in the document.

~~~
lloeki
> No, Django doesn't talk HTTP -- Django talks WSGI or CGI. That hides many of
> the details of the protocol in use -- I imagine that you could run Django
> with a server that sends/receives web requests over FTP.

I don't know how you would make e.g that[1] work on FTP. Basically you would
end up encapsulating HTTP _inside_ FTP, not using one in place of the other.

A CGI script takes raw (yet conveniently split by the web server) HTTP data
from ENV vars and stdin, and outputs HTTP data directly to stdout. Django
HttpRequest and HttpResponse object merely provides a convenient helper for
that and does not actually abstract anything. The web server pipes the
response as is straight to the client via TCP (unless there is SSL, where it
will just obliviously encrypt the stream).

To comply with that, as SPDY is a replacement to HTTP, mod_spdy transcodes
stuff live [2].

[1] [https://docs.djangoproject.com/en/dev/ref/request-
response/#...](https://docs.djangoproject.com/en/dev/ref/request-
response/#django.http.HttpRequest.META) [2] <http://code.google.com/p/mod-
spdy/wiki/Design>

