[mrmincent]

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.

[cybrox]

Well, statistically, 9 out of 10 engineers find this very funny come Monday.

[seanthemon]

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.

[nurettin]

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.

[sleepyhead]

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?

[dtech]

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.

[sleepyhead]

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.

[fastball]

We return 418s for captcha failures.

[mikepurvis]

Surely that should be a 401 unauthorized?

[fastball]

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.

[smrq]

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.

[fastball]

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.