HTTP状态管理机制(6265加州大学伯克利分校)6265加州大学伯克利分校
HTTP状态管理机制
抽象
本文档定义了HTTP Cookie和Set-Cookie标头字段。
HTTP服务器可以使用这些头字段来存储状态
（称为Cookie）在HTTP用户代理上，让服务器维护一个
通过大多数无状态HTTP协议进行的有状态会话。虽然
Cookies具有许多历史性因素，会降低其安全性
和隐私，Cookie和Set-Cookie标头字段被广泛使用
在网上。本文档淘汰了RFC 2965。
该备忘录的状态
这是一个Internet标准跟踪文档。
本文档是Internet工程任务组的产品
（IETF）。它代表了IETF社区的共识。它有
受到公众审查，并已由
互联网工程指导小组（IESG）。有关更多信息RFC 5741的第2节中
提供了Internet标准。
有关本文档当前状态的信息，任何勘误，
以及有关如何提供反馈的信息，请访问
http://www.rfc-editor.org/info/rfc6265。
巴特标准轨道[第1页]
RFC 6265 HTTP状态管理机制2011年4月
本文档可能包含来自IETF文档或IETF的材料
11月之前发布或公开发布的贡献
，2008年10月10日。在某些情况下控制版权的人
资料可能未授予IETF信托的许可权
在IETF标准流程之外对此类材料进行修改。
没有获得控制人的充分许可
此类材料的版权，不得修改本文档
在IETF标准流程之外，其衍生作品可能
除格式外，不得在IETF标准流程之外创建
以RFC形式发布或将其翻译为其他语言
比英语。
目录
1。介绍 … … 3
2。约定… … 4
2.1。合格标准… 4
2.2。语法符号… 5
2.3。术语… 5
3。概述… … 6
3.1。例子 … … 6
4。服务器要求… 8
4.1。Set-Cookie … … 8
4.1.1。语法… 8
4.1。 2。语义（非标准）… 10
4.2。曲奇饼 … … 13
4.2.1。语法… 13
4.2.2。语义… 13
5。用户代理要求… 14
5.1。子组件算法… 14
5.1.1。日期… 14
5.1。 2。规范化的主机名… 16
5.1.3。域匹配… 16
5.1.4。路径和路径匹配… 16
5.2。Set-Cookie标头… 17
5.2.1。Expires属性… 19
5.2.2。最大年龄属性… 20
5.2.3。域属性… 20
5.2.4。路径属性… 21
5.2.5。安全属性… 21
5.2.6。HttpOnly属性… 21
5.3。存储模型… 21
5.4。Cookie标题… 25
6。实施注意事项… 27
6.1。极限… … 27
6.2。应用程序编程接口… 27
6.3。IDNA依赖性和迁移… 27
7。隐私注意事项… 28
巴特标准轨道[第2页]
RFC 6265 HTTP状态管理机制2011年4月
7.1。第三方Cookie … 28
7.2。用户控件… 28
7.3。到期日期… 29
8。安全注意事项… 29
8.1。概述… 。29
8.2。环境局… 30
8.3。明文… 30
8.4。会话标识符… 31
8.5。保密性不强… 32
8.6。完整性低下… 32
8.7。依赖DNS … 33
9。IANA考虑因素… 33
9.1。曲奇饼 … … 34
9.2。Set-Cookie … 。34
9.3。Cookie2 … … 34
9.4。Set-Cookie2 … 34
10。参考资料… … 35
10.1。规范性引用文件… 35
10.2。翔实的参考资料… 35
附录A。致谢… 37
1。介绍
本文档定义了HTTP Cookie和Set-Cookie标头字段。
使用Set-Cookie标头字段，HTTP服务器可以传递名称/值
对和关联的元数据（称为Cookie）发送给用户代理。什么时候
用户代理向服务器发出后续请求，用户
代理使用元数据和其他信息来确定是否
返回Cookie标头中的名称/值对。
尽管表面上很简单，但Cookie还是有许多
复杂性。例如，服务器指示每个范围
Cookie发送到用户代理时。范围表示
用户代理应返回的最长时间
cookie，用户代理应将cookie返回到的服务器，
以及Cookie适用的URI方案。
由于历史原因，cookie包含许多安全性，
隐私隐秘。例如，服务器可以指示
给定的Cookie用于“安全”连接，但是安全
存在活动对象时属性不提供完整性
网络攻击者。同样，共享给定主机的Cookie
跨越该主机上的所有端口，即使通常的“相同来源
网络浏览器使用的“策略”隔离通过不同方式检索的内容
端口。
此规范有两个受众：cookie-开发人员
生成使用cookie的用户代理的服务器和开发人员。
巴特标准轨道[第3页]
RFC 6265 HTTP状态管理机制2011年4月
为了最大化与用户代理的互操作性，服务器应该限制
自己定义乖轮廓部分4时
生成Cookie。
用户代理必须执行定义的更宽松的处理规则
在第5节中，为了最大程度地与现有的互操作性
不符合在中定义的行为规范的服务器
第4节。
本文档将这些标头的语法和语义指定为
它们实际上是在Internet上使用的。特别是本文件
不会创建超出当今使用范围的新语法或语义。第4节中
提供了有关生成Cookie的建议
代表当前服务器行为的首选子集，甚至
在提供更自由的cookie处理算法第5确实
不建议使用所有语法和语义变体
今天。如果某些现有软件与推荐的软件不同
协议的重要方式，该文件包含说明
区别。
在此文档之前，至少有三个描述。
cookies：所谓的“ Netscape Cookie规范” [ Netscape ]，
RFC 2109 [ RFC2109 ]和RFC 2965 [ RFC2965 ]。但是，这些都不是
文档描述了Cookie和Set-Cookie标头的实际位置
在Internet上使用（有关历史背景，请参阅[ Kri2001 ]）。在
与以前的IETF HTTP状态管理规范有关
机制，本文要求采取以下措施：
1.将[ RFC2109 ] 的状态更改为“历史”（已经
被[ RFC2965 ] 淘汰。
2.将[ RFC2965 ] 的状态更改为“历史”。
3.表示[ RFC2965 ]已被本文档淘汰。
特别是，在将RFC 2965移至历史悠久并过时的过程中，
文档不赞成使用Cookie2和Set-Cookie2标头
领域。
2。约定
2.1。符合标准
关键字“必须”，“必须”，“必须”，“应”，“应不”，
“ SHOULD”，“ SHOULD NOT”，“推荐”，“ MAY”和“ OPTIONAL”
文档将按照[ RFC2119 ]中的说明进行解释。
巴特标准轨道[第4页]
RFC 6265 HTTP状态管理机制2011年4月
强制性要求中作为算法一部分的要求（例如
“删除任何前导空格字符”或“返回false并中止这些字符
步骤”）应与关键字的含义一起解释
（介绍“ MUST”，“ SHOULD”，“ MAY”等）。
用算法或特定步骤表述的一致性要求可以
只要最终结果是
当量。特别是在此定义的算法
规范旨在易于理解，而不是
旨在成为表演者。
2.2。语法符号
本规范使用增强Backus-Naur形式（ABNF）
[ RFC5234 ]的符号。
以下核心规则通过引用包括在内，如
[RFC5234]，附录B.1：ALPHA（字母），CR（回车），CRLF
（CR LF），CTL（控件），DIGIT（十进制0-9），DQUOTE（双引号），
HEXDIG（十六进制0-9 / AF / af），LF（换行），NUL（无效八位位组），
OCTET（除NUL之外的任何8位数据序列），SP（空格），HTAB
（水平标签），CHAR（任何[ USASCII ]字符），VCHAR（任何可见
[ USASCII ]字符）和WSP（空白）。
OWS（可选的空白）规则用于零个或多个线性
空格字符可能会出现：
OWS = *（[obs-fold] WSP）
; “可选”空格
折叠= CRLF
OWS应该不生产或作为单个SP生产
字符。
2.3。术语
术语用户代理，客户端，服务器，代理和原始服务器具有
与HTTP / 1.1规范（[ RFC2616 ]，第
1.3 节）中的含义相同。
request-host是用户代理所知道的主机名，
用户代理向其发送HTTP请求或向其发送HTTP请求
正在接收HTTP响应（即，它所指向的主机的名称）
发送了相应的HTTP请求）。
术语request-uri在[RFC2616]的5.1.2节中定义。
巴特标准轨道[第5页]
RFC 6265 HTTP状态管理机制2011年4月
据说两个八位字节序列不区分大小写地匹配
当且仅当它们在i; ascii-casemap下是等效的
[ RFC4790 ]中定义的排序规则。
术语字符串是指非NUL八位位组的序列。
3。总览
本节概述了源服务器发送状态的方法
信息发送给用户代理，并让用户代理返回
状态信息发送给原始服务器。
为了存储状态，原始服务器在其中包含Set-Cookie标头
HTTP响应。在后续请求中，用户代理返回一个
原始服务器的Cookie请求标头。Cookie标头
包含用户代理在先前的Set-Cookie中收到的Cookie
标头。原始服务器可以随意忽略Cookie标头或
将其内容用于应用程序定义的目的。
原始服务器可以发送带有任何内容的Set-Cookie响应头
响应。用户代理可以忽略包含在其中的Set-Cookie标头
100级状态码的响应，但必须处理Set-Cookie
其他回复中包含的标头（包括400-
和500级状态代码）。原始服务器可以包含多个
单个响应中的Set-Cookie标头字段。一个的存在
Cookie或Set-Cookie标头字段不排除HTTP缓存
从存储和重用响应。
源服务器不应该将多个Set-Cookie标头字段折叠到
一个标头字段。折叠HTTP标头的常用机制
字段（即[ RFC2616 ]中定义的字段）可能会更改
Set-Cookie标头字段，因为使用了％x2C（“，”）字符
Set-Cookie的作品与这种折叠方式有冲突。
3.1。例子
使用Set-Cookie标头，服务器可以向用户代理发送短消息
用户代理将来将返回的HTTP响应中的字符串
Cookie范围内的HTTP请求。例如，
服务器可以向用户代理发送名为SID的“会话标识符”
值31d4d96e407aad42。然后，用户代理返回
后续请求中的会话标识符。
巴特标准轨道[第6页]
RFC 6265 HTTP状态管理机制2011年4月
服务器->用户代理
Set-Cookie：SID = 31d4d96e407aad42
用户代理->服务器
Cookie：SID = 31d4d96e407aad42
服务器可以使用路径更改Cookie的默认范围
和域属性。例如，服务器可以指示用户
代理将Cookie返回到其的每个路径和每个子域
example.com。
服务器->用户代理
Set-Cookie：SID = 31d4d96e407aad42; 路径= /; 域= example.com
用户代理->服务器
Cookie：SID = 31d4d96e407aad42
如下例所示，服务器可以存储多个cookie
在用户代理处。例如，服务器可以存储会话
标识符以及用户的首选语言，方法是返回两个
Set-Cookie标头字段。请注意，服务器使用Secure和
HttpOnly属性为以下内容提供附加的安全保护
更为敏感的会话标识符（请参阅第4.1.2节）。
服务器->用户代理
Set-Cookie：SID = 31d4d96e407aad42; 路径= /; 安全; HttpOnly
Set-Cookie：lang = zh-CN; 路径= /; 域= example.com
用户代理->服务器
Cookie：SID = 31d4d96e407aad42; lang = zh-CN
请注意，上面的Cookie标头包含两个cookie，一个名为
SID和一个名为lang的语言。如果服务器希望用户代理
将Cookie保留在多个“会话”上（例如，用户代理）
重新启动），服务器可以在“到期时间”中指定到期日期
属性。请注意，用户代理可能会在删除Cookie之前
如果用户代理的cookie存储超过了它的过期日期
配额或用户手动删除服务器的cookie。
巴特标准轨道[第7页]
RFC 6265 HTTP状态管理机制2011年4月
服务器->用户代理
Set-Cookie：lang = zh-CN; 过期时间= 2021年6月9日星期三格林尼治标准时间
用户代理->服务器
Cookie：SID = 31d4d96e407aad42; lang = zh-CN
最后，要删除Cookie，服务器将返回Set-Cookie标头
过期日期为过去的日期。服务器将成功
仅在路径和域属性位于
Set-Cookie标头与使用Cookie时使用的值匹配
创建。
服务器->用户代理
Set-Cookie：lang =; Expires = Sun，1994年11月6日格林威治标准时间
用户代理->服务器
Cookie：SID = 31d4d96e407aad42
4。服务器要求
本节描述行为端正的语法和语义
Cookie和Set-Cookie标头的配置文件。
4.1。Set-Cookie
Set-Cookie HTTP响应标头用于从
服务器到用户代理。
4.1.1。句法
Set-Cookie响应标头非正式地包含标头名称
“ Set-Cookie”后跟一个“：”和一个cookie。每个Cookie都以
名称-值对，后跟零个或多个属性-值对。
服务器不应发送不符合要求的Set-Cookie标头
以下语法：
巴特标准轨道[第8页]
RFC 6265 HTTP状态管理机制2011年4月
set-cookie-header =“ Set-Cookie：” SP set-cookie-string
set-cookie-string = cookie-pair *（“;” SP cookie-av）
cookie-pair = cookie-name“ =” cookie-value
cookie名称=令牌
cookie值= * cookie八位字节/（DQUOTE * cookie八位字节DQUOTE）
cookie八位位组=％x21 /％x23-2B /％x2D-3A /％x3C-5B /％x5D-7E
; US-ASCII字符，不包括CTL，
; 空白DQUOTE，逗号，分号，
; 和反斜杠
令牌= <令牌，在[RFC2616]第2.2节中定义>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
扩展名
expires-av =“ Expires =” sane-cookie-date
sane-cookie-date = < rfc1123 -date，在[RFC2616]第3.3.1节中定义>
max-age-av =“ Max-Age =”非零数字* DIGIT
; 实际上，expires-av和max-age-av
; 仅限于由
; 用户代理。
非零数字=％x31-39
; 数字1到9
domain-av =“ Domain =”域值
域值= <子域>
; 在[RFC1034]第3.5节中定义为
; 由[RFC1123]第2.1节增强
path-av =“ Path =”路径值
路径值= <除CTL或“;”>以外的任何CHAR
secure-av =“安全”
httponly-av =“ HttpOnly”
extension-av = <除CTL或“;”>以外的任何CHAR
请注意，以上参考文档中的某些语法术语
使用与本文档不同的语法符号（
使用[ RFC5234 ]中的ABNF 。
cookie值的语义未在本文档中定义。
为了最大程度地与用户代理兼容，希望
将任意数据存储在cookie值中应对该数据进行编码，
例如，使用Base64 [ RFC4648 ]。
cookie-av术语产生的set-cookie-string部分
被称为属性。为了最大程度地与用户代理兼容，
服务器不应在服务器中产生两个具有相同名称的属性
相同的cookie字符串。（有关用户代理的处理方式，请参见第5.3节
这个案例。）
巴特标准轨道[第9页]
RFC 6265 HTTP状态管理机制2011年4月
服务器不应在其中包含多个Set-Cookie标头字段
具有相同Cookie名称的相同响应。（参见第5.2节对
用户代理如何处理这种情况。）
如果服务器发送多个包含Set-Cookie标头的响应
并发给用户代理（例如，与
用户代理（通过多个套接字），这些响应会创建“竞赛
条件”，可能导致无法预测的行为。
注意：一些现有的用户代理对它们的解释有所不同
两位数的年份。为了避免兼容性问题，服务器应使用
在RFC1123 -date格式，这需要一个四位数年份。
注意：某些用户代理将cookie中的日期存储和处理为32位
UNIX time_t值。库支持中的实现错误
在某些系统上进行time_t处理可能会导致此类用户代理
处理日期错误地在2038年之后。
4.1.2。语义学（非规范）
本节描述Set-Cookie标头的简化语义。
这些语义足够详细，有助于理解
服务器对Cookie的最常见使用。完整的语义是
在第5节中描述。
当用户代理收到Set-Cookie标头时，用户代理
将cookie及其属性存储在一起。随后，当
用户代理发出HTTP请求，用户代理包括
Cookie标头中包含适用的未过期的Cookie。
如果用户代理收到具有相同Cookie名称的新Cookie，
域值和路径值作为已存储的Cookie，
现有的cookie被逐出并替换为新的cookie。
请注意，服务器可以通过向用户代理发送
带有Expires属性的新Cookie，该属性的值是过去的值。
除非cookie的属性另有说明，否则cookie为
仅返回到原始服务器（而不返回到任何
子域），并且在当前会话结束时终止（如
由用户代理定义）。用户代理忽略无法识别的Cookie
属性（而不是整个Cookie）。
巴特标准轨道[第10页]
RFC 6265 HTTP状态管理机制2011年4月
4.1.2.1。过期属性
Expires属性指示cookie的最长生存期，
表示为Cookie过期的日期和时间。的
用户代理不需要保留cookie，直到指定了
日期已过。实际上，由于以下原因，用户代理经常驱逐Cookie：
内存压力或隐私问题。
4.1.2.2。最大年龄属性
Max-Age属性指示Cookie的最长生存期，
表示为Cookie过期之前的秒数。的
不需要用户代理保留指定的cookie
持续时间。实际上，由于存储原因，用户代理经常驱逐cookie
压力或隐私问题。
注意：一些现有的用户代理不支持最大年龄
属性。不支持Max-Age属性的用户代理
忽略该属性。
如果Cookie同时具有Max-Age和Expires属性，则Max-
年龄属性具有优先级，并控制广告的到期日期
曲奇饼。如果Cookie既没有Max-Age也没有Expires
属性，用户代理将保留cookie，直到“当前
会话结束”（由用户代理定义）。
4.1.2.3。域属性
域属性指定cookie将要到达的那些主机
被发送。例如，如果“域”属性的值是
“ example.com”，用户代理会将Cookie包含在Cookie中
向example.com，www.example.com和
www.corp.example.com。（请注意，如果有前导％x2E（“。”），
即使不允许该字符也将被忽略，但是
尾随％x2E（“。”）（如果存在）将导致用户代理忽略
属性。）如果服务器省略了域属性，则用户
代理只会将Cookie返回给原始服务器。
警告：一些现有的用户代理对待缺少的域
属性，就好像存在并包含Domain属性一样
当前主机名。例如，如果example.com返回Set-
没有Domain属性的Cookie标头，这些用户代理将
也会将Cookie错误地发送到www.example.com。
巴特标准轨道[第11页]
RFC 6265 HTTP状态管理机制2011年4月
除非Domain属性，否则用户代理将拒绝cookie。
指定cookie的范围，其中将包括来源
服务器。例如，用户代理将接受带有
来自的“ example.com”或“ foo.example.com”的域属性
foo.example.com，但用户代理将不接受带有
“ bar.example.com”或“ baz.foo.example.com”的域属性。
注意：出于安全原因，许多用户代理配置为拒绝
对应于“公共后缀”的域属性。例如，
某些用户代理将拒绝“ com”或“ co.uk”的域属性。
（有关更多信息，请参见第5.3节。）
4.1.2.4。路径属性
每个Cookie的范围仅限于一组路径，由
路径属性。如果服务器省略Path属性，则用户
代理将使用request-uri的路径组件的“目录”作为
默认值。（有关更多详细信息，请参见第5.1.4节。）
只有在以下情况下，用户代理才会将Cookie包含在HTTP请求中：
request-uri的路径部分与以下内容匹配（或是其子目录）
Cookie的Path属性，其中％x2F（“ /”）字符为
解释为目录分隔符。
尽管在隔离不同Cookie之间似乎很有用
给定主机中的路径，则不能依赖Path属性
安全性（请参阅第8节）。
4.1.2.5。安全属性
Secure属性将Cookie的范围限制为“安全”
渠道（其中“安全”由用户代理定义）。当一个
Cookie具有安全属性，用户代理将包括
仅当请求通过
安全通道（通常是基于传输层安全性（TLS）的HTTP
[ RFC2818 ]）。
尽管看似对保护cookie免受活动网络有用
攻击者，“安全”属性仅保护Cookie的
保密。活跃的网络攻击者可以覆盖安全
来自不安全渠道的Cookie，破坏了其完整性（请参阅
详见8.6节）。
巴特标准轨道[第12页]
RFC 6265 HTTP状态管理机制2011年4月
4.1.2.6。HttpOnly属性
HttpOnly属性将cookie的范围限制为HTTP
要求。特别是，该属性指示用户代理
通过“非HTTP” API提供对cookie的访问权时，忽略cookie
（例如将Cookie暴露给脚本的Web浏览器API）。
请注意，HttpOnly属性独立于Secure。
属性：cookie可以同时具有HttpOnly和Secure
属性。
4.2。曲奇饼
4.2.1。句法
用户代理将存储的cookie发送到原始服务器中的原始服务器。
Cookie标头。服务器是否符合以下要求
第4.1节（并且用户代理符合第5节的要求
），用户代理将发送符合以下条件的Cookie标头
以下语法：
cookie-header =“ Cookie：” OWS cookie-string OWS
cookie-string = cookie-pair *（“;” SP cookie-pair）
4.2.2。语义学
每个cookie对代表用户代理存储的cookie。的
cookie对包含用户代理的cookie名称和cookie值
在Set-Cookie标头中收到。
请注意，不会返回cookie属性。特别是，
服务器无法仅通过Cookie标头确定何时
cookie将过期，该cookie对哪些主机有效，对于哪个主机
cookie的有效路径，或者cookie是否使用
安全或HttpOnly属性。
Cookie标头中各个Cookie的语义不是
本文档定义。服务器有望注入这些
具有特定于应用程序语义的cookie。
尽管Cookie在Cookie标头中被线性序列化，
服务器不应该依赖序列化顺序。特别是，
如果Cookie标头包含两个同名的Cookie（例如，
设置了不同的Path或Domain属性的服务器）
不应该依赖这些Cookie在广告中出现的顺序
标头。
巴特标准轨道[第13页]
RFC 6265 HTTP状态管理机制2011年4月
5。用户代理要求
本节指定了Cookie和Set-Cookie标头
用户代理实现这些要求的足够详细的信息
可以与现有服务器（甚至那些可以
不符合第4节中所述的行为规范）。
用户代理可以执行比指定限制更多的限制
这里（例如，为了提高安全性）；然而，
实验表明，这种严格性降低了可能性
用户代理将能够与现有服务器进行互操作。
5.1。子组件算法
本节定义了用户代理用来处理的一些算法
Cookie和Set-Cookie标头的特定子组件。
5.1.1。日期
用户代理必须使用与以下等效的算法
解析cookie日期的算法。注意各种布尔
定义为算法一部分的标志（例如，发现时间，发现-
最初是“每月”，“发现月份”，“发现年份”。
1.使用以下语法，将cookie-date划分为date-token。
cookie-date = *定界符date-token-list *定界符
date-token-list = date-token *（1 *分隔符date-token）
日期令牌= 1 *非定界符
定界符=％x09 /％x20-2F /％x3B-40 /％x5B-60 /％x7B-7E
非定界符=％x00-08 /％x0A-1F / DIGIT /“：” / ALPHA /％x7F-FF
非数字=％x00-2F /％x3A-FF
月的天= 1 * 2DIGIT（非数字* OCTET）
month =（“ jan” /“ feb” /“ mar” /“ apr” /
“ may” /“ jun” /“ jul” /“ aug” /
“ sep” /“ oct” /“ nov” /“ dec”）* OCTET
年= 2 * 4DIGIT（非数字* OCTET）
时间= hms时间（非数字* OCTET）
hms-time =时域“：”时域“：”时域
时间字段= 1 * 2DIGIT
2.按日期令牌顺序依次处理每个日期令牌
出现在Cookie日期中：
巴特标准轨道[第14页]
RFC 6265 HTTP状态管理机制2011年4月
1.如果未设置found-time标志，并且令牌与
时间生产，设置发现时间标记并设置小时-
值，分钟值和二值表示的数字
分别按日期令牌中的数字表示。跳过
其余子步骤，并继续下一个日期令牌。
2.如果未设置“发现月份的日期”标志并且设置了日期令牌
匹配当月生产，设置发现日期
月标记并将月值日期设置为数字
用日期令牌表示。跳过其余子步骤，然后
继续下一个日期令牌。
3.如果未设置“发现月份”标志并且日期令牌匹配
月生产，设置“发现月份”标记并设置
月份值，以日期令牌表示的月份。跳过
其余子步骤，并继续下一个日期令牌。
4.如果未设置找到年份标志并且日期令牌匹配
年产量，设置发现年份标志并设置
年值到日期令牌所表示的数字。跳过
其余子步骤，并继续下一个日期令牌。
3.如果年值大于或等于70且小于或等于
等于99，将年值增加1900。
4.如果年值大于或等于0且小于或
等于69，则将年值增加2000。
1.注意：一些现有的用户代理会解释两位数的年份
不一样
5.如果出现以下情况，则中止这些步骤，并且无法解析cookie日期：
*至少一个找到的月份，找到的月份，找到的以下项目之一：
年份或未设置发现时间标记，
*月的天值小于1或大于31，
*年值小于1601，
*小时值大于23，
*分钟值大于59，或
*第二个值大于59。
（请注意，leap秒不能用此语法表示。）
巴特标准轨道[第15页]
RFC 6265 HTTP状态管理机制2011年4月
6.假设分析的cookie-date是其月份，月份，
年，时，分和秒（以UTC为单位）是每月的某天，
值，月值，年值，小时值，
分钟值和第二值。如果没有
日期存在，请中止这些步骤，并且无法解析cookie日期。
7.作为该算法的结果，返回解析的cookie日期。
5.1.2。规范化的主机名
规范化的主机名是以下内容生成的字符串
算法：
1.将主机名转换为单个域名的序列
标签。
2.转换不是非保留LDH（NR-LDH）标签的每个标签，
到A标签（对于前者，请参见[RFC5890]第2.3.2.1节
以及后者）或“ punycode标签”（由
“toascii将”变换在第4节的[RFC3490] ），在适当
（请参阅本规范的6.3节）。
3.连接结果标签，并用％x2E（“。”）分隔
字符。
5.1.3。域匹配
字符串域匹配给定的域字符串，如果至少有一个
符合以下条件：
o域字符串和字符串相同。（请注意，
域字符串和该字符串将被规范化为
此时小写。）
o满足以下所有条件：
*域字符串是字符串的后缀。
*字符串中不包含的最后一个字符
域字符串是％x2E（“。”）字符。
*字符串是主机名（即不是IP地址）。
5.1.4。路径和路径匹配
用户代理必须使用与以下等效的算法
计算Cookie的默认路径的算法：
巴特标准轨道[第16页]
RFC 6265 HTTP状态管理机制2011年4月
1.假设uri-path为request-uri的路径部分，
部分存在（否则为空）。例如，如果
request-uri仅包含一个路径（和可选的查询字符串），
那么uri-path是该路径（不带％x3F（“？”）字符）
或查询字符串），以及request-uri是否包含完整的
absoluteURI，uri-path是该URI的路径组件。
2.如果uri路径为空，或者uri-的第一个字符
路径不是％x2F（“ /”）字符，输出％x2F（“ /”）并跳过
其余步骤。
3.如果uri路径包含不超过一个％x2F（“ /”）字符，
输出％x2F（“ /”）并跳过其余步骤。
4.从第一个字符开始输出uri-path的字符
，但不包括最右边的％x2F（“ /”）。
如果至少以下之一，则请求路径路径与给定的Cookie路径匹配
满足以下条件：
o Cookie路径和请求路径相同。
o cookie路径是请求路径的前缀，也是最后一个
Cookie路径的字符为％x2F（“ /”）。
o cookie路径是请求路径的前缀，第一个
Cookie中未包含的请求路径的字符-
path是％x2F（“ /”）字符。
5.2。Set-Cookie标头
用户代理在HTTP中收到Set-Cookie标头字段时
响应，用户代理可以忽略其中的Set-Cookie标头字段
完整。例如，用户代理可能希望阻止
设置Cookie对“第三方”请求的响应（请参阅
7.1节）。
如果用户代理未忽略其中的Set-Cookie标头字段
整体上，用户代理必须解析Set-Cookie的字段值
标头字段为set-cookie-string（定义如下）。
注意：下面的算法比中的语法更宽松
第4.1节。例如，该算法去除前导和尾随
Cookie名称和值的空白（但保持内部
空格），而第4.1节中的语法则禁止在
这些职位。用户代理使用此算法来
与不遵循建议的服务器进行互操作
第4节。
巴特标准轨道[第17页]
RFC 6265 HTTP状态管理机制2011年4月
用户代理必须使用与以下等效的算法
解析“ set-cookie-string”的算法：
1.如果set-cookie-string包含％x3B（“;”）字符：
名称-值对字符串由以下字符组成，
但不包括第一个％x3B（“;”）和未解析的-
属性由set-cookie-string的其余部分组成
（包括有问题的％x3B（“;”））。
除此以外：
名称-值对字符串由所有字符组成
包含在set-cookie字符串中，而未解析的-
attribute是空字符串。
2.如果名称/值对字符串缺少％x3D（“ =”）字符，
完全忽略set-cookie-string。
3.（可能为空）名称字符串由向上的字符组成
，但不包括第一个％x3D（“ =”）字符，以及
（可能为空）值字符串由以下字符组成
第一个％x3D（“ =”）字符。
4.从名称中删除所有开头或结尾的WSP字符
字符串和值字符串。
5.如果名称字符串为空，则忽略set-cookie-string
完全。
- cookie-name是名称字符串，而cookie-value是
值字符串。
用户代理必须使用与以下等效的算法
解析未解析属性的算法：
1.如果unparsed-attributes字符串为空，则跳过其余部分
这些步骤。
2.丢弃未分析属性的第一个字符（
将为％x3B（“;”）字符）。
3.如果其余未解析的属性包含％x3B（“;”）
字符：
消耗未解析属性的字符，但最多
不包括第一个％x3B（“;”）字符。
巴特标准轨道[第18页]
RFC 6265 HTTP状态管理机制2011年4月
除此以外：
消耗剩余的未解析属性。
让cookie-av字符串作为此步骤中消耗的字符。
4.如果cookie-av字符串包含％x3D（“ =”）字符：
（可能为空）属性名称字符串由
最多但不包括第一个％x3D（“ =”）的字符
字符和（可能为空）属性值字符串
由第一个％x3D之后的字符（“ =”）组成
字符。
除此以外：
attribute-name字符串包含整个cookie-av
字符串，并且属性值字符串为空。
5.从属性中删除任何开头或结尾的WSP字符-
名称字符串和属性值字符串。
6.根据以下步骤处理属性名称和属性值：
以下小节中的要求。（注意
属性名称无法识别的属性将被忽略。）
7.返回此算法的步骤1。
当用户代理完成对set-cookie-string的解析后，用户
据说代理从请求uri中“接收cookie”，名称为
cookie名称，值cookie值和属性cookie-attribute-
清单。（请参阅第5.3节，了解由
收到Cookie。）
5.2.1。过期属性
如果属性名称不区分大小写与字符串匹配
用户代理“到期”必须按如下方式处理cookie-av。
令到期时间为将属性值解析为的结果
cookie-date（请参阅5.1.1节）。
如果属性值无法解析为Cookie日期，请忽略
cookie-av。
如果到期时间晚于最后日期，则用户代理可以
代表，用户代理可以用最后一个替换到期时间
可代表的日期。
巴特标准轨道[第19页]
RFC 6265 HTTP状态管理机制2011年4月
如果到期时间早于最早的日期，则用户代理
可以表示，用户代理可以将到期时间替换为
最早的可代表日期。
将一个属性附加到cookie-attribute-list
到期名称和到期时间的属性值。
5.2.2。最大年龄属性
如果属性名称不区分大小写，则匹配字符串“ Max-
年龄”，用户代理必须按如下方式处理cookie-av。
如果属性值的第一个字符不是DIGIT或“-”
字符，请忽略cookie-av。
如果其余的attribute-value包含非DIGIT字符，
忽略cookie-av。
令delta-seconds为转换为整数的属性值。
如果delta-seconds小于或等于零（0），则使到期时间
是最早可代表的日期和时间。否则，让
到期时间是当前日期和时间加上增量秒的秒数。
将一个属性附加到cookie-attribute-list
Max-Age的名称和到期时间的属性值。
5.2.3。域属性
如果属性名称不区分大小写地匹配字符串“ Domain”，
用户代理必须按如下方式处理cookie-av。
如果attribute-value为空，则行为未定义。然而，
用户代理应该完全忽略cookie-av。
如果属性值字符串的第一个字符为％x2E（“。”）：
假设cookie-domain是没有前导％x2E的属性值
（“。”）字符。
除此以外：
令cookie-domain为整个属性值。
将cookie域转换为小写。
将一个属性附加到cookie-attribute-list
域的名称和cookie域的属性值。
巴特标准轨道[第20页]
RFC 6265 HTTP状态管理机制2011年4月
5.2.4。路径属性
如果属性名称不区分大小写地匹配字符串“ Path”，
用户代理必须按如下方式处理cookie-av。
如果attribute-value为空，或者如果
属性值不是％x2F（“ /”）：
令cookie-path为默认路径。
除此以外：
令cookie-path为属性值。
将一个属性附加到cookie-attribute-list
Path的名称和cookie-path的属性值。
5.2.5。安全属性
如果属性名称不区分大小写地匹配字符串“ Secure”，
用户代理必须将属性附加到cookie-attribute-list
属性名称为Secure且属性值为空。
5.2.6。HttpOnly属性
如果属性名称不区分大小写与字符串匹配
用户代理“ HttpOnly”必须将属性附加到cookie-
attribute-list，其属性名称为HttpOnly且为空
属性值。
5.3。储存模式
用户代理存储有关每个cookie的以下字段：名称，
值，到期时间，域，路径，创建时间，最后访问时间，
持久性标志，仅主机标志，仅安全标志和仅http-
旗。
当用户代理从名称为request-uri的“接收cookie”时
cookie名称，值cookie值和属性cookie-attribute-
列表中，用户代理必须按以下方式处理Cookie：
1.用户代理可以完全忽略接收到的cookie。对于
例如，用户代理可能希望阻止接收cookie
来自“第三方”响应或用户代理可能不希望
存储超过一定大小的Cookie。
巴特标准轨道[第21页]
RFC 6265 HTTP状态管理机制2011年4月
2.创建一个名称为cookie-name，值为cookie-value的新cookie。
将创建时间和最后访问时间设置为当前时间
日期和时间。
3.如果cookie-attribute-list包含一个带有
“最大年龄”的属性名称：
将cookie的persistent-flag设置为true。
将Cookie的到期时间设置为最后一个的属性值
cookie-attribute-list中具有属性名称的属性
“最大年龄”。
否则，如果cookie-attribute-list包含一个属性
属性名称为“ Expires”（且不包含
属性名称为“最大年龄”的属性）：
将cookie的persistent-flag设置为true。
将Cookie的到期时间设置为最后一个的属性值
cookie-attribute-list中具有属性名称的属性
的“过期”。
除此以外：
将cookie的persistent-flag设置为false。
将Cookie的到期时间设置为最新的可表示时间
日期。
4.如果cookie-attribute-list包含一个带有
“域”的属性名称：
设domain-attribute为最后一个的attribute-value
cookie-attribute-list中具有属性名称的属性
“域”。
除此以外：
假设domain属性为空字符串。
5.如果用户代理配置为拒绝“公共后缀”，则
域属性是一个公共后缀：
如果域属性与规范化的相同
请求主机：
假设domain属性为空字符串。
巴特标准轨道[第22页]
RFC 6265 HTTP状态管理机制2011年4月
除此以外：
完全忽略cookie，然后中止这些步骤。
注意：“公共后缀”是由
公共注册表，例如“ com”，“ co.uk”和“ pvt.k12.wy.us”。
此步骤对于防止Attacker.com
通过设置Cookie破坏example.com的完整性
具有“ com”的Domain属性。不幸的是，
公共后缀（也称为“注册表控制的域”）
随着时间的变化。如果可行，用户代理应使用
最新的公共后缀列表，例如由
位于< http://publicsuffix.org/ > 的Mozilla项目。
6.如果域属性是非空的：
如果规范化请求主机与域不匹配，则
域属性：
完全忽略cookie，然后中止这些步骤。
除此以外：
将cookie的仅主机标志设置为false。
将Cookie的域设置为domain-attribute。
除此以外：
将cookie的仅主机标志设置为true。
将Cookie的域设置为规范化的请求主机。
7.如果cookie-attribute-list包含一个带有
“路径”的attribute-name，将cookie的路径设置为attribute-
cookie-attribute-list中最后一个属性的值，并带有
“路径”的属性名称。否则，将cookie的路径设置为
request-uri的默认路径。
8.如果cookie-attribute-list包含一个带有
属性名称为“安全”，将Cookie的仅安全标志设置为
真正。否则，将cookie的secure-only-flag设置为false。
9.如果cookie-attribute-list包含一个带有
属性名称“ HttpOnly”，将cookie的http-only-flag设置为
真正。否则，将cookie的http-only-flag设置为false。
巴特标准轨道[第23页]
RFC 6265 HTTP状态管理机制2011年4月
10.如果Cookie是从“非HTTP” API收到的，则
Cookie的http-only-flag已设置，请中止这些步骤，并忽略
Cookie完全。
11.如果cookie存储区包含同名的cookie，
域，并将路径作为新创建的Cookie：
1.将old-cookie设为具有相同名称的现有cookie，
域，并将路径作为新创建的Cookie。（注意
该算法保持不变，即最多存在
一个这样的cookie。）
2.如果新创建的cookie是从“非HTTP”接收到的
API和旧Cookie的http-only-flag已设置，请中止这些
步骤并完全忽略新创建的cookie。
3.将新创建的cookie的创建时间更新为
匹配旧Cookie的创建时间。
4.从cookie存储区中删除旧cookie。
12.将新创建的cookie插入cookie存储。
如果cookie具有过去的过期日期，则cookie被“过期”。
用户代理必须从Cookie存储库中删除所有过期的Cookie
在任何时候，如果cookie存储区中存在过期的cookie。
用户代理可以随时从“
cookie存储区，如果共享一个域字段的cookie的数量超过
一些实现定义的上限（例如50个cookie）。
用户代理可以随时从“
cookie存储区，如果cookie存储区超出某些预定上限
绑定（例如3000个Cookie）。
当用户代理从Cookie存储区中删除多余的Cookie时，
用户代理务必按以下优先级顺序退出Cookie：
- Cookie过期。
2.与一个域域共享的Cookie超过了预定域
其他Cookie的数量。
3.所有cookie。
如果两个Cookie的移除优先级相同，则用户代理务必
首先将最后访问日期最早的cookie逐出。
巴特标准轨道[第24页]
RFC 6265 HTTP状态管理机制2011年4月
当“当前会话结束”（由用户代理定义）时，
用户代理必须从Cookie存储区中删除所有带有
持久标记设置为false。
5.4。Cookie标题
用户代理将存储的cookie包含在Cookie HTTP请求中
标头。
当用户代理生成HTTP请求时，用户代理务必
不要附加多个Cookie标头字段。
用户代理可以完全省略Cookie标头。对于
例如，用户代理可能希望阻止在
设置cookie中的“第三方”请求（请参阅第7.1节）。
如果用户代理确实将Cookie标头字段附加到HTTP
请求，用户代理必须发送cookie字符串（定义如下）
作为标题字段的值。
用户代理必须使用与以下等效的算法
从cookie存储区计算“ cookie字符串”的算法
request-uri：
1.让cookie-list为来自cookie存储区的cookie集
满足以下所有要求：
*可以：
Cookie的仅主机标志为true，并且已规范化
request-host与cookie的域相同。
要么：
Cookie的仅主机标志为假，并且已规范化
request-host domain-匹配cookie的域。
* request-uri的路径path-匹配cookie的路径。
*如果Cookie的仅安全标记为true，则请求-
uri的方案必须表示“安全”协议（如
用户代理）。
注意：“安全”协议的概念未由
这个文件。通常，用户代理考虑协议
如果协议使用传输层，则此方法安全
巴特标准轨道[第25页]
RFC 6265 HTTP状态管理机制2011年4月
安全性，例如SSL或TLS。例如，大多数用户
代理商认为“ https”是表示
安全协议。
*如果Cookie的http-only-flag为true，则排除
cookie，如果正在为“非
HTTP” API（由用户代理定义）。
2.用户代理应按以下方式对Cookie列表进行排序
订购：
*路径较长的Cookie会先于
较短的路径。
*在具有等长路径字段的Cookie中，
在较早的cookie之前列出了较早的创建时间
创建时间。
注意：并非所有用户代理都按此顺序对cookie列表进行排序，但是
该命令反映了本文档在
书面的，从历史上看，有一些服务器
（错误）取决于此顺序。
3.将cookie列表中每个cookie的上次访问时间更新为
当前日期和时间。
4.通过处理每个将cookie列表序列化为cookie字符串
cookie列表中的cookie顺序为：
1.输出Cookie的名称，％x3D（“ =”）字符和
Cookie的价值。
2.如果cookie列表中有未处理的cookie，则输出
字符％x3B和％x20（“;”）。
注意：尽管它的名称，cookie字符串实际上是一个序列
八位字节，而不是字符序列。转换cookie字符串
（或其组成部分）转换为字符序列（例如，
展示给用户），用户代理可能希望尝试使用
UTF-8字符编码[ RFC3629 ]来解码八位位组序列。
但是，此解码可能会失败，因为并非
八位位组是有效的UTF-8。
巴特标准轨道[第26页]
RFC 6265 HTTP状态管理机制2011年4月
6。实施注意事项
6.1。限度
实际的用户代理实施在数量和数量上都有限制
他们可以存储的Cookie的大小。通用用户代理应该
提供以下每个最低功能：
o每个Cookie至少4096字节（以
Cookie名称，值和属性的长度）。
o每个域至少50个cookie。
o总计至少3000个cookie。
服务器应使用尽可能少的cookie，以避免
达到这些实施限制并最小化网络
由于Cookie头包含在每个请求中，因此带宽较高。
如果用户代理无法返回，则服务器应正常降级
Cookie标头中包含一个或多个Cookie，因为用户代理可能
随时根据用户的订单逐出任何cookie。
6.2。应用程序编程接口
Cookie和Set-Cookie标头使用这种深奥语法的原因之一
许多平台（包括服务器和用户代理）都提供了
Cookie的基于字符串的应用程序编程接口（API），
要求应用层程序员生成并解析
Cookie和Set-Cookie标头使用的语法，其中许多
程序员做错了，导致了互操作性
问题。
平台不向cookie提供基于字符串的API，而是
通过提供更多语义API可以很好地服务。超出范围
本文旨在推荐特定的API设计，但还有
接受一个抽象的“日期”对象而不是一个明显的好处
序列化的日期字符串。
6.3。IDNA依赖性和迁移
IDNA2008 [ RFC5890 ]取代了IDNA2003 [ RFC3490 ]。但是，有
两种规格之间的差异，因此可能存在
处理（例如转换）域名标签的差异
已根据另一方的注册进行了注册。
在IDNA2003-
基于域名的标签将无处不在。用户代理应该
实施IDNA2008 [ RFC5890 ]并可以实施[ UTS46 ]或[ RFC5895 ]
巴特标准轨道[第27页]
RFC 6265 HTTP状态管理机制2011年4月
为了促进他们的IDNA过渡。如果用户代理这样做
没有实现IDNA2008，则用户代理必须实现IDNA2003
[ RFC3490 ]。
7。隐私注意事项
Cookie通常因让服务器跟踪用户而受到批评。对于
例如，许多“网络分析”公司使用Cookie来
识别用户何时返回网站或访问其他网站
现场。尽管Cookie并不是服务器可以使用的唯一机制
通过HTTP请求跟踪用户，cookie有助于跟踪，因为
它们在用户代理会话之间是持久的，并且可以共享
主机之间。
7.1。第三方Cookie
尤其令人担忧的是所谓的“第三方” cookie。在
呈现HTML文档时，用户代理通常会请求资源
来自其他服务器（例如广告网络）。这些第三方
服务器可以使用cookie来跟踪用户，即使用户从不
直接访问服务器。例如，如果用户访问一个网站
包含来自第三方的内容，然后进行后续访问
另一个包含来自同一第三方的内容的网站，
第三方可以在两个站点之间跟踪用户。
某些用户代理限制了第三方Cookie的行为。对于
例如，其中一些用户代理拒绝发送Cookie标头
在第三方请求中。其他人拒绝处理Set-Cookie
响应第三方请求的标头。用户代理差异很大
在其第三方Cookie政策中。本文件授予使用者
代理商可以尝试第三方Cookie政策
平衡用户的隐私和兼容性需求。
但是，本文档不认可任何特定的第三方
Cookie政策。
第三方Cookie阻止策略通常在以下方面无效
如果服务器尝试解决其隐私问题，则可以实现其隐私目标
限制跟踪用户。特别是两个合作
服务器通常可以根本不使用cookie来跟踪用户
将标识信息注入动态URL。
7.2。用户控件
用户代理应该为用户提供一种管理
cookie存储在cookie存储中。例如，用户代理可能
让用户删除在指定时间段内收到的所有cookie
巴特标准轨道[第28页]
RFC 6265 HTTP状态管理机制2011年4月
或与特定域相关的所有cookie。另外，很多
用户代理包括一个用户界面元素，可让用户检查
存储在其cookie存储区中的cookie。
用户代理应该为用户提供一种禁用机制
饼干。禁用Cookie时，用户代理不得包含
出站HTTP请求中的Cookie标头，并且用户代理不得
处理入站HTTP响应中的Set-Cookie标头。
一些用户代理为用户提供了防止持久性的选项
跨会话存储Cookie。这样配置后，用户
代理商必须将所有收到的Cookie视为永久标记
设置为false。一些流行的用户代理通过以下方式公开此功能
“私人浏览”模式[ Aggarwal2010 ]。
一些用户代理使用户能够批准个人
写入Cookie存储区。在许多常见的使用场景中，这些
控件会生成大量提示。但是，有些隐私-
有意识的用户仍然发现这些控件仍然有用。
7.3。到期日期
尽管服务器可以将Cookie的过期日期设置为
在不久的将来，大多数用户代理实际上并不会保留Cookie
几十年。而不是选择不必要的长期限
期间，服务器应通过选择合理的方式来提高用户隐私
cookie的有效期（基于cookie的目的）。对于
例如，可以将典型的会话标识符合理地设置为
两周后过期。
8。安全注意事项
8.1。总览
Cookies具有许多安全隐患。本节概述
几个比较突出的问题。
特别是，Cookie鼓励开发人员依赖环境
身份验证的权限，通常容易受到攻击
例如跨站请求伪造[ CSRF ]。另外，存放时
Cookie中的会话标识符，开发人员经常创建会话
修复漏洞。
传输层加密（例如HTTPS中使用的加密）是
不足以阻止网络攻击者获取或更改
受害者的Cookie，因为Cookie协议本身具有多种
漏洞（请参阅“弱保密性”和“弱完整性”，
巴特标准轨道[第29页]
RFC 6265 HTTP状态管理机制2011年4月
下面）。此外，默认情况下，Cookie不提供
即使使用时，网络攻击者的机密性或完整性
与HTTPS结合使用。
8.2。环境局
使用Cookie验证用户身份的服务器可能会遭受安全性
漏洞，因为某些用户代理允许远程方发布
来自用户代理的HTTP请求（例如，通过HTTP重定向或HTML
形式）。发出这些请求时，用户代理甚至会附加Cookie
如果对方不知道Cookie的内容，
可能让远程方毫不留情地行使权限
服务器。
尽管此安全问题有很多名称（例如，
跨站点请求伪造，代理人困惑），此问题源于
Cookies是环境权限的一种形式。Cookies鼓励服务器
运算符，用于将名称（以网址的形式）与
授权（以Cookie的形式）。因此，用户代理
可能会提供针对由
攻击者，可能导致服务器或其客户端承担
攻击者指定的操作，就好像它们已被授权
用户。
服务器操作员可能不使用cookie进行授权，而是使用
希望考虑通过处理纠缠指定和授权
URL作为功能。与其将机密存储在Cookie中，不如
方法将机密存储在URL中，要求远程实体执行以下操作：
提供秘密本身。尽管这种方法不是万能药，
明智地应用这些原则可以导致更强大
安全。
8.3。清除文字
除非通过安全通道（例如TLS）发送，否则其中的信息
Cookie和Set-Cookie标头以明文方式传输。
1.这些标头中传达的所有敏感信息都暴露给
一个窃听者。
2.恶意中介可能会更改标头的行进路径
在任何一个方向上，结果都无法预测。
3.恶意客户端可能会先更改Cookie标头
传输，结果无法预测。
巴特标准轨道[第30页]
RFC 6265 HTTP状态管理机制2011年4月
服务器应加密和签名Cookie的内容（使用
服务器将其传输给
用户代理（即使通过安全通道发送Cookie时）。
但是，对Cookie内容进行加密和签名不会阻止
攻击者将cookie从一个用户代理移植到另一个用户代理
或稍后重播Cookie。
除了加密和签名每个Cookie的内容外，
需要更高安全性的服务器应使用Cookie
和Set-Cookie标头仅通过安全通道发送。使用时
通过安全通道的Cookie，服务器应设置安全每个Cookie的
属性（请参阅第4.1.2.5节）。如果服务器这样做
未设置安全属性，由安全提供的保护
渠道将在很大程度上没有意义。
例如，考虑一个存储会话的Webmail服务器
Cookie中的标识符，通常通过HTTPS访问。如果
服务器未在其cookie（活动的cookie）上设置Secure属性
网络攻击者可以拦截来自
用户代理，然后通过HTTP将请求重定向到Webmail服务器。
即使Webmail服务器没有监听HTTP连接，
用户代理仍将在请求中包含cookie。主动
网络攻击者可以拦截这些Cookie，然后针对
服务器，并了解用户电子邮件的内容。相反，如果
服务器已在其Cookie（用户代理）上设置了Secure属性
不会在明文请求中包含cookie。
8.4。会话标识符
而不是将会话信息直接存储在Cookie中（
可能暴露给攻击者或由攻击者重放），通常是服务器
在Cookie中存储一个随机数（或“会话标识符”）。当服务器
收到带有随机数的HTTP请求，服务器可以查找状态
使用随机数作为密钥的与cookie相关联的信息。
使用会话标识符cookie限制了攻击者可能造成的损害
导致攻击者了解cookie的内容，因为
随机数仅在与服务器交互时才有用（与非随机数不同，
随机数Cookie内容，这本身可能是敏感的）。此外，
使用单个随机数可以防止攻击者“拼凑”在一起
来自与服务器的两次互动的Cookie内容，这可能
导致服务器行为异常。
使用会话标识符并非没有风险。例如，
服务器应注意避免“会话固定”漏洞。
会话固定攻击分为三个步骤。首先，
攻击者从其用户代理移植会话标识符
给受害者的用户代理。其次，受害者使用该会话
巴特标准轨道[第31页]
RFC 6265 HTTP状态管理机制2011年4月
与服务器交互的标识符，可能包含会话
带有用户凭据或机密信息的标识符。
第三，攻击者使用会话标识符与
直接服务器，可能会获得用户的权限或
机密信息。
8.5。机密性差
Cookies不提供端口隔离。如果Cookie可以被
在一个端口上运行的服务，该Cookie也可以被
在同一服务器的另一个端口上运行的服务。如果一个cookie是
Cookie可由一个端口上的服务写入，Cookie也可由以下端口写入：
在同一服务器的另一个端口上运行的服务。为此原因，
服务器不应该在两个服务器上都运行互不信任的服务
同一主机的不同端口，并使用Cookie来存储安全性-
敏感的信息。
Cookies不提供按计划隔离。虽然最常见
与http和https方案一起使用时，给定主机的cookie
可能也可用于其他方案，例如ftp和gopher。
尽管这种缺乏按计划隔离的现象在非
允许访问cookie的HTTP API（例如HTML的document.cookie
API），实际上缺少方案隔离
自身处理Cookie的要求（例如，考虑
通过HTTP使用gopher方案检索URI）。
Cookies并不总是按路径提供隔离。虽然
网络级协议不会将为一个路径存储的Cookie发送到
另外，某些用户代理通过非HTTP API公开Cookie，例如
HTML的document.cookie API。因为其中一些用户代理（例如，
网络浏览器）不会隔离从不同路径接收到的资源，
从一条路径检索的资源可能能够访问cookie
存储为另一条路径。
8.6。完整性不足
Cookies不为同级域（和
其子域）。例如，考虑foo.example.com和
bar.example.com。foo.example.com服务器可以使用
“ example.com”的域属性（可能覆盖现有的
bar.example.com设置的“ example.com” cookie），用户代理将
将该cookie包含在对bar.example.com的HTTP请求中。在里面
最坏的情况是，bar.example.com将无法区分该Cookie
从cookie中进行设置。foo.example.com服务器可能是
能够利用这种能力对
bar.example.com。
巴特标准轨道[第32页]
RFC 6265 HTTP状态管理机制2011年4月
即使Set-Cookie标头支持Path属性，
路径属性不提供任何完整性保护，因为
用户代理将在Set-Cookie中接受任意Path属性
标头。例如，对请求的HTTP响应
http://example.com/foo/bar可以设置Path属性为的cookie
“ / qux”。因此，服务器不应该相互运行
在同一主机和使用的不同路径上不信任服务
Cookie，用于存储对安全敏感的信息。
活跃的网络攻击者还可以将Cookie注入Cookie
冒充来自的响应，将标题发送到https://example.com/
http://example.com/并注入Set-Cookie标头。HTTPS
example.com上的服务器将无法区分这些cookie
来自它在HTTPS响应中设置的cookie。一个活跃的
网络攻击者可能能够利用此功能来安装
即使example.com使用HTTPS也会攻击example.com
只。
服务器可以通过加密和加密来部分缓解这些攻击
在其Cookie的内容上签名。但是，使用加密
不能完全缓解问题，因为攻击者可以重播
他或她从的真实example.com服务器收到的Cookie
用户会话，结果无法预测。
最后，攻击者可能能够迫使用户代理删除
通过存储大量cookie来实现cookie。一旦用户代理
达到其存储限制，则用户代理将被强制逐出
一些饼干。服务器不应依赖用户代理保留
饼干。
8.7。依赖DNS
Cookies依靠域名系统（DNS）来确保安全。如果
DNS受到部分或全部破坏，cookie协议可能会失败
提供应用程序所需的安全属性。
9。IANA注意事项
永久消息头字段注册表（请参阅[ RFC3864 ]）已
更新了以下注册。
巴特标准轨道[第33页]
RFC 6265 HTTP状态管理机制2011年4月
9.1。曲奇饼
标头字段名称：Cookie
适用协议：http
状态：标准
作者/变更控制者：IETF
规范文件：本规范（第5.4节）
9.2。Set-Cookie
标头字段名称：Set-Cookie
适用协议：http
状态：标准
作者/变更控制者：IETF
规范文件：本规范（第5.2节）
9.3。Cookie2
标头字段名称：Cookie2
适用协议：http
状态：已淘汰
作者/变更控制者：IETF
规格文件：[ RFC2965 ]
9.4。Set-Cookie2
标头字段名称：Set-Cookie2
适用协议：http
状态：已淘汰
作者/变更控制者：IETF
规格文件：[ RFC2965 ]
巴特标准轨道[第34页]
RFC 6265 HTTP状态管理机制2011年4月
10。参考文献
10.1。规范性引用
[ RFC1034 ] Mockapetris，P.，“域名-概念和设施”，
STD 13，RFC 1034，1987年11月。
[ RFC1123 ] Braden，R。，“ Internet主机的要求-应用程序
和支持”，STD 3，RFC 1123，1989年10月。
[ RFC2119 ] Bradner，S.，“在RFC中用于指示的关键字
要求级别”，BCP 14，RFC 2119，1997年3月。
[ RFC2616 ] Fielding，R.，Gettys，J.，Mogul，J.，Frystyk，H.，
Masinter，L.，Leach，P.和T. Berners-Lee，“超文本
传输协议-HTTP / 1.1”，RFC 2616，1999年6月。
[ RFC3490 ] Faltstrom，P.，Hoffman，P。和A. Costello，
“应用程序中的域名国际化（IDNA）”，
RFC 3490，2003年3月。
参见第6.3节以了解为何规范性
需要参考过时的规范。
[ RFC4790 ] Newman，C.，Duerst，M.和A. Gulbrandsen，“互联网
应用协议整理注册表”，RFC 4790，
2007年3月。
[ RFC5234 ] Crocker，D。，编辑。和P. Overell，“语法增强的BNF
规格：ABNF”，STD 68，RFC 5234，2008年1月。
[ RFC5890 ] Klensin，J.，“国际化域名
应用程序（IDNA）：定义和文档框架”，
RFC 5890，2010年8月。
[ USASCII ]美国国家标准协会，“编码字符
设置-7位美国信息标准码
互换”，ANSI X3.4，1986年。
10.2。信息参考
[ RFC2109 ] Kristol，D.和L. Montulli，“ HTTP状态管理
机制”，RFC 2109，1997年2月。
[ RFC2965 ] Kristol D.和L. Montulli，“ HTTP状态管理
机制”，RFC 2965，2000年10月。
巴特标准轨道[第35页]
RFC 6265 HTTP状态管理机制2011年4月
[ RFC2818 ] Rescorla，E。，“ HTTP over TLS”，RFC 2818，2000年5月。
[ Netscape ] Netscape Communications Corp.，“持久的客户端状态-
HTTP Cookies”，1999年，< http://web.archive.org/web/
20020803110822 / http：//wp.netscape.com/newsref/std/
cookie_spec.html>。
[ Kri2001 ] Kristol，D。，“ HTTP Cookie：标准，隐私和
政治”，ACM Transactions on Internet Technology Vol。1，
＃2，2001年11月，< http://arxiv.org/abs/cs.SE/0105018 >。
[ RFC3629 ] Yergeau，F。，“ UTF-8，ISO的转换格式
10646“，STD 63，RFC 3629，2003年11月。
[ RFC4648 ] Josefsson，S。，“ Base16，Base32和Base64数据
编码”，RFC 4648，2006年10月。
[ RFC3864 ] Klyne，G.，Nottingham，M。和J. Mogul，“注册
消息标头字段的过程”，BCP 90，RFC 3864，
2004年9月。
[ RFC5895 ] Resnick，P。和P. Hoffman，“为
应用程序中的国际化域名（IDNA）
2008”，RFC 5895，2010年9月。
[ UTS46 ] Davis，M.和M. Suignard，“ Unicode IDNA兼容性
处理”，Unicode技术标准第46号，2010年，
< http://unicode.org/reports/tr46/ >。
[ CSRF ] Barth，A.，Jackson C.和J. Mitchell，“健壮的防御”
进行跨站请求伪造”，2008年，
< http://portal.acm.org/citation.cfm?id=1455770.1455782 >。
[ Aggarwal2010 ]
G. Aggarwal，E。Burzstein，C。Jackson和D. Boneh，
“现代私人浏览模式的分析
浏览器”，2010年，< http://www.usenix.org/events/sec10/tech/
full_papers / Aggarwal.pdf >。
巴特标准轨道[第36页]
RFC 6265 HTTP状态管理机制2011年4月
附录A。致谢
该文档大量借鉴了RFC 2109 [ RFC2109 ]。我们是
感谢David M. Kristol和Lou Montulli的努力
指定cookie。大卫·克里斯托（David M. Kristol）特别提供
有关浏览IETF流程的宝贵建议。我们还要
感谢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
霍夫曼，乔治·科本，迪恩·麦克纳姆，阿列克谢·梅尔尼科夫，马克·米勒，
Mark Pauley，Yngve N.Pettersen，Julian Reschke，Peter Saint-Andre，
Mark Seaborn，Maciej Stachowiak，Daniel Stenberg，Tatsuhiro
Tsujikawa，David Wagner，Dan Winship和Dan Witte