互联网工程任务组 (IETF)

M. Nottingham

请求评论： 6585

Rackspace

更新： 2616

R. Fielding

类别：标准轨道

Adobe

ISSN： 2070-1721

2012年4月

附加的 HTTP 状态码

本备忘录的状态

这是一个互联网标准轨道文档。

本文档由互联网工程任务组 (IETF) 制作。它代表了 IETF 社区的一致意见。它已接受公开审查并已获得互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参见 RFC 5741 第2节。

有关本文件当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6585。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 引言
2. 要求
3. 428 需要先决条件
4. 429 请求过多
5. 431 请求报头字段过大
6. 511 需要网络认证
7. 安全性考虑
8. IANA 注意事项
9. 参考文献
Appendix A. 致谢
Appendix B. 由强制门户引发的问题
Authors' Addresses

1. 引言

本文档为各种常见情况指定了附加的 HTTP [RFC2616] 状态码，以改进互操作性并在使用其他不太精确的状态码时避免产生混淆。

请注意，这些状态码是可选的；不能强制要求服务器支持它们。然而，因为客户端会将未知状态码视为同一类的通用错误（例如，如果未被识别，499 会被视为 400），现有服务器可以安全地部署这些状态码（更多信息请参见 [RFC2616] 第6.1.1 节）。

2. 要求

本文档中关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 的解释应当依照 [RFC2119] 中的说明进行。

3. 428 需要先决条件

428 状态码表示源服务器要求该请求为有条件请求。

它的典型用途是避免“丢失更新”（lost update）问题：客户端 GET 了资源的状态，修改后又 PUT 回服务器，而与此同时第三方已修改了服务器上的状态，导致冲突。通过要求请求为有条件的，服务器可以确保客户端正在使用正确的副本。

使用该状态码的响应应当解释如何成功地重新提交请求。例如：

HTTP/1.1 428 需要先决条件
Content-Type: text/html

<html>
   <head>
      <title>需要先决条件</title>
   </head>
   <body>
      <h1>需要先决条件</h1>
      <p>此请求需要为有条件请求；
      尝试使用 "If-Match".</p>
   </body>
</html>

带有 428 状态码的响应不得被缓存所存储。

4. 429 请求过多

429 状态码表示用户在给定时间内发送了过多请求（“速率限制”）。

响应表示应当包含解释该状况的详细信息，并且可以包含一个 Retry-After 首部来指示在再次发起请求之前需要等待的时间。

例如：

HTTP/1.1 429 请求过多
Content-Type: text/html
Retry-After: 3600

<html>
   <head>
      <title>请求过多</title>
   </head>
   <body>
      <h1>请求过多</h1>
      <p>每个登录用户我每小时仅允许对该网站发起 50 次请求。
         请稍后再试。</p>
   </body>
</html>

注意，本规范并未定义源服务器如何识别用户，也未定义如何计数请求。例如，一个限制请求速率的源服务器可以基于按资源计数、整个服务器范围内计数，或甚至在一组服务器间计数来进行限制。同样，它可能通过认证凭证或有状态的 cookie 来识别用户。

带有 429 状态码的响应不得被缓存所存储。

5. 431 请求报头字段过大

431 状态码表示服务器不愿意处理该请求，因为其报头字段过大。可以在减小请求报头字段的大小后重新提交该请求。

该状态码既可用于整个请求报头字段集合过大时，也可用于单个报头字段过大时。在后者情况下，响应表示应当指明哪个报头字段过大。

例如：

HTTP/1.1 431 请求报头字段过大
Content-Type: text/html

<html>
   <head>
      <title>请求报头字段过大</title>
   </head>
   <body>
      <h1>请求报头字段过大</h1>
      <p>“Example” 报头过大。</p>
   </body>
</html>

带有 431 状态码的响应不得被缓存所存储。

6. 511 需要网络认证

511 状态码表示客户端需要进行认证以获得网络访问权限。

响应表示应当包含一个指向允许用户提交凭证的资源的链接（例如，带有 HTML 表单的页面）。

注意，511 响应不应当包含挑战或登录界面本身，因为浏览器会将登录界面显示为与原始请求的 URL 相关联，这可能会导致混淆。

511 状态不应由源服务器生成；它旨在由作为控制网络访问手段的拦截代理使用。

带有 511 状态码的响应不得被缓存所存储。

6.1. 511 状态码与强制门户

511 状态码旨在缓解“强制门户”（captive portals）对期望从请求所指向的服务器获得响应的软件（尤其是非浏览器代理）造成的问题，而不是鼓励部署强制门户——仅用于限制其造成的损害。

希望在授予访问权限之前要求某些认证、接受条款或其他用户交互的网络运营者通常通过其媒体访问控制（MAC）地址来识别尚未完成这些操作的客户端（“未知客户端”）。

对于未知客户端，通常会阻止所有流量，除了 TCP 端口 80 的流量会被发送到一个专用于“登录”未知客户端的 HTTP 服务器（“登录服务器”），以及发往登录服务器本身的流量。

例如，用户代理可能连接到网络并在 TCP 端口 80 上发出如下 HTTP 请求：

GET /index.htm HTTP/1.1
Host: www.example.com

登录服务器在接收到此类请求后会生成一个 511 响应：

HTTP/1.1 511 需要网络认证
Content-Type: text/html

<html>
   <head>
      <title>需要网络认证</title>
      <meta http-equiv="refresh" 
            content="0; url=https://login.example.net/">
   </head>
   <body>
      <p>您需要在本地网络上 <a href="https://login.example.net/">
      进行认证</a> 才能获得访问权限。</p>
   </body>
</html>

在这里，511 状态码可以保证非浏览器客户端不会将响应解释为来自源服务器，并且 META HTML 元素会将用户代理重定向到登录服务器。

7. 安全性考虑

7.1. 428 需要先决条件

428 状态码是可选的；客户端不能依赖其来防止“丢失更新”冲突。

7.2. 429 请求过多

当服务器受到攻击或仅仅是从单一方收到了非常大量的请求时，用 429 状态码响应每个请求会消耗资源。

因此，服务器没有义务使用 429 状态码；在限制资源使用时，直接丢弃连接或采取其他措施可能更为合适。

7.3. 431 请求报头字段过大

服务器没有义务使用 431 状态码；在遭受攻击时，直接丢弃连接或采取其他措施可能更为合适。

7.4. 511 需要网络认证

在常见用法中，携带 511 状态码的响应并不会来自请求 URL 中指示的源服务器。这会带来许多安全问题；例如，攻击性的中间人可能会将 cookie 插入到原域名空间，可能会观察到从用户代理发送的 cookie 或 HTTP 认证凭证，等等。

然而，这些风险并非 511 状态码独有；换言之，没有使用该状态码的强制门户也会引入相同的问题。

此外，请注意，在安全套接层（SSL）或传输层安全（TLS）连接（通常为端口 443）上使用该状态码的强制门户会在客户端产生证书错误。

8. IANA 注意事项

HTTP 状态码注册表已使用以下条目进行更新：

Value: 428
Description: Precondition Required
Reference: [RFC6585]

Value: 429
Description: Too Many Requests
Reference: [RFC6585]

Value: 431
Description: Request Header Fields Too Large
Reference: [RFC6585]

Value: 511
Description: Network Authentication Required
Reference: [RFC6585]

9. 参考文献

9.1. 规范性引用文献

[RFC2119]: Bradner, S., “在 RFC 中用于指示要求级别的关键词”, BCP 14, RFC 2119, 1997 年 3 月。
[RFC2616]: Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “超文本传输协议 -- HTTP/1.1”, RFC 2616, 1999 年 6 月。

9.2. 参考性引用文献

[CORS]: van Kesteren, A., Ed., “跨域资源共享”, W3C 工作草案 WD-cors-20100727, 2010 年 7 月, <http://www.w3.org/TR/cors/>。
[Favicon]: Wikipedia, “Favicon”, 2012 年 3 月, <http://en.wikipedia.org/w/index.php?title=Favicon&oldid=484627550>。
[OAuth2.0]: Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 授权协议”, 工作进行中, 2012 年 3 月。
[P3P]: Marchiori, M., Ed., “隐私偏好平台 1.0 (P3P1.0) 规范”, W3C 推荐 REC-P3P-20020416, 2002 年 4 月, <http://www.w3.org/TR/P3P/>。
[RFC4791]: Daboo, C., Desruisseaux, B., and L. Dusseault, “WebDAV 的日历扩展 (CalDAV)”, RFC 4791, 2007 年 3 月。
[RFC4918]: Dusseault, L., Ed., “用于网络分布式创作与版本控制的 HTTP 扩展 (WebDAV)”, RFC 4918, 2007 年 6 月。
[WIDGETS]: Caceres, M., Ed., “Widget 打包与 XML 配置”, W3C 推荐 REC-widgets-20110927, 2011 年 9 月, <http://www.w3.org/TR/widgets/>。
[WebFinger]: WebFinger 项目, “WebFinger 协议 (草案)”, 2010 年 1 月, <http://code.google.com/p/webfinger/wiki/WebFingerProtocol>。

Appendix A. 致谢

感谢 Jan Algermissen 和 Julian Reschke 的建议与反馈。

Appendix B. 由强制门户引发的问题

由于客户端无法区分门户的响应与它们本意要通信的 HTTP 服务器的响应，会产生许多问题。511 状态码旨在帮助缓解其中的一些问题。

一个例子是浏览器常用来标识被访问站点的 "favicon.ico" [Favicon]。如果某个站点的 favicon 被从强制门户而非目标站点获取（例如因为用户未认证），它常常会被浏览器的缓存“粘住”（大多数实现对 favicon 的缓存非常激进），超出门户会话的时间范围，从而看起来门户的 favicon 已“接管”了合法站点。

另一个基于浏览器的问题出现在支持隐私偏好平台 [P3P] 时。取决于其实现方式，浏览器可能会将门户对 p3p.xml 文件的响应解释为服务器的响应，导致门户所声明的隐私策略（或缺乏隐私策略）被解释为适用于目标站点。其他基于 Web 的协议例如 WebFinger [WebFinger]、跨域资源共享 [CORS] 和开放授权 [OAuth2.0] 也可能受到此类问题的影响。

尽管 HTTP 在浏览器中最为广泛使用，但越来越多的非浏览器应用程序将其用作底层协议。例如，网络分布式创作与版本控制 (WebDAV) [RFC4918] 和 WebDAV 的日历扩展 (CalDAV) [RFC4791] 都以 HTTP 为基础（分别用于远程创作和日历）。在强制门户后使用这些应用可能导致向用户显示虚假的错误，极端情况下可能导致内容损坏。

同样，其他使用 HTTP 的非浏览器应用也可能受到影响，例如小部件 [WIDGETS]、软件更新，以及其他专用软件如 Twitter 客户端和 iTunes 音乐商店。

应注意，有时人们认为使用 HTTP 重定向将流量导向门户可以解决这些问题。然而，由于许多使用场景会“跟随”重定向，这并不是一个好的解决方案。

Authors' Addresses

Mark Nottingham
Rackspace
Email: mnot@mnot.net
URI: http://www.mnot.net/

Roy T. Fielding
Adobe Systems Incorporated
345 Park Ave.
San Jose, CA 95110
USA
Email: fielding@gbiv.com
URI: http://roy.gbiv.com/