Internet Engineering Task Force (IETF) A. Barth
Request for Comments: 6265 U.C. Berkeley
Obsoletes: 2965 April 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Barth
Request for Comments: 6265 U.C. Berkeley
Obsoletes: 2965 April 2011
Category: Standards Track
ISSN: 2070-1721
HTTP State Management Mechanism
HTTP国家管理机制
Abstract
摘要
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965.
本文档定义了HTTP Cookie和Set Cookie标头字段。HTTP服务器可以使用这些头字段在HTTP用户代理上存储状态（称为cookie），从而允许服务器通过基本无状态的HTTP协议维护有状态会话。尽管Cookie有许多降低其安全性和隐私性的历史缺陷，但Cookie和Set Cookie标头字段在Internet上被广泛使用。本文件淘汰RFC 2965。
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/rfc6265.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6265.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................4
2.1. Conformance Criteria .......................................4
2.2. Syntax Notation ............................................5
2.3. Terminology ................................................5
3. Overview ........................................................6
3.1. Examples ...................................................6
4. Server Requirements .............................................8
4.1. Set-Cookie .................................................8
4.1.1. Syntax ..............................................8
4.1.2. Semantics (Non-Normative) ..........................10
4.2. Cookie ....................................................13
4.2.1. Syntax .............................................13
4.2.2. Semantics ..........................................13
5. User Agent Requirements ........................................14
5.1. Subcomponent Algorithms ...................................14
5.1.1. Dates ..............................................14
5.1.2. Canonicalized Host Names ...........................16
5.1.3. Domain Matching ....................................16
5.1.4. Paths and Path-Match ...............................16
5.2. The Set-Cookie Header .....................................17
5.2.1. The Expires Attribute ..............................19
5.2.2. The Max-Age Attribute ..............................20
5.2.3. The Domain Attribute ...............................20
5.2.4. The Path Attribute .................................21
5.2.5. The Secure Attribute ...............................21
5.2.6. The HttpOnly Attribute .............................21
5.3. Storage Model .............................................21
5.4. The Cookie Header .........................................25
6. Implementation Considerations ..................................27
6.1. Limits ....................................................27
6.2. Application Programming Interfaces ........................27
6.3. IDNA Dependency and Migration .............................27
7. Privacy Considerations .........................................28
1. Introduction ....................................................3
2. Conventions .....................................................4
2.1. Conformance Criteria .......................................4
2.2. Syntax Notation ............................................5
2.3. Terminology ................................................5
3. Overview ........................................................6
3.1. Examples ...................................................6
4. Server Requirements .............................................8
4.1. Set-Cookie .................................................8
4.1.1. Syntax ..............................................8
4.1.2. Semantics (Non-Normative) ..........................10
4.2. Cookie ....................................................13
4.2.1. Syntax .............................................13
4.2.2. Semantics ..........................................13
5. User Agent Requirements ........................................14
5.1. Subcomponent Algorithms ...................................14
5.1.1. Dates ..............................................14
5.1.2. Canonicalized Host Names ...........................16
5.1.3. Domain Matching ....................................16
5.1.4. Paths and Path-Match ...............................16
5.2. The Set-Cookie Header .....................................17
5.2.1. The Expires Attribute ..............................19
5.2.2. The Max-Age Attribute ..............................20
5.2.3. The Domain Attribute ...............................20
5.2.4. The Path Attribute .................................21
5.2.5. The Secure Attribute ...............................21
5.2.6. The HttpOnly Attribute .............................21
5.3. Storage Model .............................................21
5.4. The Cookie Header .........................................25
6. Implementation Considerations ..................................27
6.1. Limits ....................................................27
6.2. Application Programming Interfaces ........................27
6.3. IDNA Dependency and Migration .............................27
7. Privacy Considerations .........................................28
7.1. Third-Party Cookies .......................................28
7.2. User Controls .............................................28
7.3. Expiration Dates ..........................................29
8. Security Considerations ........................................29
8.1. Overview ..................................................29
8.2. Ambient Authority .........................................30
8.3. Clear Text ................................................30
8.4. Session Identifiers .......................................31
8.5. Weak Confidentiality ......................................32
8.6. Weak Integrity ............................................32
8.7. Reliance on DNS ...........................................33
9. IANA Considerations ............................................33
9.1. Cookie ....................................................34
9.2. Set-Cookie ................................................34
9.3. Cookie2 ...................................................34
9.4. Set-Cookie2 ...............................................34
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................35
Appendix A. Acknowledgements ......................................37
7.1. Third-Party Cookies .......................................28
7.2. User Controls .............................................28
7.3. Expiration Dates ..........................................29
8. Security Considerations ........................................29
8.1. Overview ..................................................29
8.2. Ambient Authority .........................................30
8.3. Clear Text ................................................30
8.4. Session Identifiers .......................................31
8.5. Weak Confidentiality ......................................32
8.6. Weak Integrity ............................................32
8.7. Reliance on DNS ...........................................33
9. IANA Considerations ............................................33
9.1. Cookie ....................................................34
9.2. Set-Cookie ................................................34
9.3. Cookie2 ...................................................34
9.4. Set-Cookie2 ...............................................34
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................35
Appendix A. Acknowledgements ......................................37
This document defines the HTTP Cookie and Set-Cookie header fields. Using the Set-Cookie header field, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent. When the user agent makes subsequent requests to the server, the user agent uses the metadata and other information to determine whether to return the name/value pairs in the Cookie header.
本文档定义了HTTP Cookie和Set Cookie标头字段。使用Set Cookie header字段，HTTP服务器可以将名称/值对和相关元数据（称为Cookie）传递给用户代理。当用户代理向服务器发出后续请求时，用户代理使用元数据和其他信息来确定是否返回Cookie头中的名称/值对。
Although simple on their surface, cookies have a number of complexities. For example, the server indicates a scope for each cookie when sending it to the user agent. The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, and the URI schemes for which the cookie is applicable.
虽然饼干表面上很简单，但它有许多复杂性。例如，服务器在将每个cookie发送到用户代理时指示其作用域。范围指示用户代理应返回cookie的最长时间、用户代理应返回cookie的服务器以及cookie适用的URI方案。
For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for "secure" connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.
出于历史原因，Cookie包含许多安全和隐私方面的缺陷。例如，服务器可以指示给定cookie用于“安全”连接，但secure属性在活动网络攻击者存在时不提供完整性。类似地，给定主机的cookie在该主机上的所有端口上共享，即使web浏览器使用的通常“同源策略”隔离了通过不同端口检索的内容。
There are two audiences for this specification: developers of cookie-generating servers and developers of cookie-consuming user agents.
此规范有两个受众：生成cookie的服务器的开发人员和使用cookie的用户代理的开发人员。
To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in Section 4 when generating cookies.
为了最大限度地提高与用户代理的互操作性，服务器在生成cookie时应将自己限制在第4节中定义的行为良好的概要文件内。
User agents MUST implement the more liberal processing rules defined in Section 5, in order to maximize interoperability with existing servers that do not conform to the well-behaved profile defined in Section 4.
用户代理必须实现第5节中定义的更自由的处理规则，以便最大限度地提高与不符合第4节中定义的良好配置文件的现有服务器的互操作性。
This document specifies the syntax and semantics of these headers as they are actually used on the Internet. In particular, this document does not create new syntax or semantics beyond those in use today. The recommendations for cookie generation provided in Section 4 represent a preferred subset of current server behavior, and even the more liberal cookie processing algorithm provided in Section 5 does not recommend all of the syntactic and semantic variations in use today. Where some existing software differs from the recommended protocol in significant ways, the document contains a note explaining the difference.
本文档指定了这些标题的语法和语义，因为它们在Internet上实际使用。特别是，本文档不会创建今天使用的语法或语义之外的新语法或语义。第4节中提供的cookie生成建议代表了当前服务器行为的首选子集，即使第5节中提供的更自由的cookie处理算法也不推荐当前使用的所有语法和语义变体。如果某些现有软件与推荐的协议存在重大差异，则文档中会包含一条注释，解释差异。
Prior to this document, there were at least three descriptions of cookies: the so-called "Netscape cookie specification" [Netscape], RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these documents describe how the Cookie and Set-Cookie headers are actually used on the Internet (see [Kri2001] for historical context). In relation to previous IETF specifications of HTTP state management mechanisms, this document requests the following actions:
在此文档之前，至少有三种cookie描述：所谓的“Netscape cookie规范”[Netscape]、RFC 2109[RFC2109]和RFC 2965[RFC2965]。但是，这些文档都没有描述Cookie和Set-Cookie头在Internet上的实际使用方式（有关历史上下文，请参见[Kri2001]）。关于HTTP状态管理机制的先前IETF规范，本文件要求采取以下措施：
1. Change the status of [RFC2109] to Historic (it has already been obsoleted by [RFC2965]).
1. 将[RFC2109]的状态更改为历史状态（已被[RFC2965]淘汰）。
2. Change the status of [RFC2965] to Historic.
2. 将[RFC2965]的状态更改为历史。
3. Indicate that [RFC2965] has been obsoleted by this document.
3. 表明[RFC2965]已被本文件淘汰。
In particular, in moving RFC 2965 to Historic and obsoleting it, this document deprecates the use of the Cookie2 and Set-Cookie2 header fields.
特别是，在将RFC 2965移动到历史位置并将其淘汰时，本文档不推荐使用Cookie2和Set-Cookie2头字段。
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]中所述进行解释。
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
作为算法一部分的命令式要求（如“去除任何前导空格字符”或“返回false并中止这些步骤”）应使用介绍算法时使用的关键词（“必须”、“应该”、“可能”等）的含义进行解释。
Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant.
作为算法或特定步骤的一致性需求可以以任何方式实现，只要最终结果是等效的。特别是，本规范中定义的算法旨在易于理解，而不是用于执行。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）符号。
The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible [USASCII] character), and WSP (whitespace).
根据[RFC5234]附录B.1中的定义，以下核心规则通过引用包括在内：α（字母）、CR（回车）、CRLF（CR LF）、CTL（控件）、数字（十进制0-9）、DQUOTE（双引号）、HEXDIG（十六进制0-9/A-F/A-F）、LF（换行）、NUL（空八位字节）、八位字节（除NUL外的任何8位数据序列）、SP（空格）、HTAB（水平选项卡）、CHAR（任何[USASCII]字符）、VCHAR（任何可见[USASCII]字符）和WSP（空白）。
The OWS (optional whitespace) rule is used where zero or more linear whitespace characters MAY appear:
OWS（可选空白）规则用于可能出现零个或多个线性空白字符的情况：
OWS = *( [ obs-fold ] WSP )
; "optional" whitespace
obs-fold = CRLF
OWS = *( [ obs-fold ] WSP )
; "optional" whitespace
obs-fold = CRLF
OWS SHOULD either not be produced or be produced as a single SP character.
OWS不应生成或作为单个SP字符生成。
The terms user agent, client, server, proxy, and origin server have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).
术语用户代理、客户端、服务器、代理和源服务器的含义与HTTP/1.1规范（[RFC2616]，第1.3节）中的含义相同。
The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it is receiving an HTTP response (i.e., the name of the host to which it sent the corresponding HTTP request).
请求主机是用户代理已知的主机名，用户代理向其发送HTTP请求或从其接收HTTP响应（即，向其发送相应HTTP请求的主机名）。
The term request-uri is defined in Section 5.1.2 of [RFC2616].
[RFC2616]第5.1.2节定义了术语请求uri。
Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap collation defined in [RFC4790].
当且仅当两个八位元序列在i下相等时，称它们为大小写不敏感匹配；[RFC4790]中定义的ascii casemap排序规则。
The term string means a sequence of non-NUL octets.
术语字符串表示非NUL八位字节序列。
This section outlines a way for an origin server to send state information to a user agent and for the user agent to return the state information to the origin server.
本节概述了源服务器向用户代理发送状态信息以及用户代理向源服务器返回状态信息的方法。
To store state, the origin server includes a Set-Cookie header in an HTTP response. In subsequent requests, the user agent returns a Cookie request header to the origin server. The Cookie header contains cookies the user agent received in previous Set-Cookie headers. The origin server is free to ignore the Cookie header or use its contents for an application-defined purpose.
为了存储状态，源服务器在HTTP响应中包含一个Set Cookie头。在后续请求中，用户代理将Cookie请求头返回给源服务器。Cookie标头包含用户代理在以前设置的Cookie标头中接收到的Cookie。源服务器可以忽略Cookie头或将其内容用于应用程序定义的目的。
Origin servers MAY send a Set-Cookie response header with any response. User agents MAY ignore Set-Cookie headers contained in responses with 100-level status codes but MUST process Set-Cookie headers contained in other responses (including responses with 400- and 500-level status codes). An origin server can include multiple Set-Cookie header fields in a single response. The presence of a Cookie or a Set-Cookie header field does not preclude HTTP caches from storing and reusing a response.
源服务器可以发送带有任何响应的集合Cookie响应头。用户代理可以忽略包含在具有100级状态代码的响应中的Set-Cookie标头，但必须处理包含在其他响应中的Set-Cookie标头（包括包含400级和500级状态代码的响应）。源服务器可以在单个响应中包含多个Set Cookie头字段。Cookie或Set-Cookie标头字段的存在并不妨碍HTTP缓存存储和重用响应。
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.
源服务器不应将多个集合Cookie标头字段折叠为单个标头字段。折叠HTTP标头字段的常用机制（即[RFC2616]中定义的）可能会更改集合Cookie标头字段的语义，因为集合Cookie使用的%x2C（“，”）字符与这种折叠方式冲突。
Using the Set-Cookie header, a server can send the user agent a short string in an HTTP response that the user agent will return in future HTTP requests that are within the scope of the cookie. For example, the server can send the user agent a "session identifier" named SID with the value 31d4d96e407aad42. The user agent then returns the session identifier in subsequent requests.
使用Set Cookie标头，服务器可以在HTTP响应中向用户代理发送一个短字符串，用户代理将在Cookie范围内的未来HTTP请求中返回该字符串。例如，服务器可以向用户代理发送一个名为SID的“会话标识符”，其值为31d4d96e407aad42。然后，用户代理在后续请求中返回会话标识符。
== Server -> User Agent ==
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42
设置Cookie:SID=31d4d96e407aad42
== User Agent -> Server ==
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
Cookie:SID=31d4d96e407aad42
The server can alter the default scope of the cookie using the Path and Domain attributes. For example, the server can instruct the user agent to return the cookie to every path and every subdomain of example.com.
服务器可以使用路径和域属性更改cookie的默认范围。例如，服务器可以指示用户代理将cookie返回到example.com的每个路径和每个子域。
== Server -> User Agent ==
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com
== User Agent -> Server ==
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
Cookie:SID=31d4d96e407aad42
As shown in the next example, the server can store multiple cookies at the user agent. For example, the server can store a session identifier as well as the user's preferred language by returning two Set-Cookie header fields. Notice that the server uses the Secure and HttpOnly attributes to provide additional security protections for the more sensitive session identifier (see Section 4.1.2.)
如下一个示例所示，服务器可以在用户代理中存储多个cookie。例如，服务器可以通过返回两个Set Cookie头字段来存储会话标识符以及用户的首选语言。请注意，服务器使用Secure和HttpOnly属性为更敏感的会话标识符提供额外的安全保护（请参阅第4.1.2节）
== Server -> User Agent ==
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=example.com
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=example.com
== User Agent -> Server ==
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42; lang=en-US
Cookie: SID=31d4d96e407aad42; lang=en-US
Notice that the Cookie header above contains two cookies, one named SID and one named lang. If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute. Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie.
请注意，上面的Cookie标头包含两个Cookie，一个名为SID，一个名为lang。如果服务器希望用户代理在多个“会话”（例如，用户代理重新启动）上保留Cookie，则服务器可以在Expires属性中指定过期日期。请注意，如果用户代理的cookie存储超过其配额，或者如果用户手动删除服务器的cookie，则用户代理可能会在到期日期之前删除cookie。
== Server -> User Agent ==
== Server -> User Agent ==
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
== User Agent -> Server ==
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42; lang=en-US
Cookie: SID=31d4d96e407aad42; lang=en-US
Finally, to remove a cookie, the server returns a Set-Cookie header with an expiration date in the past. The server will be successful in removing the cookie only if the Path and the Domain attribute in the Set-Cookie header match the values used when the cookie was created.
最后，要删除cookie，服务器返回一个设置cookie头，其过期日期为过去。只有当Set cookie头中的Path和Domain属性与创建cookie时使用的值匹配时，服务器才能成功删除cookie。
== Server -> User Agent ==
== Server -> User Agent ==
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
== User Agent -> Server ==
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
Cookie:SID=31d4d96e407aad42
This section describes the syntax and semantics of a well-behaved profile of the Cookie and Set-Cookie headers.
本节描述Cookie和Set Cookie头的行为良好的概要文件的语法和语义。
The Set-Cookie HTTP response header is used to send cookies from the server to the user agent.
Set-Cookie HTTP响应头用于将Cookie从服务器发送到用户代理。
Informally, the Set-Cookie response header contains the header name "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with a name-value-pair, followed by zero or more attribute-value pairs. Servers SHOULD NOT send Set-Cookie headers that fail to conform to the following grammar:
非正式地说，Set Cookie响应头包含头名称“Set Cookie”，后跟“：”和Cookie。每个cookie以一个名称-值对开始，后跟零个或多个属性-值对。服务器不应发送不符合以下语法的Set-Cookie标头：
set-cookie-header = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = <token, defined in [RFC2616], Section 2.2>
set-cookie-header = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av
; are limited to dates representable by the
; user agent.
non-zero-digit = %x31-39
; digits 1 through 9
domain-av = "Domain=" domain-value
domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av
; are limited to dates representable by the
; user agent.
non-zero-digit = %x31-39
; digits 1 through 9
domain-av = "Domain=" domain-value
domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
Note that some of the grammatical terms above reference documents that use different grammatical notations than this document (which uses ABNF from [RFC5234]).
请注意，上述一些语法术语引用了与本文件（使用[RFC5234]中的ABNF）使用不同语法符号的文件。
The semantics of the cookie-value are not defined by this document.
本文档未定义cookie值的语义。
To maximize compatibility with user agents, servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 [RFC4648].
为了最大限度地与用户代理兼容，希望在cookie值中存储任意数据的服务器应该对该数据进行编码，例如，使用Base64[RFC4648]。
The portions of the set-cookie-string produced by the cookie-av term are known as attributes. To maximize compatibility with user agents, servers SHOULD NOT produce two attributes with the same name in the same set-cookie-string. (See Section 5.3 for how user agents handle this case.)
cookie av术语产生的集合cookie字符串的部分称为属性。为了最大限度地与用户代理兼容，服务器不应在同一组cookie字符串中生成两个同名属性。（有关用户代理如何处理这种情况，请参见第5.3节。）
Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. (See Section 5.2 for how user agents handle this case.)
服务器不应在具有相同Cookie名称的同一响应中包含多个Set Cookie头字段。（有关用户代理如何处理这种情况，请参见第5.2节。）
If a server sends multiple responses containing Set-Cookie headers concurrently to the user agent (e.g., when communicating with the user agent over multiple sockets), these responses create a "race condition" that can lead to unpredictable behavior.
如果服务器同时向用户代理发送多个包含Set-Cookie头的响应（例如，当通过多个套接字与用户代理通信时），这些响应将创建一个“竞争条件”，可能导致不可预测的行为。
NOTE: Some existing user agents differ in their interpretation of two-digit years. To avoid compatibility issues, servers SHOULD use the rfc1123-date format, which requires a four-digit year.
注：一些现有用户代理对两位数年份的解释不同。为避免兼容性问题，服务器应使用rfc1123日期格式，该格式需要四位数的年份。
NOTE: Some user agents store and process dates in cookies as 32-bit UNIX time_t values. Implementation bugs in the libraries supporting time_t processing on some systems might cause such user agents to process dates after the year 2038 incorrectly.
注意：一些用户代理将日期作为32位UNIX时间值存储和处理在cookie中。在某些系统上支持时间处理的库中的实现错误可能会导致此类用户代理错误地处理2038年之后的日期。
This section describes simplified semantics of the Set-Cookie header. These semantics are detailed enough to be useful for understanding the most common uses of cookies by servers. The full semantics are described in Section 5.
本节描述Set Cookie头的简化语义。这些语义足够详细，有助于理解服务器对cookie的最常见使用。第5节描述了完整的语义。
When the user agent receives a Set-Cookie header, the user agent stores the cookie together with its attributes. Subsequently, when the user agent makes an HTTP request, the user agent includes the applicable, non-expired cookies in the Cookie header.
当用户代理收到设置的Cookie头时，用户代理将Cookie及其属性一起存储。随后，当用户代理发出HTTP请求时，用户代理在Cookie头中包括适用的、未过期的Cookie。
If the user agent receives a new cookie with the same cookie-name, domain-value, and path-value as a cookie that it has already stored, the existing cookie is evicted and replaced with the new cookie. Notice that servers can delete cookies by sending the user agent a new cookie with an Expires attribute with a value in the past.
如果用户代理接收到一个新cookie，该cookie与它已存储的cookie具有相同的cookie名称、域值和路径值，则现有cookie将被逐出并替换为新cookie。请注意，服务器可以通过向用户代理发送一个新的cookie来删除cookie，该cookie具有Expires属性，并且具有过去的值。
Unless the cookie's attributes indicate otherwise, the cookie is returned only to the origin server (and not, for example, to any subdomains), and it expires at the end of the current session (as defined by the user agent). User agents ignore unrecognized cookie attributes (but not the entire cookie).
除非cookie的属性另有指示，否则cookie仅返回到源服务器（例如，不返回到任何子域），并且在当前会话结束时过期（由用户代理定义）。用户代理忽略无法识别的cookie属性（但不忽略整个cookie）。
The Expires attribute indicates the maximum lifetime of the cookie, represented as the date and time at which the cookie expires. The user agent is not required to retain the cookie until the specified date has passed. In fact, user agents often evict cookies due to memory pressure or privacy concerns.
Expires属性表示cookie的最长生存期，表示为cookie过期的日期和时间。用户代理不需要保留cookie，直到指定的日期过去。事实上，由于内存压力或隐私问题，用户代理通常会逐出cookie。
The Max-Age attribute indicates the maximum lifetime of the cookie, represented as the number of seconds until the cookie expires. The user agent is not required to retain the cookie for the specified duration. In fact, user agents often evict cookies due to memory pressure or privacy concerns.
Max Age属性表示cookie的最长生存期，表示为cookie过期前的秒数。用户代理不需要在指定的持续时间内保留cookie。事实上，由于内存压力或隐私问题，用户代理通常会逐出cookie。
NOTE: Some existing user agents do not support the Max-Age attribute. User agents that do not support the Max-Age attribute ignore the attribute.
注意：某些现有用户代理不支持“最大年龄”属性。不支持“最大年龄”属性的用户代理将忽略该属性。
If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie. If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until "the current session is over" (as defined by the user agent).
如果cookie同时具有Max Age和Expires属性，则Max Age属性具有优先权并控制cookie的过期日期。如果cookie既没有Max Age属性，也没有Expires属性，则用户代理将保留cookie，直到“当前会话结束”（由用户代理定义）。
The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.) If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.
Domain属性指定cookie将发送到的主机。例如，如果域属性的值为“example.com”，则当向example.com、www.example.com和www.corp.example.com发出HTTP请求时，用户代理将在cookie头中包含cookie。（请注意，前导的%x2E（“.”）如果存在，将被忽略，即使不允许使用该字符，但尾随的%x2E（“.”）如果存在，将导致用户代理忽略该属性。）如果服务器忽略域属性，则用户代理将仅将cookie返回给源服务器。
WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name. For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to www.example.com as well.
警告：某些现有用户代理将缺少的域属性视为域属性存在并包含当前主机名。例如，如果example.com返回一个没有域属性的Set Cookie头，这些用户代理也会错误地将Cookie发送到www.example.com。
The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".
用户代理将拒绝cookie，除非Domain属性为cookie指定了包含源服务器的范围。例如，用户代理将从foo.example.com接受域属性为“example.com”或“foo.example.com”的cookie，但用户代理将不接受域属性为“bar.example.com”或“baz.foo.example.com”的cookie。
NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes". For example, some user agents will reject Domain attributes of "com" or "co.uk". (See Section 5.3 for more information.)
注意：出于安全原因，许多用户代理被配置为拒绝与“公共后缀”对应的域属性。例如，一些用户代理将拒绝“com”或“co.uk”的域属性。（详见第5.3节。）
The scope of each cookie is limited to a set of paths, controlled by the Path attribute. If the server omits the Path attribute, the user agent will use the "directory" of the request-uri's path component as the default value. (See Section 5.1.4 for more details.)
每个cookie的作用域仅限于一组路径，由Path属性控制。如果服务器省略了Path属性，那么用户代理将使用请求uri的Path组件的“目录”作为默认值。（详见第5.1.4节。）
The user agent will include the cookie in an HTTP request only if the path portion of the request-uri matches (or is a subdirectory of) the cookie's Path attribute, where the %x2F ("/") character is interpreted as a directory separator.
仅当请求uri的路径部分与cookie的路径属性匹配（或是其子目录），其中%x2F（“/”）字符被解释为目录分隔符时，用户代理才会在HTTP请求中包含cookie。
Although seemingly useful for isolating cookies between different paths within a given host, the Path attribute cannot be relied upon for security (see Section 8).
虽然对于在给定主机内的不同路径之间隔离cookie似乎很有用，但不能依赖Path属性来实现安全性（请参见第8节）。
The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).
Secure属性将cookie的范围限制为“安全”通道（其中“安全”由用户代理定义）。当cookie具有Secure属性时，仅当请求通过安全通道传输时，用户代理才会将cookie包括在HTTP请求中（通常是HTTP over Transport Layer Security（TLS）[RFC2818]）。
Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more details).
虽然似乎有助于保护cookie免受主动网络攻击者的攻击，但安全属性仅保护cookie的机密性。主动网络攻击者可以覆盖来自不安全通道的安全cookie，从而破坏其完整性（有关更多详细信息，请参阅第8.6节）。
The HttpOnly attribute limits the scope of the cookie to HTTP requests. In particular, the attribute instructs the user agent to omit the cookie when providing access to cookies via "non-HTTP" APIs (such as a web browser API that exposes cookies to scripts).
HttpOnly属性将cookie的范围限制为HTTP请求。特别是，该属性指示用户代理在通过“非HTTP”API（例如向脚本公开cookie的web浏览器API）提供对cookie的访问时忽略cookie。
Note that the HttpOnly attribute is independent of the Secure attribute: a cookie can have both the HttpOnly and the Secure attribute.
Note that the HttpOnly attribute is independent of the Secure attribute: a cookie can have both the HttpOnly and the Secure attribute.translate error, please retry
The user agent sends stored cookies to the origin server in the Cookie header. If the server conforms to the requirements in Section 4.1 (and the user agent conforms to the requirements in Section 5), the user agent will send a Cookie header that conforms to the following grammar:
用户代理在Cookie头中将存储的Cookie发送到源服务器。如果服务器符合第4.1节的要求（并且用户代理符合第5节的要求），则用户代理将发送符合以下语法的Cookie头：
cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" SP cookie-pair )
cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" SP cookie-pair )
Each cookie-pair represents a cookie stored by the user agent. The cookie-pair contains the cookie-name and cookie-value the user agent received in the Set-Cookie header.
每个cookie对表示用户代理存储的cookie。cookie对包含用户代理在Set cookie标头中接收到的cookie名称和cookie值。
Notice that the cookie attributes are not returned. In particular, the server cannot determine from the Cookie header alone when a cookie will expire, for which hosts the cookie is valid, for which paths the cookie is valid, or whether the cookie was set with the Secure or HttpOnly attributes.
请注意，不会返回cookie属性。特别是，服务器无法仅从Cookie头确定Cookie何时过期、Cookie对哪些主机有效、Cookie对哪些路径有效，或者Cookie是否设置了Secure或HttpOnly属性。
The semantics of individual cookies in the Cookie header are not defined by this document. Servers are expected to imbue these cookies with application-specific semantics.
本文档未定义Cookie标头中各个Cookie的语义。服务器应该为这些cookie注入特定于应用程序的语义。
Although cookies are serialized linearly in the Cookie header, servers SHOULD NOT rely upon the serialization order. In particular, if the Cookie header contains two cookies with the same name (e.g., that were set with different Path or Domain attributes), servers SHOULD NOT rely upon the order in which these cookies appear in the header.
尽管Cookie在Cookie标头中线性序列化，但服务器不应依赖于序列化顺序。特别是，如果Cookie标头包含两个具有相同名称的Cookie（例如，使用不同的路径或域属性设置的Cookie），则服务器不应依赖这些Cookie在标头中的显示顺序。
This section specifies the Cookie and Set-Cookie headers in sufficient detail that a user agent implementing these requirements precisely can interoperate with existing servers (even those that do not conform to the well-behaved profile described in Section 4).
本节详细说明了Cookie和Set-Cookie头，以使实现这些要求的用户代理能够与现有服务器（即使是那些不符合第4节中描述的良好配置文件的服务器）进行互操作。
A user agent could enforce more restrictions than those specified herein (e.g., for the sake of improved security); however, experiments have shown that such strictness reduces the likelihood that a user agent will be able to interoperate with existing servers.
用户代理可以实施比本文中指定的限制更多的限制（例如，为了提高安全性）；然而，实验表明，这种严格性降低了用户代理能够与现有服务器互操作的可能性。
This section defines some algorithms used by user agents to process specific subcomponents of the Cookie and Set-Cookie headers.
本节定义了用户代理用来处理Cookie的特定子组件和设置Cookie头的一些算法。
The user agent MUST use an algorithm equivalent to the following algorithm to parse a cookie-date. Note that the various boolean flags defined as a part of the algorithm (i.e., found-time, found-day-of-month, found-month, found-year) are initially "not set".
用户代理必须使用与以下算法等效的算法来解析cookie日期。请注意，定义为算法一部分的各种布尔标志（即查找时间、查找月份的第几天、查找月份、查找年份）最初是“未设置”的。
1. Using the grammar below, divide the cookie-date into date-tokens.
1. 使用下面的语法，将cookie日期划分为日期标记。
cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter
cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF
day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT
day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT
2. Process each date-token sequentially in the order the date-tokens appear in the cookie-date:
2. 按照日期标记在cookie日期中出现的顺序依次处理每个日期标记：
1. If the found-time flag is not set and the token matches the time production, set the found-time flag and set the hour-value, minute-value, and second-value to the numbers denoted by the digits in the date-token, respectively. Skip the remaining sub-steps and continue to the next date-token.
1. 如果未设置查找时间标志且令牌与时间生产相匹配，则设置查找时间标志，并将小时值、分钟值和秒值分别设置为日期令牌中数字表示的数字。跳过其余子步骤，继续下一个日期标记。
2. If the found-day-of-month flag is not set and the date-token matches the day-of-month production, set the found-day-of-month flag and set the day-of-month-value to the number denoted by the date-token. Skip the remaining sub-steps and continue to the next date-token.
2. 如果未设置查找到的月份标志，且日期标记与当月生产日期匹配，则设置查找到的月份标志，并将月份值设置为日期标记表示的数字。跳过其余子步骤，继续下一个日期标记。
3. If the found-month flag is not set and the date-token matches the month production, set the found-month flag and set the month-value to the month denoted by the date-token. Skip the remaining sub-steps and continue to the next date-token.
3. 如果未设置found month标志，并且日期标记与月份生产相匹配，则设置found month标志，并将月份值设置为日期标记表示的月份。跳过其余子步骤，继续下一个日期标记。
4. If the found-year flag is not set and the date-token matches the year production, set the found-year flag and set the year-value to the number denoted by the date-token. Skip the remaining sub-steps and continue to the next date-token.
4. 如果未设置查找年份标志且日期标记与年份产量匹配，则设置查找年份标志并将年份值设置为日期标记所表示的数字。跳过其余子步骤，继续下一个日期标记。
3. If the year-value is greater than or equal to 70 and less than or equal to 99, increment the year-value by 1900.
3. 如果年份值大于或等于70且小于或等于99，则将年份值增加1900。
4. If the year-value is greater than or equal to 0 and less than or equal to 69, increment the year-value by 2000.
4. 如果年份值大于或等于0且小于或等于69，则将年份值增加2000。
1. NOTE: Some existing user agents interpret two-digit years differently.
1. 注：一些现有用户代理对两位数年份的解释不同。
5. Abort these steps and fail to parse the cookie-date if:
5. 如果出现以下情况，则中止这些步骤并无法解析cookie日期：
* at least one of the found-day-of-month, found-month, found-year, or found-time flags is not set,
* 未设置至少一个“查找月日”、“查找月”、“查找年”或“查找时间”标志，
* the day-of-month-value is less than 1 or greater than 31,
* 月日值小于1或大于31，
* the year-value is less than 1601,
* 年份值小于1601，
* the hour-value is greater than 23,
* 小时值大于23，
* the minute-value is greater than 59, or
* 分钟值大于59，或
* the second-value is greater than 59.
* 第二个值大于59。
(Note that leap seconds cannot be represented in this syntax.)
（请注意，此语法中不能表示闰秒。）
6. Let the parsed-cookie-date be the date whose day-of-month, month, year, hour, minute, and second (in UTC) are the day-of-month-value, the month-value, the year-value, the hour-value, the minute-value, and the second-value, respectively. If no such date exists, abort these steps and fail to parse the cookie-date.
6. 让解析后的cookie日期为其月日、月日、年日、小时、分钟和秒（UTC）分别为月日值、月值、年值、小时值、分钟值和秒值的日期。如果不存在这样的日期，则中止这些步骤并无法解析cookie日期。
7. Return the parsed-cookie-date as the result of this algorithm.
7. 返回解析后的cookie日期作为此算法的结果。
A canonicalized host name is the string generated by the following algorithm:
规范化主机名是由以下算法生成的字符串：
1. Convert the host name to a sequence of individual domain name labels.
1. 将主机名转换为一系列单独的域名标签。
2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label, to an A-label (see Section 2.3.2.1 of [RFC5890] for the former and latter), or to a "punycode label" (a label resulting from the "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate (see Section 6.3 of this specification).
2. 将每个非保留LDH（NR-LDH）标签转换为a标签（前者和后者见[RFC5890]第2.3.2.1节），或转换为“punycode标签”（由[RFC3490]第4节中的“ToASCII”转换产生的标签），视情况而定（见本规范第6.3节）。
3. Concatenate the resulting labels, separated by a %x2E (".") character.
3. 连接结果标签，以%x2E（“.”）字符分隔。
A string domain-matches a given domain string if at least one of the following conditions hold:
如果至少满足以下条件之一，则字符串域与给定域字符串匹配：
o The domain string and the string are identical. (Note that both the domain string and the string will have been canonicalized to lower case at this point.)
o 域字符串和字符串是相同的。（请注意，此时域字符串和字符串都已规范化为小写。）
o All of the following conditions hold:
o 以下所有条件均成立：
* The domain string is a suffix of the string.
* 域字符串是字符串的后缀。
* The last character of the string that is not included in the domain string is a %x2E (".") character.
* 未包含在域字符串中的字符串的最后一个字符是%x2E（“.”）字符。
* The string is a host name (i.e., not an IP address).
* 字符串是主机名（即，不是IP地址）。
The user agent MUST use an algorithm equivalent to the following algorithm to compute the default-path of a cookie:
用户代理必须使用与以下算法等效的算法来计算cookie的默认路径：
1. Let uri-path be the path portion of the request-uri if such a portion exists (and empty otherwise). For example, if the request-uri contains just a path (and optional query string), then the uri-path is that path (without the %x3F ("?") character or query string), and if the request-uri contains a full absoluteURI, the uri-path is the path component of that URI.
1. 如果存在请求uri的路径部分（否则为空），则将该部分设为uri路径。例如，如果请求uri只包含一个路径（和可选的查询字符串），则uri路径就是该路径（没有%x3F（“？”）字符或查询字符串），如果请求uri包含完整的绝对uri，则uri路径就是该uri的路径组件。
2. If the uri-path is empty or if the first character of the uri-path is not a %x2F ("/") character, output %x2F ("/") and skip the remaining steps.
2. 如果uri路径为空或uri路径的第一个字符不是%x2F（“/”）字符，则输出%x2F（“/”）并跳过其余步骤。
3. If the uri-path contains no more than one %x2F ("/") character, output %x2F ("/") and skip the remaining step.
3. 如果uri路径包含的字符不超过一个%x2F（“/”），则输出%x2F（“/”）并跳过其余步骤。
4. Output the characters of the uri-path from the first character up to, but not including, the right-most %x2F ("/").
4. 输出uri路径的字符，从第一个字符到但不包括最右边的%x2F（“/”）。
A request-path path-matches a given cookie-path if at least one of the following conditions holds:
如果至少满足以下条件之一，则请求路径与给定的cookie路径匹配：
o The cookie-path and the request-path are identical.
o cookie路径和请求路径相同。
o The cookie-path is a prefix of the request-path, and the last character of the cookie-path is %x2F ("/").
o cookie路径是请求路径的前缀，cookie路径的最后一个字符是%x2F（“/”）。
o The cookie-path is a prefix of the request-path, and the first character of the request-path that is not included in the cookie-path is a %x2F ("/") character.
o cookie路径是请求路径的前缀，请求路径中未包含的第一个字符是%x2F（“/”）字符。
When a user agent receives a Set-Cookie header field in an HTTP response, the user agent MAY ignore the Set-Cookie header field in its entirety. For example, the user agent might wish to block responses to "third-party" requests from setting cookies (see Section 7.1).
当用户代理在HTTP响应中接收到Set-Cookie标头字段时，用户代理可能会完全忽略Set-Cookie标头字段。例如，用户代理可能希望阻止对设置cookie的“第三方”请求的响应（参见第7.1节）。
If the user agent does not ignore the Set-Cookie header field in its entirety, the user agent MUST parse the field-value of the Set-Cookie header field as a set-cookie-string (defined below).
如果用户代理不完全忽略Set-Cookie标头字段，则用户代理必须将Set-Cookie标头字段的字段值解析为Set-Cookie字符串（定义如下）。
NOTE: The algorithm below is more permissive than the grammar in Section 4.1. For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in Section 4.1 forbids whitespace in these positions. User agents use this algorithm so as to interoperate with servers that do not follow the recommendations in Section 4.
注意：下面的算法比第4.1节中的语法更为宽松。例如，该算法从cookie名称和值中去掉前导和尾随空格（但保留内部空格），而第4.1节中的语法禁止在这些位置使用空格。用户代理使用此算法以便与不遵循第4节中建议的服务器进行互操作。
A user agent MUST use an algorithm equivalent to the following algorithm to parse a "set-cookie-string":
用户代理必须使用与以下算法等效的算法来解析“设置cookie字符串”：
1. If the set-cookie-string contains a %x3B (";") character:
1. 如果集合cookie字符串包含%x3B（“；”）字符：
The name-value-pair string consists of the characters up to, but not including, the first %x3B (";"), and the unparsed-attributes consist of the remainder of the set-cookie-string (including the %x3B (";") in question).
名称-值对字符串由最多但不包括第一个%x3B（“；”）的字符组成，未分析的属性由集合cookie字符串的其余部分组成（包括所讨论的%x3B（“；”）。
Otherwise:
否则：
The name-value-pair string consists of all the characters contained in the set-cookie-string, and the unparsed-attributes is the empty string.
名称-值对字符串由集合cookie字符串中包含的所有字符组成，未解析的属性为空字符串。
2. If the name-value-pair string lacks a %x3D ("=") character, ignore the set-cookie-string entirely.
2. 如果名称-值对字符串缺少%x3D（“=”）字符，请完全忽略设置cookie字符串。
3. The (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character.
3. （可能为空）名称字符串由最多但不包括第一个%x3D（“=”）字符的字符组成，而（可能为空）值字符串由第一个%x3D（“=”）字符之后的字符组成。
4. Remove any leading or trailing WSP characters from the name string and the value string.
4. 从名称字符串和值字符串中删除任何前导或尾随WSP字符。
5. If the name string is empty, ignore the set-cookie-string entirely.
5. 如果名称字符串为空，则完全忽略设置的cookie字符串。
6. The cookie-name is the name string, and the cookie-value is the value string.
6. cookie名称是名称字符串，cookie值是值字符串。
The user agent MUST use an algorithm equivalent to the following algorithm to parse the unparsed-attributes:
用户代理必须使用与以下算法等效的算法来解析未解析的属性：
1. If the unparsed-attributes string is empty, skip the rest of these steps.
1. 如果unparsed attributes字符串为空，请跳过其余步骤。
2. Discard the first character of the unparsed-attributes (which will be a %x3B (";") character).
2. 放弃未分析属性的第一个字符（将是%x3B（“；”）字符）。
3. If the remaining unparsed-attributes contains a %x3B (";") character:
3. 如果其余未分析的属性包含%x3B（“；”）字符：
Consume the characters of the unparsed-attributes up to, but not including, the first %x3B (";") character.
使用第一个%x3B（“；”）字符之前（但不包括）未解析属性的字符。
Otherwise:
否则：
Consume the remainder of the unparsed-attributes.
使用剩余的未解析属性。
Let the cookie-av string be the characters consumed in this step.
让cookie av字符串成为此步骤中使用的字符。
4. If the cookie-av string contains a %x3D ("=") character:
4. 如果cookie av字符串包含%x3D（“=”）字符：
The (possibly empty) attribute-name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) attribute-value string consists of the characters after the first %x3D ("=") character.
属性名称字符串（可能为空）由最多但不包括第一个%x3D（“=”）字符的字符组成，属性值字符串（可能为空）由第一个%x3D（“=”）字符之后的字符组成。
Otherwise:
否则：
The attribute-name string consists of the entire cookie-av string, and the attribute-value string is empty.
属性名称字符串由整个cookie av字符串组成，属性值字符串为空。
5. Remove any leading or trailing WSP characters from the attribute-name string and the attribute-value string.
5. 从属性名称字符串和属性值字符串中删除任何前导或尾随WSP字符。
6. Process the attribute-name and attribute-value according to the requirements in the following subsections. (Notice that attributes with unrecognized attribute-names are ignored.)
6. 根据以下小节的要求处理属性名称和属性值。（请注意，将忽略属性名称无法识别的属性。）
7. Return to Step 1 of this algorithm.
7. 返回此算法的步骤1。
When the user agent finishes parsing the set-cookie-string, the user agent is said to "receive a cookie" from the request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute-list. (See Section 5.3 for additional requirements triggered by receiving a cookie.)
当用户代理完成对设置的cookie字符串的解析时，用户代理被称为从请求uri“接收cookie”，其名称为cookie name、值cookie value和属性cookie属性列表。（有关接收cookie触发的其他要求，请参见第5.3节。）
If the attribute-name case-insensitively matches the string "Expires", the user agent MUST process the cookie-av as follows.
如果属性名称大小写与字符串“Expires”不敏感地匹配，则用户代理必须按如下方式处理cookie av。
Let the expiry-time be the result of parsing the attribute-value as cookie-date (see Section 5.1.1).
将到期时间作为将属性值解析为cookie日期的结果（参见第5.1.1节）。
If the attribute-value failed to parse as a cookie date, ignore the cookie-av.
如果属性值无法解析为cookie日期，请忽略cookie av。
If the expiry-time is later than the last date the user agent can represent, the user agent MAY replace the expiry-time with the last representable date.
如果到期时间晚于用户代理可以表示的最后日期，则用户代理可以用最后可表示的日期替换到期时间。
If the expiry-time is earlier than the earliest date the user agent can represent, the user agent MAY replace the expiry-time with the earliest representable date.
如果到期时间早于用户代理可以表示的最早日期，则用户代理可以用最早的可表示日期替换到期时间。
Append an attribute to the cookie-attribute-list with an attribute-name of Expires and an attribute-value of expiry-time.
将属性名称为Expires、属性值为Expire time的属性附加到cookie属性列表中。
If the attribute-name case-insensitively matches the string "Max-Age", the user agent MUST process the cookie-av as follows.
如果属性名称大小写与字符串“Max Age”不敏感地匹配，则用户代理必须按如下方式处理cookie av。
If the first character of the attribute-value is not a DIGIT or a "-" character, ignore the cookie-av.
如果属性值的第一个字符不是数字或“-”字符，请忽略cookie av。
If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.
如果属性值的其余部分包含非数字字符，请忽略cookie av。
Let delta-seconds be the attribute-value converted to an integer.
将delta seconds作为转换为整数的属性值。
If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time. Otherwise, let the expiry-time be the current date and time plus delta-seconds seconds.
如果delta seconds小于或等于零（0），则将到期时间设为最早的可表示日期和时间。否则，将到期时间设为当前日期和时间加上增量秒。
Append an attribute to the cookie-attribute-list with an attribute-name of Max-Age and an attribute-value of expiry-time.
在cookie属性列表中附加一个属性，属性名称为Max Age，属性值为expiration time。
If the attribute-name case-insensitively matches the string "Domain", the user agent MUST process the cookie-av as follows.
如果属性名称大小写与字符串“Domain”不敏感地匹配，则用户代理必须按如下方式处理cookie av。
If the attribute-value is empty, the behavior is undefined. However, the user agent SHOULD ignore the cookie-av entirely.
如果属性值为空，则行为未定义。但是，用户代理应该完全忽略cookie av。
If the first character of the attribute-value string is %x2E ("."):
如果属性值字符串的第一个字符是%x2E（“.”）：
Let cookie-domain be the attribute-value without the leading %x2E (".") character.
让cookie域作为属性值，不带前导%x2E（“.”）字符。
Otherwise:
否则：
Let cookie-domain be the entire attribute-value.
让cookie域成为整个属性值。
Convert the cookie-domain to lower case.
将cookie域转换为小写。
Append an attribute to the cookie-attribute-list with an attribute-name of Domain and an attribute-value of cookie-domain.
将属性名为Domain、属性值为cookie Domain的属性附加到cookie属性列表中。
If the attribute-name case-insensitively matches the string "Path", the user agent MUST process the cookie-av as follows.
如果属性名称大小写与字符串“Path”不敏感地匹配，则用户代理必须按如下方式处理cookie av。
If the attribute-value is empty or if the first character of the attribute-value is not %x2F ("/"):
如果属性值为空或属性值的第一个字符不是%x2F（“/”）：
Let cookie-path be the default-path.
将cookie路径设为默认路径。
Otherwise:
否则：
Let cookie-path be the attribute-value.
让cookie路径作为属性值。
Append an attribute to the cookie-attribute-list with an attribute-name of Path and an attribute-value of cookie-path.
在cookie属性列表中附加属性，属性名称为Path，属性值为cookie Path。
If the attribute-name case-insensitively matches the string "Secure", the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of Secure and an empty attribute-value.
如果属性名称大小写与字符串“Secure”不敏感地匹配，则用户代理必须将属性名称为Secure且属性值为空的属性附加到cookie属性列表中。
If the attribute-name case-insensitively matches the string "HttpOnly", the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of HttpOnly and an empty attribute-value.
如果属性名称大小写与字符串“HttpOnly”不敏感地匹配，则用户代理必须将属性名称为HttpOnly且属性值为空的属性附加到cookie属性列表中。
The user agent stores the following fields about each cookie: name, value, expiry-time, domain, path, creation-time, last-access-time, persistent-flag, host-only-flag, secure-only-flag, and http-only-flag.
用户代理存储关于每个cookie的以下字段：名称、值、过期时间、域、路径、创建时间、上次访问时间、持久性标志、仅主机标志、仅安全标志和仅http标志。
When the user agent "receives a cookie" from a request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute-list, the user agent MUST process the cookie as follows:
当用户代理从具有名称cookie name、值cookie value和属性cookie属性列表的请求uri“接收cookie”时，用户代理必须按如下方式处理cookie：
1. A user agent MAY ignore a received cookie in its entirety. For example, the user agent might wish to block receiving cookies from "third-party" responses or the user agent might not wish to store cookies that exceed some size.
1. 用户代理可以完全忽略接收到的cookie。例如，用户代理可能希望阻止从“第三方”响应接收cookie，或者用户代理可能不希望存储超过某个大小的cookie。
2. Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.
2. 创建名为cookie name、值为cookie value的新cookie。将创建时间和上次访问时间设置为当前日期和时间。
3. If the cookie-attribute-list contains an attribute with an attribute-name of "Max-Age":
3. 如果cookie属性列表包含属性名称为“Max Age”的属性：
Set the cookie's persistent-flag to true.
将cookie的持久性标志设置为true。
Set the cookie's expiry-time to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Max-Age".
将cookie的过期时间设置为cookie属性列表中属性名称为“Max Age”的最后一个属性的属性值。
Otherwise, if the cookie-attribute-list contains an attribute with an attribute-name of "Expires" (and does not contain an attribute with an attribute-name of "Max-Age"):
否则，如果cookie属性列表包含属性名称为“Expires”的属性（并且不包含属性名称为“Max Age”的属性）：
Set the cookie's persistent-flag to true.
将cookie的持久性标志设置为true。
Set the cookie's expiry-time to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Expires".
将cookie的过期时间设置为cookie属性列表中属性名称为“Expires”的最后一个属性的属性值。
Otherwise:
否则：
Set the cookie's persistent-flag to false.
将cookie的持久性标志设置为false。
Set the cookie's expiry-time to the latest representable date.
将cookie的到期时间设置为最新的可表示日期。
4. If the cookie-attribute-list contains an attribute with an attribute-name of "Domain":
4. 如果cookie属性列表包含属性名称为“域”的属性：
Let the domain-attribute be the attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Domain".
让domain属性成为cookie属性列表中属性名称为“domain”的最后一个属性的属性值。
Otherwise:
否则：
Let the domain-attribute be the empty string.
让domain属性为空字符串。
5. If the user agent is configured to reject "public suffixes" and the domain-attribute is a public suffix:
5. 如果用户代理配置为拒绝“公共后缀”，并且域属性为公共后缀：
If the domain-attribute is identical to the canonicalized request-host:
如果域属性与规范化请求主机相同：
Let the domain-attribute be the empty string.
让domain属性为空字符串。
Otherwise:
否则：
Ignore the cookie entirely and abort these steps.
完全忽略cookie并中止这些步骤。
NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us". This step is essential for preventing attacker.com from disrupting the integrity of example.com by setting a cookie with a Domain attribute of "com". Unfortunately, the set of public suffixes (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at <http://publicsuffix.org/>.
注：“公共后缀”是由公共注册表控制的域，如“com”、“co.uk”和“pvt.k12.wy.us”。此步骤对于防止攻击者.com通过设置域属性为“com”的cookie破坏example.com的完整性至关重要。不幸的是，公共后缀集（也称为“注册表控制域”）会随着时间的推移而变化。如果可行，用户代理应该使用最新的公共后缀列表，如Mozilla项目在<http://publicsuffix.org/>.
6. If the domain-attribute is non-empty:
6. 如果域属性为非空：
If the canonicalized request-host does not domain-match the domain-attribute:
如果规范化请求主机与域属性不匹配：
Ignore the cookie entirely and abort these steps.
完全忽略cookie并中止这些步骤。
Otherwise:
否则：
Set the cookie's host-only-flag to false.
将cookie的仅主机标志设置为false。
Set the cookie's domain to the domain-attribute.
将cookie的域设置为domain属性。
Otherwise:
否则：
Set the cookie's host-only-flag to true.
将cookie的仅主机标志设置为true。
Set the cookie's domain to the canonicalized request-host.
将cookie的域设置为规范化请求主机。
7. If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Path". Otherwise, set the cookie's path to the default-path of the request-uri.
7. 如果cookie属性列表包含属性名称为“Path”的属性，请将cookie的路径设置为属性名称为“Path”的cookie属性列表中最后一个属性的属性值。否则，将cookie的路径设置为请求uri的默认路径。
8. If the cookie-attribute-list contains an attribute with an attribute-name of "Secure", set the cookie's secure-only-flag to true. Otherwise, set the cookie's secure-only-flag to false.
8. 如果cookie属性列表包含属性名称为“Secure”的属性，请将cookie的仅安全标志设置为true。否则，将cookie的仅安全标志设置为false。
9. If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to true. Otherwise, set the cookie's http-only-flag to false.
9. 如果cookie属性列表包含属性名称为“HttpOnly”的属性，请将cookie的http only标志设置为true。否则，将cookie的http only标志设置为false。
10. If the cookie was received from a "non-HTTP" API and the cookie's http-only-flag is set, abort these steps and ignore the cookie entirely.
10. 如果cookie是从“非HTTP”API接收的，并且设置了cookie的HTTP only标志，则中止这些步骤并完全忽略cookie。
11. If the cookie store contains a cookie with the same name, domain, and path as the newly created cookie:
11. 如果cookie存储包含与新创建的cookie具有相同名称、域和路径的cookie：
1. Let old-cookie be the existing cookie with the same name, domain, and path as the newly created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.)
1. 让旧cookie成为与新创建的cookie具有相同名称、域和路径的现有cookie。（请注意，此算法保持不变，即最多有一个这样的cookie。）
2. If the newly created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is set, abort these steps and ignore the newly created cookie entirely.
2. 如果新创建的cookie是从“非HTTP”API接收的，并且设置了旧cookie的HTTP only标志，则中止这些步骤并完全忽略新创建的cookie。
3. Update the creation-time of the newly created cookie to match the creation-time of the old-cookie.
3. 更新新创建的cookie的创建时间以匹配旧cookie的创建时间。
4. Remove the old-cookie from the cookie store.
4. 从cookie存储中删除旧cookie。
12. Insert the newly created cookie into the cookie store.
12. 将新创建的cookie插入cookie存储。
A cookie is "expired" if the cookie has an expiry date in the past.
如果cookie的过期日期在过去，则cookie为“过期”。
The user agent MUST evict all expired cookies from the cookie store if, at any time, an expired cookie exists in the cookie store.
如果cookie存储中随时存在过期的cookie，则用户代理必须从cookie存储中逐出所有过期的cookie。
At any time, the user agent MAY "remove excess cookies" from the cookie store if the number of cookies sharing a domain field exceeds some implementation-defined upper bound (such as 50 cookies).
在任何时候，如果共享域字段的cookie数量超过某个实现定义的上限（例如50个cookie），则用户代理可以从cookie存储中“删除多余的cookie”。
At any time, the user agent MAY "remove excess cookies" from the cookie store if the cookie store exceeds some predetermined upper bound (such as 3000 cookies).
在任何时候，如果cookie存储超过某个预定上限（例如3000个cookie），则用户代理可以从cookie存储中“移除多余的cookie”。
When the user agent removes excess cookies from the cookie store, the user agent MUST evict cookies in the following priority order:
当用户代理从cookie存储中删除多余的cookie时，用户代理必须按以下优先级顺序逐出cookie：
1. Expired cookies.
1. 过期的饼干。
2. Cookies that share a domain field with more than a predetermined number of other cookies.
2. 与超过预定数量的其他Cookie共享域字段的Cookie。
3. All cookies.
3. 所有的饼干。
If two cookies have the same removal priority, the user agent MUST evict the cookie with the earliest last-access date first.
如果两个cookie具有相同的删除优先级，则用户代理必须首先以最早的最后访问日期收回cookie。
When "the current session is over" (as defined by the user agent), the user agent MUST remove from the cookie store all cookies with the persistent-flag set to false.
当“当前会话结束”（由用户代理定义）时，用户代理必须从cookie存储中删除持久标志设置为false的所有cookie。
The user agent includes stored cookies in the Cookie HTTP request header.
用户代理在Cookie HTTP请求头中包含存储的Cookie。
When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field.
当用户代理生成HTTP请求时，用户代理不能附加多个Cookie头字段。
A user agent MAY omit the Cookie header in its entirety. For example, the user agent might wish to block sending cookies during "third-party" requests from setting cookies (see Section 7.1).
用户代理可以完全省略Cookie头。例如，用户代理可能希望在设置cookie的“第三方”请求期间阻止发送cookie（参见第7.1节）。
If the user agent does attach a Cookie header field to an HTTP request, the user agent MUST send the cookie-string (defined below) as the value of the header field.
如果用户代理将Cookie头字段附加到HTTP请求，则用户代理必须发送Cookie字符串（定义如下）作为头字段的值。
The user agent MUST use an algorithm equivalent to the following algorithm to compute the "cookie-string" from a cookie store and a request-uri:
用户代理必须使用与以下算法等效的算法从cookie存储和请求uri计算“cookie字符串”：
1. Let cookie-list be the set of cookies from the cookie store that meets all of the following requirements:
1. cookie list是cookie store中满足以下所有要求的cookie集：
* Either:
* 要么：
The cookie's host-only-flag is true and the canonicalized request-host is identical to the cookie's domain.
cookie的host only标志为true，规范化请求主机与cookie的域相同。
Or:
或：
The cookie's host-only-flag is false and the canonicalized request-host domain-matches the cookie's domain.
cookie的host only标志为false，并且规范化的请求主机域与cookie的域匹配。
* The request-uri's path path-matches the cookie's path.
* 请求uri的路径与cookie的路径匹配。
* If the cookie's secure-only-flag is true, then the request-uri's scheme must denote a "secure" protocol (as defined by the user agent).
* 如果cookie的仅安全标志为true，则请求uri的方案必须表示“安全”协议（由用户代理定义）。
NOTE: The notion of a "secure" protocol is not defined by this document. Typically, user agents consider a protocol secure if the protocol makes use of transport-layer
注：本文件未定义“安全”协议的概念。通常，如果协议使用传输层，则用户代理认为协议是安全的。
security, such as SSL or TLS. For example, most user agents consider "https" to be a scheme that denotes a secure protocol.
安全性，例如SSL或TLS。例如，大多数用户代理认为“HTTPS”是表示安全协议的方案。
* If the cookie's http-only-flag is true, then exclude the cookie if the cookie-string is being generated for a "non-HTTP" API (as defined by the user agent).
* 如果cookie的http only标志为true，则如果为“非http”API（由用户代理定义）生成cookie字符串，则排除cookie。
2. The user agent SHOULD sort the cookie-list in the following order:
2. 用户代理应按以下顺序对cookie列表进行排序：
* Cookies with longer paths are listed before cookies with shorter paths.
* 路径较长的Cookie列在路径较短的Cookie之前。
* Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times.
* 在具有等长路径字段的Cookie中，创建时间较早的Cookie列在创建时间较晚的Cookie之前。
NOTE: Not all user agents sort the cookie-list in this order, but this order reflects common practice when this document was written, and, historically, there have been servers that (erroneously) depended on this order.
注意：并非所有用户代理都按此顺序对cookie列表进行排序，但此顺序反映了编写此文档时的常见做法，而且在历史上，有些服务器（错误地）依赖于此顺序。
3. Update the last-access-time of each cookie in the cookie-list to the current date and time.
3. 将cookie列表中每个cookie的上次访问时间更新为当前日期和时间。
4. Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order:
4. 通过按以下顺序处理cookie列表中的每个cookie，将cookie列表序列化为cookie字符串：
1. Output the cookie's name, the %x3D ("=") character, and the cookie's value.
1. 输出cookie的名称、%x3D（“=”）字符和cookie的值。
2. If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").
2. 如果cookie列表中存在未处理的cookie，则输出字符%x3B和%x20（“；”）。
NOTE: Despite its name, the cookie-string is actually a sequence of octets, not a sequence of characters. To convert the cookie-string (or components thereof) into a sequence of characters (e.g., for presentation to the user), the user agent might wish to try using the UTF-8 character encoding [RFC3629] to decode the octet sequence. This decoding might fail, however, because not every sequence of octets is valid UTF-8.
注意：尽管名称不同，cookie字符串实际上是一个八位字节序列，而不是一个字符序列。为了将cookie字符串（或其组件）转换为字符序列（例如，用于向用户呈现），用户代理可能希望尝试使用UTF-8字符编码[RFC3629]来解码八位字节序列。然而，这种解码可能会失败，因为并非每个八位字节序列都是有效的UTF-8。
Practical user agent implementations have limits on the number and size of cookies that they can store. General-use user agents SHOULD provide each of the following minimum capabilities:
实际的用户代理实现对它们可以存储的cookie的数量和大小有限制。通用用户代理应至少提供以下各项功能：
o At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes).
o 每个cookie至少4096字节（通过cookie的名称、值和属性的长度之和来衡量）。
o At least 50 cookies per domain.
o 每个域至少有50个cookie。
o At least 3000 cookies total.
o 总共至少有3000块饼干。
Servers SHOULD use as few and as small cookies as possible to avoid reaching these implementation limits and to minimize network bandwidth due to the Cookie header being included in every request.
服务器应使用尽可能少和小的Cookie，以避免达到这些实现限制，并尽量减少网络带宽，因为每个请求中都包含Cookie头。
Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header because the user agent might evict any cookie at any time on orders from the user.
如果用户代理未能返回Cookie标头中的一个或多个Cookie，则服务器应正常降级，因为用户代理可能随时根据用户的命令逐出任何Cookie。
One reason the Cookie and Set-Cookie headers use such esoteric syntax is that many platforms (both in servers and user agents) provide a string-based application programming interface (API) to cookies, requiring application-layer programmers to generate and parse the syntax used by the Cookie and Set-Cookie headers, which many programmers have done incorrectly, resulting in interoperability problems.
Cookie和Set-Cookie标头使用这种深奥语法的一个原因是，许多平台（服务器和用户代理中）为Cookie提供了基于字符串的应用程序编程接口（API），要求应用层程序员生成和解析Cookie和Set-Cookie标头使用的语法，许多程序员做得不正确，导致互操作性问题。
Instead of providing string-based APIs to cookies, platforms would be well-served by providing more semantic APIs. It is beyond the scope of this document to recommend specific API designs, but there are clear benefits to accepting an abstract "Date" object instead of a serialized date string.
与向cookie提供基于字符串的API不同，平台可以通过提供更多语义API得到更好的服务。推荐特定的API设计超出了本文的范围，但接受抽象的“日期”对象而不是序列化的日期字符串显然有好处。
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are differences between the two specifications, and thus there can be differences in processing (e.g., converting) domain name labels that have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003- based domain name labels will exist in the wild. User agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895]
IDNA2008[RFC5890]取代IDNA2003[RFC3490]。然而，这两个规范之间存在差异，因此在处理（例如，转换）已在其中一个规范下注册的域名标签与在另一个规范下注册的域名标签方面可能存在差异。将有一段时间的过渡期，在此期间，基于IDNA2003的域名标签将在野外存在。用户代理应该实现IDNA2008[RFC5890]，并且可以实现[UTS46]或[RFC5895]
in order to facilitate their IDNA transition. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003 [RFC3490].
为了促进他们的IDNA过渡。如果用户代理未实现IDNA2008，则用户代理必须实现IDNA2003[RFC3490]。
Cookies are often criticized for letting servers track users. For example, a number of "web analytics" companies use cookies to recognize when a user returns to a web site or visits another web site. Although cookies are not the only mechanism servers can use to track users across HTTP requests, cookies facilitate tracking because they are persistent across user agent sessions and can be shared between hosts.
Cookie经常因让服务器跟踪用户而受到批评。例如，许多“网络分析”公司使用cookies来识别用户何时返回某个网站或访问另一个网站。虽然Cookie不是服务器可以用来跨HTTP请求跟踪用户的唯一机制，但Cookie有助于跟踪，因为它们在用户代理会话中是持久的，并且可以在主机之间共享。
Particularly worrisome are so-called "third-party" cookies. In rendering an HTML document, a user agent often requests resources from other servers (such as advertising networks). These third-party servers can use cookies to track the user even if the user never visits the server directly. For example, if a user visits a site that contains content from a third party and then later visits another site that contains content from the same third party, the third party can track the user between the two sites.
尤其令人担忧的是所谓的“第三方”饼干。在呈现HTML文档时，用户代理通常从其他服务器（如广告网络）请求资源。这些第三方服务器可以使用cookie跟踪用户，即使用户从未直接访问服务器。例如，如果用户访问包含第三方内容的网站，然后又访问包含同一第三方内容的其他网站，则第三方可以在两个网站之间跟踪该用户。
Some user agents restrict how third-party cookies behave. For example, some of these user agents refuse to send the Cookie header in third-party requests. Others refuse to process the Set-Cookie header in responses to third-party requests. User agents vary widely in their third-party cookie policies. This document grants user agents wide latitude to experiment with third-party cookie policies that balance the privacy and compatibility needs of their users. However, this document does not endorse any particular third-party cookie policy.
一些用户代理限制第三方cookie的行为。例如，其中一些用户代理拒绝在第三方请求中发送Cookie头。其他人拒绝处理Set-Cookie头以响应第三方请求。用户代理的第三方cookie策略差异很大。本文档为用户代理提供了广泛的空间来试验第三方cookie策略，以平衡其用户的隐私和兼容性需求。但是，本文档不支持任何特定的第三方cookie策略。
Third-party cookie blocking policies are often ineffective at achieving their privacy goals if servers attempt to work around their restrictions to track users. In particular, two collaborating servers can often track users without using cookies at all by injecting identifying information into dynamic URLs.
如果服务器试图绕过其限制来跟踪用户，则第三方cookie阻止策略通常无法实现其隐私目标。特别是，两个协作服务器通常可以通过将标识信息注入动态URL来跟踪用户，而根本不使用cookie。
User agents SHOULD provide users with a mechanism for managing the cookies stored in the cookie store. For example, a user agent might let users delete all cookies received during a specified time period
用户代理应为用户提供管理存储在cookie存储中的cookie的机制。例如，用户代理可能允许用户删除指定时间段内收到的所有cookie
or all the cookies related to a particular domain. In addition, many user agents include a user interface element that lets users examine the cookies stored in their cookie store.
或与特定域相关的所有cookie。此外，许多用户代理包括一个用户界面元素，允许用户检查存储在其cookie存储中的cookie。
User agents SHOULD provide users with a mechanism for disabling cookies. When cookies are disabled, the user agent MUST NOT include a Cookie header in outbound HTTP requests and the user agent MUST NOT process Set-Cookie headers in inbound HTTP responses.
用户代理应为用户提供禁用cookie的机制。禁用Cookie时，用户代理不得在出站HTTP请求中包含Cookie标头，并且用户代理不得在入站HTTP响应中处理Set-Cookie标头。
Some user agents provide users the option of preventing persistent storage of cookies across sessions. When configured thusly, user agents MUST treat all received cookies as if the persistent-flag were set to false. Some popular user agents expose this functionality via "private browsing" mode [Aggarwal2010].
一些用户代理为用户提供了防止跨会话持久存储cookie的选项。因此配置时，用户代理必须将所有收到的cookie视为持久性标志设置为false。一些流行的用户代理通过“私人浏览”模式公开此功能[Aggarwal2010]。
Some user agents provide users with the ability to approve individual writes to the cookie store. In many common usage scenarios, these controls generate a large number of prompts. However, some privacy-conscious users find these controls useful nonetheless.
一些用户代理为用户提供了批准对cookie存储的单个写入的能力。在许多常见的使用场景中，这些控件会生成大量提示。然而，一些关注隐私的用户发现这些控件仍然有用。
Although servers can set the expiration date for cookies to the distant future, most user agents do not actually retain cookies for multiple decades. Rather than choosing gratuitously long expiration periods, servers SHOULD promote user privacy by selecting reasonable cookie expiration periods based on the purpose of the cookie. For example, a typical session identifier might reasonably be set to expire in two weeks.
尽管服务器可以将cookie的过期日期设置为遥远的将来，但大多数用户代理实际上并不会将cookie保留几十年。服务器应该根据cookie的用途选择合理的cookie过期期限，从而提高用户的隐私，而不是选择无缘无故的长过期期限。例如，一个典型的会话标识符可能被合理地设置为在两周内过期。
Cookies have a number of security pitfalls. This section overviews a few of the more salient issues.
Cookie有很多安全隐患。本节概述了一些更突出的问题。
In particular, cookies encourage developers to rely on ambient authority for authentication, often becoming vulnerable to attacks such as cross-site request forgery [CSRF]. Also, when storing session identifiers in cookies, developers often create session fixation vulnerabilities.
特别是，Cookie鼓励开发人员依赖环境授权进行身份验证，通常容易受到跨站点请求伪造[CSRF]等攻击。此外，在Cookie中存储会话标识符时，开发人员通常会创建会话固定漏洞。
Transport-layer encryption, such as that employed in HTTPS, is insufficient to prevent a network attacker from obtaining or altering a victim's cookies because the cookie protocol itself has various vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
传输层加密（如HTTPS中使用的加密）不足以防止网络攻击者获取或更改受害者的cookie，因为cookie协议本身存在各种漏洞（请参阅“弱机密性”和“弱完整性”），
below). In addition, by default, cookies do not provide confidentiality or integrity from network attackers, even when used in conjunction with HTTPS.
下）。此外，默认情况下，cookie不提供来自网络攻击者的机密性或完整性，即使与HTTPS结合使用。
A server that uses cookies to authenticate users can suffer security vulnerabilities because some user agents let remote parties issue HTTP requests from the user agent (e.g., via HTTP redirects or HTML forms). When issuing those requests, user agents attach cookies even if the remote party does not know the contents of the cookies, potentially letting the remote party exercise authority at an unwary server.
使用cookie对用户进行身份验证的服务器可能存在安全漏洞，因为某些用户代理允许远程方从用户代理发出HTTP请求（例如，通过HTTP重定向或HTML表单）。发出这些请求时，即使远程方不知道cookie的内容，用户代理也会附加cookie，这可能会让远程方在不小心的服务器上行使权限。
Although this security concern goes by a number of names (e.g., cross-site request forgery, confused deputy), the issue stems from cookies being a form of ambient authority. Cookies encourage server operators to separate designation (in the form of URLs) from authorization (in the form of cookies). Consequently, the user agent might supply the authorization for a resource designated by the attacker, possibly causing the server or its clients to undertake actions designated by the attacker as though they were authorized by the user.
尽管这种安全问题涉及许多名称（例如，跨站点请求伪造、代理混淆），但问题源于cookie是一种环境权限。Cookie鼓励服务器操作员将指定（以URL的形式）与授权（以Cookie的形式）分开。因此，用户代理可能会为攻击者指定的资源提供授权，这可能会导致服务器或其客户端执行攻击者指定的操作，就好像它们是由用户授权的一样。
Instead of using cookies for authorization, server operators might wish to consider entangling designation and authorization by treating URLs as capabilities. Instead of storing secrets in cookies, this approach stores secrets in URLs, requiring the remote entity to supply the secret itself. Although this approach is not a panacea, judicious application of these principles can lead to more robust security.
代替使用Cookie进行授权，服务器操作员可能希望通过处理URL作为能力来考虑纠缠指定和授权。这种方法不是将秘密存储在cookie中，而是将秘密存储在URL中，要求远程实体自己提供秘密。尽管这种方法不是万能的，但明智地应用这些原则可以带来更强大的安全性。
Unless sent over a secure channel (such as TLS), the information in the Cookie and Set-Cookie headers is transmitted in the clear.
除非通过安全通道（如TLS）发送，否则Cookie和Set Cookie标头中的信息将以明文形式传输。
1. All sensitive information conveyed in these headers is exposed to an eavesdropper.
1. 这些头文件中传递的所有敏感信息都会暴露给窃听者。
2. A malicious intermediary could alter the headers as they travel in either direction, with unpredictable results.
2. 恶意中介可能会在头文件沿任意方向移动时改变头文件，从而导致不可预知的结果。
3. A malicious client could alter the Cookie header before transmission, with unpredictable results.
3. 恶意客户端可能会在传输前更改Cookie头，导致不可预知的结果。
Servers SHOULD encrypt and sign the contents of cookies (using whatever format the server desires) when transmitting them to the user agent (even when sending the cookies over a secure channel). However, encrypting and signing cookie contents does not prevent an attacker from transplanting a cookie from one user agent to another or from replaying the cookie at a later time.
服务器在向用户代理传输cookie内容时（即使在通过安全通道发送cookie时），也应该对cookie内容进行加密和签名（使用服务器希望的任何格式）。但是，对cookie内容进行加密和签名并不能阻止攻击者将cookie从一个用户代理移植到另一个用户代理，或在以后重放cookie。
In addition to encrypting and signing the contents of every cookie, servers that require a higher level of security SHOULD use the Cookie and Set-Cookie headers only over a secure channel. When using cookies over a secure channel, servers SHOULD set the Secure attribute (see Section 4.1.2.5) for every cookie. If a server does not set the Secure attribute, the protection provided by the secure channel will be largely moot.
除了对每个cookie的内容进行加密和签名外，需要更高安全级别的服务器还应该使用cookie并仅通过安全通道设置cookie头。当通过安全通道使用cookie时，服务器应为每个cookie设置安全属性（参见第4.1.2.5节）。如果服务器没有设置Secure属性，那么安全通道提供的保护将在很大程度上没有意义。
For example, consider a webmail server that stores a session identifier in a cookie and is typically accessed over HTTPS. If the server does not set the Secure attribute on its cookies, an active network attacker can intercept any outbound HTTP request from the user agent and redirect that request to the webmail server over HTTP. Even if the webmail server is not listening for HTTP connections, the user agent will still include cookies in the request. The active network attacker can intercept these cookies, replay them against the server, and learn the contents of the user's email. If, instead, the server had set the Secure attribute on its cookies, the user agent would not have included the cookies in the clear-text request.
例如，考虑一个Webmail服务器，它在cookie中存储会话标识符，通常通过HTTPS访问。如果服务器未在其Cookie上设置安全属性，则活动网络攻击者可以拦截来自用户代理的任何出站HTTP请求，并通过HTTP将该请求重定向到webmail服务器。即使webmail服务器没有侦听HTTP连接，用户代理仍将在请求中包含cookie。主动网络攻击者可以截获这些cookie，针对服务器重播它们，并了解用户电子邮件的内容。相反，如果服务器在其cookie上设置了Secure属性，那么用户代理将不会在明文请求中包含cookie。
Instead of storing session information directly in a cookie (where it might be exposed to or replayed by an attacker), servers commonly store a nonce (or "session identifier") in a cookie. When the server receives an HTTP request with a nonce, the server can look up state information associated with the cookie using the nonce as a key.
服务器通常在cookie中存储nonce（或“会话标识符”），而不是将会话信息直接存储在cookie中（在cookie中它可能会暴露给攻击者或被攻击者重放）。当服务器接收到带有nonce的HTTP请求时，服务器可以使用nonce作为密钥查找与cookie关联的状态信息。
Using session identifier cookies limits the damage an attacker can cause if the attacker learns the contents of a cookie because the nonce is useful only for interacting with the server (unlike non-nonce cookie content, which might itself be sensitive). Furthermore, using a single nonce prevents an attacker from "splicing" together cookie content from two interactions with the server, which could cause the server to behave unexpectedly.
使用会话标识符cookie可以限制攻击者在了解cookie内容时可能造成的损害，因为nonce仅用于与服务器交互（与非nonce cookie内容不同，非nonce cookie内容本身可能是敏感的）。此外，使用单个nonce可防止攻击者将来自与服务器的两次交互的cookie内容“拼接”在一起，从而导致服务器出现意外行为。
Using session identifiers is not without risk. For example, the server SHOULD take care to avoid "session fixation" vulnerabilities. A session fixation attack proceeds in three steps. First, the attacker transplants a session identifier from his or her user agent to the victim's user agent. Second, the victim uses that session
使用会话标识符并非没有风险。例如，服务器应注意避免“会话固定”漏洞。会话固定攻击分三步进行。首先，攻击者将会话标识符从其用户代理移植到受害者的用户代理。其次，受害者使用该会话
identifier to interact with the server, possibly imbuing the session identifier with the user's credentials or confidential information. Third, the attacker uses the session identifier to interact with server directly, possibly obtaining the user's authority or confidential information.
标识符与服务器交互，可能将会话标识符嵌入用户的凭据或机密信息。第三，攻击者使用会话标识符直接与服务器交互，可能获取用户的权限或机密信息。
Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security-sensitive information.
Cookie不提供端口隔离。如果在一个端口上运行的服务可以读取cookie，那么在同一服务器的另一个端口上运行的服务也可以读取cookie。如果cookie可由一个端口上的服务写入，则cookie也可由同一服务器的另一个端口上运行的服务写入。因此，服务器不应在同一主机的不同端口上运行相互不信任的服务，也不应使用cookie存储安全敏感信息。
Cookies do not provide isolation by scheme. Although most commonly used with the http and https schemes, the cookies for a given host might also be available to other schemes, such as ftp and gopher. Although this lack of isolation by scheme is most apparent in non-HTTP APIs that permit access to cookies (e.g., HTML's document.cookie API), the lack of isolation by scheme is actually present in requirements for processing cookies themselves (e.g., consider retrieving a URI with the gopher scheme via HTTP).
Cookie不按方案提供隔离。尽管最常用于http和https方案，但给定主机的cookie也可能可用于其他方案，如ftp和gopher。虽然这种方案的隔离缺乏在允许访问cookie的非HTTP API中最为明显（例如，HTML的文档。Cookie API），但是事实上，在处理cookie本身的需求中存在缺少方案的隔离（例如，考虑通过HTTP使用GopHER方案检索URI）。
Cookies do not always provide isolation by path. Although the network-level protocol does not send cookies stored for one path to another, some user agents expose cookies via non-HTTP APIs, such as HTML's document.cookie API. Because some of these user agents (e.g., web browsers) do not isolate resources received from different paths, a resource retrieved from one path might be able to access cookies stored for another path.
Cookie并不总是按路径提供隔离。尽管网络级协议不会将为一条路径存储的cookie发送到另一条路径，但一些用户代理通过非HTTP API（如HTML的document.cookie API）公开cookie。由于其中一些用户代理（例如web浏览器）不会隔离从不同路径接收的资源，因此从一条路径检索的资源可能能够访问为另一条路径存储的cookie。
Cookies do not provide integrity guarantees for sibling domains (and their subdomains). For example, consider foo.example.com and bar.example.com. The foo.example.com server can set a cookie with a Domain attribute of "example.com" (possibly overwriting an existing "example.com" cookie set by bar.example.com), and the user agent will include that cookie in HTTP requests to bar.example.com. In the worst case, bar.example.com will be unable to distinguish this cookie from a cookie it set itself. The foo.example.com server might be able to leverage this ability to mount an attack against bar.example.com.
Cookie不为同级域（及其子域）提供完整性保证。例如，考虑Fo..ExpLo.com和B.ExpLo.com。foo.example.com服务器可以设置一个域属性为“example.com”的cookie（可能会覆盖bar.example.com设置的现有“example.com”cookie），用户代理将在对bar.example.com的HTTP请求中包含该cookie。在最坏的情况下，bar.example.com将无法区分此cookie和它自己设置的cookie。foo.example.com服务器可能能够利用此功能对bar.example.com发起攻击。
Even though the Set-Cookie header supports the Path attribute, the Path attribute does not provide any integrity protection because the user agent will accept an arbitrary Path attribute in a Set-Cookie header. For example, an HTTP response to a request for http://example.com/foo/bar can set a cookie with a Path attribute of "/qux". Consequently, servers SHOULD NOT both run mutually distrusting services on different paths of the same host and use cookies to store security-sensitive information.
即使Set Cookie头支持Path属性，Path属性也不提供任何完整性保护，因为用户代理将接受Set Cookie头中的任意Path属性。例如，对请求的HTTP响应http://example.com/foo/bar 可以设置路径属性为“/qux”的cookie。因此，服务器不应同时在同一主机的不同路径上运行相互不信任的服务，也不应使用cookie存储安全敏感信息。
An active network attacker can also inject cookies into the Cookie header sent to https://example.com/ by impersonating a response from http://example.com/ and injecting a Set-Cookie header. The HTTPS server at example.com will be unable to distinguish these cookies from cookies that it set itself in an HTTPS response. An active network attacker might be able to leverage this ability to mount an attack against example.com even if example.com uses HTTPS exclusively.
主动网络攻击者还可以将Cookie注入发送到的Cookie头中https://example.com/ 通过模拟来自http://example.com/ 以及注入一组Cookie头。example.com上的HTTPS服务器将无法区分这些cookie和它在HTTPS响应中自行设置的cookie。即使example.com专门使用HTTPS，活动网络攻击者也可能利用此能力对example.com发起攻击。
Servers can partially mitigate these attacks by encrypting and signing the contents of their cookies. However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic example.com server in the user's session, with unpredictable results.
服务器可以通过对其cookie的内容进行加密和签名来部分缓解这些攻击。但是，使用加密技术并不能完全缓解此问题，因为攻击者可以在用户会话中重放他或她从authentic example.com服务器接收到的cookie，结果不可预测。
Finally, an attacker might be able to force the user agent to delete cookies by storing a large number of cookies. Once the user agent reaches its storage limit, the user agent will be forced to evict some cookies. Servers SHOULD NOT rely upon user agents retaining cookies.
最后，攻击者可能会通过存储大量cookie来强制用户代理删除cookie。一旦用户代理达到其存储限制，用户代理将被迫退出一些cookie。服务器不应依赖保留cookie的用户代理。
Cookies rely upon the Domain Name System (DNS) for security. If the DNS is partially or fully compromised, the cookie protocol might fail to provide the security properties required by applications.
Cookie依赖域名系统（DNS）进行安全保护。如果DNS部分或完全受损，cookie协议可能无法提供应用程序所需的安全属性。
The permanent message header field registry (see [RFC3864]) has been updated with the following registrations.
永久消息头字段注册表（请参见[RFC3864]）已使用以下注册进行更新。
Header field name: Cookie
标题字段名称：Cookie
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 5.4)
规范文件：本规范（第5.4节）
Header field name: Set-Cookie
标题字段名称：设置Cookie
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 5.2)
规范文件：本规范（第5.2节）
Header field name: Cookie2
标题字段名称：Cookie2
Applicable protocol: http
适用协议：http
Status: obsoleted
状态：已淘汰
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: [RFC2965]
规范文件：[RFC2965]
Header field name: Set-Cookie2
标题字段名称：Set-Cookie2
Applicable protocol: http
适用协议：http
Status: obsoleted
状态：已淘汰
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: [RFC2965]
规范文件：[RFC2965]
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年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月。
[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月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
See Section 6.3 for an explanation why the normative reference to an obsoleted specification is needed.
参见第6.3节，以了解为什么需要对废弃规范进行规范性引用。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]Newman，C.，Duerst，M.，和A.Gulbrandsen，“互联网应用协议整理注册表”，RFC 47902007年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月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[USASCII]美国国家标准协会，“编码字符集——信息交换用7位美国标准代码”，ANSI X3.41986。
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997.
[RFC2109]Kristol，D.和L.Montulli，“HTTP状态管理机制”，RFC2109，1997年2月。
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2965]Kristol，D.和L.Montulli，“HTTP状态管理机制”，RFC 29652000年10月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[Netscape] Netscape Communications Corp., "Persistent Client State -- HTTP Cookies", 1999, <http://web.archive.org/web/ 20020803110822/http://wp.netscape.com/newsref/std/ cookie_spec.html>.
[网景]网景通信公司，“持久客户端状态——HTTP Cookies”，1999年<http://web.archive.org/web/ 20020803110822/http://wp.netscape.com/newsref/std/ cookie_spec.html>。
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and Politics", ACM Transactions on Internet Technology Vol. 1, #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[Kristol，D.，“HTTP Cookies：标准、隐私和政治”，ACM互联网技术交易第1卷，第2期，2001年11月<http://arxiv.org/abs/cs.SE/0105018>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
[RFC5895]Resnick，P.和P.Hoffman，“应用程序中国际化域名的映射字符（IDNA）2008”，RFC 58952010年9月。
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility Processing", Unicode Technical Standards # 46, 2010, <http://unicode.org/reports/tr46/>.
[UTS46]Davis，M.和M.Suignard，“Unicode IDNA兼容性处理”，Unicode技术标准#46，2010年<http://unicode.org/reports/tr46/>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", 2008, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[CSRF]Barth，A.，Jackson，C.，和J.Mitchell，“跨站点请求伪造的强大防御”，2008年<http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[Aggarwal2010] Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, "An Analysis of Private Browsing Modes in Modern Browsers", 2010, <http://www.usenix.org/events/sec10/tech/ full_papers/Aggarwal.pdf>.
[Aggarwal2010]Aggarwal，G.，Burzstein，E.，Jackson，C.，和D.Boneh，“现代浏览器中私人浏览模式的分析”，2010<http://www.usenix.org/events/sec10/tech/ 全文/Aggarwal.pdf>。
This document borrows heavily from RFC 2109 [RFC2109]. We are indebted to David M. Kristol and Lou Montulli for their efforts to specify cookies. David M. Kristol, in particular, provided invaluable advice on navigating the IETF process. We would also like to thank Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry, corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller, Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their valuable feedback on this document.
本文件大量借鉴了RFC 2109[RFC2109]。我们感谢David M.Kristol和Lou Montulli为指定饼干所做的努力。特别是David M.Kristol，就IETF流程的导航提供了宝贵的建议。我们还要感谢托马斯·布罗耶、泰勒·克洛斯、艾莉莎·库珀、比尔·科里、科维德、丽莎·杜肖尔、罗伊·T·菲尔丁、布莱克·弗兰茨、安妮·范凯斯特伦、埃兰·哈默·拉哈夫、杰夫·霍吉斯、比约恩·霍尔曼、阿希姆·霍夫曼、格奥尔格·科彭、迪安·麦克纳米、阿列克西·梅尔尼科夫、马克·米勒、马克·保利、伊格维·佩特森、朱利安·雷什克、彼得·圣安德烈、，Mark Seaborn、Maciej Stachowiak、Daniel Stenberg、Tatsuhiro Tsujikawa、David Wagner、Dan Winship和Dan Witte感谢他们对本文件的宝贵反馈。
Author's Address
作者地址
Adam Barth University of California, Berkeley
亚当巴思加利福尼亚大学，伯克利
EMail: abarth@eecs.berkeley.edu
URI: http://www.adambarth.com/
EMail: abarth@eecs.berkeley.edu
URI: http://www.adambarth.com/