很明显，一些表单POST请求会导致4xx HTTP错误（例如错误的URL，缺少预期字段，无法发送auth cookie），但现有问题like this似乎表明所有无效表单提交都应被视为4xx HTTP错误。真的？
错误密码或意外省略必填字段非常常见且应用程序中的预期发生。从任何规范中都不清楚这些应该构成“HTTP客户端错误”，或者如果POST产生永久状态更改，则POST只能被视为2xx成功。
我想我的直觉是，如果服务器向客户端发送表单，并且客户端立即使用所有预期字段向该表单发出正确形成的POST请求，则常见的业务逻辑违规不应该是HTTP错误。
如果通过JSON-RPC等方式提交表单，情况就更不明确了。 HTTP只是传输机制，如果成功调用函数并且响应返回给调用者，则应该没有HTTP错误。
更少见的是，某些形式可能会做多件事，而另一部分可能会成功而另一部分失败。
理想情况下，IETF会使用RFC清除这一点，可能会为“由于表单失效失败而未执行操作”添加HTTP错误代码，或者扩展422的定义以涵盖此内容。
答案 0 :(得分：1)
这里没有对错。我认为HTML形式在某种程度上违背了HTTP的设计。
此处的浏览器是HTTP客户端。如果它提交请求并且收到HTTP错误，它将回显响应的主体，但对响应代码做的很少。
从HTTP的角度来看，浏览器可能不应该“刷新”错误。也许它应该只是传达了用户的错误，并允许他们改变表单并重新尝试请求。
从HTML的角度来看，要做的最好的事情是不要发回错误，而是重定向回表单的URL，通常带有一组查询参数。
对于JSON-RPC，（以及诸如XML-RPC，Soap等许多协议，以及诸如GraphQL之类的新协议）根本不能以与HTTP很好地融合的方式使用HTTP。
从这个意义上说，它们不是HTTP应用程序，它们几乎都使用HTTP作为“隧道”。他们使用HTTP作为传输，但他们不会“利用HTTP协议”。
对于那些情况，我认为http发出错误代码是不合适的。错误是在更高级别处理的，您可能只是总是希望使用POST并在响应正文中传递错误信息时返回200.
回到你的问题：
遇到422时，浏览器的行为是否应该不同？也许。但“有一个错误”通常不足以成为一个好的用户体验。除了改变浏览器使用422的行为方式之外，您可能需要一种媒体类型，其中包含有关浏览器如何将问题传达回客户端的更具体信息。