If you are bored you can read the discussion when _mnot_ tried removing 418 status code from different languages and implementations because it wasn't technically correct.
Other than the humor in it, makes you wonder why they'd pick 418. It does sometimes feel like some errors are missing from the http codes, prompting developers to either create their own, or repurpose some, like 418, where they feel relatively safe that it won't conflict with something.
It never ceases to amaze how http status codes can be misused. My favorite is still the customer who had built a service that would return "200 OK" and then in the response just be the text "500". We had asked if they could return a 500 error, if there was an error in the API, rather than a 200, so they swapped out the 200 in the response, but not the headers. "200 Created" is also up there, in terms of developers with limited understanding or weird framework limitations.
There are definitely missing codes, which is why sometimes the WebDAV status additions get used in purported RESTful APIs—which is semantically wrong, but often carries a lot of helpful meaning. For example, things like 422: Unprocessable Content or 423: Locked are really helpful to convey meaning, but not available in plain HTTP.
I hate to be that guy, but just a reminder that if you’re implementing a production system - even if it’s an internal tool - please don’t return 418 as a joke unless you really are a teapot. As an SRE I’ve been on the receiving end of a broken system returning teapots over the weekend, and it’s not as funny then.
5xx indicates an error in the server, 4xx indicates a client error. So it's quite common for clients to handle them differently like retrying 5xx but not 4xx.
I did this many years ago on the app I still work on, the product became much more enterprise and eventually customers started to see 418 errors.. it wasn't a good look and I felt great shame.
Please, never ever again add such features to standards as a joke. Some backend folks have started to return it as an indetermiante error code, which in turn means that all client-side libraries will have to handle it at some level.
They have to handle it anyway. There's nothing in the HTTP specifications that disallows a server from using whatever codes it wants to that aren't specifically specified. There is no "HTTP 527 Server Needs a Nap" but it is perfectly legal for my server to reply to clients with that HTTP status, and clients are expected to handle it like they would handle any other non-specific error in the 5xx class of response codes (server error).
Other perfectly legal responses:
242 - TOO MUCH COFFEE
(Server is overcaffeinated and processing requests too quickly)
299 - SUCCESSFUL BUT SASSY
(Request succeeded but the server is throwing shade about it)
333 - QUANTUM UNCERTAINTY
(The server simultaneously succeeded and failed until observed)
Clients have always had to handle unknown return code according to the first digit, and by and large they do this succesfully, with the exception of 1xx codes which are widely buggy.
Imo, the real problem and where it went wrong is the people using it as an error code outside of its intended purpose(to signal being a teapot, not a coffee machine). I mean this 100% seriously, unironically.
I thought that at first, but then realized that it is, in fact, correctly a client error: the client erroneously directed a coffee-related request to a server that is, in fact, not meant to service such requests. :-P
I counter-disagree. It is so easy in life to have fun. There's so much fun everywhere. If you're so starved for fun then this won't do it for you either. The higher the scale the more likely your easter egg becomes not an easter egg.
I also think the supermajority of engineers prefer fun entirely outside of work, hence why open source can feel so lonely and without corporate funding would probably shrink to a pathetic size. Hence why personal websites are so culturally irrelevant. Or why there's such a lack of artistic experimentation in apps or web. Or why there's so few non-corporate meetups nowadays in CA or NY.
Oh, definitely hard disagree with this! I am an engineer because I love it and because it brings me joy, and I love love LOVE things that involve humor and fun within the realm of what is oftentimes just work. It delights me when people can find ways to be creative and tongue-in-cheek and not take things so seriously all the time. It is one way in which we can have fun in our work. For me, the idea of keeping all my fun separated from my work sounds like a dystopian nightmare!
So many things in the IT world started as non-professional things by non-professional engineers. If you're a professional who lives off one of these things you should be glad that someone wanted to have fun at some point.
Counter-counter-disagree. This is the ultimate way to make sure the joke is preserved for the future generations while keeping implications absolutely miniscule.
Thankfully, error codes such as this are structured so that the initial "4" digit is the only one that really matters. Just treat it as a client error and you can't go wrong.
So, you're saying you expect libraries that don't have a generic 4xx "Oops, my bad, dev please handle it" error case to be bothered by the existence of 418 in any way, shape or form? I think you're barking up the wrong tree.
Well, I recently used it in a small PostgREST-subset query builder I wrote in case the query builder received an input more complicated that what it could handle. I found 418 a natural response in this case. In retrospect a 5xx (edit: or better 422) error is more appropriate, however.
The older generation of software craftsmen have been reading about it for a while now and the joke got a bit tedious at this point.
The linked source RFC is a pleasant read too: https://www.rfc-editor.org/rfc/rfc2324
Now. I didn't know about the RFC. This is so good. I hope we can continue to advance this field with good humor, and good coffee.
There are quite some RFC with humor, most prominently probably RFC1149 and its extension RFC2549
If you are bored you can read the discussion when _mnot_ tried removing 418 status code from different languages and implementations because it wasn't technically correct.
https://github.com/nodejs/node/issues/14644
https://github.com/golang/go/issues/21326
And someone even ended up making a website http://save418.com/
I had Sonatype Nexus return to me once upon upload of an artifact. I was not impressed.
Other than the humor in it, makes you wonder why they'd pick 418. It does sometimes feel like some errors are missing from the http codes, prompting developers to either create their own, or repurpose some, like 418, where they feel relatively safe that it won't conflict with something.
It never ceases to amaze how http status codes can be misused. My favorite is still the customer who had built a service that would return "200 OK" and then in the response just be the text "500". We had asked if they could return a 500 error, if there was an error in the API, rather than a 200, so they swapped out the 200 in the response, but not the headers. "200 Created" is also up there, in terms of developers with limited understanding or weird framework limitations.
There are definitely missing codes, which is why sometimes the WebDAV status additions get used in purported RESTful APIs—which is semantically wrong, but often carries a lot of helpful meaning. For example, things like 422: Unprocessable Content or 423: Locked are really helpful to convey meaning, but not available in plain HTTP.
i think you may mean “never _ceases_ to amaze”, as in it never stops amazing </pedant>
Fixed, thank you :-)
Odd coming from such a Serious Enterprise™ Solution®
This was the nerdy non sequitur joke before "sir, this is a wendy's" went platinum on facebook memes in the 2010s.
Discussions in:
2020 (153 points, 118 comments) https://news.ycombinator.com/item?id=24206899
2021 (193 points, 108 comments) https://news.ycombinator.com/item?id=28541327
2023 (206 points, 189 comments) https://news.ycombinator.com/item?id=36090344
I think we were due another
2022 was a sad year
Vim implemented this: `:call err_teapot()`.
Why would a text editor have a way to produce HTTP error codes? I don't get it
Why would a web server try to brew coffee when it's a teapot?
I hate to be that guy, but just a reminder that if you’re implementing a production system - even if it’s an internal tool - please don’t return 418 as a joke unless you really are a teapot. As an SRE I’ve been on the receiving end of a broken system returning teapots over the weekend, and it’s not as funny then.
Well, statistically, 9 out of 10 engineers find this very funny come Monday.
I don't get it. If the system is so broken it is returning some random http code then I don't see how returning some other random http code is better?
5xx indicates an error in the server, 4xx indicates a client error. So it's quite common for clients to handle them differently like retrying 5xx but not 4xx.
I did this many years ago on the app I still work on, the product became much more enterprise and eventually customers started to see 418 errors.. it wasn't a good look and I felt great shame.
We return 418s for captcha failures.
Here I was, foolishly thinking it was code for operator panic: https://www.youtube.com/watch?v=kLQStcdhAGA
https://http.cat/418
Google has it too. :) https://www.google.com/teapot
I didn't realize that this is actually interactive!
https://http.dog/ as well
The internet never fails to amuse me, this is awesome haha
419 I‘m an awfully hot coffee pot
I love engineering sense of humour :)
Please, never ever again add such features to standards as a joke. Some backend folks have started to return it as an indetermiante error code, which in turn means that all client-side libraries will have to handle it at some level.
They have to handle it anyway. There's nothing in the HTTP specifications that disallows a server from using whatever codes it wants to that aren't specifically specified. There is no "HTTP 527 Server Needs a Nap" but it is perfectly legal for my server to reply to clients with that HTTP status, and clients are expected to handle it like they would handle any other non-specific error in the 5xx class of response codes (server error).
Other perfectly legal responses:
242 - TOO MUCH COFFEE (Server is overcaffeinated and processing requests too quickly)
299 - SUCCESSFUL BUT SASSY (Request succeeded but the server is throwing shade about it)
333 - QUANTUM UNCERTAINTY (The server simultaneously succeeded and failed until observed)
452 - EXCESSIVE TOAST
Clients have always had to handle unknown return code according to the first digit, and by and large they do this succesfully, with the exception of 1xx codes which are widely buggy.
Imo, the real problem and where it went wrong is the people using it as an error code outside of its intended purpose(to signal being a teapot, not a coffee machine). I mean this 100% seriously, unironically.
I thought that at first, but then realized that it is, in fact, correctly a client error: the client erroneously directed a coffee-related request to a server that is, in fact, not meant to service such requests. :-P
> Some backend folks have started to return it as an indetermiante error code
in other words, they decided to break the standard
are we sure it's the standard who's wrong?
Then do it. If a teapot has a handle on it so can you.
Disagree. We gotta have fun.
I counter-disagree. It is so easy in life to have fun. There's so much fun everywhere. If you're so starved for fun then this won't do it for you either. The higher the scale the more likely your easter egg becomes not an easter egg.
I also think the supermajority of engineers prefer fun entirely outside of work, hence why open source can feel so lonely and without corporate funding would probably shrink to a pathetic size. Hence why personal websites are so culturally irrelevant. Or why there's such a lack of artistic experimentation in apps or web. Or why there's so few non-corporate meetups nowadays in CA or NY.
Oh, definitely hard disagree with this! I am an engineer because I love it and because it brings me joy, and I love love LOVE things that involve humor and fun within the realm of what is oftentimes just work. It delights me when people can find ways to be creative and tongue-in-cheek and not take things so seriously all the time. It is one way in which we can have fun in our work. For me, the idea of keeping all my fun separated from my work sounds like a dystopian nightmare!
So many things in the IT world started as non-professional things by non-professional engineers. If you're a professional who lives off one of these things you should be glad that someone wanted to have fun at some point.
Let this HTTP code be a reminder of that.
This! 100% this.
Counter-counter-disagree. This is the ultimate way to make sure the joke is preserved for the future generations while keeping implications absolutely miniscule.
You're the perfect reason to learn new english words/phrases: Killjoy.. And now I finally know what "wet blanket" mean,s thanks for that!
Why is this a problem for libraries? Not that most libraries handle anything about HTTP correctly out of the box anyway.
Relevant earlier discussions: https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_...
* get to handle it.
Thankfully, error codes such as this are structured so that the initial "4" digit is the only one that really matters. Just treat it as a client error and you can't go wrong.
So, you're saying you expect libraries that don't have a generic 4xx "Oops, my bad, dev please handle it" error case to be bothered by the existence of 418 in any way, shape or form? I think you're barking up the wrong tree.
Well, I recently used it in a small PostgREST-subset query builder I wrote in case the query builder received an input more complicated that what it could handle. I found 418 a natural response in this case. In retrospect a 5xx (edit: or better 422) error is more appropriate, however.
you are not a tea pot.