The Typo and the Teapot

Our internet is built on many standards. Thousands of pages of technical specifications that define how computers should talk to each other, how data should be formatted and how errors should be handled. These documents are usually precise and boring.

However, there are two things in HTTP that break this pattern.

One is a typo that has been around for almost 30 years. The other is a joke that became so beloved that it is now officially protected forever.

Let me tell you about both.

The “Referer” Typo

Every time you click a link on a website, your browser tells the next website where you came from. It does this through an HTTP header called the Referer header. But it is spelled wrong.

The correct spelling is “referrer” with two R’s. But in HTTP, it is “referer” with one R. And this is not some spelling difference or accepted variant. It is simply just wrong. Everyone knows it is wrong, and it has been wrong since 1992.

How It Happened

In 1992, Phillip Hallam-Baker was working on the HTTP specification. He was adding a new header that would let servers know which page sent the user their way. This is especially useful for analytics, tracking and understanding how people navigate the web.

He wrote up the proposal and spelled “referrer” as “referer”.

Nobody caught it. Or if they did, nobody thought it was worth fixing. By the time anyone pointed it out in March 1995, the typo had already been implemented in browsers, servers and probably countless other systems around the world.

Roy Fielding, one of the HTTP specification authors, simply acknowledged the typo and moved on.

Except some people did care. Because now everyone implementing HTTP had to remember to spell it wrong. Documentation had to spell it wrong. Code had to spell it wrong. Developers learning web programming would get confused when their correctly-spelled “Referrer” header did not work.

The Aftermath

By May 1996, when HTTP/1.0 was being documented in RFC 1945, the misspelling was made official. They even added [sic] next to it in later specs, admitting that they know it is wrong, but it is too late to fix it now.

And it really was too late. Changing it would have broken millions of websites, servers, proxies, analytics tools, everything that relied on that header. The cost of fixing a typo was just too high to justify this effort.

So we live with it.

I’m a teapot

Now for the fun one.

On April 1st, 1998, Larry Masinter published RFC 2324: the Hyper Text Coffee Pot Control Protocol, or HTCPCP.

It was just a joke. A completely absurd technical specification for controlling internet-connected coffee pots. The whole document is filled with coffee puns. “There is a strong, dark, rich requirement for a protocol designed espressoly for the brewing of coffee”.

The protocol even defined new HTTP methods like BREW and headers like Accept-Additions: Cream; Sugar. And it introduced a new HTTP status code: 418 I’m a teapot.

The Error That Shouldn’t Exist

According to RFC 2324, if you try to use HTCPCP to brew coffee with a teapot, you get back a 418 status code with the following body:

HTTP/1.1 418 I'm a teapot
Content-Type: text/plain

I'm a teapot. The resulting entity body MAY be short and stout.

That last part is a reference to the children’s song “I’m a Little Teapot”.

It was supposed to be a one-day April Fools’ joke, but developers loved it.

It Spread Everywhere

People started implementing 418 as an easter egg in real systems. Node.js added support for it, Python did too, Go included it, ASP.NET, even Google used it in joke responses.

Returning 418 I'm a teapot became a way to tell automated bots or scrapers “I know what you’re doing and I’m not going to help you”. Some APIs used it as a playful way to reject malformed requests.

Getting the reference became a way to tell other developers that you know the joke. It simply became a shared joke, connecting people who worked on completely different projects.

The Battle to Save 418

In 2017, Mark Nottingham, chair of the IETF HTTP working group, decided that having a joke status code in the official spec was unprofessional. He proposed removing 418 from Node.js, Go, Python, and other implementations.

Aaand as you can imagine, internet lost its mind.

A 15-year-old developer named Shane Brunswick created save418.com, a website dedicated to keeping the status code alive. Within hours, it went viral, with thousands upvoting it on Reddit. Even on Twitter, #save418 hashtag started trending. Developers from around the world united to protect a joke.

The argument wasn’t just that “it’s funny.” People also pointed out that 418 had become part of web history. Removing it would erase a piece of internet culture, and honestly, it wasn’t hurting anything by existing.

Nottingham ended up listening. Instead of removing 418, he did something better: he submitted an RFC to officially reserve the status code. This means that as of RFC 9110 in 2022, HTTP 418 is now protected. It can’t be used for anything else. It will forever be “I’m a teapot.”

What These Stories Tell Us

Both of these things, the typo and the teapot, are permanently integrated in the foundation of the web. One by accident, the other on purpose.

The “referer” typo shows how hard it is to fix mistakes once they’re widely deployed. Sometimes you just have to live with the consequences of a rushed decision. Today, every developer who implements HTTP has to remember to spell it wrong. I remember spelling it wrong myself, and at first, it was annoying finding out that it was not spelled correctly, but looking up the history of it, I realized that it’s actually kind of charming. It’s a reminder to all of us that the web was built by real people, who also make mistakes