Internet Engineering Task Force (IETF) Y. Oiwa
Request for Comments: 8053 H. Watanabe
Category: Experimental H. Takagi
ISSN: 2070-1721 ITRI, AIST
K. Maeda
T. Hayashi
Lepidum
Y. Ioku
Individual Contributor
January 2017
Internet Engineering Task Force (IETF) Y. Oiwa
Request for Comments: 8053 H. Watanabe
Category: Experimental H. Takagi
ISSN: 2070-1721 ITRI, AIST
K. Maeda
T. Hayashi
Lepidum
Y. Ioku
Individual Contributor
January 2017
HTTP Authentication Extensions for Interactive Clients
交互式客户端的HTTP身份验证扩展
Abstract
摘要
This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.
本文档指定了交互式客户端HTTP身份验证框架的扩展。目前，HTTP级别身份验证的基本功能不足以满足各种基于Web的应用程序的复杂需求。这迫使这些应用程序通过HTML表单等方式实现自己的身份验证框架，这成为引入由服务器和用户代理联合处理的安全身份验证机制的障碍之一。扩展框架填补了Web应用程序需求和HTTP身份验证规定之间的空白，以解决上述问题，同时保持与HTTP身份验证的现有Web和非Web使用的兼容性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8053.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8053.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terms for Describing Authentication Protocol Flow . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8
3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8
3.1. Note on Optional-WWW-Authenticate and Use of
WWW-Authenticate Header with Non-401 Status . . . . . . . 10
4. Authentication-Control Header . . . . . . . . . . . . . . . . 11
4.1. Non-ASCII Extended Header Parameters . . . . . . . . . . 13
4.2. Auth-Style Parameter . . . . . . . . . . . . . . . . . . 13
4.3. Location-When-Unauthenticated Parameter . . . . . . . . . 14
4.4. No-Auth Parameter . . . . . . . . . . . . . . . . . . . . 15
4.5. Location-When-Logout Parameter . . . . . . . . . . . . . 16
4.6. Logout-Timeout Parameter . . . . . . . . . . . . . . . . 17
4.7. Username Parameter . . . . . . . . . . . . . . . . . . . 17
5. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Example 1: A Portal Site . . . . . . . . . . . . . . . . 19
5.1.1. Case 1: A Simple Application . . . . . . . . . . . . 19
5.1.2. Case 2: Specific Action Required on Logout . . . . . 20
5.1.3. Case 3: Specific Page Displayed before Login . . . . 20
5.2. Example 2: Authenticated User-Only Sites . . . . . . . . 20
5.3. When to Use Cookies . . . . . . . . . . . . . . . . . . . 21
5.4. Parallel Deployment with Form/Cookie Authentication . . . 22
6. Methods to Extend This Protocol . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Security Implication of the Username Parameter . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. (Informative) Applicability of Features for Each
Message . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terms for Describing Authentication Protocol Flow . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8
3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8
3.1. Note on Optional-WWW-Authenticate and Use of
WWW-Authenticate Header with Non-401 Status . . . . . . . 10
4. Authentication-Control Header . . . . . . . . . . . . . . . . 11
4.1. Non-ASCII Extended Header Parameters . . . . . . . . . . 13
4.2. Auth-Style Parameter . . . . . . . . . . . . . . . . . . 13
4.3. Location-When-Unauthenticated Parameter . . . . . . . . . 14
4.4. No-Auth Parameter . . . . . . . . . . . . . . . . . . . . 15
4.5. Location-When-Logout Parameter . . . . . . . . . . . . . 16
4.6. Logout-Timeout Parameter . . . . . . . . . . . . . . . . 17
4.7. Username Parameter . . . . . . . . . . . . . . . . . . . 17
5. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Example 1: A Portal Site . . . . . . . . . . . . . . . . 19
5.1.1. Case 1: A Simple Application . . . . . . . . . . . . 19
5.1.2. Case 2: Specific Action Required on Logout . . . . . 20
5.1.3. Case 3: Specific Page Displayed before Login . . . . 20
5.2. Example 2: Authenticated User-Only Sites . . . . . . . . 20
5.3. When to Use Cookies . . . . . . . . . . . . . . . . . . . 21
5.4. Parallel Deployment with Form/Cookie Authentication . . . 22
6. Methods to Extend This Protocol . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Security Implication of the Username Parameter . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. (Informative) Applicability of Features for Each
Message . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
This document defines several extensions to the current HTTP authentication framework, to provide functionality comparable with current, widely used, form-based Web authentication. A majority of the recent websites on the Internet use custom application-layer authentication implementations using Web forms. The reasons for these may vary, but many people believe that the current HTTP Basic and Digest authentication methods do not have enough functionality (including good user interfaces) to support most realistic Web-based applications. However, such use of form-based Web authentication has several weaknesses against attacks like phishing, because all behavior of the authentication is controlled from the server-side application. This makes it really hard to implement any cryptographically strong authentication mechanisms into Web systems. To overcome this problem, we need to "modernize" the HTTP authentication framework so that better client-controlled secure methods can be used with Web applications. The extensions proposed in this document include:
本文档定义了当前HTTP身份验证框架的几个扩展，以提供与当前广泛使用的基于表单的Web身份验证相当的功能。Internet上最近的大多数网站都使用自定义的应用程序层身份验证实现（使用Web表单）。原因可能各不相同，但许多人认为当前的HTTP基本和摘要身份验证方法没有足够的功能（包括良好的用户界面）来支持最现实的基于Web的应用程序。然而，这种基于表单的Web身份验证的使用在抵御网络钓鱼等攻击方面存在一些弱点，因为身份验证的所有行为都是由服务器端应用程序控制的。这使得在Web系统中实现任何加密强身份验证机制变得非常困难。为了克服这个问题，我们需要“现代化”HTTP身份验证框架，以便更好地将客户端控制的安全方法用于Web应用程序。本文件中提议的扩展包括：
o optional authentication on HTTP (Section 3),
o HTTP上的可选身份验证（第3节），
o log out from both the server and client side (Section 4), and
o 从服务器端和客户端注销（第4节），然后
o finer control for redirection depending on the authentication status (Section 4)
o 根据身份验证状态对重定向进行更精细的控制（第4节）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document distinguishes the terms "client" and "user" in the following way: a "client" is an entity understanding and talking HTTP and the specified authentication protocol, usually computer software; a "user" is a (usually natural) person who wants to access data resources using "a client".
本文档通过以下方式区分术语“客户机”和“用户”：“客户机”是一个理解并谈论HTTP和指定的身份验证协议（通常是计算机软件）的实体；“用户”是希望使用“客户端”访问数据资源的人（通常是自然人）。
HTTP Authentication defined in [RFC7235] can involve several pairs of HTTP requests/responses. Throughout this document, the following terms are used to categorize those messages.
[RFC7235]中定义的HTTP身份验证可能涉及多对HTTP请求/响应。在本文档中，以下术语用于对这些消息进行分类。
For requests:
对于请求：
1) A non-authenticating request is a request not attempting any authentication: a request without any Authorization header field.
1) 非身份验证请求是不尝试任何身份验证的请求：没有任何授权标头字段的请求。
2) An authenticating request is the opposite: a request with an Authorization header field.
2) 身份验证请求正好相反：具有授权标头字段的请求。
For responses:
有关答复：
1) A non-authenticated response is a response that does not involve any HTTP authentication. It does not contain any WWW-Authenticate ([RFC7235]) or Authentication-Info header field ([RFC7615]).
1) 未经身份验证的响应是不涉及任何HTTP身份验证的响应。它不包含任何WWW身份验证（[RFC7235]）或身份验证信息头字段（[RFC7615]）。
Servers send this response when the requested resource is not protected by an HTTP authentication mechanism. In the context of this specification, non-authentication-related negative responses (e.g., 403 and 404) are also considered non-authenticated responses.
当请求的资源不受HTTP身份验证机制保护时，服务器会发送此响应。在本规范的上下文中，与非认证相关的否定响应（例如403和404）也被视为非认证响应。
(See the note on successfully authenticated responses below for some ambiguous cases.)
（有关一些不明确的情况，请参阅下面关于成功验证响应的说明。）
2) An authentication-initializing response is a response that requires or allows clients to start authentication attempts. Servers send this response when the requested resource is protected by an HTTP authentication mechanism, and the request meets one of the following cases:
2) 身份验证初始化响应是要求或允许客户端启动身份验证尝试的响应。当请求的资源受HTTP身份验证机制保护，并且请求满足以下情况之一时，服务器会发送此响应：
* The request is a non-authenticating request, or
* 该请求是非身份验证请求，或
* The request contained an authentication trial directed to a protection space (realm) other than the one that the server expected.
* 该请求包含指向服务器期望的保护空间（领域）以外的保护空间（领域）的身份验证试验。
The server will specify the protection space for authentication in this response.
服务器将在此响应中指定身份验证的保护空间。
Upon receiving this response, the client's behavior is further divided to two possible cases:
收到此响应后，客户的行为进一步分为两种可能的情况：
* If the client has no prior knowledge on authentication credentials (e.g., a username and a password) related to the requested protection space, the protocol flow terminates and the client will ask the user to provide authentication credentials.
* 如果客户端事先不知道与请求的保护空间相关的身份验证凭据（例如用户名和密码），则协议流终止，客户端将要求用户提供身份验证凭据。
* On the other hand, if the client already has enough authentication credentials to the requested protection space, the client will automatically send an authenticating request. Such cases often occur when the client does not know beforehand that the current request-URL requires authentication.
* 另一方面，如果客户端已经有足够的身份验证凭据访问请求的保护空间，则客户端将自动发送身份验证请求。当客户端事先不知道当前请求URL需要身份验证时，通常会发生这种情况。
3) A successfully authenticated response is a response for an authenticating request meaning that the authentication attempt was granted. (Note: if the authentication scheme used does not use an Authentication-Info header field, it can't be distinguished from a non-authenticated response.)
3) 成功身份验证响应是对身份验证请求的响应，表示已授予身份验证尝试。（注意：如果使用的身份验证方案未使用身份验证信息标头字段，则无法将其与未经身份验证的响应区分开来。）
4) An intermediate authenticating response is a response for an authenticating request that requires more reaction by the client software without involving users. Such a response is required when an authentication scheme requires two or more round-trip messages to perform authentication, or when an authentication scheme uses some speculative short-cut method (such as uses of cached shared secrets) and it fails.
4) 中间身份验证响应是对身份验证请求的响应，该请求要求客户端软件做出更多反应，而不涉及用户。当身份验证方案需要两个或多个往返消息来执行身份验证时，或者当身份验证方案使用某种推测性快捷方法（例如使用缓存的共享机密）而失败时，需要这样的响应。
5) A negatively authenticated response is a response for an authenticating request, which means that the authentication attempt was declined and cannot continue without a different set of authentication credentials. Clients typically erase the memory of the active credentials and ask the user for other ones.
5) 负面身份验证响应是对身份验证请求的响应，这意味着身份验证尝试已被拒绝，并且在没有其他身份验证凭据集的情况下无法继续。客户端通常会擦除活动凭据的内存，并向用户请求其他凭据。
Usually the format of these responses is the same as the one for authentication-initializing responses. Clients can distinguish negatively authenticated responses from authentication-initializing responses by comparing the protection spaces contained in the request and in the response.
通常，这些响应的格式与身份验证初始化响应的格式相同。客户机可以通过比较请求和响应中包含的保护空间来区分否定身份验证响应和身份验证初始化响应。
Figure 1 shows a state diagram of generic HTTP authentication with the above message categorization. Note that many authentication schemes use only a subset of the transitions described in the diagram. Labels in the figure show the abbreviated names of response types.
图1显示了具有上述消息分类的通用HTTP身份验证的状态图。请注意，许多身份验证方案仅使用图中描述的转换的子集。图中的标签显示了响应类型的缩写名称。
=========== -----------------
NEW REQUEST ( UNAUTHENTICATED )
=========== -----------------
| ^ non-auth.
v | response
+----------------------+ NO +-------------+
| The requested URI |--------------------------->| send normal |
| known to be auth'ed? | ---------------->| request |
+----------------------+ / +-------------+
YES | / initializing|
v / |
+------------------+ NO / |
| Can auth-req.(*1)|--------- |
| be constructed? | |
+------------------+ |
YES | initializing |
| ---------------------------------------. |
| / v v
| | ---------------- NO +-----------+
| | ( AUTH-REQUESTED )<------| passwords |
| | ---------------- |etc. known?|
v | +-----------+
+-----------+ negative ------------- negative |YES
| send |---------->( AUTH-FAILED )<---------, |
/| auth-req | ------------- | |
/ +-----------+\ | v
| \ \ intermediate +-----------+
| \ -------------------------------->| send |
| \ | auth-req |
| non-auth. \successful successful +-----------+
| response (*2) \ / | ^
v \ / | |
----------------- \ -------------- / `----'
( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate
----------------- --------------
=========== -----------------
NEW REQUEST ( UNAUTHENTICATED )
=========== -----------------
| ^ non-auth.
v | response
+----------------------+ NO +-------------+
| The requested URI |--------------------------->| send normal |
| known to be auth'ed? | ---------------->| request |
+----------------------+ / +-------------+
YES | / initializing|
v / |
+------------------+ NO / |
| Can auth-req.(*1)|--------- |
| be constructed? | |
+------------------+ |
YES | initializing |
| ---------------------------------------. |
| / v v
| | ---------------- NO +-----------+
| | ( AUTH-REQUESTED )<------| passwords |
| | ---------------- |etc. known?|
v | +-----------+
+-----------+ negative ------------- negative |YES
| send |---------->( AUTH-FAILED )<---------, |
/| auth-req | ------------- | |
/ +-----------+\ | v
| \ \ intermediate +-----------+
| \ -------------------------------->| send |
| \ | auth-req |
| non-auth. \successful successful +-----------+
| response (*2) \ / | ^
v \ / | |
----------------- \ -------------- / `----'
( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate
----------------- --------------
Figure 1: Generic State Diagram for HTTP Authentication
图1:HTTP身份验证的通用状态图
Notes: (*1) For example, the "Digest" scheme requires a server-provided nonce to construct client-side challenges. (*2) In "Basic" and some others, this cannot be distinguished from a successfully authenticated response.
注意：（*1）例如，“摘要”方案需要服务器提供的nonce来构造客户端挑战。（*2）在“Basic”和其他一些语言中，这无法与成功验证的响应区分开来。
This specification uses an extended ABNF syntax defined in [RFC7230] and [RFC5234]. The following syntax definitions are quoted from [RFC7230] and [RFC7235]: auth-scheme, quoted-string, auth-param, SP, BWS, header-field, and challenge. It also uses the convention of using header field names for specifying the syntax of values for the header field.
本规范使用[RFC7230]和[RFC5234]中定义的扩展ABNF语法。以下语法定义引用自[RFC7230]和[RFC7235]：验证方案、引用字符串、验证参数、SP、BWS、头字段和质询。它还使用使用头字段名称的约定来指定头字段值的语法。
Additionally, this specification uses the following syntax definitions as a refinement for token and the right-hand-side of auth-param in [RFC7235].
此外，本规范使用以下语法定义作为[RFC7235]中标记和auth param右侧的细化。
bare-token = bare-token-lead-char *bare-token-char
bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token
integer = "0" / (%x31-39 *%x30-39) ; no leading zeros
bare-token = bare-token-lead-char *bare-token-char
bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token
integer = "0" / (%x31-39 *%x30-39) ; no leading zeros
Figure 2: The BNF Syntax for Common Notations
图2：常用符号的BNF语法
Extensive-tokens are used in this protocol where the set of acceptable tokens includes private extensions. Any extensions of this protocol MAY use either bare-tokens allocated by IANA (under the procedure described in Section 7), or extension-tokens with the format "-<token>.<domain-name>", where <domain-name> is a valid (sub-)domain name on the Internet owned by the party who defines the extension.
此协议中使用扩展令牌，其中可接受令牌集包括专用扩展。本协议的任何扩展都可以使用IANA分配的裸令牌（按照第7节所述的程序），或格式为“<token><domain name>”的扩展令牌，其中<domain name>是定义扩展的一方在互联网上拥有的有效（子）域名。
The Optional-WWW-Authenticate header enables a non-mandatory authentication, which is not possible under the current HTTP authentication mechanism.
可选的WWW Authenticate标头启用非强制身份验证，这在当前HTTP身份验证机制下是不可能的。
In several Web applications, users can access the same contents as both a guest user and an authenticated user. In most Web applications, this functionality is implemented using HTTP cookies [RFC6265] and custom form-based authentication. The new authentication method using this message will provide a replacement for these authentication systems.
在多个Web应用程序中，用户可以访问与来宾用户和经过身份验证的用户相同的内容。在大多数Web应用程序中，此功能是使用HTTP cookies[RFC6265]和自定义基于表单的身份验证实现的。使用此消息的新身份验证方法将替代这些身份验证系统。
Servers MAY send HTTP non-interim responses containing the Optional-WWW-Authenticate header as a replacement for a 401 response when it is authentication-initializing. The Optional-WWW-Authenticate header MUST NOT be sent on 401 responses (i.e., a usual WWW-Authenticate header MUST be used on 401 responses).
当401响应进行身份验证初始化时，服务器可以发送包含可选WWW Authenticate标头的HTTP非临时响应，以替换401响应。可选的WWW-Authenticate报头不能在401响应上发送（即，普通的WWW-Authenticate报头必须在401响应上使用）。
Optional-WWW-Authenticate = 1#challenge
可选WWW-Authenticate=1#挑战
Figure 3: BNF Syntax for Optional-WWW-Authenticate Header
图3：可选WWW认证头的BNF语法
Example: HTTP/1.1 200 OK Optional-WWW-Authenticate: Basic realm="xxxx"
示例：HTTP/1.1 200 OK可选WWW-Authenticate:Basic realm=“xxxx”
The challenges contained in the Optional-WWW-Authenticate header are the same as those for a 401 response corresponding to the same request. For authentication-related matters, an optional authentication request will have the same meaning as a 401 message with a corresponding WWW-Authenticate header (as an authentication-initializing response). (The behavior for other matters MAY be different between the optional authentication and 401 messages. For example, clients MAY choose to cache the 200 messages with the Optional-WWW-Authenticate header field but not the 401 messages by default.)
可选WWW-Authenticate报头中包含的挑战与对应于相同请求的401响应的挑战相同。对于与身份验证相关的事项，可选身份验证请求将具有与401消息相同的含义，该消息具有相应的WWW Authenticate标头（作为身份验证初始化响应）。（可选身份验证和401消息之间的其他事项的行为可能不同。例如，客户端可以选择使用可选的WWW Authenticate标头字段缓存200条消息，但默认情况下不缓存401条消息。）
A response with an Optional-WWW-Authenticate header SHOULD be returned from the server only when the request is either non-authenticated or authenticating to a wrong (not the server's expected) protection space. If a response is either an intermediate or a negative response to a client's authentication attempt, the server MUST respond with a 401 status response with a WWW-Authenticate header instead. Failure to comply with this rule will render clients unable to distinguish between authentication successes and failures.
只有当请求未经身份验证或验证到错误（不是服务器预期的）保护空间时，才应从服务器返回带有可选WWW Authenticate标头的响应。如果响应是对客户端身份验证尝试的中间响应或否定响应，则服务器必须使用带有WWW Authenticate标头的401状态响应进行响应。如果不遵守此规则，客户端将无法区分身份验证成功与失败。
The server is NOT RECOMMENDED to include an Optional-WWW-Authenticate header in a positive response when a client's authentication attempt succeeds.
当客户端的身份验证尝试成功时，不建议服务器在肯定响应中包含可选的WWW Authenticate标头。
Whenever an authentication scheme supports servers sending some parameter that gives a hint about the URL space for the corresponding protection space for the same realm (e.g., "path" or "domain"), servers requesting non-mandatory authentication SHOULD send such a parameter with the response. Clients supporting non-mandatory authentication MUST recognize the parameter and MUST send a request with an appropriate authentication credential in an Authorization header for any URI inside the specified paths.
每当身份验证方案支持服务器发送某个参数，该参数提示同一领域（例如，“路径”或“域”）的相应保护空间的URL空间时，请求非强制性身份验证的服务器应发送此类参数和响应。支持非强制身份验证的客户端必须识别该参数，并且必须在授权标头中为指定路径内的任何URI发送具有适当身份验证凭据的请求。
Implementations are not required to support this header for all of their supported authentication schemes (i.e., they may choose to implement it only for a subset of their supported schemes). New authentication schemes can require support of the optional authentication as a prerequisite, though.
实现不需要为其所有受支持的身份验证方案支持此报头（即，他们可以选择仅为其受支持方案的子集实现此报头）。不过，新的身份验证方案可能需要支持可选身份验证作为先决条件。
3.1. Note on Optional-WWW-Authenticate and Use of WWW-Authenticate Header with Non-401 Status
3.1. 关于可选WWW-Authenticate和使用非401状态的WWW-Authenticate报头的说明
In the current specification of HTTP/1.1, it is clarified that the WWW-Authenticate header can be used with messages with status codes other than 401 (Authentication Required). In particular, the use of the WWW-Authenticate header with the 200 status messages implies a very similar meaning to the above-defined Optional-WWW-Authenticate header.
在当前的HTTP/1.1规范中，澄清了WWW Authenticate标头可用于状态代码不是401（需要身份验证）的消息。具体地说，对200条状态消息使用WWW-Authenticate报头意味着与上面定义的可选WWW-Authenticate报头非常相似的含义。
The design of Optional-WWW-Authenticate header expects that the use of a new header guarantees that clients that are unaware of this extension will ignore the header, and that Web developers can rely on that behavior to implement a secondary fallback method of authentication. Several behavioral requirements written in the above section also assume this property and define a necessary functionality to implement an optional authentication reliably and consistently.
可选WWW-Authenticate报头的设计期望使用新的报头保证不知道此扩展的客户端将忽略该报头，并且Web开发人员可以依赖该行为来实现二级回退身份验证方法。上一节中编写的几个行为需求也假定了此属性，并定义了可靠且一致地实现可选身份验证的必要功能。
On the other hand, some experiments and discussions on the IETF mailing list revealed that most of (but not necessarily all of) the existing HTTP clients, at the time of writing, just ignore the WWW-Authenticate headers in non-401 messages, giving similar behavior with the Optional-WWW-Authenticate. However, every corner case of behavior was not fully tested or well-defined in the existing specifications.
另一方面，IETF邮件列表上的一些实验和讨论表明，在撰写本文时，大多数（但不一定全部）现有HTTP客户机只是忽略了非401消息中的WWW认证头，从而产生了与可选WWW认证类似的行为。然而，在现有规范中，没有对每个角落的行为进行充分测试或明确定义。
Considering these situations, the authors of this document chose to use a new header for a new feature "experiment". This is to avoid defining every corner-case behavior for the existing standard WWW-Authentication header in this experimental document, which could be considered by some implementers as an incompatible changes to existing specification.
考虑到这些情况，本文的作者选择使用一个新的标题作为新特性“实验”。这是为了避免在本实验文档中为现有标准WWW身份验证头定义每个角落的行为，一些实现者可能会将其视为对现有规范的不兼容更改。
Experimentally, the authors propose that implementers of the standard HTTP/1.1 specification (especially implementers of this extension) implement undefined (implementation-dependent) detailed handling of the WWW-Authenticate header with non-401 status messages similar as those defined above for the Optional-WWW-Authenticate header. For example, we propose that servers return the 401 status for failed authentication attempts, even when the unauthenticated request to the same resource will result in the 200 status. This can determine how
在实验上，作者建议标准HTTP/1.1规范的实现者（尤其是此扩展的实现者）使用非401状态消息实现WWW认证报头的未定义（依赖于实现）详细处理，类似于上面为可选WWW认证报头定义的那些。例如，我们建议服务器为失败的身份验证尝试返回401状态，即使对同一资源的未经身份验证的请求将导致200状态。这可以决定如何
(whether) non-mandatory authentication using the standard header fields and status codes can be implemented. If this experiment is successful, a future revision of this experimental document may "bless" and recommend the use of a standard WWW-Authenticate header, with some stricter requirements on some corner-case behavior.
（是否）可以使用标准标题字段和状态代码实施非强制性身份验证。如果本实验成功，本实验文档的未来版本可能会“祝福”并建议使用标准WWW认证头，对某些角落案例行为有更严格的要求。
Authentication-Control = 1#auth-control-entry
auth-control-entry = auth-scheme 1*SP 1#auth-control-param
auth-control-param = extensive-token BWS "=" BWS token
/ extensive-token "*" BWS "=" BWS ext-value
ext-value = <see RFC 5987, Section 3.2>
Authentication-Control = 1#auth-control-entry
auth-control-entry = auth-scheme 1*SP 1#auth-control-param
auth-control-param = extensive-token BWS "=" BWS token
/ extensive-token "*" BWS "=" BWS ext-value
ext-value = <see RFC 5987, Section 3.2>
Figure 4: The BNF Syntax for the Authentication-Control Header
图4：身份验证控制头的BNF语法
The Authentication-Control header provides more precise control of the client behavior for Web applications using an HTTP authentication protocol. This header is supposed to be generated in the application layer, as opposed to the WWW-Authenticate headers, which will usually be generated by the Web servers.
身份验证控制头为使用HTTP身份验证协议的Web应用程序提供更精确的客户端行为控制。该报头应该在应用程序层生成，而WWW-Authenticate报头通常由Web服务器生成。
Clients MAY freely choose any subset of these parameters to be supported. Also, these may choose to support any of the parameters for only a subset of their supported authentication schemes. However, authentication schemes can require/recommend support for some of these parameters as a prerequisite.
客户可以自由选择要支持的这些参数的任何子集。此外，它们可以选择仅为其支持的认证方案的子集支持任何参数。但是，身份验证方案可能需要/建议支持其中一些参数作为先决条件。
The Authentication-Control header contains one or more "authentication control entries", each of which corresponds to a single realm for a specific authentication scheme. If the auth-scheme specified for an entry supports the HTTP "realm" feature, that entry MUST contain the "realm" parameter. If not, the entry MUST NOT contain the "realm" parameter.
身份验证控制标头包含一个或多个“身份验证控制条目”，每个条目对应于特定身份验证方案的单个域。如果为条目指定的身份验证方案支持HTTP“realm”功能，则该条目必须包含“realm”参数。否则，条目不得包含“realm”参数。
Among the multiple entries in the header, the relevant entries in the header are those corresponding to an auth-scheme and a realm (if any) for which "the authentication process is being performed or going to be performed". In more detail:
在报头中的多个条目中，报头中的相关条目是与“正在执行或将要执行认证过程”的认证方案和领域（如果有）相对应的条目。更详细地说：
(1) If the response is either an authentication-initializing response or a negatively authenticated response, there can be multiple challenges in the WWW-Authenticate header (or the Optional-WWW-Authenticate header defined in this extension), each of which corresponds to a different scheme and realm. In this case, the client has a choice about the scheme and realm they will use to authenticate. Only the entry in the
(1) 如果响应是身份验证初始化响应或否定身份验证响应，则WWW Authenticate标头（或此扩展中定义的可选WWW Authenticate标头）中可能存在多个质询，每个质询对应于不同的方案和领域。在这种情况下，客户机可以选择用于身份验证的方案和领域。只有
Authentication-Control header corresponding to that scheme and realm are relevant.
与该方案和领域对应的身份验证控制头是相关的。
(2) If the response is either an intermediate authenticating response or a successfully authenticated response, the scheme and realm given in the Authorization header of the HTTP request will determine the currently ongoing authentication process. Only the entry corresponding to that scheme and realm are relevant.
(2) 如果响应是中间身份验证响应或成功身份验证响应，则HTTP请求的授权标头中给出的方案和域将确定当前正在进行的身份验证过程。只有对应于该方案和领域的条目才相关。
The server MAY send an Authentication-Control header containing non-relevant entries. The client MUST ignore all non-relevant entries it received.
服务器可以发送包含不相关条目的身份验证控制头。客户必须忽略其收到的所有不相关条目。
Every entry contains one or more parameters, each of which is a name-value pair. The name of each parameter MUST be an extensive-token. Clients MUST ignore any unknown parameters contained in this header. The entries for the same auth-scheme and the realm MUST NOT contain duplicated parameters for the same name. Clients MAY either take any one of those duplicated entries or ignore all of them.
每个条目都包含一个或多个参数，每个参数都是名称-值对。每个参数的名称必须是扩展标记。客户端必须忽略此标头中包含的任何未知参数。同一身份验证方案和领域的条目不得包含相同名称的重复参数。客户机可以接受这些重复条目中的任何一个，也可以忽略所有条目。
The type of parameter value depends on the parameter name as defined in the following subsections. Regardless of the type, however, the recipients MUST accept both quoted and unquoted representations of values as defined in HTTP. If the parameter is defined to have a string value, implementations MUST send any value outside of the "token" ABNF syntax in either a quoted form or an ext-value form (see Section 4.1). If the parameter is defined as a token (or similar) or an integer, the value SHOULD follow the corresponding ABNF syntax after possible unquoting of the quoted-string value (as defined in HTTP) and MUST be sent in a plain (not an ext-value) form. (Note: the rest of this document will show all string-value parameters in quoted forms, and it will show others in unquoted forms.)
参数值的类型取决于以下小节中定义的参数名称。但是，无论类型如何，收件人都必须接受HTTP中定义的带引号和不带引号的值表示。如果参数定义为具有字符串值，则实现必须以引号形式或ext-value形式发送“token”ABNF语法之外的任何值（参见第4.1节）。如果参数定义为令牌（或类似的）或整数，则在可能取消引用带引号的字符串值（如HTTP中所定义）后，该值应遵循相应的ABNF语法，并且必须以普通（而不是ext值）形式发送。（注意：本文档的其余部分将以带引号的形式显示所有字符串值参数，并以不带引号的形式显示其他参数。）
Any parameters contained in this header MAY be ignored by clients. Also, even when a client accepts this header, users are able to circumvent the semantics of this header. Therefore, if this header is used for security purposes, its use MUST be limited to providing some non-fundamental additional security measures valuable for end-users (such as client-side logout for protection against console takeover). Server-side applications MUST NOT rely on the use of this header for protecting server-side resources.
客户端可能会忽略此标头中包含的任何参数。此外，即使客户机接受此标头，用户也可以绕过此标头的语义。因此，如果此标头用于安全目的，则其使用必须限于提供一些对最终用户有价值的非基本附加安全措施（例如客户端注销以防止控制台接管）。服务器端应用程序不得依赖使用此标头来保护服务器端资源。
Note: The header syntax allows servers to specify Authentication-Control for multiple authentication schemes, either as multiple occurrences of this header or as a combined single header (see Section 3.2.2 of [RFC7230] for rationale). The same care as for parsing multiple authentication challenges needs to be taken.
注：标头语法允许服务器为多个身份验证方案指定身份验证控制，可以是此标头的多次出现，也可以是组合的单个标头（基本原理见[RFC7230]第3.2.2节）。需要采取与解析多个身份验证挑战相同的注意事项。
Parameters contained in the Authentication-Control header MAY be extended to non-ASCII values using the framework described in [RFC5987]. All servers and clients MUST be capable of receiving and sending values encoded in [RFC5987] syntax.
可以使用[RFC5987]中描述的框架将身份验证控制报头中包含的参数扩展为非ASCII值。所有服务器和客户端必须能够接收和发送以[RFC5987]语法编码的值。
If a value to be sent contains only ASCII characters, the field MUST be sent using plain RFC 7235 syntax. The syntax as extended by ext-value MUST NOT be used in this case.
如果要发送的值仅包含ASCII字符，则必须使用普通RFC 7235语法发送字段。在这种情况下，不能使用ext value扩展的语法。
If a value (except the "realm" header) contains one or more non-ASCII characters, the parameter SHOULD be sent using the ext-value syntax defined in Section 3.2 of [RFC5987]. Such a parameter MUST have a charset value of "UTF-8", and the language value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the syntax used.
如果值（除“领域”标题外）包含一个或多个非ASCII字符，则应使用[RFC5987]第3.2节中定义的ext value语法发送参数。此类参数的字符集值必须为“UTF-8”，并且必须始终忽略语言值（具有空值）。无论使用何种语法，同一参数不能发送多次。
For example, a parameter "username" with the value "Renee of France" SHOULD be sent as < username="Renee of France" >. If the value is "Ren<e acute>e of France", it SHOULD be sent as < username*=UTF-8''Ren%C3%89e%20of%20France > instead.
例如，值为“法国蕾妮”的参数“username”应作为<username=“法国蕾妮”>发送。如果值为“Ren<e acute>e of France”，则应改为<username*=UTF-8“Ren%C3%89e%20of%20France>。
Interoperability note: [RFC7235], Section 2.2, defines the "realm" authentication parameter that cannot be replaced by the "realm*" extend parameter. This means that the use of non-ASCII values for an authentication realm is not the defined behavior in HTTP. Unfortunately, some people currently use a non-ASCII realm parameter in reality, but even its encoding scheme is not well defined. Given this background, this document does not specify how to handle a non-ASCII "realm" parameter in the extended header fields. If needed, the authors propose using a non-extended "realm" parameter form, with a wish for maximum interoperability.
互操作性说明：[RFC7235]第2.2节定义了不能用“realm*”扩展参数替换的“realm”身份验证参数。这意味着对身份验证领域使用非ASCII值不是HTTP中定义的行为。不幸的是，目前有些人在现实中使用非ASCII领域参数，但甚至其编码方案也没有很好的定义。鉴于此背景，本文档不指定如何在扩展头字段中处理非ASCII“realm”参数。如果需要，作者建议使用非扩展的“领域”参数形式，并希望实现最大的互操作性。
Example: Authentication-Control: Digest realm="protected space", auth-style=modal
示例：身份验证控件：Digest realm=“受保护的空间”，auth style=modal
The parameter "auth-style" specifies the server's preference for user interface behavior for user authentication. This parameter can be included in any kind of response; however, it is only meaningful for either authentication-initializing or negatively authenticated responses. The value of this parameter MUST be one of the bare-tokens, "modal" or "non-modal". When the Optional-WWW-Authenticate header is used, the value of this parameter MUST be disregarded and the value "non-modal" is implied.
参数“auth style”指定服务器对用户身份验证的用户界面行为的首选项。该参数可以包含在任何类型的响应中；但是，它仅对身份验证初始化或负面身份验证响应有意义。此参数的值必须是裸标记之一，“模态”或“非模态”。当使用可选的WWW Authenticate标头时，必须忽略此参数的值，并隐含值“非模态”。
The value "modal" means that the server thinks the content of the response (body and other content-related headers) is valuable only for users refusing the authentication request. The clients are expected to ask the user for a password before processing the content. This behavior is common for most of the current implementations of Basic and Digest authentication schemes.
值“modal”表示服务器认为响应的内容（正文和其他与内容相关的标题）仅对拒绝身份验证请求的用户有价值。在处理内容之前，客户端需要向用户请求密码。这种行为在当前大多数基本和摘要身份验证方案的实现中都很常见。
The value "non-modal" means that the server thinks that the content of the response (body and other content-related headers) is valuable for users before processing an authentication request. The clients are expected to first process the content and then provide users with the opportunity to perform authentication.
值“non-modal”表示服务器在处理身份验证请求之前认为响应的内容（正文和其他与内容相关的标题）对用户有价值。客户机应首先处理内容，然后为用户提供执行身份验证的机会。
The default behavior for clients is implementation dependent, and it may also depend on authentication schemes. The proposed default behavior is "modal" for all authentication schemes unless otherwise specified.
客户端的默认行为取决于实现，也可能取决于身份验证方案。除非另有规定，否则所有身份验证方案的建议默认行为都是“模态”。
The above two different methods of authentication possibly introduce an observable difference of semantics when the response contains state-changing side effects; for example, it can affect how Cookie headers [RFC6265] in 401 responses are processed. However, the server applications SHOULD NOT depend on the existence of such side effects.
当响应包含状态变化的副作用时，上述两种不同的认证方法可能会引入语义上的明显差异；例如，它会影响401响应中Cookie头[RFC6265]的处理方式。但是，服务器应用程序不应依赖于此类副作用的存在。
Example:
Authentication-Control: Mutual realm="auth-space-1",
location-when-unauthenticated="http://www.example.com/login.html"
Example:
Authentication-Control: Mutual realm="auth-space-1",
location-when-unauthenticated="http://www.example.com/login.html"
The parameter "location-when-unauthenticated" specifies a location to which any unauthenticated clients should be redirected. This header can be used, for example, when there is a central login page for the entire Web application. The value of this parameter is a string that contains a URL location. If a received URL is not absolute, the clients SHOULD consider it a relative URL from the current location.
参数“未经身份验证时的位置”指定任何未经身份验证的客户端应重定向到的位置。例如，当整个Web应用程序都有一个中心登录页面时，可以使用此标题。此参数的值是包含URL位置的字符串。如果接收到的URL不是绝对的，则客户端应该将其视为来自当前位置的相对URL。
This parameter MAY be used with a 401 response for an authentication-initializing response. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully authenticated or intermediately authenticated.
此参数可与401响应一起用于身份验证初始化响应。它也可以包含在带有可选WWW Authenticate标头的肯定响应中，尽管不建议这样做。当响应通过成功身份验证或中间身份验证时，客户端必须忽略此参数。
When a client receives an authentication-initiating response with this parameter, and if the client has to ask users for authentication credentials, the client will treat the entire response as if it were a 303 "See Other" response with a Location header that contains the value of this parameter (i.e., the client will be redirected to the specified location with a GET request). Unlike a normal 303 response, if the client can process authentication without the user's interaction, this parameter MUST be ignored.
当客户端接收到此参数的身份验证启动响应时，如果客户端必须向用户请求身份验证凭据，则客户端会将整个响应视为包含此参数值的位置标头的303“查看其他”响应（即，客户端将通过GET请求重定向到指定位置）。与正常的303响应不同，如果客户端可以在没有用户交互的情况下处理身份验证，则必须忽略此参数。
Example:
Authentication-Control: Basic realm="entrance", no-auth=true
Example:
Authentication-Control: Basic realm="entrance", no-auth=true
The parameter "no-auth" is a variant of the location-when-unauthenticated parameter; it specifies that new authentication attempts are not to be performed on this location in order to improve the user experience, without specifying the redirection on the HTTP level. This header can be used, for example, when there is a central login page for the entire Web application and when an explicit user interaction with the Web content is desired before authentication. The value of this parameter MUST be a token "true". If the value is incorrect, the client MAY ignore this parameter.
参数“no auth”是未经验证参数时位置的变体；它指定不在此位置执行新的身份验证尝试以改善用户体验，而不指定HTTP级别的重定向。例如，当整个Web应用程序都有一个中心登录页面，并且在身份验证之前需要用户与Web内容进行显式交互时，可以使用此标题。此参数的值必须是标记“true”。如果值不正确，客户端可能会忽略此参数。
This parameter MAY be used with authentication-initiating responses. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully authenticated or intermediately authenticated.
此参数可与身份验证启动响应一起使用。它也可以包含在带有可选WWW Authenticate标头的肯定响应中，尽管不建议这样做。当响应通过成功身份验证或中间身份验证时，客户端必须忽略此参数。
When a client receives an authentication-initiating response with this parameter, if the client has to ask users for authentication credentials, the client will ignore the WWW-Authenticate header contained in the response and treat the whole response as a normal negative 4xx-class response instead of giving the user an opportunity to start authentication. If the client can process authentication without the user's interaction, this parameter MUST be ignored.
当客户端接收到此参数的身份验证启动响应时，如果客户端必须向用户请求身份验证凭据，客户端将忽略响应中包含的WWW Authenticate标头，并将整个响应视为正常的负4xx类响应，而不是为用户提供启动身份验证的机会。如果客户端可以在没有用户交互的情况下处理身份验证，则必须忽略此参数。
Using this parameter along with the location-when-unauthenticated parameter is meaningless. If both were supplied, clients SHOULD ignore the location-when-unauthenticated parameter.
当未经验证的参数没有意义时，将此参数与位置一起使用。如果同时提供了这两个参数，则当未经验证的参数出现时，客户端应忽略该位置。
This parameter SHOULD NOT be used as a security measure to prevent authentication attempts, as it is easily circumvented by users. This parameter SHOULD be used solely for improving the user experience of Web applications.
此参数不应用作防止身份验证尝试的安全措施，因为用户很容易绕过它。此参数应仅用于改善Web应用程序的用户体验。
Example:
Authentication-Control: Digest realm="protected space",
location-when-logout="http://www.example.com/byebye.html"
Example:
Authentication-Control: Digest realm="protected space",
location-when-logout="http://www.example.com/byebye.html"
The parameter "location-when-logout" specifies a location where the client is to be redirected when the user explicitly requests a logout. The value of this parameter MUST be a string that contains a URL location. If a given URL is not absolute, the clients MUST consider it a relative URL from the current location.
参数“注销时的位置”指定当用户明确请求注销时客户端重定向的位置。此参数的值必须是包含URL位置的字符串。如果给定URL不是绝对的，则客户端必须将其视为来自当前位置的相对URL。
This parameter MAY be used with successfully authenticated responses. If this parameter is contained in other kinds of responses, the clients MUST ignore this parameter.
此参数可用于已成功验证的响应。如果此参数包含在其他类型的响应中，则客户端必须忽略此参数。
When the user tells the client to terminate the current authentication period, if the client currently displays a page supplied by a response with this parameter, the client will automatically change the current location to the location specified in this parameter using a new GET request, as if it has received a 303 response. Any operations related to logout (e.g., erasing memories of username, authentication credential, and all related one-time credentials such as nonce or keys) SHOULD occur before processing a page transition.
当用户告诉客户端终止当前身份验证期间时，如果客户端当前显示由带有此参数的响应提供的页面，则客户端将使用新的GET请求自动将当前位置更改为此参数中指定的位置，就好像它已收到303响应一样。任何与注销相关的操作（例如，擦除用户名、身份验证凭据和所有相关一次性凭据（如nonce或key）的内存）都应在处理页面转换之前进行。
When the user requests the client for the termination of an authentication period, if the client supports this parameter but the server response does not contain this parameter, the client's RECOMMENDED behavior is as follows: if the request corresponding to the current content was the GET method, reload the page without the authentication credential. Otherwise, keep the current content as-is and simply forget the authentication status. The client SHOULD NOT replay a non-idempotent request without the user's explicit approval.
当用户请求客户端终止身份验证期间时，如果客户端支持此参数，但服务器响应不包含此参数，则客户端的建议行为如下：如果当前内容对应的请求是GET方法，在没有身份验证凭据的情况下重新加载页面。否则，保持当前内容不变，只需忘记身份验证状态即可。未经用户明确批准，客户端不应重播非幂等请求。
Web applications are encouraged to send this parameter with an appropriate value for any responses (except those with redirection (3XX) statuses) for non-GET requests.
建议Web应用程序为非GET请求的任何响应（具有重定向（3XX）状态的响应除外）发送带有适当值的此参数。
See Section 5 for some examples for possible deployment of this parameter.
有关此参数的可能部署示例，请参见第5节。
Example:
Authentication-Control: Basic realm="entrance", logout-timeout=300
Example:
Authentication-Control: Basic realm="entrance", logout-timeout=300
The parameter "logout-timeout", when contained in a successfully authenticated response, means that any authentication credentials and state related to the current protection space are to be discarded if the time specified in this header (in seconds) has passed since the time this header was received. The value MUST be an integer. As a special case, the value 0 means that the server is logging the client out immediately from the current authentication space and that the client is now returned to the unauthenticated state. This does not, however, mean that the long-term memories for the passwords and passwords-related details (such as password reminders and auto fill-ins) should be removed. If a new timeout value is received for the same authentication space, it cancels the previous timeout and sets a new timeout.
参数“注销超时”包含在已成功验证的响应中时，表示如果自收到此标头后已超过此标头中指定的时间（以秒为单位），则将丢弃与当前保护空间相关的任何验证凭据和状态。该值必须是整数。作为一种特殊情况，值0表示服务器正在将客户端立即从当前身份验证空间注销，并且客户端现在返回到未经身份验证的状态。但是，这并不意味着应删除密码和密码相关详细信息（如密码提醒和自动填写）的长期记忆。如果为同一身份验证空间接收到新的超时值，则会取消以前的超时并设置新的超时。
Example:
Authentication-Control: Basic realm="configuration", username="admin"
Example:
Authentication-Control: Basic realm="configuration", username="admin"
The parameter "username" tells us that the only "username" to be accepted by the server is the value given in this parameter.
参数“username”告诉我们服务器只接受此参数中给定的值。
This parameter is particularly useful, for example, for routers and other network appliances with a Web configuration interface. Many of those use an HTTP Basic authentication with one predefined username, with many varieties such as "admin", "root", "user", etc. In the current situation, users have almost no hint about the valid username upon the authentication request. Some show the valid value in a "realm" string, some in the 401-status response page, shown _after_ the user gave up the authentication and canceled the authentication dialog. If this parameter is given, the client Web browser can auto-fill the username field in the authentication dialog before the users attempt to authenticate themselves.
例如，对于路由器和具有Web配置接口的其他网络设备，此参数特别有用。其中许多人使用HTTP基本身份验证和一个预定义的用户名，以及多种类型，如“admin”、“root”、“user”等。在当前情况下，用户在身份验证请求时几乎没有关于有效用户名的提示。有些在“领域”字符串中显示有效值，有些在401状态响应页面中，在用户放弃身份验证并取消身份验证对话框后显示。如果给定此参数，则客户端Web浏览器可以在用户尝试进行身份验证之前自动填充“身份验证”对话框中的“用户名”字段。
This parameter MAY be used with authentication-initiating responses or negatively authenticated responses requiring another attempt at authentication. The clients MUST ignore this parameter when a response is either successfully authenticated or intermediately authenticated.
此参数可用于身份验证启动响应或需要再次尝试身份验证的反向身份验证响应。当响应通过成功身份验证或中间身份验证时，客户端必须忽略此参数。
If the authentication scheme to be used has a syntax limitation on the allowed usernames (e.g., Basic and Digest do not allow colons in usernames); the specified value MUST follow that limitation. Clients SHOULD ignore any values that do not conform to such limitations.
如果要使用的身份验证方案对允许的用户名有语法限制（例如，Basic和Digest不允许用户名中使用冒号）；指定的值必须遵循该限制。客户应忽略任何不符合此类限制的值。
Also, if the used authentication scheme requires a specific style of text preparation for the username (e.g., PRECIS [RFC7564] string preparation or Unicode normalization), the server SHOULD send the values satisfying such requirements (so that clients can use the given username as is).
此外，如果所使用的身份验证方案需要为用户名准备特定样式的文本（例如PRECIS[RFC7564]字符串准备或Unicode规范化），则服务器应发送满足此类要求的值（以便客户端可以按原样使用给定的用户名）。
Clients MAY still send any authentication requests with other usernames, possibly in vain. Clients are not required (also not forbidden) to give users opportunities for supplying a username different from the server-specified one. Servers are also not strictly required to reject usernames other than specified, but doing so will usually result in bad user experiences and may confuse users and clients.
客户端仍然可以发送任何带有其他用户名的身份验证请求，这可能是徒劳的。客户端不需要（也不禁止）为用户提供提供不同于服务器指定用户名的机会。服务器也不严格要求拒绝指定以外的用户名，但这样做通常会导致糟糕的用户体验，并可能混淆用户和客户端。
Although this parameter is useful in a specific class of use cases, using it in a general use case has many security implications and possible pitfalls. Please consult Section 8.1 before deciding to use this parameter.
尽管此参数在特定类别的用例中很有用，但在一般用例中使用它会带来许多安全隐患和可能的陷阱。在决定使用此参数之前，请参考第8.1节。
This section shows some examples for applying this extension to typical websites that use forms and cookies for managing authentication and authorization. The content of this section is not normative and is for illustrative purposes only.
本节展示了将此扩展应用于使用表单和cookie管理身份验证和授权的典型网站的一些示例。本节内容不规范，仅用于说明目的。
In these examples, we assume that there are two kinds of clients (Web browsers). One kind of these implements all features described in the previous sections. We also assume that browsers will have a user interface that allows users to deactivate (log out from) current authentication sessions. The other kind are the "existing" implementations that do not support any of these features.
在这些示例中，我们假设有两种客户端（Web浏览器）。其中一种实现了前面章节中描述的所有功能。我们还假设浏览器将具有允许用户停用（注销）当前身份验证会话的用户界面。另一种是不支持这些特性的“现有”实现。
When not explicitly specified, all settings described below are to be applied with Authentication-Control headers, and these can be sent to clients regardless of the authentication status (these will be silently ignored whenever not effective).
当未明确指定时，下面描述的所有设置都将与身份验证控制头一起应用，并且可以将这些设置发送到客户端，而不管身份验证状态如何（当这些设置无效时，将自动忽略）。
This subsection provides an example application for a site whose structure is somewhat similar to conventional portal sites. In particular, most Web pages are available for guest (unauthenticated) users, and, if authentication is performed, the content of these pages is customized for each user. We assume that the site has the following kinds of pages currently:
本小节提供了一个网站的示例应用程序，该网站的结构与传统门户网站类似。特别是，大多数网页可供来宾（未经身份验证的）用户使用，如果执行身份验证，这些网页的内容将针对每个用户进行定制。我们假设该站点当前有以下类型的页面：
o Content pages
o 内容页
o Pages/mechanism for performing authentication:
o 用于执行身份验证的页面/机制：
* There is one page that asks for a username and a password using a HTML POST form.
* 有一个页面使用HTML POST表单要求输入用户名和密码。
* After the authentication attempt, the user will be redirected to either the page that was previously displayed before the authentication or some specific page.
* 尝试身份验证后，用户将被重定向到以前在身份验证之前显示的页面或某个特定页面。
o A de-authentication (logout) page.
o 取消身份验证（注销）页面。
When such a site does not require specific actions upon login and logout, the following simple settings can be used:
当此类站点在登录和注销时不需要特定操作时，可以使用以下简单设置：
o Set up an optional authentication to all pages available to guests. Set up an Authentication-Control header with the "auth-style=non-modal" setting.
o 为来宾可用的所有页面设置可选身份验证。使用“auth style=non-modal”设置设置身份验证控制标头。
o If there are pages only available to authenticated users, set up a mandatory authentication with the "auth-style=non-modal" setting.
o 如果只有经过身份验证的用户才能使用页面，请使用“auth style=non-modal”设置设置强制身份验证。
o No specific pages for authentication are needed. It will be performed automatically, directed by the above setting.
o 不需要用于身份验证的特定页面。它将根据上述设置自动执行。
o A de-authentication page is also not needed. If the site has one, put "logout-timeout=0" there.
o 也不需要取消身份验证页面。如果站点有一个，请将“注销超时=0”放在那里。
o For all pages for POST requests, it is advisable to have a "location-when-logout=<some page>".
o 对于POST请求的所有页面，建议设置“注销时的位置=<some page>”。
If the site requires specific actions upon logout, the following settings can be used:
如果站点需要在注销时执行特定操作，则可以使用以下设置：
o All settings in Case 1 are applied.
o 案例1中的所有设置均已应用。
o For all pages, set up the Authentication-Control header "location-when-logout=<de-authentication page>".
o 对于所有页面，设置身份验证控制标题“注销时的位置=<de Authentication page>”。
o In the de-authentication page, no specific setup is needed. If there are any direct links to the de-authentication page, put "logout-timeout=0".
o 在“取消身份验证”页面中，不需要特定设置。如果有任何指向取消身份验证页面的直接链接，请输入“注销超时=0”。
If the site needs to display a specific page before login actions (some announcements, user notices, or even advertisements), the following settings can be applied:
如果站点需要在登录操作（某些公告、用户通知甚至广告）之前显示特定页面，则可以应用以下设置：
o Set up an optional authentication to all pages available to guests. Set up an Authentication-Control header with "no-auth=true". Put a link to a specific login page in contents.
o 为来宾可用的所有页面设置可选身份验证。设置带有“no auth=true”的身份验证控制标头。在目录中放置指向特定登录页面的链接。
o If there are pages only available to authenticated users, set up a mandatory authentication with the "location-when-unauthenticated=<the login page>".
o 如果只有经过身份验证的用户才能使用页面，请使用“未经身份验证时的位置=<登录页面>”设置强制身份验证。
o For the specific login page, set up a mandatory authentication.
o 对于特定登录页面，设置强制身份验证。
o For all pages for POST requests, it is advisable to have "location-when-logout=<some page>", too.
o 对于POST请求的所有页面，建议也设置“注销时的位置=<some page>”。
o De-authentication pages are not needed. If the site has one, put "logout-timeout=0".
o 不需要取消身份验证页面。如果站点有一个，请输入“注销超时=0”。
If almost all pages in the target site require authentication (e.g., an Internet banking site), or if there is no need to support both unauthenticated and authenticated users on the same resource, the settings will become simpler. The following are examples for such a site:
如果目标站点中的几乎所有页面都需要身份验证（例如，网上银行站点），或者如果不需要在同一资源上同时支持未经身份验证和已验证的用户，则设置将变得更简单。以下是此类场地的示例：
o Set up a mandatory authentication to all pages available to authenticated users. Set up an Authentication-Control header with the "auth-style=non-modal" setting.
o 对已验证用户可用的所有页面设置强制验证。使用“auth style=non-modal”设置设置身份验证控制标头。
o Set up a handler for the 401-status that requests users to authenticate.
o 为401状态设置请求用户进行身份验证的处理程序。
o For all pages for POST requests, it is advisable to have a "location-when-logout=<some page>", too.
o 对于POST请求的所有页面，建议也有一个“注销时的位置=<some page>”。
o De-authentication pages are not needed. If the site will have one, put "logout-timeout=0" there.
o 不需要取消身份验证页面。如果站点将有一个，请将“注销超时=0”放在那里。
In current websites using form-based authentication, Cookies [RFC6265] are used for managing both authorization and application sessions. Using the extensions in this document, the former features will be provided by using (extended) HTTP authentication/ authorization mechanisms. In some cases, there will be ambiguity on whether some functions are for authorization management or for session management. The following hints will be helpful for deciding which features to use.
在当前使用基于表单的身份验证的网站中，Cookie[RFC6265]用于管理授权和应用程序会话。使用本文中的扩展，将通过使用（扩展的）HTTP身份验证/授权机制来提供前面的功能。在某些情况下，对于某些功能是用于授权管理还是用于会话管理，会存在歧义。以下提示将有助于决定使用哪些功能。
o If there is a need to serve multiple sessions for a single user using multiple browsers concurrently, use a Cookie for distinguishing between sessions for the same user. (C.f. if there is a need to distinguish between sessions in the same browser, HTML5 Web Storage [W3C.REC-webstorage-20130730] features can be used instead of Cookies.)
o 如果需要同时使用多个浏览器为单个用户提供多个会话，请使用Cookie来区分同一用户的会话。（C.f.如果需要区分同一浏览器中的会话，可以使用HTML5 Web存储[W3C.REC-webstorage-20130730]功能代替cookie。）
o If a website is currently deploying a session time-out feature, consider who benefits from the feature. In most cases, the main requirement for such a feature is to protect users from having their consoles and browsers hijacked (i.e., benefits are on the users' side). In such cases, the time-out features provided in this extension can be used. On the other hand, the requirement is to protect the server's privilege (e.g., when some regulations require limiting the time difference between a user's two-factor authentication and financial transaction commitment; the requirement is strictly on the servers' side), that should be managed on the server side using Cookies or other session-management mechanisms.
o 如果网站当前正在部署会话超时功能，请考虑从该特性中获益的人。在大多数情况下，此类功能的主要要求是保护用户免受其控制台和浏览器被劫持（即，好处在用户一方）。在这种情况下，可以使用此扩展中提供的超时功能。另一方面，要求是保护服务器的特权（例如，当一些法规要求限制用户的双因素身份验证和金融交易承诺之间的时间差时；要求严格在服务器一方），应该使用cookie或其他会话管理机制在服务器端对其进行管理。
In some transition periods, sites may need to support both HTTP-layer and form-based authentication. The following example shows one way to achieve that.
在某些过渡期，站点可能需要同时支持HTTP层和基于表单的身份验证。下面的示例显示了实现这一点的一种方法。
o If Cookies are used even for HTTP-authenticated users, each session determined by Cookies SHOULD identify which authentication has been used for the session.
o 如果Cookie甚至用于HTTP身份验证的用户，则Cookie确定的每个会话都应标识会话使用了哪个身份验证。
o First, set up any of the above settings for enabling HTTP-layer authentication.
o 首先，设置上述任何设置以启用HTTP层身份验证。
o For unauthenticated users, add the following things to the Web pages, unless the client supports this extension and HTTP-level authentication:
o 对于未经身份验证的用户，请将以下内容添加到网页，除非客户端支持此扩展和HTTP级别身份验证：
* For non-mandatory authenticated pages, add a link to the form-based authenticated pages.
* 对于非强制认证页面，请添加指向基于表单的认证页面的链接。
* For mandatory authenticated pages, either put a link to form-based authenticated pages or put an HTML-level redirection (using <META http-equiv="refresh" ...> element) to such pages.
* 对于强制认证页面，可以将链接放置到基于表单的认证页面，或者将HTML级别的重定向（使用<META-http equiv=“refresh”…>元素）放置到此类页面。
o In the form-based authenticated pages, if users are not authenticated, the page can provide a redirection for HTTP-level authentication by the "location-when-unauthenticated" setting.
o 在基于表单的身份验证页面中，如果用户未经身份验证，则该页面可以通过“未经身份验证时的位置”设置为HTTP级身份验证提供重定向。
o Users are identified for authorization and content customization by the following logic:
o 用户通过以下逻辑进行授权和内容定制：
* First, check the result of the HTTP-level authentication. If there is a Cookie session tied to a specific user, both should match.
* 首先，检查HTTP级别身份验证的结果。如果存在绑定到特定用户的Cookie会话，则两者应匹配。
* If the user is not authenticated on the HTTP-level, use the conventional form-based method to determine the user.
* 如果用户未在HTTP级别进行身份验证，请使用传统的基于表单的方法确定用户。
* If there is a Cookie tied to HTTP authentication but there is no corresponding HTTP authentication result, that session will be discarded (because it means that authentication is deactivated by the corresponding user).
* 如果有一个Cookie绑定到HTTP身份验证，但没有相应的HTTP身份验证结果，则该会话将被丢弃（因为这意味着相应的用户将停用身份验证）。
If a private extension to this protocol is implemented, it MUST use the extension-param to avoid conflicts with this protocol and any other extensions. (Standardized extensions or extensions that are being standardized MAY use either bare-tokens or extension-tokens.)
如果实现了此协议的专用扩展，则必须使用扩展参数以避免与此协议和任何其他扩展冲突。（标准化扩展或正在标准化的扩展可以使用裸令牌或扩展令牌。）
When bare-tokens are used in this protocol, these MUST be allocated by IANA. Any tokens used for non-private, non-experimental parameters are RECOMMENDED to be registered with IANA, regardless of the kind of tokens used.
当在本协议中使用裸令牌时，这些令牌必须由IANA分配。任何用于非私有、非实验性参数的令牌，无论使用何种令牌，都建议向IANA注册。
Extension-tokens MAY be freely used for any non-standard, private, and/or experimental uses. An extension-token MUST use the format "-<bare-token>.<domain-name>", where <domain-name> is a validly registered (sub-)domain name on the Internet owned by the party that defines the extensions. Any unknown parameter name is to be ignored regardless of whether it is an extension-token or a bare-token.
扩展令牌可自由用于任何非标准、私有和/或实验用途。扩展令牌必须使用“-<bare token><domain name>”格式，其中<domain name>是定义扩展的一方在Internet上拥有的有效注册（子）域名。任何未知参数名称都将被忽略，无论它是扩展令牌还是裸令牌。
This document defines two new entries for the "Permanent Message Header Field Names" registry.
本文档为“永久消息头字段名”注册表定义了两个新条目。
+-------------+---------------------------+-------------------------+
| | Entry 1: | Entry 2: |
+-------------+---------------------------+-------------------------+
| Header | Optional-WWW-Authenticate | Authentication-Control |
| Field Name | | |
| Protocol | http | http |
| Status | experimental | experimental |
| Change | IETF | IETF |
| Control | | |
| Spec. | Section 3 of this | Section 4 of this |
| Document | document | document |
+-------------+---------------------------+-------------------------+
+-------------+---------------------------+-------------------------+
| | Entry 1: | Entry 2: |
+-------------+---------------------------+-------------------------+
| Header | Optional-WWW-Authenticate | Authentication-Control |
| Field Name | | |
| Protocol | http | http |
| Status | experimental | experimental |
| Change | IETF | IETF |
| Control | | |
| Spec. | Section 3 of this | Section 4 of this |
| Document | document | document |
+-------------+---------------------------+-------------------------+
This document also establishes the "HTTP Authentication Control Parameters" registry. The registry manages case-insensitive ASCII strings. The string MUST follow the extensive-token syntax defined in Section 2.2.
本文档还建立了“HTTP身份验证控制参数”注册表。注册表管理不区分大小写的ASCII字符串。字符串必须遵循第2.2节中定义的扩展令牌语法。
To acquire registered tokens, a specification for the use of such tokens MUST be available as a publicly accessible document (see "Specification Required" in [RFC5226]).
要获取注册令牌，必须将此类令牌的使用规范作为可公开访问的文档提供（请参阅[RFC5226]中的“所需规范”）。
Registrations for authentication control parameters are required to include a description of the control extension. New registrations are advised to provide the following information:
认证控制参数的注册需要包括控制扩展的描述。建议新注册者提供以下信息：
o Token: A token used in HTTP headers for identifying the algorithm.
o 令牌：HTTP头中用于标识算法的令牌。
o Specification: A reference for the specification defining the algorithm.
o 规范：定义算法的规范的参考。
The initial content of this registry is as follows:
本登记册的初始内容如下：
+-------------------------------+------------------------------+
| Token | Specification |
+-------------------------------+------------------------------+
| auth-style | Section 4.2 of this document |
| location-when-unauthenticated | Section 4.3 of this document |
| no-auth | Section 4.4 of this document |
| location-when-logout | Section 4.5 of this document |
| logout-timeout | Section 4.6 of this document |
| username | Section 4.7 of this document |
+-------------------------------+------------------------------+
+-------------------------------+------------------------------+
| Token | Specification |
+-------------------------------+------------------------------+
| auth-style | Section 4.2 of this document |
| location-when-unauthenticated | Section 4.3 of this document |
| no-auth | Section 4.4 of this document |
| location-when-logout | Section 4.5 of this document |
| logout-timeout | Section 4.6 of this document |
| username | Section 4.7 of this document |
+-------------------------------+------------------------------+
The purpose of the logout timeout feature in the Authentication-control header is to protect users of clients from impersonation caused by an attacker having access to the same console. The server application implementers SHOULD be aware that the directive may always be ignored by either malicious clients or clients not supporting this extension. If the purpose of introducing a timeout for an authentication period is to protect server-side resources, this protection MUST be implemented by other means such as HTTP Cookies [RFC6265].
身份验证控制标头中的注销超时功能的目的是保护客户端用户不受访问同一控制台的攻击者造成的模拟。服务器应用程序实现者应该知道，恶意客户端或不支持此扩展的客户端可能总是忽略该指令。如果为认证周期引入超时的目的是保护服务器端资源，则必须通过HTTP cookie等其他方式实现此保护[RFC6265]。
All parameters in the Authentication-Control header SHOULD NOT be used for any security-enforcement purposes. Server-side applications MUST NOT assume that the header will be honored by clients and users.
身份验证控制标头中的所有参数不应用于任何安全强制目的。服务器端应用程序不得假定客户端和用户将遵守标头。
The "username" parameter sometimes reveals sensitive information about the HTTP server and its configurations that are useful for security attacks. In general, common security practice suggests that any kind of information on the existence/non-existence of a specific username shall not be disclosed before successful authentication. Obviously, the "username" parameter contradicts this practice.
“username”参数有时会显示有关HTTP服务器及其配置的敏感信息，这些信息对安全攻击非常有用。一般来说，常见的安全实践表明，在成功认证之前，不得披露关于特定用户名存在/不存在的任何信息。显然，“username”参数与这种做法相矛盾。
Given this background, the use of the "username" parameter SHOULD be strictly limited to cases where all of the following conditions are met:
在这种背景下，“username”参数的使用应严格限于满足以下所有条件的情况：
(1) the valid username is pre-configured and not modifiable (such as root, admin, or similar ones);
(1) 有效用户名是预先配置的，不可修改（如root、admin或类似用户名）；
(2) the valid username for such an appliance is publicly known (for example, written in a manual document); and
(2) 此类设备的有效用户名是公开的（例如，写在手册文档中）；和
(3) either the valid username for the server is easily guessable by other means (for example, from the model number shown in an unauthenticated page), or the server is accessible only from limited networks.
(3) 服务器的有效用户名可以通过其他方式轻松猜测（例如，通过未经验证的页面中显示的型号），或者服务器只能通过有限的网络访问。
Most importantly, the "username" parameter SHOULD NOT be used in any case when the valid usernames can be changed/configured by users or administrators.
最重要的是，当用户或管理员可以更改/配置有效用户名时，不应在任何情况下使用“username”参数。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, <http://www.rfc-editor.org/info/rfc5987>.
[RFC5987]Reschke，J.，“超文本传输协议（HTTP）头字段参数的字符集和语言编码”，RFC 5987，DOI 10.17487/RFC5987，2010年8月<http://www.rfc-editor.org/info/rfc5987>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.
[RFC7564]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备、实施和比较”，RFC 7564，DOI 10.17487/RFC7564，2015年5月<http://www.rfc-editor.org/info/rfc7564>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>.
[RFC7615]Reschke，J.，“HTTP身份验证信息和代理身份验证信息响应头字段”，RFC 7615，DOI 10.17487/RFC7615，2015年9月<http://www.rfc-editor.org/info/rfc7615>.
[W3C.REC-webstorage-20130730] Hickson, I., "Web Storage", World Wide Web Consortium Recommendation REC-webstorage-20130730, July 2013, <http://www.w3.org/TR/2013/REC-webstorage-20130730>.
[W3C.REC-webstorage-20130730]希克森，I.，“网络存储”，万维网联盟建议REC-webstorage-20130730，2013年7月<http://www.w3.org/TR/2013/REC-webstorage-20130730>.
Appendix A. (Informative) Applicability of Features for Each Message
附录A（资料性附录）各信息功能的适用性
This section provides a cross-reference table showing the applicability of the features provided in this specification to each kind of response described in Section 2.1. The table provided in this section is for informative purposes only.
本节提供了一个对照表，显示了本规范中提供的特征对第2.1节中描述的每种响应的适用性。本节提供的表格仅供参考。
+-------------------+-------+----------+-----------+------+
| | init. | success. | intermed. | neg. |
+-------------------+-------+----------+-----------+------+
| Optional auth. | O | n | N | N |
| auth-style | O | - | - | O |
| loc.-when-unauth. | O | I | I | i |
| no-auth | O | I | I | i |
| loc.-when-logout | - | O | - | - |
| logout-timeout | - | O | - | - |
| username | O | - | - | O |
+-------------------+-------+----------+-----------+------+
+-------------------+-------+----------+-----------+------+
| | init. | success. | intermed. | neg. |
+-------------------+-------+----------+-----------+------+
| Optional auth. | O | n | N | N |
| auth-style | O | - | - | O |
| loc.-when-unauth. | O | I | I | i |
| no-auth | O | I | I | i |
| loc.-when-logout | - | O | - | - |
| logout-timeout | - | O | - | - |
| username | O | - | - | O |
+-------------------+-------+----------+-----------+------+
Legends:
O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain
i = SHOULD be ignored; I = MUST be ignored;
- = meaningless (to be ignored)
Legends:
O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain
i = SHOULD be ignored; I = MUST be ignored;
- = meaningless (to be ignored)
Authors' Addresses
作者地址
Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Yutaka Oiwa国家高级工业科学技术研究所信息技术研究所筑波中心1 1-1-1日本茨城市梅佐诺筑波市
Email: y.oiwa@aist.go.jp
Email: y.oiwa@aist.go.jp
Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
渡边哈吉国家高级工业科学技术研究所信息技术研究所筑波中心1 1-1-1日本茨城梅佐诺筑波市
Email: h-watanabe@aist.go.jp
Email: h-watanabe@aist.go.jp
Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Hiromitsu Takagi国家高级工业科学技术研究所信息技术研究所筑波中心1 1-1-1日本茨城市梅佐诺筑波市
Email: takagi.hiromitsu@aist.go.jp
Email: takagi.hiromitsu@aist.go.jp
Kaoru Maeda Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo Japan
Kaoru Maeda Lepidum有限公司位于日本东京涩谷佐佐助村3号602室1-30-3
Email: maeda@lepidum.co.jp
Email: maeda@lepidum.co.jp
Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo Japan
Tatsuya Hayashi Lepidum有限公司位于日本东京涩谷佐佐助村3号602 1-30-3室
Email: hayashi@lepidum.co.jp
Email: hayashi@lepidum.co.jp
Yuichi Ioku Individual Contributor
Ioku Yuichi个人撰稿人
Email: mutual-work@ioku.org
Email: mutual-work@ioku.org