27 ms·

500 “Internal Server Error” is the code you should be using for generic server errors.

49bc 8y ago
Yes a 500. Not sure how anything else would ever pass the smell test of even a lazy pull request.
curun1r 8y ago
It's important to say why that's the correct error code. In this case, it's because 5xx errors can be retried in the future whereas 4xx errors tell the client that any retries will receive the same response.
- eropple 8y ago
  This is honored more in the breach than the observance at times, though, particularly with 404.
- boomlinde 8y ago
  In general, this is wrong. 4xx status may be retried, achieving different results each time. This makes sense with for example status 409 and 429, where this is definitely expected, or 404 since resources may be added or removed at any time independent of any single client, or 402 and 403 which may change out of band. Conversely, there are 5xx statuses that you shouldn't expect to change with each request, for example 505 (HTTP version not supported) or, really, 500 in some cases. There's AFAIK no standardized strategy to deal with the different status code. Instead it's important to get the status code right to as accurately as possible describe the error to the client. The server never tells the client what to do; it tells it what went wrong so that the client can deal with the error at its own discretion. In this case the server told he client that it was a teapot when what actually happened was an internal server error. That's wrong because it's wrong, not because every client will or even should deal with either of these errors in a predictable way.
  - curun1r 8y ago
    > There's AFAIK no standardized strategy to deal with the different status code While I was a bit too over-broad in my generalizations of 4xx vs 5xx status codes when it comes to retries, the gist is still the same. The specification does specifically call out when it's okay to retry and when it isn't. And it also specifically calls out when it's okay for intermediate servers and browsers to cache responses and when it isn't. In the case being discussed, 500 is specifically the correct error code because it cannot be cached and can be retried. That's not the case for 409 or 429, which either cannot be retried automatically (409) or can be cached (429). 402 is, IIRC, underspecified and shouldn't be used. 403 specifically states that the request should not be retried. It's important to make a distinction between the user/application and the user agent when we talk about retries. The user agent is the program or library that implements the HTTP spec. You seem to be talking about the former, who is always capable of retrying a request when they feel circumstances have changed enough for the request to succeed. But user agents are intentionally dumber. They can't resolve conflicts, fix permissions or do anything outside of the logic dictated by the spec. And they have much more limited license to retry 4xx responses or cache 5xx responses.
yeukhon 8y ago
Actually, 503 is better in this case. Internally it shlkld report 500.
hluska 8y ago
I'm sorry that I wasn't more clear. The person I was replying to aptly wrote "'cuteness' and 'cleverness' has a way of biting you in the behind", and I was agreeing with/adding to that comment. I've been guilty of cleverness and sure enough, it has usually found a way to get me in the end. Today, in similar situations, I'd return a 500 with a message in the body.
sofaofthedamned 8y ago
I've seen the teapot error used when the internal route of a request was circuitous (many servers involved) and a 500 could have come form anywhere. It was used as a canary, and only on this codebase which was bought-in and absolutely awful.
K0nserv 8y ago
No it's not since this is a error on the client's side it should be a 4xx code, probably not 418 though.

49bc 8y ago

Yes a 500. Not sure how anything else would ever pass the smell test of even a lazy pull request.

It's important to say why that's the correct error code. In this case, it's because 5xx errors can be retried in the future whereas 4xx errors tell the client that any retries will receive the same response.

eropple 8y ago
This is honored more in the breach than the observance at times, though, particularly with 404.
boomlinde 8y ago
In general, this is wrong. 4xx status may be retried, achieving different results each time. This makes sense with for example status 409 and 429, where this is definitely expected, or 404 since resources may be added or removed at any time independent of any single client, or 402 and 403 which may change out of band. Conversely, there are 5xx statuses that you shouldn't expect to change with each request, for example 505 (HTTP version not supported) or, really, 500 in some cases. There's AFAIK no standardized strategy to deal with the different status code. Instead it's important to get the status code right to as accurately as possible describe the error to the client. The server never tells the client what to do; it tells it what went wrong so that the client can deal with the error at its own discretion. In this case the server told he client that it was a teapot when what actually happened was an internal server error. That's wrong because it's wrong, not because every client will or even should deal with either of these errors in a predictable way.
- curun1r 8y ago
  > There's AFAIK no standardized strategy to deal with the different status code While I was a bit too over-broad in my generalizations of 4xx vs 5xx status codes when it comes to retries, the gist is still the same. The specification does specifically call out when it's okay to retry and when it isn't. And it also specifically calls out when it's okay for intermediate servers and browsers to cache responses and when it isn't. In the case being discussed, 500 is specifically the correct error code because it cannot be cached and can be retried. That's not the case for 409 or 429, which either cannot be retried automatically (409) or can be cached (429). 402 is, IIRC, underspecified and shouldn't be used. 403 specifically states that the request should not be retried. It's important to make a distinction between the user/application and the user agent when we talk about retries. The user agent is the program or library that implements the HTTP spec. You seem to be talking about the former, who is always capable of retrying a request when they feel circumstances have changed enough for the request to succeed. But user agents are intentionally dumber. They can't resolve conflicts, fix permissions or do anything outside of the logic dictated by the spec. And they have much more limited license to retry 4xx responses or cache 5xx responses.

yeukhon 8y ago

Actually, 503 is better in this case. Internally it shlkld report 500.

hluska 8y ago

I'm sorry that I wasn't more clear. The person I was replying to aptly wrote "'cuteness' and 'cleverness' has a way of biting you in the behind", and I was agreeing with/adding to that comment. I've been guilty of cleverness and sure enough, it has usually found a way to get me in the end. Today, in similar situations, I'd return a 500 with a message in the body.

sofaofthedamned 8y ago

I've seen the teapot error used when the internal route of a request was circuitous (many servers involved) and a 500 could have come form anywhere. It was used as a canary, and only on this codebase which was bought-in and absolutely awful.

K0nserv 8y ago

No it's not since this is a error on the client's side it should be a 4xx code, probably not 418 though.