Should I use HTTP 4xx to indicate HTML form errors?

Question

I just spent 20 minutes debugging some (django) unit tests. I was testing a view POST, and I was expecting a 302 return code, after which I asserted a bunch database entities were as expected. Turns out a recently merged commit had added a new form field, and my tests were failing because I wasn't including the correct form data.

The problem is that the tests were failing because the HTTP return code was 200, not 302, and I could only work out the problem by printing out the response HTTP and looking through it. Aside from the irritation of having to look through HTML to work out the problem, a 200 seems like the wrong code for a POST that doesn't get processed. A 4xx (client error) seems more appropriate. In addition, it would have made debugging the test a cinch, as the response code would have pointed me straight at the problem.

I've read about using 422 (Unprocessable Entity) as a possible return code within REST APIs, but can't find any evidence of using it within HTML views / handlers.

My question is - is anyone else doing this, and if not, why not?

[UPDATE 1]

Just to clarify, this question relates to HTML forms, and not an API.

It is also a question about HTTP response codes per se - not Django. That just happens to be what I'm using. I have removed the django tag.

[UPDATE 2]

Some further clarification, with W3C references (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):

10.2 Successful 2xx

This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to have erred.

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax.

And from https://www.rfc-editor.org/rfc/rfc4918#page-78

11.2. 422 Unprocessable Entity

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

[UPDATE 3]

Digging in to it, 422 is a WebDAV extension[1], which may explain its obscurity. That said, since Twitter use 420 for their own purposes, I think I'll just whatever I want. But it will begin with a 4.

[UPDATE 4]

Notes on the use of custom response codes, and how they should be treated (if unrecognised), from HTTP 1.1 specification (https://www.rfc-editor.org/rfc/rfc2616#section-6.1.1):

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.

[1] https://www.rfc-editor.org/rfc/rfc4918

Answer 1

You are right that 200 is wrong if the outcome is not success.

I'd also argue that a success-with-redirect-to-result-page should be 303, not 302.

4xx is correct for client error. 422 seems right to me. In any case, don't invent new 4xx codes without registering them through IANA.