From the Annals of the Internet: HTCPCP and HTTP status 418
While working on a project to implement an API recently, I was reviewing HTTP status code definitions to determine appropriate error responses for our server to throw in different situations. One status code in particular caught my eye:
Obviously, I had to know more. So I took a quick dive down this internet rabbit hole to learn about the origins of HTTP, the IETF, RFCs, and other acronyms that make the world wide web possible.
Where do status codes come from?
Before we get to the specifics of the 418 status code, let’s unpack a couple of the acronyms above: the IETF and RFCs.
The Internet Engineering Task Force (IETF) is one of several volunteer, community-based organizations that develop and propose standards that have become foundational to how the internet is used, and how protocols are implemented across computers around the world. Per their website:
The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.
One of the primary concerns of the IETF is to establish standards that allow for consistent and efficient communication between computers over the internet. These standards are proposed in technical papers known as RFCs (Request for Comments). RFCs have a long and important history in relation to the internet — they’ve outlined things like the Internet Protocol (RFC 791) and the standard implementation for HTTP/1.1 (RFC 2616), which gave us many of the original HTTP status codes and provided details for how these status codes should be implemented by servers.
HTCPCP and the BREW method
On April 1, 1998, RFC 2324 was published outlining a proposal for a new internet protocol known as the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). A brief summary, quoting the RFC:
There is coffee all over the world. Increasingly, in a world in which computing is ubiquitous, the computists want to make coffee. Coffee brewing is an art, but the distributed intelligence of the web-connected world transcends art. Thus, there is a strong, dark, rich requirement for a protocol designed espressoly for the brewing of coffee. Coffee is brewed using coffee pots. Networked coffee pots require a control protocol if they are to be controlled.
This new protocol was proposed to be based off of HTTP:
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.
Part of the specification also included proposed status codes which a properly implemented HTCPCP server was meant to include in response to the BREW method if it was unable to process the request:
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.
In case you missed the publication date above — this paper was published as an April Fool’s day joke (which the IETF has a long history with). I strongly encourage reading the whole thing, it’s fantastic.
The current state of 418
Since the original RFC was written, several prominent platforms have implemented the 418 status code as an Easter egg. Node.js and ASP.NET both have default implementations for returning HTTP 418 status messages, and Google has a 418 status page:
The maker community has also attempted implementations of the HTCPCP with varying levels of success:
In 2017, a member of the IETF who oversees implementations of the HTTP protocol started a minor campaign, waged via issue reports on Github, to have several popular codebases remove their implementations of the HTTP 418 status. In response, teenage programmer Shane Brunswick started the #Save418 movement to keep the implementation in place. The movement was eventually successful, resulting in a IETF proposal to reserve the 418 status code officially.