Even though not everyone is aware of it, at the heart of the internet is the Hypertext Transfer Protocol (HTTP) and its extension, the HTTP Secure (HTTPS) protocol. Even though concept of hypertext, which is essentially structured electronic text and media with links that allow establishing connections between documents, was developed in the 1960s, we had to wait almost three decades, when the networks were already developed enough, to get the first public specification of the protocol that enabled the transfer of said documents over communication networks. HTTP/0.9 was born in 1991, and with it, the World Wide Web (WWW or W3). Now we are all very familiar with the idea of web pages, to the point that almost everyone, every day, opens a browser and access them.
Managing changes
The protocol is in constant evolution, and so there are changes. The process of proposing, managing and implementing them is done through technical documents known as Requests For Comments (RFC), managed by the Internet Engineering Task Force (IETF). Those contain all the specifications required to analyze, refine and evaluate the proposed modifications. When they are released, they contain a description of the protocol that is detailed enough so any software developer can implement the system, that will be able to interconnect with other systems through the network, regardless of the nature of the tools used to create said software or the computer that is running it. The current most widely used version of HTTP is HTTP/1.1, which was developed in 1997 with the last revision happening in 2014. The IETF releases the standards in an open way, so anyone can have access to them. This philosophy is one of the factors has enabled the internet to become ubiquitous. HTTP/2 is already developed, but it will take some time until it is broadly used.
Status codes
The transfer of the documents is done on a conversation. The user requests a document using the client, which is usually a browser, and the server answers with what is called a response. Many conditions can happen during this process, and hence the standard reflects all possible outcomes of said conversation through the use of status codes, that are part of the response. One example with which many people are familiar is the status code 404, which means ”Not Found” for when the document can’t be found in the server. Some other examples are 200 – ”OK”, when everything goes right or 410 – ”Gone”, when a resource is removed from the internet and the user should not try to access it anymore. But one of the status codes rises over the rest, and it is the status code 418.
But… What if you are a teapot?
The status code 418 started as part of an April Fools joke. RFC 2324 was submitted in April the 1st, 1998 by Larry Masinter of the IETF. It defines a protocol to control, monitor and diagnose coffee pots, extending HTTP. It was called Hypertext Coffee Pot Control Protocol (HTCPCP/1.0). As part of the status codes, it included the code 418. The official definition is:
> *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.
This is so deeply buried in the internet folklore that, what was originally intended as a joke or a satire to dismiss the creation of badly designed HTTP extension protocols is very difficult to remove nowadays. Tries have been made, and many people have actually opposed them, like ”The Save 418 Movement” http://save418.com. Even Google has an error page for 418 https://www.google.com/teapot and the Mozilla Developers Network (MDN) thoroughly describes the status https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418. As you can see, even the most seriously engineered and impactful products of mankind can have a side dish of humor.