For those who may not know, this comes from RFC 2324: ""Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0), The RFC was published 1 April 1998 (April Fool's Day). There's a long history of humorous RFCs published on 1 April. For example, RFC 1149 "IP over Avian Carriers" https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
To toot my own horn, I did an April Fool’s status code RFC: 397 Tolerating, for when a client sends a flawed request, but you’re going to tolerate it because you know what they really meant:
At the firm I work at, one of my "10% time" projects was to build out a "warnings" field in the API response. There are often times that you want to say "this is not inherently wrong, but likely represents wrong assumptions upstream" or "you're asking for something that's obsolete and is now being silently ignored".
For example, if someone passes a currency field with the wrong number of decimal places. You might actually want to say your product costs $1.62346, but it's more likely you're not sanitizing your data and relying on non-guaranteed rounding behaviour to make it right.
The problem we have is that the most of the API fields are opt-in-- the people who could most use the warnings are unlikely to go in and activate them.
To be honest I think the robustness principle isn’t very well supported. We shouldn’t be this accommodating in what we accept. We’re very likely harming users by ignoring errors.
April Fools RFCs are part of the "Independent Stream", which mean the top left would say "Independent Submission", not IETF. Also, Informational, not Standards Track. Just FYI :)
This is a good idea for APIs that allow you to update an object by sending a partial JSON object with the keys you want to update, when technically you’re supposed to send the entire updated object representation unless JSON Patch is being used.
Alternatively there actually is a HTTP PATCH verb that you can use for this - I think that tolerating is more appropriate for common misspellinks - i.e. accepting a request like an HTTP POST {"days": 12, "horus": 13 "minutes": 27}
If I have anything to do with it, there is a 418 response hidden somewhere.
I recall a few internal projects at a previous employer would return 418 if the user managed to royally mess something up as a "wtf, how are you here?!" kind of response.
I feel like I am not alone in implementing 'weird' HTTP codes when I get bored / as an easter egg. Pretty sure I also used HTTP 420 at least once.
I remember reviewing a really long document (> 50 pages) that had in one bullet list the phrase 'Marks and Spencer tandoori chicken sandwich'. The doc was otherwise camera ready and the phrase was obviously there to see if I was in fact reading it
I added the 418 response code to my gopher server [1]. There was one web bot that constantly hit it and was clueless that it wasn't a web server. It finally got a clue.
Binance API (i.e https://api.binance.com/api/v3/ticker/price) does it when there are too many requests from one IP (I assume that's the reason). They could have used something else like 429 but for some obscur reasons they're using 418 (if anyone knows the actual reason...).
It will happen often if you try to make a call to their API through Google sheet scripts.
The NPM one is fun now, but man that was a frustrating one when it was happening. Explaining to people I couldn’t deploy the app because NPM decided it was a teapot. Error messages do not need to be silly.
I remember I was at some training course for New Relic and we zoned out when the alert came through. Having come across 418 before, I recognised it in our failed build pipeline and facepalmed. My coworker asked how do we fix it and U said I honestly don't know because it's never actually meant to be a real error code but here we are!
I'm personally of the opinion that 418 shouldn't be considered a joke response, but would actually useful as 418 "Unsupported Device".
What response should a printer give if you asked it to send a fax, but you have a base-model printer that doesn't support sending faxes. From the perspective of the printer, I know what you want (i.e. not a 404) and you've asked for it correctly (i.e. not 400 or 401 or 403), but I can't do it, and this does not indicate an error on my part (not a 500 or 503). Thus, 418: Unsupported Device.
Perhaps this too much of an overlap with 404 (I don't have that resource) and 501 (I can't do that verb to that resource), which I assume is why there's not a huge need for it. But if we're going to have 418 exist and receive browser support anyway, it might as well have a useful meaning rather than just exist as a joke.
This interpretation is fully in keeping with the non-joke meaning of the original RFC, as a teapot is a device that does not support brewing coffee.
I'd probably use a 422 in that case. I think 422 errors are underused, and can good for communicating errors when a client requests something which doesn't make sense from a business context.
For those that haven't memorized every single HTTP error code, 422 is "Unprocessable Entity": 'the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.'
If you throw a 404 to a completely valid GET for a file that doesn't exist for example, how is that a "complete overlap" to something like asking a database REST API to print a PDF? In the latter case, you have the ability to give a more detailed (better) error message, so why shouldn't you?
I return 418 in some cases where somehow someone ended up somewhere in the code that I otherwise thought impossible. It works pretty well as far as letting folks know that something particularly unusual has happened / this isn't your ordinary error.
I come from a country with rather _interesting_ views on what should be allowed online. 451 is used often enough that I've seen it in the wild more than once (and consider yourself lucky if you haven't encountered it...).
Why? The codes mean things, 418 specifically is a joke, but the entire 4xx range are client errors, i.e. a differently formed request would've succeeded.
A perhaps-reasonable suggestion could be to use a 5xx range code that isn't specified. E.g. 555, or 567.
(But I'm not sure how it would ever not simply be a 500 - server thought it couldn't happen, it could and did, that's just a plain and simple error isn't it?)
I think the idea behind 418, as much as there was an idea beyond a joke, was to indicate you sent your request to a teapot instead of a server. So yeah, client error for why it's not 518 instead.
But it works in this example for "client did something weird I don't understand", so still client error - something akin to a 404, "client tried to go somewhere I don't understand".
But it's the clients fault for trying to communicate with a teapot. There's nothing wrong inside the teapot. You just tried to communicate with a teapot. That's silly. Here's a 418 for you.
It's quaint, it's a joke about IoT devices before they were everywhere. I'm currently disappointed that the office has "upgraded" coffee machines and the new one has a permanent internet connection and shows ads/branding (for coffee) when it is idle.
I read a while ago about some coffee machines unintentionally bridging an internal network and spreading ransomware. I think they had Windows XP on the inside. Couldn't help but find the situation funny in a way.
One day in the future, people will be amazed out how forward thinking our society was circa 1999 when they planned status codes for IoT devices that wouldn't be invented for another 20 years. "Oh if only society now could be as wise forward thinking as people were back then. Planting seeds in gardens they'd never get to see."
A couple of years ago the gas pumps at station nearest to my place were replaced by devices with screens that play ads with sound - so far just touting discounts with their supermarket loyalty cards. They start when someone picks up the nozzle, and were annoyingly loud initially; the sound has been turned down a bit lately.
(Well, there's another reason for me to be pleased with having traded one of the family cars for an electric that charges at home ...)
There are a few gas stations around here with pumps that like to play ads at you while pumping gas. I tend to make a note of them and purposely get my gas elsewhere.
just stuff that emphasizes the brand of coffee that's in the machine. It's ridiculous (obviously an ad to buy that brand at home too, which I safely won't since I like my specialty coffee).
We need coffee machines that shut up and serve coffee and don't do brand ads.
> Office Space is great but the cubicles date it firmly in the 90s.
I had a cubicle almost identical to the ones in Office Space all the way up to 2011. If I ever had to return to an office, I’d much prefer that over any office desk I’ve had since.
I guess it's been about a generation since I implemented this as an easter-egg in a RESTful API service I built. It was quite the joke then, but now with IoT "smart" teapots and whatnot being so popular, it's not so funny now.
Support for this landed in Microsoft Edge v12, according to the table in the article. So it's supported across all major browsers, green across the board. But all that may be humorous lisense.
Hm, that's surprising. I added it as a known error response to the Internet Explorer dev tools in 2015 (inadvertently causing "I'm a teapot" to be localized into 108 languages...). I wonder what "support" means.
It's all fun and games until some clever developer uses this error code in a production system and the client developer or SRE folks have no idea what it means. Have also seen error code 420 used this way.
List of Additional April Fool's RFCs https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...