I honestly use this a lot when I'm testing, because it's basically the only response that can show up where I know god damned well that it's only happening because I programmed it to happen under certain conditions.
edit: a common one for me is that if any test passes a post request without a csrf token... sorry, I'm a teapot, because I forgot to add a csrf token to that form.
I like to respond with 418 as the catch all response code for mock web services for requests that dont match any installed expected requests. The reasoning is sometimes 404 is a valid mock response for some test cases, so I needed the "404 for mocks" that would never appear on any legit service. Very clearly highlights when something is going wrong on a test.
Yes. And write something to the logs, so you can find out there's a bug before users call your helpdesk. Arguably that's the most important part of any 5xx error.
It's a bit of a purist argument, but 4xx series means the client can fix something and get a better response.
Hmm, I don't think it's that purist. All my HTTP clients have the logic that 4xx is a non-retryable error, i.e. if I repeat the request I will always get the same response unless something is changed, whereas 5xx means that something is wrong on the backend and I should retry it later.
It is true I have often encountered inconsistencies in implementations but I do think that when that happens it really is a backend bug that should be fixed.
There are some 4xx codes that should be retried. 408, 413, and 429 at the very least. There are also cases where it makes sense to retry 404, such as when polling for a resource that is being created and will soon be available.
You are right about the 429, of course, and my more "advanced" clients take it into account and only reissue requests after the requested backoff time. The smaller "stupid" clients error out, as they should, because a dumb retry would just cause "angrier" responses from the server.
I am not sure about the other two though.
413 definitely does not seem retryable, if the client continues sending too large content. Special handling would be needed to break down the data into smaller chunks and when I encounter this error I just break it down to smaller chunks beforehand so built-in handling is not needed.
Never encountered 408. It might be because I never keep connections too long...
abort(418) is just quick and easy and gets the job done… even if I wasn’t the one reviewing the code it would throw up enough confusion to get attention.
It also works perfectly in case it accidentally gets pushed to production.
It doesn’t get the job done though… for anything non-trivial multiple errors can occur and if you just abort(418) then you don’t know which one it is. If you generate a real error message you can include some actually useful information. “This is some kind of error I triggered” is not anywhere near as useful as “The error is…”.
I mean, yea, I can pass a message with the 418 if I just have:
return "this error, blah", 418
I understand your point, and it's a good one. I really don't need to use 418, I just find it useful. I think the key is that when I see that 418 error, I know it's something I put in there at once.
I also think a naked 418 is a bit cleaner if it did end up on my production server, just because I'm not tipping my hat too much by returning anything about what's happening behind the scenes.
It could be a lot cleaner if I did everything by the book, but where I use this is just my hobby project, and I'm just going for doing as much as I can quickly, and the mental energy that goes into error handling could easily add very significant time. Again, you're not wrong, and it would be better if i clearly articulated these errors in the long run.
edit: a common one for me is that if any test passes a post request without a csrf token... sorry, I'm a teapot, because I forgot to add a csrf token to that form.