代码之家  ›  专栏  ›  技术社区  ›  Adam Byrtek

在开发web应用程序时,您实际使用哪些HTTP状态代码?[关闭]

  •  10
  • Adam Byrtek  · 技术社区  · 17 年前

    HTTP/1.1规范( RFC2616 )定义了HTTP服务器可以返回的多个状态代码,以表示某些条件。其中一些代码可以被web应用程序(和框架)使用。在经典和异步(XHR)响应中,哪些代码在实践中最有用,在什么情况下使用它们?

    应该避免哪些代码,例如,应用程序是否应该弄乱5xx代码范围?在REST web服务中返回HTTP代码时,您有什么约定?你曾经使用过302以外的重定向吗?

    12 回复  |  直到 16 年前
        1
  •  13
  •   Rich Bradshaw    16 年前

    我正在使用的(我可以快速找到) grep 'Status:' 无论如何):

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

    我意识到,我可以简单地让服务器为所有内容发送“200”,但当用户看到(或导致)错误而不告诉你时,它们可以节省很多痛苦。我已经有了显示拒绝访问消息等的功能,所以无论如何添加这些功能都不需要太多工作。

        2
  •  13
  •   Mathieu Rodic    11 年前

    418:我是茶壶

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

        3
  •  6
  •   Kevin Kevin    16 年前

    别忘了503-服务不可用。这一点对于站点停机至关重要。尤其是在搜索引擎方面。

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

    如果你只是显示一个“临时关闭”页面,但仍然返回200 OK,蜘蛛可能会为你的错误页面建立索引,或者更糟糕的是,用这个“新”内容替换现有的索引。

    这可能会严重影响你的SEO排名,特别是如果你的网站很大,很受欢迎。

        4
  •  3
  •   alex    17 年前

    303 See Other 这是必须的 PRG ,您应该使用 现在 如果你还没有。

        5
  •  2
  •   Marc Novakowski    17 年前

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

    1xx-2xx范围内的响应代码通常由底层Web服务器(即Apache、IIS)自动处理,因此您不必担心这些。

    代码301和302通常用于重定向,当客户端或代理已经包含数据的有效副本并且不需要来自服务器的新版本时,经常使用304(有关其工作原理的详细信息,请参阅RFC)。

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

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

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

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

    如果您在后端从Web服务器(如Apache)代理到应用服务器(如Tomcat),并且无法连接到应用服务器,则通常会看到代码502。

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

        6
  •  2
  •   Adam Byrtek    17 年前

    我倾向于使用 405方法不允许 当有人试图获取一个只能发布的URL时。其他人也这样做吗?

        7
  •  1
  •   Janko MivÅ¡ek    17 年前

    在……里面 Aida/Web 我们使用的框架

    • 200 Ok
    • 302重定向
    • 404未找到
    • 500内部服务器错误
        8
  •  1
  •   Avi Flax    16 年前

    我基本上会在适当的时候使用它们。规范本身定义了每个代码及其使用环境。

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

    在我的公司,我们有一些Flex客户。他们不能正确处理200以外的状态代码,所以我们让他们在请求时发送一个特殊参数,这告诉我们的服务器总是发送200,即使不是正确的响应。

        9
  •  0
  •   Matthew Marshall    17 年前

    我做过关于500这个数字的噩梦。

        10
  •  0
  •   Janko MivÅ¡ek    17 年前

    当您的Web应用程序引发异常时,Aida/Web中会返回500内部服务器错误。因为这是一个Smalltalk应用程序,所以当用户得到500和一个短堆栈时,服务器上会出现一个异常窗口(如果你以满负荷运行它)。

    当然,在服务器继续运行的同时,您可以在服务器上打开一个完整的调试器并尝试解决问题。另一件好事是,具有全栈的异常窗口正等着你,直到你回来。

    结论:500是福,不是噩梦!

        11
  •  0
  •   jhnstn    13 年前

    我使用409而不是400来处理错误的用户数据(即表单提交)。

    409的规范继续讨论版本冲突,但它提到应在响应中发送有关如何修复问题的信息。非常适合格式错误的电子邮件或错误的密码消息。

    400只解决了语法问题,在我看来,这个请求根本没有意义,而不是失败了一些正则表达式。

        12
  •  -5
  •   Garry    13 年前

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

    推荐文章