在开发Web应用程序时，您实际使用哪些HTTP状态代码？

Question

HTTP / 1.1规范（RFC2616）定义了许多状态代码，HTTP服务器可以返回这些状态代码以指示某些条件。其中一些代码可以被Web应用程序（和框架）使用。在经典和异步（XHR）响应中，哪些代码在实践中最有用，在哪些情况下您使用它们？

应避免使用哪些代码，例如。应用程序应该与5xx代码范围混淆吗？在REST Web服务中返回HTTP代码时有哪些约定？你有没有使用302以外的重定向？

Answer 1

我正在使用的那些（无论如何我能快速找到grep 'Status:'）：

• 200 成功检索资源而不影响资源
• 201 每当表单提交将重要内容放入数据库（论坛帖子，用户帐户等），创建新资源时发送
• 204 以空身体发送，例如在DELETE
之后
• 304 HTTP缓存。我发现这个非常很难做到，因为它必须考虑用户更改显示设置等等。我想出的最好的想法是使用用户首选项的哈希作为ETag。大多数浏览器在这里都有不可预测和不一致的行为......
• 400 用于未通过某些验证检查的错误表单提交。
• 403 只要有人在某个地方，他们就不应该使用（虽然我试图通过不显示用户不应访问的内容的链接来避免这种情况）。
• 404 除了普通的网络服务器之外，当URL包含无效的ID号时，我会使用这些。我想在这种情况下检查是否存在更高的有效ID并发送410而不是......
• 429 当用户的请求过于频繁时
• 500 ：我倾向于将这些放在catch {}块中，唯一的选择是放弃，以确保向浏览器发送有意义的内容。

我意识到只要让服务器为所有内容发送“200”就可以逃脱，但是当用户看到（或导致）错误并且没有告诉你它们时，它们会节省很多痛苦。我已经有了显示拒绝访问消息的功能等等，所以无论如何添加这些消息并不多。

Answer 2

418：我是一个茶壶

来自http://www.ietf.org/rfc/rfc2324.txt超文本咖啡壶控制协议（HTCPCP / 1.0）

Answer 3

不要忘记503 - 服务不可用。这个对于网站停机至关重要。特别是在搜索引擎方面。

假设您要将网站停用几个小时进行维护或升级工作。通过将所有请求定向到返回503代码的友好页面，它会告诉蜘蛛“稍后再试”。

如果您只是显示“暂时关闭”页面但仍然返回200 OK，则蜘蛛可能会将您的错误页面编入索引，或者更糟糕的是，用这个“新”内容替换现有索引。

这可能会严重影响您的搜索引擎优化排名，特别是如果您的网站很受欢迎。

Answer 4

303 See Other是PRG必须的，如果您尚未使用， 。

Answer 5

根据我的经验，以下是最常见的响应代码：

1xx-2xx范围内的响应代码通常由底层网络服务器（即Apache，IIS）自动处理，因此您无需担心这些代码。

代码301和302通常用于重定向，当客户端或代理已包含数据的有效副本且不需要服务器的新版本时，304会被大量使用（有关确切详细信息，请参阅RFC这是如何工作的。）

代码400通常用于指示客户端发送了导致服务器出现问题的错误或意外数据。

代码403用于执行身份验证，通常由服务器配置自动处理。

代码404是找不到页面的错误代码。

代码500表示服务器中的错误情况，不一定是由客户端发送的数据引起的。例如，数据库连接失败，编程错误或其他未处理的异常。

如果您从后端从Web服务器（例如Apache）代理到应用服务器（例如Tomcat），则通常会看到代码502，并且无法与应用服务器建立连接。

对于异步调用（即AJAX / JSON响应），始终返回200响应通常是最安全的。即使在处理请求时服务器中存在错误，最好将错误包含在JSON对象中，让客户端以这种方式处理它。原因是并非所有Web浏览器都允许访问非200响应代码的响应正文。

Answer 6

当有人试图获取只能发布的网址时，我倾向于使用 405 Method Not Allowed 。其他人也这样做吗？

Answer 7

在Aida/Web框架中，我们只使用

• 200好
• 302 Redirect
• 404 Not Found
• 500内部服务器错误

Answer 8

我基本上在适当的时候使用所有这些。规范本身定义了每个代码以及应该使用它们的环境。

在构建RESTful Web应用程序时，我不建议选择和选择状态代码，并将自己限制在整个范围的子集中。也就是说，除非为特定的HTTP客户端构建Web应用程序 - 在这种情况下，一个人不是真正构建Web应用程序，而是为该特定客户端构建应用程序。

在我的公司，我们有一些Flex客户。它们无法正确处理200以外的状态代码，因此我们让它们发送一个带有请求的特殊参数，告诉我们的服务器总是发送200，即使它不是正确的响应。

Answer 9

我有关于500号的噩梦。

Answer 10

当您的Web应用程序引发异常时，在Aida / Web中返回

500内部服务器错误。因为这是一个Smalltalk应用程序，所以当用户获得500和一个短堆栈时，会在服务器上引发异常窗口（如果你运行它的头部）。

在服务器上，您可以打开一个完整的调试器并尝试解决问题，而服务器当然正在继续运行。另一个好处是带有完整堆栈的异常窗口等着你，直到你来到这里。

结论：500是一种祝福，而不是一场噩梦！

Answer 11

我使用409而不是400来表示糟糕的用户数据（即表单提交）。

409的规范继续讨论版本冲突，但它提到应该在响应中发送有关如何解决问题的信息。适用于格式错误的电子邮件或错误的密码信息。

400只能解决语法问题，对我来说这听起来就像请求完全没有意义，而不是一些正则表达式失败。

Answer 12

我使用webmachine，它自动生成正确的错误代码。但有些情况下，我需要提供自己的。我发现在这些情况下返回666有助于开发和调试，所以我可以很容易地告诉我哪些来自我的代码，哪些来自webmachine。此外，当它出现时我会笑出来。您必须记住在部署之前更改此内容。