Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7235 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Updates: 2617 greenbytes
Category: Standards Track June 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7235 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Updates: 2617 greenbytes
Category: Standards Track June 2014
ISSN: 2070-1721
Hypertext Transfer Protocol (HTTP/1.1): Authentication
超文本传输协议（HTTP/1.1）：身份验证
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.
超文本传输协议（HTTP）是用于分布式、协作式超媒体信息系统的无状态应用程序级协议。本文档定义了HTTP身份验证框架。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7235.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7235.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。本协议某些部分的版权控制人
material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
材料可能未授予IETF信托允许在IETF标准过程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conformance and Error Handling .............................3
1.2. Syntax Notation ............................................3
2. Access Authentication Framework .................................3
2.1. Challenge and Response .....................................3
2.2. Protection Space (Realm) ...................................5
3. Status Code Definitions .........................................6
3.1. 401 Unauthorized ...........................................6
3.2. 407 Proxy Authentication Required ..........................6
4. Header Field Definitions ........................................7
4.1. WWW-Authenticate ...........................................7
4.2. Authorization ..............................................8
4.3. Proxy-Authenticate .........................................8
4.4. Proxy-Authorization ........................................9
5. IANA Considerations .............................................9
5.1. Authentication Scheme Registry .............................9
5.1.1. Procedure ...........................................9
5.1.2. Considerations for New Authentication Schemes ......10
5.2. Status Code Registration ..................................11
5.3. Header Field Registration .................................11
6. Security Considerations ........................................12
6.1. Confidentiality of Credentials ............................12
6.2. Authentication Credentials and Idle Clients ...............12
6.3. Protection Spaces .........................................13
7. Acknowledgments ................................................14
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................14
Appendix A. Changes from RFCs 2616 and 2617 .......................16
Appendix B. Imported ABNF .........................................16
Appendix C. Collected ABNF ........................................17
Index .............................................................18
1. Introduction ....................................................3
1.1. Conformance and Error Handling .............................3
1.2. Syntax Notation ............................................3
2. Access Authentication Framework .................................3
2.1. Challenge and Response .....................................3
2.2. Protection Space (Realm) ...................................5
3. Status Code Definitions .........................................6
3.1. 401 Unauthorized ...........................................6
3.2. 407 Proxy Authentication Required ..........................6
4. Header Field Definitions ........................................7
4.1. WWW-Authenticate ...........................................7
4.2. Authorization ..............................................8
4.3. Proxy-Authenticate .........................................8
4.4. Proxy-Authorization ........................................9
5. IANA Considerations .............................................9
5.1. Authentication Scheme Registry .............................9
5.1.1. Procedure ...........................................9
5.1.2. Considerations for New Authentication Schemes ......10
5.2. Status Code Registration ..................................11
5.3. Header Field Registration .................................11
6. Security Considerations ........................................12
6.1. Confidentiality of Credentials ............................12
6.2. Authentication Credentials and Idle Clients ...............12
6.3. Protection Spaces .........................................13
7. Acknowledgments ................................................14
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................14
Appendix A. Changes from RFCs 2616 and 2617 .......................16
Appendix B. Imported ABNF .........................................16
Appendix C. Collected ABNF ........................................17
Index .............................................................18
HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. This document defines HTTP/1.1 authentication in terms of the architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" [RFC7230], including the general framework previously described in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617] and the related fields and status codes previously defined in "Hypertext Transfer Protocol -- HTTP/1.1" [RFC2616].
HTTP通过一组可扩展的质询-响应身份验证方案提供了访问控制和身份验证的通用框架，服务器可以使用这些方案质询客户端请求，客户端可以使用这些方案提供身份验证信息。本文档根据“超文本传输协议（HTTP/1.1）：消息语法和路由”[RFC7230]中定义的体系结构定义了HTTP/1.1身份验证，包括前面在“HTTP身份验证：基本和摘要访问身份验证”[RFC2617]中描述的通用框架以及之前在“超文本传输协议——HTTP/1.1”[RFC2616]中定义的相关字段和状态代码。
The IANA Authentication Scheme Registry (Section 5.1) lists registered authentication schemes and their corresponding specifications, including the "basic" and "digest" authentication schemes previously defined by RFC 2617.
IANA认证方案注册表（第5.1节）列出了注册的认证方案及其相应规范，包括RFC 2617先前定义的“基本”和“摘要”认证方案。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
[RFC7230]第2.5节定义了与错误处理相关的一致性标准和注意事项。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.
本规范使用[RFC7230]第7节中定义的[RFC5234]的增广巴科斯-诺尔形式（ABNF）符号和列表扩展，允许使用“#”运算符（类似于“*”运算符表示重复）对逗号分隔的列表进行紧凑定义。附录B描述了从其他文件导入的规则。附录C显示了收集的语法，所有列表运算符都扩展为标准ABNF表示法。
HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for achieving
HTTP提供了一个简单的质询-响应身份验证框架，服务器可以使用该框架质询客户机请求，客户机可以使用该框架提供身份验证信息。它使用不区分大小写的令牌作为标识身份验证方案的手段，然后是实现身份验证所需的附加信息
authentication via that scheme. The latter can be either a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
通过该方案进行身份验证。后者可以是逗号分隔的参数列表，也可以是能够保存base64编码信息的单个字符序列。
Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name MUST only occur once per challenge.
身份验证参数是名称=值对，其中名称令牌不区分大小写进行匹配，每个参数名称在每个质询中只能出现一次。
auth-scheme = token
auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )
auth-param = token BWS "=" BWS ( token / quoted-string )
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
The token68 syntax allows the 66 unreserved URI characters ([RFC3986]), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace ([RFC4648]).
token68语法允许66个无保留URI字符（[RFC3986]）以及其他一些字符，因此它可以保存base64、base64url（URL和文件名安全字母表）、base32或base16（十六进制）编码，包括或不包括填充，但不包括空格（[RFC4648]）。
A 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent, including a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
401（未经授权）响应消息由源服务器用于质询用户代理的授权，包括包含至少一个适用于所请求资源的质询的WWW-Authenticate报头字段。
A 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client, including a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
代理使用407（需要代理身份验证）响应消息来质询客户端的授权，包括代理身份验证报头字段，该字段包含至少一个适用于所请求资源的代理的质询。
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Note: Many clients fail to parse a challenge that contains an unknown scheme. A workaround for this problem is to list well-supported schemes (such as "basic") first.
注意：许多客户端无法解析包含未知方案的质询。解决这个问题的一个方法是首先列出支持良好的方案（如“basic”）。
A user agent that wishes to authenticate itself with an origin server
-- usually, but not necessarily, after receiving a 401 (Unauthorized)
-- can do so by including an Authorization header field with the
request.
A user agent that wishes to authenticate itself with an origin server
-- usually, but not necessarily, after receiving a 401 (Unauthorized)
-- can do so by including an Authorization header field with the
request.
A client that wishes to authenticate itself with a proxy -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) -- can do so by including a Proxy-Authorization header field with the request.
希望使用代理对自己进行身份验证的客户机（通常，但不一定，在收到407（需要代理身份验证）后）可以通过在请求中包含代理授权头字段来实现。
Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate. Transmission of credentials within header field values implies significant security considerations regarding the confidentiality of the underlying connection, as described in Section 6.1.
“授权”字段值和“代理授权”字段值都包含所请求资源领域的客户端凭据，该凭据基于响应中接收到的质询（可能是在过去的某个时间）。在创建它们的值时，用户代理应该通过选择它认为最安全的身份验证方案（它理解该方案）的质询，并根据需要从用户处获取凭据来实现。如第6.1节所述，在标头字段值内传输凭据意味着有关基础连接机密性的重要安全考虑。
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server SHOULD send a 401 (Unauthorized) response that contains a WWW-Authenticate header field with at least one (possibly new) challenge applicable to the requested resource.
在收到对受保护资源的请求时，如果请求中忽略了凭据、包含无效凭据（例如，错误的密码）或部分凭据（例如，当身份验证方案需要多次往返时），则源服务器应发送401（未经授权）响应，该响应包含至少包含一个凭据的WWW Authenticate标头字段适用于请求的资源的（可能是新的）质询。
Likewise, upon receipt of a request that omits proxy credentials or contains invalid or partial proxy credentials, a proxy that requires authentication SHOULD generate a 407 (Proxy Authentication Required) response that contains a Proxy-Authenticate header field with at least one (possibly new) challenge applicable to the proxy.
同样，在收到忽略代理凭据或包含无效或部分代理凭据的请求时，需要身份验证的代理应生成407（需要代理身份验证）响应，该响应包含代理身份验证标头字段，其中至少有一个（可能是新的）质询适用于该代理。
A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code (Section 6.5.3 of [RFC7231]).
接收到不足以获得访问权限的有效凭据的服务器应以403（禁止）状态代码响应（RFC7231的第6.5.3节）。
HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.
HTTP不会将应用程序限制在这个简单的质询-响应框架中进行访问身份验证。可以使用其他机制，例如在传输级别或通过消息封装进行身份验证，并使用指定身份验证信息的附加头字段。但是，本规范未定义此类附加机制。
The "realm" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.
“realm”身份验证参数保留供希望指示保护范围的身份验证方案使用。
A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI; see Section 5.5 of [RFC7230]) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources on a server to be partitioned into a set of protection
保护空间由被访问服务器的规范根URI（有效请求URI的方案和权限组件；参见[RFC7230]第5.5节）以及领域值（如果存在）定义。这些领域允许将服务器上受保护的资源划分为一组保护
spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but with different realms.
空间，每个空间都有自己的身份验证方案和/或授权数据库。领域值是一个字符串，通常由源服务器分配，可以具有特定于身份验证方案的附加语义。请注意，一个响应可以有多个具有相同身份验证方案但具有不同领域的挑战。
The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a configurable inactivity timeout). Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server.
保护空间确定可以自动应用凭据的域。如果先前的请求已被授权，则用户代理可以在由认证方案、参数和/或用户首选项（例如可配置的不活动超时）确定的时间段内对该保护空间内的所有其他请求重用相同的凭据。除非身份验证方案特别允许，否则单个保护空间不能扩展到其服务器的范围之外。
For historical reasons, a sender MUST only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability with existing clients that have been accepting both notations for a long time.
出于历史原因，发送方只能生成带引号的字符串语法。收件人可能必须同时支持令牌和带引号的字符串语法，以便与长期以来接受这两种符号的现有客户端实现最大的互操作性。
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
401（未经授权）状态代码表示请求尚未应用，因为它缺少目标资源的有效身份验证凭据。生成401响应的服务器必须发送包含至少一个适用于目标资源的质询的WWW Authenticate标头字段（第4.1节）。
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
如果请求包括身份验证凭据，则401响应表示已拒绝这些凭据的授权。用户代理可以使用新的或替换的授权标头字段重复请求（第4.2节）。如果401响应包含与先前响应相同的质询，并且用户代理已经尝试了至少一次身份验证，那么用户代理应该向用户呈现所附的表示，因为它通常包含相关的诊断信息。
The 407 (Proxy Authentication Required) status code is similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy. The proxy MUST send a Proxy-Authenticate header field (Section 4.3) containing a challenge applicable to that proxy for the target resource. The client MAY repeat the request with a new or replaced Proxy-Authorization header field (Section 4.4).
407（需要代理身份验证）状态代码类似于401（未经授权），但它表示客户端需要进行自身身份验证才能使用代理。代理必须发送一个代理身份验证标头字段（第4.3节），其中包含适用于该代理的针对目标资源的质询。客户端可以使用新的或替换的代理授权标头字段重复请求（第4.4节）。
This section defines the syntax and semantics of header fields related to the HTTP authentication framework.
本节定义了与HTTP身份验证框架相关的头字段的语法和语义。
The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.
“WWW Authenticate”标头字段表示适用于目标资源的身份验证方案和参数。
WWW-Authenticate = 1#challenge
WWW Authenticate=1#挑战
A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge. A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response.
生成401（未经授权）响应的服务器必须发送包含至少一个质询的WWW Authenticate标头字段。服务器可以在其他响应消息中生成WWW Authenticate标头字段，以指示提供凭据（或不同凭据）可能会影响响应。
A proxy forwarding a response MUST NOT modify any WWW-Authenticate fields in that response.
转发响应的代理不得修改该响应中的任何WWW身份验证字段。
User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times.
建议用户代理在解析字段值时特别小心，因为它可能包含多个质询，并且每个质询可以包含以逗号分隔的身份验证参数列表。此外，标题字段本身可能出现多次。
For instance:
例如：
WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple"
WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple"
This header field contains two challenges; one for the "Newauth" scheme with a realm value of "apps", and two additional parameters "type" and "title", and another one for the "Basic" scheme with a realm value of "simple".
此标题字段包含两个挑战；一个用于领域值为“apps”的“Newauth”方案，另外两个参数为“type”和“title”，另一个用于领域值为“simple”的“Basic”方案。
Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value and thus is harmless.
注意：质询语法产品也使用列表语法。因此，逗号、空格和逗号的序列可以视为应用于前面的质询，也可以视为质询列表中的空条目。实际上，这种歧义不会影响头字段值的语义，因此是无害的。
The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
“Authorization”头字段允许用户代理在收到401（未经授权）响应后，向源服务器进行身份验证。其值由包含所请求资源领域的用户代理的身份验证信息的凭据组成。
Authorization = credentials
Authorization = credentials
If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).
如果一个请求经过身份验证并指定了一个域，则假定相同的凭据对该域中的所有其他请求有效（假设身份验证方案本身不需要其他凭据，例如根据质询值或使用同步时钟而变化的凭据）。
A proxy forwarding a request MUST NOT modify any Authorization fields in that request. See Section 3.2 of [RFC7234] for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
转发请求的代理不得修改该请求中的任何授权字段。有关HTTP缓存处理授权字段的详细信息和要求，请参见[RFC7234]第3.2节。
The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy for this effective request URI (Section 5.5 of [RFC7230]). A proxy MUST send at least one Proxy-Authenticate header field in each 407 (Proxy Authentication Required) response that it generates.
“Proxy Authenticate”（代理验证）标头字段至少包含一个质询，该质询指示适用于此有效请求URI的代理的验证方案和参数（RFC7230）的第5.5节）。代理必须在其生成的每个407（需要代理身份验证）响应中至少发送一个代理身份验证标头字段。
Proxy-Authenticate = 1#challenge
代理身份验证=1#挑战
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authenticate is being forwarded because each proxy will send the same challenge set.
与WWW-Authenticate不同，Proxy-Authenticate头字段仅适用于响应链上的下一个出站客户端。这是因为只有选择了给定代理的客户端才可能具有身份验证所需的凭据。但是，当在同一管理域中使用多个代理时，例如大型公司网络中的办公室和区域缓存代理，通常由用户代理生成凭据并通过层次结构传递，直到使用为止。因此，在这种配置中，似乎正在转发代理身份验证，因为每个代理都将发送相同的质询集。
Note that the parsing considerations for WWW-Authenticate apply to this header field as well; see Section 4.1 for details.
请注意，WWW Authenticate的解析注意事项也适用于此标头字段；详见第4.1节。
The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication. Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the resource being requested.
“Proxy Authorization”标头字段允许客户端向需要身份验证的代理标识自己（或其用户）。它的值由包含所请求资源的代理和/或领域的客户端身份验证信息的凭据组成。
Proxy-Authorization = credentials
Proxy-Authorization = credentials
Unlike Authorization, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.
与授权不同，Proxy Authorization header字段仅适用于要求使用Proxy Authenticate字段进行身份验证的下一个入站代理。当链中使用多个代理时，代理授权标头字段将由第一个预期接收凭据的入站代理使用。代理可以将来自客户端请求的凭据中继到下一个代理，如果这是代理协同验证给定请求的机制。
The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the authentication schemes in challenges and credentials. It has been created and is now maintained at <http://www.iana.org/assignments/http-authschemes>.
“超文本传输协议（HTTP）身份验证方案注册表”定义了挑战和凭据中身份验证方案的命名空间。它已创建，现在维护在<http://www.iana.org/assignments/http-authschemes>.
Registrations MUST include the following fields:
注册必须包括以下字段：
o Authentication Scheme Name
o 身份验证方案名称
o Pointer to specification text
o 指向规范文本的指针
o Notes (optional)
o 注释（可选）
Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
添加到此命名空间的值需要IETF审查（请参见[RFC5226]，第4.1节）。
There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can work:
HTTP身份验证框架的某些方面限制了新身份验证方案的工作方式：
o HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 2.3 of [RFC7230]).
o HTTP身份验证被认为是无状态的：对请求进行身份验证所需的所有信息都必须在请求中提供，而不是依赖于服务器来记住以前的请求。基于或绑定到基础连接的身份验证不在本规范的范围内，并且存在固有缺陷，除非采取措施确保除已认证用户之外的任何一方不能使用该连接（请参见[RFC7230]第2.3节）。
o The authentication parameter "realm" is reserved for defining protection spaces as described in Section 2.2. New schemes MUST NOT use it in a way incompatible with that definition.
o 身份验证参数“realm”保留用于定义保护空间，如第2.2节所述。新方案不得以与该定义不兼容的方式使用它。
o The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge or credential. Thus, new schemes ought to use the auth-param syntax instead, because otherwise future extensions will be impossible.
o 引入“token68”符号是为了与现有身份验证方案兼容，并且每个质询或凭证只能使用一次。因此，新方案应该改用auth-param语法，否则未来的扩展将是不可能的。
o The parsing of challenges and credentials is defined by this specification and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes.
o 质询和凭据的解析由本规范定义，不能由新的身份验证方案修改。使用auth param语法时，所有参数都应支持标记和带引号的字符串语法，并且应在解析后（即带引号的字符串处理）在字段值上定义语法约束。这是必要的，以便收件人可以使用适用于所有身份验证方案的通用解析器。
Note: The fact that the value syntax for the "realm" parameter is restricted to quoted-string was a bad design choice not to be repeated for new parameters.
注意：“realm”参数的值语法被限制为带引号的字符串这一事实是一个错误的设计选择，不能对新参数重复。
o Definitions of new schemes ought to define the treatment of unknown extension parameters. In general, a "must-ignore" rule is preferable to a "must-understand" rule, because otherwise it will be hard to introduce new parameters in the presence of legacy recipients. Furthermore, it's good to describe the policy for defining new parameters (such as "update the specification" or "use this registry").
o 新方案的定义应定义未知扩展参数的处理。一般来说，“必须忽略”规则比“必须理解”规则更可取，因为否则在遗留收件人在场的情况下很难引入新参数。此外，最好描述定义新参数的策略（例如“更新规范”或“使用此注册表”）。
o Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), and/or proxy authentication (i.e., using Proxy-Authenticate).
o 身份验证方案需要记录它们是否可用于源服务器身份验证（即使用WWW身份验证）和/或代理身份验证（即使用代理身份验证）。
o The credentials carried in an Authorization header field are specific to the user agent and, therefore, have the same effect on HTTP caches as the "private" Cache-Control response directive (Section 5.2.2.6 of [RFC7234]), within the scope of the request in which they appear.
o 授权标头字段中携带的凭据特定于用户代理，因此，在其出现的请求范围内，对HTTP缓存的影响与“专用”缓存控制响应指令（RFC7234的第5.2.2.6节）相同。
Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response directives (e.g., "private").
因此，选择不在授权标头字段中携带凭证的新身份验证方案（例如，使用新定义的标头字段）将需要通过强制使用缓存控制请求指令（例如，[RFC7234]第5.2.1.5节“无存储”）或响应指令（例如，“专用”）来明确禁止缓存。
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at <http://www.iana.org/assignments/http-status-codes> has been updated with the registrations below:
“超文本传输协议（HTTP）状态代码注册表”位于<http://www.iana.org/assignments/http-status-codes>已更新以下注册信息：
+-------+-------------------------------+-------------+
| Value | Description | Reference |
+-------+-------------------------------+-------------+
| 401 | Unauthorized | Section 3.1 |
| 407 | Proxy Authentication Required | Section 3.2 |
+-------+-------------------------------+-------------+
+-------+-------------------------------+-------------+
| Value | Description | Reference |
+-------+-------------------------------+-------------+
| 401 | Unauthorized | Section 3.1 |
| 407 | Proxy Authentication Required | Section 3.2 |
+-------+-------------------------------+-------------+
HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.
HTTP头字段在“消息头”注册表中注册，该注册表维护在<http://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).
本文档定义了以下HTTP头字段，因此“永久消息头字段名称”注册表已相应更新（请参见[BCP90]）。
+---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+
| Authorization | http | standard | Section 4.2 |
| Proxy-Authenticate | http | standard | Section 4.3 |
| Proxy-Authorization | http | standard | Section 4.4 |
| WWW-Authenticate | http | standard | Section 4.1 |
+---------------------+----------+----------+-------------+
+---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+
| Authorization | http | standard | Section 4.2 |
| Proxy-Authenticate | http | standard | Section 4.3 |
| Proxy-Authorization | http | standard | Section 4.4 |
| WWW-Authenticate | http | standard | Section 4.1 |
+---------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
变更控制者是：“IETF(iesg@ietf.org)-互联网工程工作队”。
This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP authentication. More general security considerations are addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
本节旨在告知开发人员、信息提供商和用户特定于HTTP身份验证的已知安全问题。HTTP消息传递[RFC7230]和语义[RFC7231]中介绍了更一般的安全注意事项。
Everything about the topic of HTTP authentication is a security consideration, so the list of considerations below is not exhaustive. Furthermore, it is limited to security considerations regarding the authentication framework, in general, rather than discussing all of the potential considerations for specific authentication schemes (which ought to be documented in the specifications that define those schemes). Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]), including common pitfalls for implementing and using the authentication schemes found in practice.
HTTP身份验证主题的所有内容都是安全考虑因素，因此下面列出的考虑因素并不详尽。此外，一般来说，它仅限于关于认证框架的安全考虑，而不是讨论特定认证方案的所有潜在考虑（应该在定义这些方案的规范中记录）。各种组织都维护有关Web应用程序安全性（例如[OWASP]）的最新研究的主题信息和链接，包括实施和使用实践中发现的身份验证方案的常见缺陷。
The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials; instead, each authentication scheme defines how the credentials are encoded prior to transmission. While this provides flexibility for the development of future authentication schemes, it is inadequate for the protection of existing schemes that provide no confidentiality on their own, or that do not sufficiently protect against replay attacks. Furthermore, if the server expects credentials that are specific to each individual user, the exchange of those credentials will have the effect of identifying that user even if the content within credentials remains confidential.
HTTP身份验证框架没有定义维护凭据机密性的单一机制；相反，每个身份验证方案定义了凭证在传输之前的编码方式。虽然这为未来身份验证方案的开发提供了灵活性，但它不足以保护现有方案，这些方案本身不提供保密性，或者不能充分防止重播攻击。此外，如果服务器需要特定于每个用户的凭据，则即使凭据中的内容仍然保密，这些凭据的交换也将具有识别该用户的效果。
HTTP depends on the security properties of the underlying transport-or session-level connection to provide confidential transmission of header fields. In other words, if a server limits access to authenticated users using this framework, the server needs to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used. For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", [RFC5246]) prior to exchanging any credentials.
HTTP依赖于底层传输或会话级连接的安全属性来提供头字段的机密传输。换句话说，如果服务器限制使用此框架的经过身份验证的用户的访问，则服务器需要根据所使用的身份验证方案的性质确保连接的安全性。例如，依赖于单个用户身份验证的服务通常需要在交换任何凭据之前使用TLS（“传输层安全性”[RFC5246]）保护连接。
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials are obtained
现有HTTP客户端和用户代理通常无限期地保留身份验证信息。HTTP不提供源服务器指示客户端丢弃这些缓存凭据的机制，因为该协议不知道如何获取凭据
or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of an authentication scheme definition.
或由用户代理管理。凭据过期或撤消机制可以作为身份验证方案定义的一部分指定。
Circumstances under which credential caching can interfere with the application's security model include but are not limited to:
凭据缓存可能干扰应用程序安全模型的情况包括但不限于：
o Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt the user for credentials.
o 长时间处于空闲状态的客户端，之后服务器可能希望使客户端重新提示用户提供凭据。
o Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the server side of the application "knows" that there is no further reason for the client to retain the credentials.
o 包含会话终止指示（例如页面上的“注销”或“提交”按钮）的应用程序，在此指示之后，应用程序的服务器端“知道”客户端没有进一步的理由保留凭据。
User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.
鼓励缓存凭据的用户代理提供易于访问的机制，以便在用户控制下丢弃缓存的凭据。
Authentication schemes that solely rely on the "realm" mechanism for establishing a protection space will expose credentials to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the same authentication credentials for other resources on the same origin server. This makes it possible for a different resource to harvest authentication credentials for other resources.
仅依靠“领域”机制建立保护空间的身份验证方案将向源服务器上的所有资源公开凭据。已成功使用资源发出身份验证请求的客户端可以对同一源服务器上的其他资源使用相同的身份验证凭据。这使得其他资源可以获取其他资源的身份验证凭据。
This is of particular concern when an origin server hosts resources for multiple parties under the same canonical root URI (Section 2.2). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content of the Authorization request header field available), and separating protection spaces by using a different host name (or port number) for each party.
当源服务器在同一个规范根URI下为多方托管资源时，这一点尤其值得关注（第2.2节）。可能的缓解策略包括限制对身份验证凭据的直接访问（即，不使授权请求标头字段的内容可用），以及通过为每一方使用不同的主机名（或端口号）来分隔保护空间。
This specification takes over the definition of the HTTP Authentication Framework, previously defined in RFC 2617. We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on that specification. See Section 6 of [RFC2617] for further acknowledgements.
本规范接管了先前在RFC2617中定义的HTTP身份验证框架的定义。我们感谢John Franks、Phillip M.Hallam Baker、Jeffery L.Hostetler、Scott D.Lawrence、Paul J.Leach、Ari Luotonen和Lawrence C.Stewart在该规范方面所做的工作。有关进一步确认，请参见[RFC2617]第6节。
See Section 10 of [RFC7230] for the Acknowledgments related to this document revision.
有关本文件版本的确认，请参见[RFC7230]第10节。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，2014年6月。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[BCP90]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web Applications and Web Services", The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <https://www.owasp.org/>.
[OWASP]van der Stock，A.，Ed.，“构建安全Web应用程序和Web服务指南”，开放Web应用程序安全项目（OWASP）2.0.12005年7月<https://www.owasp.org/>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
The framework for HTTP Authentication is now defined by this document, rather than RFC 2617.
HTTP身份验证的框架现在由本文档定义，而不是RFC2617。
The "realm" parameter is no longer always required on challenges; consequently, the ABNF allows challenges without any auth parameters. (Section 2)
挑战不再总是需要“realm”参数；因此，ABNF允许在没有任何auth参数的情况下进行质询。（第2节）
The "token68" alternative to auth-param lists has been added for consistency with legacy authentication schemes such as "Basic". (Section 2)
为了与传统身份验证方案（如“Basic”）保持一致，添加了auth param列表的“token68”替代方案。（第2节）
This specification introduces the Authentication Scheme Registry, along with considerations for new authentication schemes. (Section 5.1)
本规范介绍了身份验证方案注册表，以及新身份验证方案的注意事项。（第5.1节）
The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).
根据[RFC5234]附录B.1中的定义，以下核心规则通过引用包括在内：ALPHA（字母）、CR（回车）、CRLF（CR LF）、CTL（控件）、Digital（十进制0-9）、DQUOTE（双引号）、HEXDIG（十六进制0-9/A-F/A-F）、LF（换行符）、OCTET（任何8位数据序列）、SP（空格）和VCHAR（任何可见的US-ASCII字符）。
The rules below are defined in [RFC7230]:
[RFC7230]中定义了以下规则：
BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].
在下面收集的ABNF中，列表规则按照[RFC7230]的第1.2节展开。
Authorization = credentials
Authorization = credentials
BWS = <BWS, see [RFC7230], Section 3.2.3>
BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
challenge ] )
Proxy-Authorization = credentials
Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
challenge ] )
Proxy-Authorization = credentials
WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
] )
WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
] )
auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token
challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
OWS "," [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
*( OWS "," [ OWS auth-param ] ) ] ) ]
challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
OWS "," [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
*( OWS "," [ OWS auth-param ] ) ] ) ]
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"="
token = <token, see [RFC7230], Section 3.2.6>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"="
Index
指数
4 401 Unauthorized (status code) 6 407 Proxy Authentication Required (status code) 6
4 401未经授权（状态代码）6 407需要代理身份验证（状态代码）6
A Authorization header field 8
授权标头字段8
C Canonical Root URI 5
C规范根URI 5
G Grammar auth-param 4 auth-scheme 4 Authorization 8 challenge 4 credentials 5 Proxy-Authenticate 8 Proxy-Authorization 9 token68 4 WWW-Authenticate 7
G语法身份验证参数4身份验证方案4授权8质询4凭据5代理身份验证8代理授权9令牌68 4 WWW身份验证7
P Protection Space 5 Proxy-Authenticate header field 8 Proxy-Authorization header field 9
P保护空间5代理身份验证标头字段8代理授权标头字段9
R Realm 5
R领域5
W WWW-Authenticate header field 7
W WWW验证头字段7
Authors' Addresses
作者地址
Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
Roy T.Fielding（编辑）美国加利福尼亚州圣何塞公园大道345号Adobe系统公司，邮编95110
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke（编辑）greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/