[aunderscored]

Disagree. Annoyingly there is a reasonable case for 200 but with an error, if http is your transport but not your application, then 200 says "yes, the message was transfered and understood correctly, here is your response" which may be an error response from the application

[eadmund]

If you’re using HTTP for something other than transferring hypertext — i.e., if your application is not a hypermedia application — then you are doing something just as wrong as encoding IP in DNS packets or email messages. Don’t do that. It’s wrong, even if it is technically interesting.

If, OTOH, your application is a hypermedia application, then returning a success status for errors is just wrong.

[aunderscored]

Every JSON API under the sun disagrees, but I do agree in principle. People very much like using HTTP as a JSON (or XML) transfer protocol

[sunshowers]

This ship sailed the day the first HTTP proxy was installed, and likely well before that.

[andreyvit]

Sorry, what? HTTP is perfectly fine for APIs which are not hypermedia.

[Izkata]

For example: Apache (httpd) replaces the 4xx and 5xx response body with its own content instead of whatever you'd returned from an external handler like wsgi. You have to use a 2xx (except for 204) to get a relevant error message back out.

[AdieuToLogic]

> For example: Apache (httpd) replaces the 4xx and 5xx response body with its own content instead of whatever you'd returned from an external handler like wsgi.

This is the default behavior. Apache httpd can be configured to produce different responses by way of ErrorDocument[0]. From the documentation:

  Customized error responses can be defined for any HTTP
  status code designated as an error condition - that is,
  any 4xx or 5xx status.

HTH

0 - https://httpd.apache.org/docs/trunk/custom-error.html

[jjnoakes]

Even with custom error documents configured in the web server, you still lose the application-specific (and probably request- and error-specific) message generated by the application itself.

[Izkata]

Yeah, this is how we ran across it - whoever originally wrote a particular feature was trying to do the right thing by using an HTTP error code, but with a message that would be presented to the user about why that operation failed. A generic response wouldn't work, there were multiple possible reasons all fixable by the user, and tying a whole error code to one specific feature would've probably been a bad idea anyway.

[Groxx]

Which is why "you resized the terminal window, clearly you meant to shut down this web server" is even crazier, yes

[aunderscored]

Indeed. That is particularly good at violating the principle of least astonishment