You are reading this somewhere. On your laptop or on your phone or in your email or RSS reader. If you’re reading this on the web, then this page was delivered from my server to you via a protocol called HTTP. There’s all sorts of fascinating things I can say about HTTP, but the important thing to know is that it’s one of the foundational technologies created by Tim Berners-Lee specifically for the web. When I broke down the component parts of the web in a previous post, I described HTTP like this:
HTTP is an incredibly straightforward protocol for sending and receiving webpages on the Internet. HTTP is also stateless. Stateless means forgetful, essentially “dumb.” Each time a client makes a request to a server, the server responds to that request. It has no memory of previous requests and no way of storing information for future requests. Browsers say, “I want this page,” and servers say “Ok, here it is.” The next time around, the whole process starts again from scratch.
That is, of course, if everything goes as planned. That’s hardly always the case though, so the browser needs some way to know how things are going. That’s where HTTP status codes come in. Status codes are a three digit number transmitted with each request that tells a story of how things went. For instance, if everything is normal and working, the status code is
200: OK. You may have come across a
404: Not Found error at some point in your life. That’s HTTP letting us know that the page you wanted doesn’t exist (for instance, here: https://thehistoryoftheweb.com/404).
There are dozens of status codes, and each tells a different story. The first number is often the most important.
5XX codes mean something went really wrong.
2XX codes mean things are generally okay.
3XX codes lie somewhere in the middle. And of all the status codes, only of them is a joke. Status code
418: I'm a teapot.
Satire is probably a better word for 418. That’s how its creator, Larry Masinter, has described it. It was included as part of RFC 2324, that Masinter published on April 1, 1998 (an RFC is basically a proposal for a new piece of Internet technology. If you want to know more, I’d recommend Darius Kazemi’s excellent blog 365 RFCs). The proposal was for a new protocol that extended HTTP called Hyper Text Coffee Pot Control Protocol (HTCPCP). HTCPCP was designed for the very specific time when a coffee pot needs to transmit documents over the Internet, and specifically “for controlling, monitoring, and diagnosing coffee pots”.
The date of publication is the most important part here. As some of you probably realized, RFC 2324 was published on April Fools Day. HTCPCP was a fake specification, not to be taken seriously. It’s not the first time April Fool’s day was used for a not-all-together-serious RFC and it wouldn’t be the last. Masinter’s protocol, however, had a fairly specific purpose, to satirize the many, to his mind similar, although serious, requests from the larger Internet community for extensions to HTTP that dealt in narrow and unrealistic implementations. Put simply, he wanted to show up the many bad Internet designs that had crossed his path by proposing an absolutely outlandish one.
As a side note, RFC 2324 is worth a quick read, if you’re interested in that type of thing. And not simply for how outrageous it is, but for how prescient. Compare the following excerpt from the RFC, again, written in 1998, with a search for “smart” coffee pots on Amazon that yields 900+ results.
Increasingly, home and consumer devices are being connected to the Internet… Consumers want remote control of devices such as coffee pots so that they may wake up to freshly brewed coffee, or cause coffee to be prepared at a precise time after the completion of dinner preparations.
The proposal may have been a bit silly, but years later, it strikes me as almost too on the nose.
Anyway, Masinter’s final bit of satire was a demonstration of short-sighted additions to status codes, which are meant to be enduring and as universal as possible. Instead, he introduced an error status code that was as narrow in scope as you can image.
418: I'm a teapot, indicating that the request is indeed not a coffee pot, but instead a teapot, and accompanied by the description “resulting entity body MAY be short and stout.” It was ridiculous and unnecessary, much like the other status codes Masinter had seen suggested over the years.
Of course, Masinter never really expected for the RFC to go much further than that. And most of it didn’t, except for a subtle reference to that 418 status code here and there. “Getting the reference” to the imaginary status code became something of a matter of pride in certain web developer circles. And because of that influence, the imagined status code slowly became real. It was hidden as a sort of Easter egg in a number of very serious and very real Internet technologies, including built-in support in programming languages, inclusion in the text editor Emacs, and even in bug reports submitted to Mozilla Firefox requesting proper support.
In 2017, Mark Notthingham, chairman of the IETF working group, made the astute observation that making use of the fictitious status code 418 in certain programming languages blocked it from being used in the future for a more necessary purpose. There are, after all, only 100 possible status codes that can be used for 4xx, so freeing up 418 could potentially be useful in the future, especially since this one started as a joke. He posted requests to several programming languages that support be officially removed.
The backlash was not at all what Nottingham expected. Seemingly overnight, developers rallied to intervene and block the status code’s removal. On the one hand, it was, essentially, just the butt of a joke. However, as many were quick to point out, the status code had a firm place in web history, and that its removal took that a way. 15 year old freshman and amateur coder Shane Brunswick made himself the de facto leader of the movement when he created the site Save418.com. In it, he affirmed that 418 was an integral piece of the web:
It’s a reminder that the underlying processes of computers are still made by humans. It’d be a real shame to see 418 go.
After enough pushback, Nottingham relented. He even went so far as to submit an RFC of his own that reserved the use of status code 418, which ensures that, though it won’t officially designate a coffee pot, it also can’t be used for something else in the future.
That’s not even the only status code with a story behind its number.
In December of 2008, Chris Applegate posted a blog post, There is no HTTP code for censorship, after a particularly aggressive blacklist managed by the Internet Watch Foundation led to a number of ISP’s blocking access to Wikipedia for a large number of users throughout the UK because of a single album cover that was flagged as obscene. Applegate expressed frustration for, among other things, the inability to distinguish between when a page is not working (such as with the 404 example above) and when it is working just fine, but being actively blocked or censored. His primary grievance, however, was with the blacklist itself.
Almost four years later, Terence Eden published his own follow up, There is no HTTP code for censorship (but perhaps there should be). In the post, Eden took Applegate’s argument one step further, making the case for a new status code that would cover censorship of sites by governments or ISP’s. In some cases, firewalls or network proxies may wish to indicate that they are unable to access a particular site. In others, such as mass censorship from governments, the site itself may want to indicate that everything on their servers is working perfectly fine and it is, in fact, human beings and not computers standing in the way of a particular request. Perhaps most importantly, a single status code that indicates some form of censorship could be tracked across the web programmatically that can help organizations gather data about how widespread it is.
Eden had a few suggestions for what this new status code could be, each with a different first number, since censorship kind of blurred the lines in terms of purpose. They included
112: Emergency. Censorship in action and
460: Blocked by Repressive Regime.
Eden’s post was published on June 8th. Three days earlier, author Ray Bradbury had passed away. His passing was still very much on people’s minds when one user on Slashdot suggested 451, as a sort of hat tip to Bradbury’s Fahrenheit 451, a fictional account of an oppressive regime. Less than a week later, status code 451 had an RFC of its own, submitted by Tim Bray (who some of you may know from his work with XML).
In 2015, 451 was officially approved by the Internet standards body IETF with the designation
451: Unavailable For Legal Reasons. Over the years, it has been used by NGO’s and journalists to track censorship across the globe. More recently, it’s been used by sites that refuse to comply with Europe’s new GDPR regulations, which has stirred up some controversy of its own.
So there you go, there’s some fun with HTTP status codes, for whatever that’s worth.