Create a pattern to have the framework handle validation errors automatically

[rynowak]

This would be a filter that responds with a 400 without calling your action code.

[khellang]

Could I propose 422 is used instead of 400?

From RFC4918 Section 11.2:

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.

It's kinda sad that syntax and semantics are conflated in the MVC validation system today 😢

[khellang]

I guess my comment is related to #4862

[rynowak]

Could I propose 422 is used instead of 400?

You can propose whatever you want 😆 To me it's not the most important thing - because even if we can choose a right answer there will still be lots of developers who want to do it differently.

I still welcome the discussion, but I don't expect us to get an overwhelming consensus.

---

It's kinda sad that syntax and semantics are conflated in the MVC validation system today 😢

In my readings of a few other blogs and forum posts this morning on the topic of 400 vs 422 I came across a lot of cases where the author totally misunderstands what 'syntax' is. I'm currently busy being sad about that 😢

What would you have us do to improve this?

The big barrier that I see is that we don't really have an input validation system at all. We only have a model validation system.

---

Regarding HTTP 422:

Some people are bothered by the fact that 422 is defined by the WebDAV RFC and it's not mentioned at all in RFC7231 which came 7 years later. I don't think this is a big deal, 422 is in common use for this purposes.

The part that I have trouble with is that 422 is that it is specific about the request entity - another term for the BODY, and that's it's specific about semantics not syntax.

As you pointed out, we don't have a clear separation between syntax and semantics. We're also generally operating pretty far away from the actual request entity when we perform validation. We also provide validation for lots of non-request-entity data and right now it all goes down the same pipe.

---

Consider also that the language for 400 was revised by RFC7231

Old

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

New

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).

The changes specifically drop the language that states that 400 is intended for cases where the request syntax is incorrect. It's now considered an example of when a 400 is appropriate.

---

I've also heard arguments in the past for 409 for generic validation errors, which I do not find persuasive. 409 could be appropriate for some business rule kinds of validations but it's not a good 'general' choice.

[khellang]

Why do you even involve the model state and hit the action method on syntactical errors? I'm not sure what you expect the developer to do in this case?

What would you have us do to improve this?

I would just return 400 right away, but I'm probably missing something 😅

[khellang]

At the very least, it would be nice if the status code was configurable 😄

[rynowak]

Why do you even involve the model state and hit the action method on syntactical errors? I'm not sure what you expect the developer to do in this case?

Yeah this is part of the spirit of this work item.

At the very least, it would be nice if the status code was configurable

Absolutely