如果表单提交包含验证错误，我应该回复400错误吗？

Question

在经典的基于表单的webapp中，如果用户提交包含验证错误的HTML表单，假设没有JavaScript，那么正确的做法是什么？

1. 回复HTTP 200 +页面内容（包括用户的错误信息）
2. 回复HTTP 400 +页面内容（包括用户的错误信息）

重要吗？

Answer 1

您的应用是与人类交谈，而不是与其他机器交谈。因此，您应该以用户友好的方式做正确的事情并处理异常。

您的用户并不关心HTTP返回代码，因此它甚至不应该是您的考虑因素。您将业务逻辑问题与HTTP协议问题混淆起来。

事实上，通过在网络浏览器上抛出400错误，您很可能会遇到Web浏览器向用户抛出丑陋的消息。

如果您正在编写REST api，那么答案就会有所不同。但你不是。

Answer 2

1）将是正确的方法，因为您希望向用户显示突出显示无效输入值的内容页面。

2）的问题是某些浏览器可能会显示自己的“友好”错误页面，旨在帮助用户理解4xx错误。以下是有关何时IE显示“友好”错误页面的一些信息：

http://support.microsoft.com/kb/294807

Answer 3

一方面，如果它是供人类消费的网络应用程序，那么带有一些有用的错误消息的200将起作用。在这种意义上，为人类制作网站更容易，因为他们可以阅读和理解内容，而不必依赖于状态代码来与应用程序进行交互。

另一方面，如果您考虑使用REST API，则更合适的方法是抛出4xx错误，因为它是客户端错误。在这种情况下，您有几个选择。

根据RFC2616，400意味着

  

由于格式错误，服务器无法理解该请求   句法。客户端不应该重复请求   修改

这似乎不合适，因为它不是由于语法错误造成的。

然而，RFC2616 is now obsoleted by RFC7230-7235。新的RFC7231以更广泛的方式定义了400的含义。

  

客户端错误4xx 4xx（客户端错误）状态代码类指示   客户似乎错了。除了回应HEAD之外   请求，服务器应该发送一个包含的表示   解释错误情况，以及它是暂时的还是   永久性条件。

     

400错误请求

     

400（错误请求）状态代码表示服务器不能或   由于被认为是某种东西，它不会处理请求   客户端错误（例如，格式错误的请求语法，无效请求   消息框架或欺骗性请求路由）

所以即使仍然是通用的，这似乎是可以接受的。另一种选择是使用422 status code定义的RFC4918 (WebDAV)。

  

422 Unprocessable Entity 422（不可处理实体）状态代码   表示服务器理解请求实体的内容类型   （因此415（不支持的媒体类型）状态代码不合适），   并且请求实体的语法是正确的（因此是400（不好）   请求）状态代码不合适但是无法处理   包含说明。例如，可能发生此错误情况   如果XML请求体包含格式良好（即语法上）   正确的，但语义上错误的XML指令。