I stumbled across an interesting StackOverflow thread earlier this week. I had to read it a few times to notice what bothered me: it turns out that there is a status code for HTTP 418 "I'm a teapot". Why in the world would HTTP need such a status code? I'd never heard of this before, and it got me wondering: whoever thought this up, and why? Were they trying to make a point, or just having a little fun? What does it mean?
Nothing, as it turns out. Or maybe it does mean something. Come along with me as I dive headfirst into a silly (or not-so-silly) Internet joke and try to work out if it has any deeper meaning.
Brewing Coffee with HTTP
HTTP 418 I'm a teapot was specified in a document called RFC 2324 in 1998, published by the Internet Engineering Task Force (IETF). RFC 2324 describes the implementation of a Hyper Text Coffee Pot Control Protocol (HTCPCP), which extends HTTP and "permits the full request and responses necessary to control all devices capable of making the popular caffeinated hot beverages". The document justifies extending HTTP like so:
HTTP 1.1 ([RFC2068]) permits the transfer of web objects from origin servers to clients. The web is world-wide. HTCPCP is based on HTTP. This is because HTTP is everywhere. It could not be so pervasive without being good. Therefore, HTTP is good. If you want good coffee, HTCPCP needs to be good. To make HTCPCP good, it is good to base HTCPCP on HTTP.
(Seriously, read the whole thing, the justifications it uses are hilarious to anyone with a working knowledge of how the Internet is constructed).
RFC 2324 thoroughly describes the process of brewing coffee via HTCPCP, right up to and including the kinds of error codes the specification can return:
418 I'm a teapot
Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.
The whole document reads like a big joke, a gag that the IETF is in on (which makes sense, considering it was released on April Fools' and the IETF has a history of publishing such things). Of course, the Internet responded in kind, with varying "implementations" of the protocol, including ones by Google and StackOverflow. Node.js supports it natively, and Mozilla has a long-standing bug that asks for full support of the HTCPCP standard.
So, clearly, the rest of the web is in on this little joke too. And that's all this is: a joke. Right?
Maybe not.
Joke, Or Satire?
The author of RFC 2324 is Larry Masinter, who on his personal page added a little footnote in which he described the protocol as:
...An April 1 joke with a serious purpose -- to spoof ways in which HTTP had been extended inappropriately.
This is all the information I could find about what he meant to show by writing this document, so it's difficult to determine what he actually wanted to accomplish by writing this RFC (if, indeed, he intended to accomplish anything other than making a joke). He seems to express regret that HTTP is being extended so widely, without much thought as to why any of these new status codes should exist. But what does he mean by "inappropriately"?
As best as I can tell, Masinter's purpose in writing this RFC was to point out the dangers of over-extending HTTP for increasingly-specific purposes. We don't need an HTTP derivative specifically for brewing coffee anymore than we need an HTTP derivative for a vending machine. In essence, Masinter's warning was that we should avoid making implementations that are too specific to our domain, because in doing so we reduce the amount of reusability the solutions have, thereby forcing other people to reinvent the wheel if they encounter a similar problem in a different domain. He intended RFC 2324 to be satire, not just a joke.
To be perfectly clear, I'm extrapolating a lot of Masinter's intent from a single sentence, and I could be way off the mark. But I think he was hitting on a common problem in software development: the tradeoff between a given implementation being specific enough to fit the domain vs. being generic enough to solve a wide variety of problems. Seems to me that Masinter was in favor of the more generic solution, and given that HTTP is a critical piece of infrastructure for the Internet, it's hard to find fault with his (supposed) stance.
So, where does that leave us with HTTP 418 and it's supposed deeper meaning? In my humble opinion HTTP 418 is a joke, but one that comes with a relatable message: don't built a hyper-specific implementation when a more generic one will do just fine.
Or it could be just a joke. In which case, you can bet that the next Web API project I build will handle this code. Better keep an eye out, future service clients!
UPDATE 11/2/2015: I posted an off-the-cuff question on Twitter and got a response from Larry Masinter himself!
@ExceptionFound Satire: make fun of many bad HTTP extensions that had been proposed.— Larry Masinter (@masinter) November 2, 2015
Happy Coding!
