异常的正确 HTTP 状态是什么？答案

【问题标题】：What is the correct HTTP status for exceptions?异常的正确 HTTP 状态是什么？
【发布时间】：2012-01-19 17:27:35
【问题描述】：

如果我的脚本抛出异常，我应该返回什么 HTTP 状态？

200 正常

或

500 内部服务器错误

假设用户请求参数是正确的，但我的脚本中有一个错误，导致出现错误消息而不是正确的响应（XML、JSON 或其他格式）。 HTTP 状态应该是什么？

【问题讨论】：

我会说404。我前段时间在我的项目中也有同样的问题，在阅读了所有代码及其含义后，我留在了404。异常的原因很重要。在 sw 错误上给出 500，在无效的用户输入上给出 404（无效的产品 ID 等）。
这取决于异常及其对最终用户的意义！您应该更加精确才能获得有意义的答案！
@Notinlist 如果事实上您只是犯了一个编程错误，您会告诉某人资源不存在吗？如果您告诉它该页面不存在，Google 将很快停止在搜索结果中显示您的 URL :) 404 Not Found 仅在请求的资源不存在时才适用（实际上仅在它存在时）从未存在过）。
@Mchl：这不是一个完整的答案，所以留下评论是正确的。
404 仅适用于用户要求不存在的内容。如果用户只是给你错误的输入，我认为 400（错误请求）更合适。

【解决方案1】：

500 Internal Server Error 是正确的状态，如果错误不能通过客户端更改他们的请求来修复。

如果客户端可能能够修复其请求以避免错误，则使用任何4XX 状态（如果找不到资源，则使用404）。

200 OK 是不是在几乎任何错误情况下的适当状态，因为那时客户端认为事情运行正常（它们不是）并且可能继续发出相同的导致错误的请求.

熟悉available status codes in RFC2616 并找到最适合这种情况的。

【讨论】：

【解决方案2】：

这取决于抛出异常的原因，因为它们几乎可以用于任何错误。如果因为在数据库中找不到 URI 中的某些 id 而被抛出，我会说 404。另一方面，如果是因为数据库已关闭，我会抛出 500。如果抛出异常但结果页面仍然是对用户有用，我会说返回 200。

【讨论】：

我认为如果抛出异常，应该仍然是 500 错误，但是响应的正文仍然可以包含有用的内容。
@cdeszaq 这可能对视觉检查错误响应的人有用，但如果提供 500 状态代码，许多 HTTP 客户端将不会读取响应正文，因此客户端不一定能够调整其根据错误原因的行为。这就是 WCF 异常可以返回为 200 并带有错误类型响应的原因。
@cdeszaq 在大多数情况下，我会同意你的观点，但我仍然认为这取决于。 HTTP 状态代码供客户端（网络用户/搜索引擎机器人）使用。因此，假设您抛出异常是因为您想记录一些错误，但您仍然确信响应的主体不会受到影响。客户端应该仍然能够假设页面是好的（它应该使用状态码来检查）。这样可以避免 Google 因为您的分析系统损坏而从索引中删除页面。
我假设一个不可恢复的异常，而不是预期的异常，但我同意你处理预期的异常。

【解决方案3】：

查看Status Code Definitions。 500 或 400 应该适用于一般问题，但是，您越详细，返回的状态就越有用。

【讨论】：

当你让 PHP 抛出异常时，我想说你已经通过了400 的合法使用点。 Web 服务器应该捕获任何构成 Bad Request 的内容，并且 PHP 甚至不会被调用。任何引发异常的东西可能是5xx 错误——因为它是服务器端的。显然在某些情况下这是不正确的，例如验证请求的无效资源，但这些都有自己的代码（401、403、404）并且不构成400 Bad Request
@DaveRandom - “Web 服务器应该捕获任何构成错误请求的内容，并且 PHP 甚至不会被调用。”* - 不一定。您可能期待一个特定格式的请求正文，但收到一个格式错误的请求正文，这值得400 Bad Request （服务器不会处理）。该状态对 API 尤其有用（而不是常规的 ol' 网页请求 - 尽管它仍然对那些 API 有用）。
@RobHruska - 感谢您澄清我最初应该在我的答案中扩展的内容。现在，如果只有我雇主的代理喜欢 SO 并且可以按预期加载它而不会超时，那么我不会落后 2 小时。