51–60 of 146 posts
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 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 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?
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…
Earlier quoted context omitted.
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 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.
419 I‘m an awfully hot coffee pot
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/
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.
Earlier quoted context omitted.
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
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.
We return 418s for captcha failures.