418 I’m a teapot
developer.mozilla.org
developer.mozilla.org
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/
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.
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"
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.
Were they pointless, or were they positive feedback about a thing you personally disliked?
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.
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.
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…
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.
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.
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
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;
I've donated already, but I use it so much I'll donate again.
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!
Wonder how to ban that address permanently just for asking for these urls?
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)
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.
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)
IP over Avian Carriers with Quality of Service https://www.rfc-editor.org/rfc/rfc2549
There are a lot more of them than I had realized before finding that. Some years even had multiple.
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. :)
Not cheeky or funny. Boring actually. I know I'm boring but I have a job to do.
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
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...
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.
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?)
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.
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
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)
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
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?
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 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.
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.
Its not like people are posting this daily
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.
Let this HTTP code be a reminder of that.
"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."
in other words, they decided to break the standard
are we sure it's the standard who's wrong?
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