I use 418 as a reply to illegitimate bots. It’s fun and it makes filtering logs easier.
Nginx config snippet:
# Nothing to hack around here, I’m just a teapot:
location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ {
return 418;
}
error_page 418 /418.html;
Example: https://FreeSolitaire.win/wp-login.php
(NB: /wp-login.php is WordPress login URL, and it’s commonly blindly requested by bots searching for weak WordPress installs.)
Quick side-note. Thank you for freesolitaire.win. It's such a beautiful implementation of solitaire. Works so well as a PWA, I can enjoy it even without proper internet connection, it's simple, does the basics, but does it perfectly. There's nothing to add to it, but more importantly... nothing to take out. I wish more software was written like this.
I've donated already, but I use it so much I'll donate again.
Wow, thanks jbombadil! That’s so heart-warming to hear <3 I’m speechless. I’m glad you like https://FreeSolitaire.win that much! Thank you again for your kind words (and donation!)
Also a +1 for the solitaire! One suggestion: how about an inverted mode where the piles grow up from the bottom? I think it would be much easier to control while playing on phone
Oh that’s an interesting idea! Thanks Dave, had not think about that!
Regarding playing on phone: one improvement I have in mind, is to have the stock (aka reserve) and waste piles be on the right side. That would make them easier to reach for right-handed players, I guess. What do you think? (The foundations piles would inversely go to the left. They are rarely manipulated, given that one can double-tap a card to automatically send it to its foundation pile.)
Thank you again for the feedback, that’s always very appreciated!
Blocking at the edge (on the CDN) is another, and it would be even quicker ;-) (I use Cloudflare, a Cloudflare worker could be set to answer /wp-login.php or anything, without even reaching my own server.)
> Blocking at the edge (on the CDN) is another, and it would be even quicker ;-) (I use Cloudflare, a Cloudflare worker could be set to answer /wp-login.php or anything, without even reaching my own server.)
With HTTPS, blocking on the edge requires using a CDN that holds your secret keys. The only way they could block paths is being able to decrypt requests since the path is encrypted. If you trust Cloudflare or someone else to manage your secrets, this will work, but if you are terminating your HTTPS connections, you'll need to handle it with your own infrastructure as people above have.
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.
This 418 stuff reminds me of a previous job where we had some arguments about putting emojis in our applications. I was against it and a coworker was for it. Like putting rocket ship emoji when an operation succeeds.
My main argument was that if you put things like that in your applications then people start having opinions about it and they want to discuss it and add more to certain places or remove from other places and bring it up when you are trying to discuss unrelated things.
The increase in communication is a big detriment in my opinion, especially if there is no user behavior tracking to see if those emojis actually improve any user-related metrics (this was a b2b application so we didn't do a lot of user tracking).
It wasn't even about professionalism or anything like that, just the fact that those kind of things are subjective (some people like, some don't, some don't notice, some like a lot and want more) created small-scale friction often enough that I was getting annoyed by it.
We just had a work party and they invited the whole staff. I was outraged they didn't do a proper controlled A/B test. Management will never know if having fun together was a good use of their money. Idiots.
The problem was people (including management) wanting to talk about where and how to put emojis once we added a few. The less I have to talk to management the better.
All those small discussions were essentially pointless and they happened often enough that I was getting annoyed by them.
Like, sometimes we would be showing "in development" stuff to clients and then they would interrupt and mention something like "nice rocketship emoji" and I am like "can you just focus on what I am showing you"
You're doing the thing he was trying to avoid. You want to have a discussion about this hypothetical emoji and make a bunch of statements about the psychology of the person who doesn't want to waste his life on it. Nothing like being accused of not liking "fun" when you don't want to do something useless at work.
Maybe not everybody likes goofy emojis, or Harry Potter references, or whatever easy nothing passes as wit for some people, and they think it makes everything less professional and introduces unnecessary maintenance. Those people have to make the choice to shut up about it, or mention it and have somebody tell them they're joyless.
edit: irt 418, it's historical and it has already imposed most of its maintenance burden. But using it when you're not a teapot is forcing the meme.
As a former engineering manager: no, I don't want to have a discussion about the hypothetical emoji. I want the engineer to put a rocketship in their commit message to have a slightly brighter day, and I want to acknowledge that someone else made a positive comment about it.
If you are genuinely at the point in your life where "people saying they like things" is the same as ... what you're describing ... please be aware of the emotional impact you're having on the people around you.
People like novelty and engage on things they feel they can contribute an opinion on.
Been on many a demo in the past where all sorts of "magical" and complicated stuff is happening that ends up with "ooh I've never seen a date picker like that" or "wouldn't it be a lot better if it was blue and not red".
Often it's because they accept the other stuff is working or don't even fully remember what the demo is about.
Surely both having and not-having emojis could be just as likely to trigger discussions about whether to have or not have emojis?
Sometimes I feel like the opposite of your position happens: just add the damn emojis already to put an end to the endless discussions about whether to add emojis
> My main argument was that if you put things like that in your applications then people start having opinions about it
You can say this about literally any discussion outside the realm of bugfixes. And yes I do want to discuss the psychology behind this, because this is, IMO, a perfect example of the tendency for a certain kind of dude (usually dude, anyway) to ascribe "objective," "rational," or other such power-words to their own personal opinions and state them as though they are fact.
Emoji's are characters, my guy. That's it. And if the saying "A picture is worth a thousand words" holds any water... well, I think a thousand is pushing it, but I think an emoji can save you a bunch of words in certain contexts, and doesn't need nearly as much attention for localization.
The only pushback I see consistently on this is from old farts like myself who remember fondly the days pre-emoji and have feels about it. And having feels is completely fair, but trying to pass off your feels as facts doesn't fly.
Let me give you an example that actually happened. We had a rocketship emoji to indicate success in an potentially dangerous operation related to high voltage wires. Right before we made a final release (which we would do every 4 months or so) someone in the QA department brought up that having a rocketship emoji on something that can catch fire and potentially explode is not a very good idea.
This was during a meeting and that derailed the meeting by a few minutes or so, but we had to make new last-minute pre-release for testing to remove the emoji. This was right before a release so pressure was high, you only have to run into something like this a few times before you start to think that this kind of thing is not worth any "good feelings" it might bring.
This job was a high stress environment where we were always behind schedule. This kind of thing, happened often enough that it was really getting to my nerves.
Personally I don't really mind emojis in the software I use as long as it works as intended. What I mind is wasting my time with this kind of stuff. This HTTP 418 is in the same kind of situation, I have had 3rd-party APIs throw 418 back at me (presumably some fun a dev had at that company) and I couldn't even tell if my request was wrong or if that was supposed to be a 500. Software for controlling high voltage is not supposed to be fun, network protocols are not supposed to be fun.
I love those RFC documents. I am currently working with CCSDS documents and they are total trash comparing to RFC. For example when I read documents about how TCP works or TLS works I see that it has been written by professionals with experience and vision. And CCSDS documents have been written by bureaucrats who have never written a line of code in their lives.
This always reminds me of a great find I discovered a while back when I was reading the HTTP/2 RFC for whatever reason.
Back before "429 Too Many Requests" was standardized, Twitter's API used to return a nonstandard 420 status code (with the caption "Enhance Your Calm") when rate-limiting incoming requests. They stopped doing this for understandable reasons, but the caption, at least, got snuck into HTTP/2, see:
Every time I have encountered this error code in the wild I have been extremely frustrated. Somebody tries to be cheeky, and rather than just return the proper status code (like a 429 or 503) they return this, which breaks a lot of HTTP status code parsing.
Not cheeky or funny. Boring actually. I know I'm boring but I have a job to do.
Honestly this discussion makes the occasional "I'm a teapot" seem useful. Your log and error handling ought to be capable of handling occurrences of a programmer doing something goofy.
A possibly apocryphal didactic story relevant because if an HTTP implementation misses 418, what else does it miss?:
The story goes that Van Halen had stipulated on their concert rider that they wanted M&M candy backstage, but with all the brown ones removed.
In his autobiography ‘Crazy From the Heat’ singer David Lee Roth explained this was not just a childish request, but in fact was a cunning test whereby he could tell instantly if the venue was safe or not.
He reasoned that if a concert venue did put brown M&Ms out, then they cannot have read the rider properly and that they then might also have made other more dangerous errors, such as in their electricity supply or stage weight capacity.
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 honestly would have thought 400 Bad Request would cover that? Might be too generic though. Is "422" "ok, I admit it's formatted correctly, but I can't process it for some higher-level reason than syntax"?
(Just reading through 4xx codes, and I think I need to use 410 Gone a lot more often. Does anyone know if search engines treat 404 and 410 differently?)
The issue I have with 400 Bad Request is that it's very broad. The request might actually be fine, but the data posted is not. Now you could argue that it doesn't matter why the request is bad, formatting, protocol or data, 400 for everything. It just feels a lot like throwing a generic Exception and attempting to convey the details in the message body.
From personal experience search engines don’t honor 404 or 410.
I switched much of my personal site to returning 410 over a decade ago and Googlebot still returns on a routine basis re-requesting a document that hasn’t been on the site since 2012.
Out of paranoia I just checked and yeah, GoogleBot actual (and not the dozens of fakes) requested each 410'd URL at least once a month, some URLs get multiple requests per month. All have been marked 410 since 2014 or earlier.
> Is "422" "ok, I admit it's formatted correctly, but I can't process it for some higher-level reason than syntax"?
That is my understanding. Something to say that the request is understood as an HTTP request (therefore not 400) but the server doesn't know what to do with it, usually in the context of a POST, or it's otherwise invalid for processing.
We use the 418 response code in our authentication service. We use to determine whether the token is invalid due to expiration, vs any other reason. If 418, we know to refresh to access token automatically... pretty harmless and definitely not a security measure.
iiNet was probably the best job I've ever had, certainly the place where I learnt the most, and had the most fun.
The coffeecam was cute, acb - the one primarily responsible for the coffeecam - also had American candies for sale around it (at least when I worked there at Hay Street)
Disagree, asking a teapot for a cup of coffee is an invalid user request. The server is working as expected, but is not being asked to work as expected.
Vim has http support as part of netrw which exists so you can do things like edit files over scp. I have at times had to fix remote hosts using this type of thing for example
vim scp://seanhunter@somehost.example.com:1234/.vimrc
^ ...which believe it or not works just fine if I have ssh access to that host.
..and I think http is supported for stuff like webdav, although I can't think of ever using http directly in vim like that. Given it's built-in it's useful for things like updating plugins etc. Once you've made the leap to thinking having net support like that built in is worthwhile, it makes sense for vim to have the wherewithall to test the responses for different status codes etc so plugins and scripts which use that network functionality can test the different failure cases.
There's this website called tcrf.net discussing hidden gems in old games and I feel like in the past, at least in some companies, engineering was fun. I really cannot picture creating anything like 418 in my current workplace.
I use 418 in place of 400. It doesn’t matter too much because too much information about the error is a security risk, I just give generic codes for everything. If you want to debug something look at the logs.
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.
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.
I handle all these special cases like 2xx_other, 3xx_other, 4xx_other and 5xx_other. I log the http code and the response in case I have to debug later. 4xx_other just means you shouldn't repeat the request, since the server thinks it is invalid.
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.
Sure, but if the server is returning 418 by an error it is likely that it would return some other 4xx error instead of 5xx. 418 is irrelevant here, the server is rogue.
Could, but when it comes to handling errors in the frontend, I find it is easier for the discriminator to be the actual status code when possible, rather than needing multiple additional properties.
Surely "when possible" should be "when semantically correct"?
I don't hate fun (see the threads on removing 418 from Node and Go for that), but misusing a joke status code in production to mean something completely unrelated seems less like fun and more like poor design.
There is no status code for captcha failures, so I don't think using 418 for that is "misuse".
By design, our API routes which utilize a challenge should not be consumed by others either, so even if using 418 somehow broke someone's attempted usage, that sounds like a feature not a bug.
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.
"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already."
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.
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.
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.
I use 418 as a reply to illegitimate bots. It’s fun and it makes filtering logs easier.
Nginx config snippet:
Example: https://FreeSolitaire.win/wp-login.php (NB: /wp-login.php is WordPress login URL, and it’s commonly blindly requested by bots searching for weak WordPress installs.)Quick side-note. Thank you for freesolitaire.win. It's such a beautiful implementation of solitaire. Works so well as a PWA, I can enjoy it even without proper internet connection, it's simple, does the basics, but does it perfectly. There's nothing to add to it, but more importantly... nothing to take out. I wish more software was written like this.
I've donated already, but I use it so much I'll donate again.
Wow, thanks jbombadil! That’s so heart-warming to hear <3 I’m speechless. I’m glad you like https://FreeSolitaire.win that much! Thank you again for your kind words (and donation!)
Also a +1 for the solitaire! One suggestion: how about an inverted mode where the piles grow up from the bottom? I think it would be much easier to control while playing on phone
Oh that’s an interesting idea! Thanks Dave, had not think about that!
Regarding playing on phone: one improvement I have in mind, is to have the stock (aka reserve) and waste piles be on the right side. That would make them easier to reach for right-handed players, I guess. What do you think? (The foundations piles would inversely go to the left. They are rarely manipulated, given that one can double-tap a card to automatically send it to its foundation pile.)
Thank you again for the feedback, that’s always very appreciated!
I think that in such a UI where it's trivial to mirror left and right just give an option and let the user decide their preference
444 might be quicker, if less fun. https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#...
Wonder how to ban that address permanently just for asking for these urls?
444 is a (nginx-specific) idea too, indeed.
Blocking at the edge (on the CDN) is another, and it would be even quicker ;-) (I use Cloudflare, a Cloudflare worker could be set to answer /wp-login.php or anything, without even reaching my own server.)
Wrt. how to ban: an option would be something like fail2ban (https://en.wikipedia.org/wiki/Fail2ban)
> Blocking at the edge (on the CDN) is another, and it would be even quicker ;-) (I use Cloudflare, a Cloudflare worker could be set to answer /wp-login.php or anything, without even reaching my own server.)
With HTTPS, blocking on the edge requires using a CDN that holds your secret keys. The only way they could block paths is being able to decrypt requests since the path is encrypted. If you trust Cloudflare or someone else to manage your secrets, this will work, but if you are terminating your HTTPS connections, you'll need to handle it with your own infrastructure as people above have.
> Wonder how to ban that address permanently just for asking for these urls?
fail2ban supports rules based on nginx logs (clients that triggers x 444 responses in y minutes (or y-times) gets banned for n minutes/hours/days)
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/
This 418 stuff reminds me of a previous job where we had some arguments about putting emojis in our applications. I was against it and a coworker was for it. Like putting rocket ship emoji when an operation succeeds.
My main argument was that if you put things like that in your applications then people start having opinions about it and they want to discuss it and add more to certain places or remove from other places and bring it up when you are trying to discuss unrelated things.
The increase in communication is a big detriment in my opinion, especially if there is no user behavior tracking to see if those emojis actually improve any user-related metrics (this was a b2b application so we didn't do a lot of user tracking).
It wasn't even about professionalism or anything like that, just the fact that those kind of things are subjective (some people like, some don't, some don't notice, some like a lot and want more) created small-scale friction often enough that I was getting annoyed by it.
We just had a work party and they invited the whole staff. I was outraged they didn't do a proper controlled A/B test. Management will never know if having fun together was a good use of their money. Idiots.
The problem was people (including management) wanting to talk about where and how to put emojis once we added a few. The less I have to talk to management the better.
All those small discussions were essentially pointless and they happened often enough that I was getting annoyed by them.
Like, sometimes we would be showing "in development" stuff to clients and then they would interrupt and mention something like "nice rocketship emoji" and I am like "can you just focus on what I am showing you"
> All those small discussions were essentially pointless
Were they pointless, or were they positive feedback about a thing you personally disliked?
You're doing the thing he was trying to avoid. You want to have a discussion about this hypothetical emoji and make a bunch of statements about the psychology of the person who doesn't want to waste his life on it. Nothing like being accused of not liking "fun" when you don't want to do something useless at work.
Maybe not everybody likes goofy emojis, or Harry Potter references, or whatever easy nothing passes as wit for some people, and they think it makes everything less professional and introduces unnecessary maintenance. Those people have to make the choice to shut up about it, or mention it and have somebody tell them they're joyless.
edit: irt 418, it's historical and it has already imposed most of its maintenance burden. But using it when you're not a teapot is forcing the meme.
As a former engineering manager: no, I don't want to have a discussion about the hypothetical emoji. I want the engineer to put a rocketship in their commit message to have a slightly brighter day, and I want to acknowledge that someone else made a positive comment about it.
If you are genuinely at the point in your life where "people saying they like things" is the same as ... what you're describing ... please be aware of the emotional impact you're having on the people around you.
Because nothing brightens an engineer's day like putting rocketship emojis in commit messages
We need to talk about your flair.
Now, it’s up to you whether or not you just want to do the minimum.
But look at Brian over there! He has 4, sometimes 5 emojis in his commit messages! And a terrific smile…
possible reference to https://youtu.be/F7SNEdjftno?si=HgwhGPbwL8U8deOo
it wasn't about putting emojis in commit messages, it was about putting them in the application
It sounds like people really liked the emojis
People like novelty and engage on things they feel they can contribute an opinion on.
Been on many a demo in the past where all sorts of "magical" and complicated stuff is happening that ends up with "ooh I've never seen a date picker like that" or "wouldn't it be a lot better if it was blue and not red".
Often it's because they accept the other stuff is working or don't even fully remember what the demo is about.
This is actually selling me on using emojis
If they had not been paying attention to what you were showing them, then how would they have noticed the emoji?
Work parties. Worst thing ever.
Surely both having and not-having emojis could be just as likely to trigger discussions about whether to have or not have emojis?
Sometimes I feel like the opposite of your position happens: just add the damn emojis already to put an end to the endless discussions about whether to add emojis
> My main argument was that if you put things like that in your applications then people start having opinions about it
You can say this about literally any discussion outside the realm of bugfixes. And yes I do want to discuss the psychology behind this, because this is, IMO, a perfect example of the tendency for a certain kind of dude (usually dude, anyway) to ascribe "objective," "rational," or other such power-words to their own personal opinions and state them as though they are fact.
Emoji's are characters, my guy. That's it. And if the saying "A picture is worth a thousand words" holds any water... well, I think a thousand is pushing it, but I think an emoji can save you a bunch of words in certain contexts, and doesn't need nearly as much attention for localization.
The only pushback I see consistently on this is from old farts like myself who remember fondly the days pre-emoji and have feels about it. And having feels is completely fair, but trying to pass off your feels as facts doesn't fly.
Let me give you an example that actually happened. We had a rocketship emoji to indicate success in an potentially dangerous operation related to high voltage wires. Right before we made a final release (which we would do every 4 months or so) someone in the QA department brought up that having a rocketship emoji on something that can catch fire and potentially explode is not a very good idea.
This was during a meeting and that derailed the meeting by a few minutes or so, but we had to make new last-minute pre-release for testing to remove the emoji. This was right before a release so pressure was high, you only have to run into something like this a few times before you start to think that this kind of thing is not worth any "good feelings" it might bring.
This job was a high stress environment where we were always behind schedule. This kind of thing, happened often enough that it was really getting to my nerves.
Personally I don't really mind emojis in the software I use as long as it works as intended. What I mind is wasting my time with this kind of stuff. This HTTP 418 is in the same kind of situation, I have had 3rd-party APIs throw 418 back at me (presumably some fun a dev had at that company) and I couldn't even tell if my request was wrong or if that was supposed to be a 500. Software for controlling high voltage is not supposed to be fun, network protocols are not supposed to be fun.
So, it was swapped for a :thumbs_up:, right?
Whenever I catch myself having a discussion about having fewer discussions, I try to stop and just let it go.
The linked source RFC is a pleasant read too: https://www.rfc-editor.org/rfc/rfc2324
I love those RFC documents. I am currently working with CCSDS documents and they are total trash comparing to RFC. For example when I read documents about how TCP works or TLS works I see that it has been written by professionals with experience and vision. And CCSDS documents have been written by bureaucrats who have never written a line of code in their lives.
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
IP Datagrams on Avian Carriers https://www.rfc-editor.org/rfc/rfc1149
IP over Avian Carriers with Quality of Service https://www.rfc-editor.org/rfc/rfc2549
It's even been updated[1] for IPv6, so no reason not to use it!
[1]: https://www.rfc-editor.org/rfc/rfc6214
For anyone who wants to explore further, Wikipedia has a list page for these RFCs: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
There are a lot more of them than I had realized before finding that. Some years even had multiple.
This was the nerdy non sequitur joke before "sir, this is a wendy's" went platinum on facebook memes in the 2010s.
I mean there were a million, including the game, which everyone was freed of by xkcd.
Dangit, I had finally gotten good at The Game.
https://xkcd.com/391/
This always reminds me of a great find I discovered a while back when I was reading the HTTP/2 RFC for whatever reason.
Back before "429 Too Many Requests" was standardized, Twitter's API used to return a nonstandard 420 status code (with the caption "Enhance Your Calm") when rate-limiting incoming requests. They stopped doing this for understandable reasons, but the caption, at least, got snuck into HTTP/2, see:
https://datatracker.ietf.org/doc/html/rfc7540#section-7
down at 0xb, the caption for disconnection due to excessive load is, indeed, ENHANCE_YOUR_CALM. Always makes me smile. :)
Every time I have encountered this error code in the wild I have been extremely frustrated. Somebody tries to be cheeky, and rather than just return the proper status code (like a 429 or 503) they return this, which breaks a lot of HTTP status code parsing.
Not cheeky or funny. Boring actually. I know I'm boring but I have a job to do.
If your parser can't handle in-spec error codes, then that's a parser problem.
Regardless of the parser if you're using a 4XX status code when you should be using a 5XX status code then you're simply doing it wrong.
Honestly this discussion makes the occasional "I'm a teapot" seem useful. Your log and error handling ought to be capable of handling occurrences of a programmer doing something goofy.
Why would being a teapot justify being a 5xx status? The server hasn’t failed, it’s a functioning teapot, definitely not broken.
I would assume if the teapot were to be broken, then a 518 teacup is empty error would be more appropriate.
But as long as there is a piping hot cup of tea, then it’s a 418 code.
/s
A possibly apocryphal didactic story relevant because if an HTTP implementation misses 418, what else does it miss?:
The story goes that Van Halen had stipulated on their concert rider that they wanted M&M candy backstage, but with all the brown ones removed.
In his autobiography ‘Crazy From the Heat’ singer David Lee Roth explained this was not just a childish request, but in fact was a cunning test whereby he could tell instantly if the venue was safe or not.
He reasoned that if a concert venue did put brown M&Ms out, then they cannot have read the rider properly and that they then might also have made other more dangerous errors, such as in their electricity supply or stage weight capacity.
https://www.metaltalk.net/chris-dale-myth-busting-the-van-ha...
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.
> 422: Unprocessable Content
I honestly would have thought 400 Bad Request would cover that? Might be too generic though. Is "422" "ok, I admit it's formatted correctly, but I can't process it for some higher-level reason than syntax"?
(Just reading through 4xx codes, and I think I need to use 410 Gone a lot more often. Does anyone know if search engines treat 404 and 410 differently?)
The issue I have with 400 Bad Request is that it's very broad. The request might actually be fine, but the data posted is not. Now you could argue that it doesn't matter why the request is bad, formatting, protocol or data, 400 for everything. It just feels a lot like throwing a generic Exception and attempting to convey the details in the message body.
From personal experience search engines don’t honor 404 or 410. I switched much of my personal site to returning 410 over a decade ago and Googlebot still returns on a routine basis re-requesting a document that hasn’t been on the site since 2012.
Well... a thorough "meh" to Google. Thanks for the info though, one less thing for me to care about.
Out of paranoia I just checked and yeah, GoogleBot actual (and not the dozens of fakes) requested each 410'd URL at least once a month, some URLs get multiple requests per month. All have been marked 410 since 2014 or earlier.
Google has FoMO...
The webmaster tools used to say Google will punish your rank if the crawler gets too many 404 or 410...
> Is "422" "ok, I admit it's formatted correctly, but I can't process it for some higher-level reason than syntax"?
That is my understanding. Something to say that the request is understood as an HTTP request (therefore not 400) but the server doesn't know what to do with it, usually in the context of a POST, or it's otherwise invalid for processing.
410 could be useful if you want to make sure that the client does not confuse a “real” 404 with a gateway issue.
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®
We use the 418 response code in our authentication service. We use to determine whether the token is invalid due to expiration, vs any other reason. If 418, we know to refresh to access token automatically... pretty harmless and definitely not a security measure.
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
Typically people post older conversations so people can check them out, not as a chastisement for reposting.
Fair enough. Hadn't thought of it that way
2022 was a sad year
Every April 18th
Usually in one of these threads, someone links the iiNet coffee cam. Here you go:
https://coffeecam.iinet.net.au/coffee/history/
iiNet was probably the best job I've ever had, certainly the place where I learnt the most, and had the most fun.
The coffeecam was cute, acb - the one primarily responsible for the coffeecam - also had American candies for sale around it (at least when I worked there at Hay Street)
I think since it is I am a teapot not you are a teapot It should be a 5xx code because clearly it's a server side issue.
Disagree, asking a teapot for a cup of coffee is an invalid user request. The server is working as expected, but is not being asked to work as expected.
Agree, it’s a functioning teapot. Definitely 418.
If the cup is empty, then a 518 teacup is empty error would be more appropriate but as long as there is piping hot tea - 418 for me.
/s
Honestly doesn't sound like a problem at all in the greater scheme of things.
The RFC covers mostly coffee brewing related activities.
I've always wondered if you were to have an actual networked Teapot, when would it be appropriate to send 418.
I am sure there are some networked teapots already.
If someone wanted to send a "brew tea" request (via POST?) to an actual teapot, then 418 would not be suitable, you'd want something else, no?
I think making a networked teapot with an undocumented endpoint for "brew coffee" that returned 418 would be fun :)
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
Here I was, foolishly thinking it was code for operator panic: https://www.youtube.com/watch?v=kLQStcdhAGA
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?
Postel's law
Vim has http support as part of netrw which exists so you can do things like edit files over scp. I have at times had to fix remote hosts using this type of thing for example
vim scp://seanhunter@somehost.example.com:1234/.vimrc
^ ...which believe it or not works just fine if I have ssh access to that host.
..and I think http is supported for stuff like webdav, although I can't think of ever using http directly in vim like that. Given it's built-in it's useful for things like updating plugins etc. Once you've made the leap to thinking having net support like that built in is worthwhile, it makes sense for vim to have the wherewithall to test the responses for different status codes etc so plugins and scripts which use that network functionality can test the different failure cases.
I named my IoT Wireless SSID to 418. Thought I was clever, even if nobody else understands it.
The password is "I'm a teapot" right?
I definitely thought about it but that seemed a bit too crackable
There's this website called tcrf.net discussing hidden gems in old games and I feel like in the past, at least in some companies, engineering was fun. I really cannot picture creating anything like 418 in my current workplace.
I use 418 in place of 400. It doesn’t matter too much because too much information about the error is a security risk, I just give generic codes for everything. If you want to debug something look at the logs.
I love engineering sense of humour :)
419 I‘m an awfully hot coffee pot
419 - I’m a Nigerian Prince.
Objectively speaking, the best status code.
Friendly reminder never to use a 4XX status code when you mean to return a 5XX even if you think it's cheeky or funny.
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 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.
I handle all these special cases like 2xx_other, 3xx_other, 4xx_other and 5xx_other. I log the http code and the response in case I have to debug later. 4xx_other just means you shouldn't repeat the request, since the server thinks it is invalid.
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.
Sure, but if the server is returning 418 by an error it is likely that it would return some other 4xx error instead of 5xx. 418 is irrelevant here, the server is rogue.
We return 418s for captcha failures.
Surely that should be a 401 unauthorized?
Could, but when it comes to handling errors in the frontend, I find it is easier for the discriminator to be the actual status code when possible, rather than needing multiple additional properties.
Surely "when possible" should be "when semantically correct"?
I don't hate fun (see the threads on removing 418 from Node and Go for that), but misusing a joke status code in production to mean something completely unrelated seems less like fun and more like poor design.
There is no status code for captcha failures, so I don't think using 418 for that is "misuse".
By design, our API routes which utilize a challenge should not be consumed by others either, so even if using 418 somehow broke someone's attempted usage, that sounds like a feature not a bug.
you are not a tea pot.
Ceci n'est pas une théière
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.
Eh, I remember it being introduced and it always puts a smile on my face. Though I admittedly don't click on it after reading the title.
Its not like people are posting this daily
Relevant xkcd: https://xkcd.com/1053/
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
This is a great point. I'm going to start calling 418 the brown M&M of server response codes.
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?
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.
Also hard disagree from me. To quote from SICP:
"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already."
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!
Then do it. If a teapot has a handle on it so can you.
Why is this a problem for libraries? Not that most libraries handle anything about HTTP correctly out of the box anyway.
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.
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.
Relevant earlier discussions: https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_...
* get to handle it.
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.