Comment by Izkata
1 day ago
> Slack puts {"ok": false} inside a 200.
I found out due to a live bug that Apache strips out the response body for 5xx HTTP codes for security, and it's not configurable, so you can't use any of those if you want to return the error message to the user. Don't know what else might do the same, so nowadays I only use HTTP error codes for protocol-level issues, and application-level issues all go into a 200 OK with JSON just like that.
Do you mean Apache APISIX, https://github.com/apache/apisix/issues/13501? That sounds like a simple bug which existed for a short time and has been fixed. For Apache HTTP Server (what people mean by “Apache” in such a context), what you describe is thoroughly unbelievable.
4xx errors are for when the client did something wrong and needs to know about it. 5xx errors are for when the server is having problems and the only people who can do anything about it are the operators, who should be looking for errors in the logs rather than the HTTP client.
Truly "application level" issues are therefore correct as 200, although some application communication issues lead to 4xx errors that should be handled as such. But the case of an application trying to communicate via 5xx errors should never have been the case anyway.
I worked in environment where every HTTP 500 error was replaced by some middle ware by user "friendly" error page, and that included REST calls between services. That HTML also included one huge header image(as base64), so my logs were flooded by that junk response.
We run into that a lot using Mulesoft. 3 layer APIs, and each layer will discard error messages returned by the underlying layers unless we do tedious custom error handling. Makes it impossible for the teams using our integrations to know what they're doing wrong.