Default error handlers should return 422 status code to client?

[sloria]

Currently, error handlers return a 400 response. It may be more appropriate to return a 422, which is typically used for ValidationErrors.

From RFC 4918:

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.

[rajatkhanduja]

I am not an expert at this, but I'd like to discuss more about this.

Quoting a stackoverflow answer, RFC 7231 has the following to say about status code 400 (Bad Request)

The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).

Wouldn't "invalid request message framing" cover the scenarios where a ValidationError would be raised?

[ghost]

This is old, but I also believe validation errors should be returning 400. 422 is a webdav extension and is not included in RFC 7231 https://tools.ietf.org/html/rfc7231