Is a simple password typo really an HTTP error?

Question

It's obvious that some form POST requests should result in a 4xx HTTP error (e.g. wrong URL, lacking an expected field, failing to send an auth cookie), but existing questions like this seem to suggest that all invalid form submissions should be considered 4xx HTTP errors. Really?

Mistyping passwords or accidentally omitting required fields are extremely common and expected occurrences in an application. It doesn't seem clear from any spec that these should constitute an "HTTP client error", or that a POST can only be considered 2xx successful if it yields a permanent state change.

I guess my intuition is that, if a server sends a client a form, and the client promptly replies with a correctly-formed POST request to that form with all expected fields, a common business logic violation shouldn't be an HTTP error.

The situation is even less defined if a form is submitted over something like JSON-RPC. HTTP is just the transport mechanism and if the function is successfully called and the response returned to the caller, there should be no HTTP error.

More rarely, some forms may do multiple things and one part may succeed while the other fails.

Ideally the IETF would clear this up with an RFC, maybe adding an HTTP error code for "the operation was not performed due to a form invalidation failure" or expanding the definition of 422 to cover this.

Answer 1

There is no right or wrong here. I think HTML forms kind of counter the design of HTTP to a certain extend.

The browser here is a HTTP client. If it submits a request and it receives a HTTP error, it will echo the body of the response, but do little with the response code.

From a HTTP perspective, perhaps the browser should not have 'refreshed' to the error. Perhaps it should have just communicated an error the user and allow them to alter the form and re-try the request.

From a HTML perspective, the sanest thing to do though is to not send an error back at all, but a redirect back to the URL of the form, usually with a set of query parameters.

In the case of JSON-RPC, (and many protocols such as XML-RPC, Soap, but also newer ones such as GraphQL) don't at all use HTTP in a way that meshes well with HTTP.

They are not HTTP applications in that sense, they pretty much use HTTP as a "tunnel". They use HTTP as a transport but they don't "leverage the HTTP protocol" as such.

For those situations I don't think it's appropriate to http emit errors codes. Errors are handled on a higher level, and you probably just always want to use POST and return a 200 while communicating the error information in the response body.

So back to your question:

• Yes, from a HTTP perspective an invalid form submission should be a 4xx error. Invalid password a 401.
• No, this is not the sanest thing to in every real-life use-case such as browsers and protocols that use HTTP merely as a transport.
• But if you're developing a REST-based architecture, or you want to use HTTP as it was intended, then this is what you should do.

Should browsers behave differently when encountering a 422? Maybe. But "there was an error" is usually not enough for a good UX. Aside from changing how browsers behave with a 422, you might instead need a media-type with more specific information on how a browser should communicate problems back to a client.