一个简单的密码错字真的是 HTTP 错误吗？ [关闭]

Question

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

密码输入错误或不小心遗漏了必填字段在应用程序中非常常见，预计会发生。从任何规范中似乎都不清楚这些应该构成“HTTP 客户端错误”，或者只有在产生永久状态更改的情况下才能将 POST 视为 2xx 成功。

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

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

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

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

Answer 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 更改浏览器的行为方式之外，您可能还需要一个媒体类型，其中包含有关浏览器应如何将问题传达回客户端的更具体信息。