title: Should I use HTTP 4xx to indicate HTML form errors?
body: <p>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.</p>
  <p>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.</p>
  <p>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.</p>
  <p>My question is - is anyone else doing this, and if not, why not?</p>
  <p>[<strong>UPDATE 1</strong>]</p>
  <p>Just to clarify, this question relates to HTML forms, and not an API.</p>
  <p>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.</p>
  <p>[<strong>UPDATE 2</strong>]</p>
  <p>Some further clarification, with W3C references (<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="nofollow noreferrer">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a>):</p>
  <blockquote>
  <p><strong>10.2 Successful 2xx</strong></p>
  </blockquote>
  <blockquote>
  <p>This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
  </blockquote>
  <blockquote>
  <p><strong>10.4 Client Error 4xx</strong></p>
  </blockquote>
  <blockquote>
  <p>The 4xx class of status code is intended for cases in which the client seems to have erred.</p>
  </blockquote>
  <blockquote>
  <p><em>10.4.1 400 Bad Request</em></p>
  </blockquote>
  <blockquote>
  <p>The request could not be understood by the server due to malformed syntax.</p>
  </blockquote>
  <p>And from <a href="https://www.rfc-editor.org/rfc/rfc4918#page-78" rel="nofollow noreferrer">https://www.rfc-editor.org/rfc/rfc4918#page-78</a></p>
  <blockquote>
  <p><strong>11.2.</strong>  422 Unprocessable Entity</p>
  </blockquote>
  <blockquote>
  <p>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.</p>
  </blockquote>
  <p>[<strong>UPDATE 3</strong>]</p>
  <p>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.</p>
  <p>[<strong>UPDATE 4</strong>]</p>
  <p>Notes on the use of custom response codes, and how they should be treated (if unrecognised), from HTTP 1.1 specification (<a href="https://www.rfc-editor.org/rfc/rfc2616#section-6.1.1" rel="nofollow noreferrer">https://www.rfc-editor.org/rfc/rfc2616#section-6.1.1</a>):</p>
  <blockquote>
  <p>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.</p>
  </blockquote>
  <p>[1] <a href="https://www.rfc-editor.org/rfc/rfc4918" rel="nofollow noreferrer">https://www.rfc-editor.org/rfc/rfc4918</a></p>