YD/T 2918-2015.Technical specifications of HTTP state (cookie) management mechanism.
1范围
YD/T 2918规定了超文本传输协议(HTTP) 的cookie和Set-cookie的头字段，详细定义了cookie的语法，属性和字段要求、数据格式，并明确了cookie的作用域。
YD/T 2918适用于支持cookie功能的系统(包括客户端、服务器和用户代理)。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC 1034域名一 概念和设备
IETF RFC 1123互联网主机需求-应用和支持
IETF RFC 2616超文本传输协议-HTTP/1.1
IETF RFC 3490应用中的国际化域名(IDNA)
IETF RFC 5234扩展BNF的语法规范: ABNF
IETF RFC 5890面向应用的国际化域名(IDNA): 定义和规范框架
IETF RFC 6265超文 本传输协议状态管理机制
USASCII 美国国家标准协议 “编码字符集一7位美国 标准信息交换码”，ANSI X3.4, 1986
3术语、定义和缩略语
3.1 术语和定义
下列术语和定义适用于本文件。
3.1.1
客户端 Client
用来建立连接、发送请求的一个程序([ETP RFC 2616]。
3.1.2
用户代理 User Agent
用来发起请求的客户端，通常是浏览器、编辑器、蜘蛛或其他终端用户工具[IETP RFC 2616]。

ICS35.100.70
中华人民共和国通信行业标准
YD/T2918-2015
超文本传输协议状态（cookie）管理机制技术规范
Technical specificationsofHTTPstate(cookie)managementmechanism
2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
2规范性引用文件
3术语、定义和缩略语
3.1术语和定义
概要·
5服务器要求·
概述·
Set-cookie\
cookie
“用户代理要求·
6.2子模块算法
Set-cookie消息头
存储模型·
6.5cookie消息头
7实现注意事项
限制·
应用程序接口（API）
7.3IDNA依赖和迁移.
8隐私问题·
概述：
第三方cookie·
用户控制…
过期日期
附录A（资料性附录）安全考量
附录B（资料性附录）样例·
参考文南
YD/T2918-2015
YD/T2918-2015
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：互联网域名系统北京市工程研究中心有限公司、北龙中网（北京）科技有限责任公司、中国互联网络信息中心、中国信息通信研究院。本标准主要起草人：赵雅静、卢文哲、马迪、钱炜烁、毛伟、沈烁、马军锋。I
YD/T2918-2015
本标准对超文本传输协议（HTTP）的cookie和Set-cookie的头字段进行了技术规范。HTTP服务器可以用这些头字段在HTTP用户代理上储存状态（称作cookies）。通过这种形式，服务器可以在通常是无状态的HTTP协议上维护个有状态的会话。尽管cookie和Set-cookie头字段在互联网上被广泛使用，cookies存在技术缺陷，本标准对其安全性和隐私性也进行了技术说明。1范围
YD/T2918-2015
超文本传输协议状态（cookie）管理机制技术规范本标准规定了超文本传输协议（HTTP）的cookie和Set-cookie的头字段，详细定义了cookie的语法，属性和字段要求、数据格式，并明确了cookie的作用域。本标准适用于支持cookie功能的系统（包括客户端、服务器和用户代理）。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC1034域名一概念和设备
IETFRFC1123互联网主机需求-应用和支持IETFRFC2616超文本传输协议-HTTP/1.1IETFRFC3490应用中的国际化域名(IDNA)IETFRFC5234扩展BNF的语法规范：ABNFIETFRFC5890面向应用的国际化域名(IDNA)：定义和规范框架IETFRFC6265超文本传输协议状态管理机制USASCII美国国家标准协议“编码字符集一7位美国标准信息交换码”，ANSIX3.4,19863术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。3.1.1
客户端Client
用来建立连接、发送请求的一个程序[IETFRFC2616]。3.1.2
用户代理UserAgent
用来发起请求的客户端，通常是浏览器、编辑器、蜘蛛或其他终端用户工具[IETFRFC2616]。3.1.3
服务器Server
用来响应服务请求、接受连接的应用程序。任何程序可以是一个客户端也可以是一个服务器：任何服务器可以作为原始服务器、代理、网关、或者隧道，根据每个请求的性质来决定[IETFRFC2616]。3.1.4
原始服务器OriginServer
一个存储或产生资源的服务器[IETFRFC2616]。YD/T2918-2015
主机名TheRequest-Host
用户代理发送HTTP请求到或者从其收到HTTP回应的主机的名字[IETFRFC2616]。3.1.6
请求URIRequest-Uri
一种全球统一资源标识符，用于指定请求的资源[IETFRFC2616]。3.1.7
字符串
一列非空八位字节[IETFRFC2616]。4概要
本章概括阐述了源服务器发送状态信息给用户代理和用户代理返回状态信息给源服务器一种方法。为了存储状态信息，源服务器在一个HTTP响应消息里放置一个Set-cookie消息头。在随后的请求中，用户代理返回一个cookie请求消息头到源服务器其中，包含有用户代理从之前的Set-cookie消息头中收到的cookies。源服务器可以忽略这个cookie消息头或者将其内容用于一个程序定义的目的。源服务器可以采用任意的HTTP消息来发送Set-cookie响应消息头。用户代理可以忽略100级状态代码的响应中的Set-cookie消息头，但是必须处理其他响应（包括带有400和500级状态代码的响应）中的Set-cookie消息头。源服务器可以在一个响应中放置多个Set-cookie消息头字段。cookie或者Set-cookie消息头字段的出现并不妨碍HTTP缓存存储或者重用一个响应。源服务器不应该将多个Set-cookie消息头字段组装成一个消息头字段。通常使用的折叠HTTP消息头字段的机制（如IETFRFC2616所述）可能会改变Set-cookie头字段的语义，因为Set-cookie使用%x2C（\”）字符的方法与这种方法冲突。
5服务器要求
5.1概述
本条描述了关于cookie和Set-cookie消息头的语法和语义概要。5.2 Set-cookie
5.2.1语法
Set-cookie响应消息头中包含了消息头的名字\Set-cookie\，后跟一个\\和一个cookie。每个cookie都以一个名/值对（name-value-pari）开头，后跟零个到多个属性/值对（attribute-value）。服务器在发送Set-cookie消息头时应该遵循如下语法：set-cookie-header=\Set-cookie:\sP set-cookie-stringset-cookie-string=cookie-pair*(\;\sP cookie-av)cookie-pair=cookie-name\\cookie-valuecookie-name=token
cookie-value=*cookie-octet/(DQUOTE*cookie-octetDQUOTE）cookie-0ctet=%x21/%x23-2B/%x2D-3A/%x3C-5B/%x5D-7E；除CTLs、
；空白分隔符双引号、逗号、分号、：和反斜杠以外的US-ASCI字符
token=cookie-ay=expires-av/max-age-av/domain-av/path-av/secure-av/httponly-av/extension-avexpires-av=\Expires=\sane-cookie-datesane-cookie-date=max-age-av=\Max-Age-\non-zero-digit *DIGIT；在实际操作中
；expires-av和max-age-av字段的取值：都被限制于用户代理所能表示的范围以内non-zero-digit=%x31-39
；数字1到9
domain-av=\Domain-\domain-valuedomain-value=
；定义于IETFRFC1034第3.5节
；改进于IETFRFC1123第2.1节
path-av \Path-\path-value
path-value=*<除CTLs和“；”以外的任意字符>secure-av -\Secure\
httponly-av=\HttpOnly
extension-av=*<除CTLs和“；”以外的任意字符>YD/T2918-2015
需要注意的是，规定了上面某些语法术语的标准使用了与本标准不同的语法标注方式（本标准使用的是IETFRFC5234定义的ABNF体系）。cookie-value的语义在本标准中没有定义。为了兼容更广泛的用户代理，想要在cookie-value中存储任意数据的服务器需要对数据进行编码，例如，采用Base64（IETFRFC4648）。set-cookie-string中由cookie-av组成的部分通常被称为属性。为了最广泛地兼容用户代理，服务器不应该在同一个set-cookie-string中产生两个同名的属性（6.4讲解了用户代理对这种情况的处理）。服务器不应该在同一个响应中向用户代理发送包含多个具有相同的cookie-name的Set-cookie消息头（6.3中讲解了用户代理是如何处理这种情况的）如果服务器同时向用户代理发送包括Set-cookie消息头的多个响应（例如，当与用户代理的通讯在多个套接字上并发进行时），这些响应会造成“竞争情况”，从而导致不可预测的行为。由于一些现有的用户代理对用两位数表示的年的解释并不相同，为了避免兼容性的问题，服务器在上述各字段的定义中，如果用到日期，应该使用IETFRFC1123规定的日期格式。这种格式要求用四位数字表示年。
YD/T2918-2015
注1：一些用户代理将cookie中的数据作为32位UNIXtime_t值来存储和处理。在一些操作系统上支持timet处理的库中的执行漏洞可能会导致这些用户代理在2038年后不能正确地处理日期。5.2.2语义（非规范）
5.2.2.1概述
5.2.2描述了Set-cookie消息头的简化语义。这些简化的语义有助于理解最常见的服务器cookie用法。完整的语义描述详见第6章。
当用户代理收到Set-cookie消息头时，用户代理存储其中的cookie及其属性。随后，当用户代理发出HTTP请求时，用户代理将适用并未过期的cookie包括在cookie消息头中。如果用户代理收到的新cookie和它之前储存过的某个cookie有相同的cookie名(cookie-name)、域值（domain-value）和路径（path-value），则已存储的cookie会被驱逐并被新的cookie替代。需要注意的是，通过向用户代理发送过期日期为过去某一时间点的新cookie，服务器可以删除旧的cookiea
除非cookie的属性有其他定义，cookie只能被返回到源服务器（而不是其它地方。例如，某个子域）。此cookie会在当前会话结束时过期（由用户代理定义）。用户代理会忽略无法识别的cookie属性（但不是整个cookie）。
5.2.2.2过期属性
过期属性通过定义cookie过期的日期和时间来规定cookie的最长生命周期。然而，本标准并不强制要求用户代理将该cookie保存到过期。实际上，因为存储压力或隐私原因，用户代理经常会驱逐cookie5.2.2.3最大存活时间属性
最大存活时间属性通过规定cookie经过多少秒才过期，来规定cookie的最长生命周期。然而，本标准并不强制要求用户代理将该cookie保存指定的时长。实际上，因为存储压力或隐私原因，用户代理经常会驱逐cookie
注：当前有些用户代理并不支持最大存活时间属性。这些用户代理会忽略这一属性。如果cookie同时有最大存活时间属性和过期属性，最大存活时间属性优先控制cookie的过期日期。如果cookie既没有最大存活时间属性，也没有过期属性，用户代理会保存cookie直到“当前会话结束”（会话结束时间由用户代理定义）。下载标准就来标准下载网
5.2.2.4域属性
域属性规定了cookie将被发送到哪些主机。例如，如果某个cookie的域属性值为\example.com”，那么当用户代理向example.com，example.com或者corp.example.com发出HTTP请求时，就会把该cookie包括在cookie消息头里（注意：如果%x2E（\\)出现在域属性值的开头，%x2E(\\)将被忽略，尽管它是不允许出现的字符：如果%x2E(\\)出现在域属性值的结尾，用户代理会忽略此域属性）如果服务器省略了域属性，用户代理会仅将cookie返回到源服务器。注意：当前有些用户代理将源服务器名作为缺省值来处理域属性省略的情况。例如，如果example.com返回的Set-cookie消息头没有域属性，这些用户代理会错误地将域属性设置为默认值example.com，从而导致将cookie也发送到example.com。YD/T2918-2015
cookie的域属性必须包含源服务器，否则用户代理会拒绝该cookie。例如，如果cookie来自foo.cxample.com，用户代理会接受域属性值为\example.com\或“foo.example.com\的cookie，但是并不会接受域属性值为\bar.example.com\或\baz.foo.example.com\的cookie。考虑到安全性，很多用户代理被设置成拒绝与公共后缀”相同的域属性。例如，有些用户代理会拒绝值为\com\or\co.uk\的域属性（详见本标准6.4）。5.2.2.5路径属性
cookie的作用域仅限于路径属性规定的一系列路径。如果服务器省略了路径属性，用户代理会将请求URI（request-uri）的路径部分的目录作为默认值（详见第6.2.5节）。只有在请求URI的路径部分和cookie的路径属性相匹配，或者前者是后者的子目录的情况下，用户代理才会把cookie包括在HTTP请求中。在cookie路径属性中，%x2F(\/\)字符被当做目录分隔符。尽管将给定主机上的不同路径间的cookie隔离开的策略看起来有效，但路径属性在安全性方面仍然不能被信赖（见附录A）。
5.2.2.6安全属性
安全属性将cookie的作用域限制在“安全的”信道上（“安全的”由用户代理来定义）如果cookie带有安全属性，那么只有当请求在安全信道上（比较典型的是传输层安全协议（TLS）上的HTTP，参见IETFRFC2818）传输时，用户代理才会把cookie包括在HTTP请求中。尽管安全属性看似可以有效地保护cookie免受主动网络攻击者的攻击，它仅能保护cookie的机密性。主动网络攻击者能够从不安全的信道覆盖安全的cookie，并打乱它的完整性（详见附录A）。5.2.2.7仅限HTTP属性
仅限HTTP属性将cookie的作用域限制在HTTP请求范围内。尤其是，用户代理通过“非HTTP”的应用程序接口（例如会将cookie暴露给脚本的网络浏览器API）提供cookie访问时，该属性会通知用户代理忽略该cookie
需要注意的是，仅限HTTP属性独立于安全属性：cookie可以同时具有仅限HTTP属性和安全属性。5.3cookie
5.3.1语法
通过cookie消息头，用户代理将存储的cookie发送给源服务器。如果服务器符合5.2中的要求（并且用户代理符合第6章中的要求），用户代理将发出符合以下的语法规范的cookie消息头：cookie-header=\cookie\owS cookie-stringOwscookie-string=cookie-pair*(\\SPcookie-pair）5:3.2语义
每一个cookie对（cookie-pair）都代表一个用户代理已存储的cookie。cookie对（cookie-pair）包含用户代理在Set-cookie消息头中获取的cookie-name和cookie-value。注意，cookie属性不会被返回。尤其要注意的是，单从cookie消息头里，服务器无法判断该cookie何时过期、对哪些主机该cookie是有效的、对哪些路径该cookie是有效的，或者该cookie是否设置了安全属性、仅限HTTP属性。
包含在cookie消息头中的单个cookie的语义没有在本标准中定义。服务器需要对这些cookie冠以与特定应用相关的语义。
YD/T2918-2015
虽然cookie在cookie消息头中以线性方式序列化，但是服务器不应该依赖于这些序列化的顺序。尤其当cookie消息头中包含了两个同名的不同的cookies时（例如，路径或域属性值不同的cookie），服务器不能依赖于这些cookies在消息头中出现的顺序。6用户代理要求
6.1概述
本章详细描述了cookie和Set-cookie消息头。严格执行这些要求的用户代理可以与现有的服务器交互操作（对于那些不遵守第5章中描述的规范概要的服务器也不例外）。用户代理可以强制执行比此处规定更严格的限制（例如，处于加强安全性的目的）：但是，实验证明那样严格的规定将有可能降低用户代理与现有服务器交互操作的兼容性。6.2子模块算法
6.2.1简述
本条描述了用户代理处理cookie和Set-cookie消息头的特定子部件的算法。6.2.2日期
用户代理必须使用等价于下列算法的算法来解释cookie日期（cookie-date）。注意，作为算法一部分的各种布尔指示器（即found-time，foundday-of-month，found-month，found-year）的默认值为“未设置/非”（即“NotSet”）。
算法的步骤如下：
a）使用下列语法，将cookie-date分割成若干个date-token。cookie-date
date-token-list
date-token
delimiter
non-delimiter
non-digit
day-of-month
hms-time
time-field
=*delimiterdate-token-list*delimiter=date-token *(1*delimiter date-token)= 1*non-delimiter
=%x09/%x20-2F/%x3B-40/%x5B-60/%x7B-7E=%x00-08/%x0A-1F/DIGIT/*\/ALPHA/%x7F-FF=%x00-2F/%x3A-FF
=I*2DIGIT(non-digit*OCTET)
-（\jan\/\feb\/\mar\/\apr\/\may\/\jun\/\jul\/\aug\/\sep\/\oct\/\nov\/\dec\）*OCTET=2*4DIGIT(non-digit*OCTET）
=hms-time (non-digit *OCTET)=time-field\,\time-field\,\time-field=1*2DIGIT
b）按照日期标记（date-token）出现在cookie日期（cookie-date）中的顺序来依次处理每个date-token，逻辑如下：
1）如果found-time指示器未设置并且标记与产生时间匹配，则设置found-time指示器，分别将设置小时值（hourvalue），分钟值（minute-value）和秒值（second-value）设置成date-token中数字所代表的值。忽略余下的子步骤并继续处理下一个date-token。6
YD/T2918-2015
2）如果found-day-of-month指示器未设定并且date-token与day-of-month相匹配，则设置found-day-of-month指示器，并将day-of-month-value设置成date-token中数字所代表的值。忽略余下的子步骤并继续处理下一个date-token。3）如果found-month指示器未设定并且date-token与月份相匹配，则设置found-month指示器并将month-value设置成date-token中数字所代表的月份。忽略余下的子步骤并且继续处理下一个date-token。4）如果found-year指示器未设定并且date-token与年份相匹配，则设置found-year指示器并将year-value设置成date-token中数字所代表的值。忽略余下的子步骤并且继续处理下一个date-token。c）如果year-value大于等于70且小于等于99，将year-value加上1900。d）如果year-value大于等于0且小于等于69，将year-value加上2000。注：某些现有的用户代理以不同方式解释两位数的年份。e）如果至少出现下列情况之一，应终止上述步骤并且报告cookie-date解析失败：。found-day-of-month，found-month，found-year，或者found-time这4个指示器中至少有一个的值未设定：
·day-of-month-value小于1或大于31；·year-value小于1601；
·hour-value大于23：
minute-value大于59，或者：
·second-value大于59。
（注意，此语法不能表示闰秒）。f）按世界标准时间（UTC），分别将day-of-month-value，month-value，year-value，hour-value，minute-value和second-value解释为月的第几天、月、年、小时、分钟、秒，得到一个时间结果，将其作为parsed-cookie-date；如果不存在该日期，则终止上述步骤并宜布解析cookie-date失败。g）将parsed-cookie-date作为本算法的结果返回。6.2.3规范化主机名
规范化的主机名是采用以下算法生成的一串字符：a）将主机名转化为一个域名标签（domainnamelabel）的序列。b）按照6.3描述的方法将除了“非保留LDH（NR-LDH）标签”以外的所有标签转变成A类标签（见IETFRFC58902.3.2.1中对NR-LDH标签和A类标签的定义），或punycde标签（该标签是根据IETFRFC3490第4章中定义的\ToASCII\方法转换而来的标签）。c）串联得到的标签，以%x2E（\.\)字符分隔。6.2.4域匹配
如果出现下列情况之一，则字符串“域匹配（domain-match）”给定的域字符串：域字符串和该字符串是一致的（注意，在这一步骤域字符串和该字符串都需要转换成小写）。一符合以下所有情况：
：域字符串是该字符串的后缀；·该字符串的最后一个未被域字符串包括的字符是%x2E(\\)：，该字符串是主机名（即，不是IP地址）。7
YD/T2918-2015
6.2.5路径和路径匹配
用户代理必须使用与下列算法等效的算法计算cookie的默认路径（default-path）：a）如果request-uri中存在路径部分（或者该部分为空），uri-path的取值应该为该部分。例如，如果request-uri仅包含一个路径（和可选的查询字符串），uri-path即为此路径（不含%x3F（\?\)字符或者查询字符串）；如果request-uri包括一个完整的绝对URI，uri-path是该URI的路径部分。b）如果uri-path为空或者uri-path的首字符不是%x2F（\/\)，输出%x2F（\/\)并跳过余下的步骤。c）如果uri-path仅包括一个%x2F（\/\)，输出%x2F（\/\)并跳过余下的步骤。d）输出uri-path中从第一个字符开始到（但不包括）最右的%x2F（\/\)之间的所有字符。如果满足下列条件之一，request-path在“路径匹配（path-match）”给定的cookie-path：·cookie-path和request-path是一致的。值得注意的是，这里的“path一致”与RFC3986中关于“致性”的要求不同，因此两个相同的path却可以拥有不同的cookie。·cookie-path是request-path的前缀，并且cookie-path以%x2F（\/\)结尾。cookie-path是request-path的前缀，并且request-path的首个未包含在cookie-path中的字符是%x2F\)。
6.3Set-cookie消息头
6.3.1概述
当用户代理收到HTTP响应中的Set-cookie消息头字段时，用户代理可以整个忽略该Set-cookie消息头字段。例如，用户代理可能希望通过禁止Set-cookie的方法来阻挡对“第三方请求的回应（见第8.2节）。如果用户代理没有整个忽略Set-cookie消息头字段，则必须解析Set-cookie消息头字段中的field-value并以其作为set-cookie-string（见以下定义）。注：与5.2中定义的语法相比，下述算法更自由。例如，该算法去除了在cookie名称和值的开头和结尾的空白分隔符（但仍然保留了内部的空白分隔符），而5.2中的语法禁止空白分隔符出现在上述位置。用户代理使用该算法，以便于那些未遵循第5节中规范的服务器交互。用户代理必须使用与下列算法等效的算法来解析set-coolkie-string：a）如果set-cookie-string包含%x3B（\；\），则：name-value-pair字符串包括直到（但并不包括）第一个%x3B（\\)的所有字符，而unparsed-attributes包括set-cookie-string的剩余字符（包括上文提到的%x3B(\；\)）。否则：
name-value-pair字符串包括set-cookie-string中的所有字符，而unparsed-attributes为空串。b）如果name-value-pair串缺少%x3D(\=\)字符，忽略整个set-cookie-string。c）名字串（可能为空）包括直到首个%x3D（\=\)的所有字符（但并不包括%x3D（\=\)本身），而值串（可能为空）包括首个%x3D(\=\)字符后的所有字符。d）从名串和值串中移除所有开头结尾的WSP（空白，“whitespace\）符号。e）如果名串是空的，忽略整个set-cookie-string。f）cookie-name是名串，cookie-value是值串。用户代理必须使用与下列算法等效的算法解析unparsed-attributes：a）如果unparsed-attributes为空，跳过余下的步骤。8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。