|
|
1
13
我正在使用的(我可以快速找到)
我意识到,我可以简单地让服务器为所有内容发送“200”,但当用户看到(或导致)错误而不告诉你时,它们可以节省很多痛苦。我已经有了显示拒绝访问消息等的功能,所以无论如何添加这些功能都不需要太多工作。 |
|
|
2
13
418:我是茶壶 来自 http://www.ietf.org/rfc/rfc2324.txt 超文本咖啡壶控制协议(HTCPCP/1.0) |
|
|
3
6
别忘了503-服务不可用。这一点对于站点停机至关重要。尤其是在搜索引擎方面。 假设你要将网站关闭几个小时以进行维护或升级工作。通过将所有请求定向到返回503代码的友好页面,它告诉蜘蛛“稍后再试”。 如果你只是显示一个“临时关闭”页面,但仍然返回200 OK,蜘蛛可能会为你的错误页面建立索引,或者更糟糕的是,用这个“新”内容替换现有的索引。 这可能会严重影响你的SEO排名,特别是如果你的网站很大,很受欢迎。 |
|
|
4
3
303 See Other 这是必须的 PRG ,您应该使用 现在 如果你还没有。 |
|
|
5
2
根据我的经验,以下是最常见的响应代码: 1xx-2xx范围内的响应代码通常由底层Web服务器(即Apache、IIS)自动处理,因此您不必担心这些。 代码301和302通常用于重定向,当客户端或代理已经包含数据的有效副本并且不需要来自服务器的新版本时,经常使用304(有关其工作原理的详细信息,请参阅RFC)。 代码400通常用于指示客户端发送了导致服务器出现问题的错误或意外数据。 代码403用于执行身份验证,这通常由服务器配置自动处理。 代码404是未找到页面的错误代码。 代码500表示服务器中的错误情况,不一定是由客户端发送的数据引起的。例如,数据库连接失败、编程错误或其他未处理的异常。 如果您在后端从Web服务器(如Apache)代理到应用服务器(如Tomcat),并且无法连接到应用服务器,则通常会看到代码502。 对于异步调用(即AJAX/JSON响应),通常最安全的方法是始终返回200响应。即使服务器在处理请求时出错,最好将错误包含在JSON对象中,让客户端以这种方式处理。原因是并非所有网络浏览器都允许访问非200响应代码的响应体。 |
|
|
6
2
我倾向于使用 405方法不允许 当有人试图获取一个只能发布的URL时。其他人也这样做吗? |
|
|
7
1
在……里面 Aida/Web 我们使用的框架
|
|
|
8
1
我基本上会在适当的时候使用它们。规范本身定义了每个代码及其使用环境。 在构建RESTful web应用程序时,我不建议挑选和选择状态代码,并将自己限制在完整范围的一个子集中。也就是说,除非一个人正在为特定的HTTP客户端构建一个web应用程序——在这种情况下,他并没有真正构建web应用程序,而是在为该特定客户端构建应用程序。 在我的公司,我们有一些Flex客户。他们不能正确处理200以外的状态代码,所以我们让他们在请求时发送一个特殊参数,这告诉我们的服务器总是发送200,即使不是正确的响应。 |
|
|
9
0
我做过关于500这个数字的噩梦。 |
|
|
10
0
当您的Web应用程序引发异常时,Aida/Web中会返回500内部服务器错误。因为这是一个Smalltalk应用程序,所以当用户得到500和一个短堆栈时,服务器上会出现一个异常窗口(如果你以满负荷运行它)。 当然,在服务器继续运行的同时,您可以在服务器上打开一个完整的调试器并尝试解决问题。另一件好事是,具有全栈的异常窗口正等着你,直到你回来。 结论:500是福,不是噩梦! |
|
|
11
0
我使用409而不是400来处理错误的用户数据(即表单提交)。 409的规范继续讨论版本冲突,但它提到应在响应中发送有关如何修复问题的信息。非常适合格式错误的电子邮件或错误的密码消息。 400只解决了语法问题,在我看来,这个请求根本没有意义,而不是失败了一些正则表达式。 |
|
|
12
-5
我使用webmachine,它可以自动生成正确的错误代码。但在某些情况下,我需要自己提供。我发现在这些情况下返回666对开发和调试很有帮助,所以我可以很容易地分辨出哪些来自我的代码,哪些来自webmachine。此外,当它出现时,我会咯咯地笑出来。您必须记住在部署之前更改此设置。 |