2

很明显，某些表单 POST 请求应该会导致 4xx HTTP 错误（例如错误的 URL、缺少预期的字段、无法发送 auth cookie），但是像这样的现有问题似乎表明所有无效的表单提交都应该被视为 4xx HTTP错误。真的吗？

错误输入密码或意外遗漏必填字段是应用程序中极为常见和预期的情况。从任何规范中似乎都不清楚这些应该构成“HTTP 客户端错误”，或者如果 POST 产生永久状态更改，则只能认为 2xx 成功。

我想我的直觉是，如果服务器向客户端发送一个表单，并且客户端立即使用格式正确的 POST 请求回复该表单并包含所有预期字段，那么常见的业务逻辑违规不应该是 HTTP 错误。

如果通过 JSON-RPC 之类的方式提交表单，则情况就更不明确了。HTTP 只是传输机制，如果函数被成功调用并且响应返回给调用者，应该没有 HTTP 错误。

更罕见的是，某些形式可能会做多种事情，其中​​一部分可能会成功，而另一部分可能会失败。

理想情况下，IETF 会使用 RFC 来解决这个问题，可能会添加一个 HTTP 错误代码来表示“由于表单失效失败而没有执行操作”，或者扩展422的定义以涵盖这一点。

4

1 回答 1

1

这里没有对错。我认为 HTML 表单在一定程度上与 HTTP 的设计背道而驰。

这里的浏览器是一个 HTTP 客户端。如果它提交请求并收到 HTTP 错误，它将回显响应的正文，但对响应代码几乎没有做任何事情。

从 HTTP 的角度来看，浏览器可能不应该“刷新”错误。也许它应该刚刚向用户传达了一个错误，并允许他们更改表单并重试请求。

从 HTML 的角度来看，最明智的做法是根本不发回错误，而是重定向回表单的 URL，通常使用一组查询参数。

在 JSON-RPC 的情况下（以及许多协议，例如 XML-RPC、Soap，以及较新的协议，例如 GraphQL）根本没有以与 HTTP 很好地融合的方式使用 HTTP。

从这个意义上说，它们不是 HTTP 应用程序，它们几乎将 HTTP 用作“隧道”。他们使用 HTTP 作为传输，但他们没有“利用 HTTP 协议”。

对于这些情况，我认为 http 发出错误代码是不合适的。错误在更高级别上进行处理，您可能只想在响应正文中传达错误信息时始终使用 POST 并返回 200。

所以回到你的问题：

  • 是的，从 HTTP 的角度来看，无效的表单提交应该是 4xx 错误。401 密码无效。
  • 不，这对于每个现实生活用例（例如仅使用 HTTP 作为传输的浏览器和协议）来说并不是最明智的做法。
  • 但是，如果您正在开发基于 REST 的架构，或者您想按预期使用 HTTP，那么您应该这样做。

浏览器在遇到 422 时应该表现不同吗？也许。但是对于一个好的用户体验来说，“有一个错误”通常是不够的。除了通过 422 更改浏览器的行为方式之外，您可能还需要一个媒体类型，其中包含有关浏览器应如何将问题传达回客户端的更具体信息。

于 2016-05-20T21:15:28.827 回答