YD/T 2918-2015 超文本传输协议状态(Cookie)管理机制技术规范

YD/T 2918-2015 YD/T 2918-2015 Hypertext Transfer Protocol State (Cookie) Management Mechanism Technical Specification

行业标准-邮电通信 简体中文 现行 页数:24页 | 格式:PDF

基本信息

标准号
YD/T 2918-2015
标准类型
行业标准-邮电通信
标准状态
现行
中国标准分类号(CCS)
国际标准分类号(ICS)
发布日期
2015-07-14
实施日期
2015-10-01
发布单位/组织
工业和信息化部
归口单位
-
适用范围
-

发布历史

研制信息

起草单位:
起草人:
出版信息:
页数:24页 | 字数:- | 开本: -

内容描述

IC�35.100.70

L79Y口

中华人民共和国通信行业标准

丫D汀2918-2015

超文本传输协议状态(cookie)

管理机制技术规范���

TechnicalspecificationsofHTTPstate(cookie)HTTPstateofspecificationsTechnical

managementmechanismmanagement����

2015-07-14发布2015-10-01实施

中华人民共和国工1k和信息化部发布

丫D厅2918-2015

目次

前言·····················································································································⋯⋯n

引言·····················································································································⋯⋯m

1范围·····················································································································⋯⋯1

2规范性引用文件···················································································。··················⋯⋯1

3术语、定义和缩略语································································································⋯⋯1

3.1术语和定义···································································································⋯⋯1�

4概要·····················································································································⋯⋯

5服务器要求············································································································⋯⋯

5.1概述·................................................................................................................2��

5.2�Set-cookie............................................................................................................25.2�Set-cookie��

5.3一cookie...······································································································.....5��

6用户代理要求·..........................................................................................................6

6.1概��.................................................................................................................6��

6.2子模块算法···································································································⋯⋯6�

6.3�Set-cookie消息头·············································································⋯⋯:······⋯⋯8�

6.4存储模型······································································································⋯⋯10�

6.5�cookie消息头·.....................................................................................................12�

7实现注意事项······································································································⋯⋯13

7.1限制············································································································⋯⋯13��

7.2应用程序接口..........................................................................................13API)(�

7.3�IDNA依赖和迁移··························································································⋯⋯13�

8隐私问题············································································································⋯⋯14

8.1概述············································································································⋯⋯14��

8.2第三��cookie......................................................................................................14��

8.3用户控制······································································································⋯⋯14��

8.4过期日期·...........................................................................................................14��

附录A(资料性附录)安全考量·.........................................................................................15

附录B(资料性附录)样例·...............................................................................................18

参考文献·......................................................................................................................20

丫D厅2918-2015

ol1青

本标准按照GB/T1.1-2009给出的规则起草。��

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。��

本标准由中国通信标准化协会提出并归口。��

本标准起草单位:互联网域名系统北京市工程研究��中心有限公司、北龙中网(北京)科技有限责任

公司、中国互联网络信息中心、中国信息通信研究院。

本标准主要起草人:赵雅静、卢文哲、马迪、钱炜烁、毛��伟、沈烁、马军锋。

丫D厅2918-2015

己I雀.

JI����F=l

本标准对超文本传输协议(HTTP)的cookie和Set-cookie的头字段进行了技术规范��。HTTP月及务器可

以用这些头字段在HTTP用户代理上储存状态(称作cookies)。通过这种形式,服务器可以在通常是无

状态的HTTP协议上维护一个有状态的会话。尽管。ookie和Set-cookie头字段在互联网上被广泛使用,

cookies存在技术缺陷,本标准对其安全性和隐私性也进行了技术说明。

丫D厅2918-2015

超文本传输协议状态(cookie)管理机制技术规范

范围

本标准规定��了超文本传输协议(HTTP)的cookie和Set-cookie的头字段,详细定义了cookie的语法,

属性和字段要求、数据格式,并明确了cookie的作用域。

本标准适用于支持cookie功能的系统(包括客户端、服务器和用户代理��)。

2规范性引用文件

下列文件对于本文件的应用是必不可少��的。凡是注日期的引用文件,仅所注日期的版本适用于本文

件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。

IRFC1034域名一概念和设备ETF��

IETFRFC1123互联网主机需求一应用和支持RFCIETF��

I2616超文本传输协议一HTTP/1.1RFCETF��

ETFRFC3490应用中的国际化域名(IDNA)IRFCETF��

IETFRFC5234扩展M-M的语法规范:ABNFRFCIETF��

ETFRFC5890面向应用的国际化域名(IDNA):定义和规范框架RFCIETF��

IETFRFC6265超文本传输协议状态管理机制RFCIETF��

USASCII美国国家标准协议“编码字符集一7位美国标准信息交换码”,��1986X3.4,ANSI

3术语、定义和缩略语

3.,术语和定义

下列术语和定义适用于本文件��。

3.1.1

��客户端Client

用来建立连接、发送请求的一个程序[[IETF��26161.RFC

3.1.2

��用户代理AgentUser

用来发起请求的客户端,通常是浏览器、编辑器、蜘蛛或其他终端用户工具【IETF��26161.RFC

3.1.3

��服务器Server

用来响应服务请求、接受连接的应用程序。任何程序��可以是一个客户端也可以是一个服务��;任何

服务器可以作为原始服务器、代理、网关、或者隧道,根据每个请求的性质来决定【IETF2616].RFC

3.1.4

��原始服务器ServerOrigin

一个存储或产生资源的服务器〔IETF��26161.RFC

丫D厅2918-2015

3.1.5

��主机名TheRequest-Host

用户代理发送HTTP请求到或者从其收到HTTP回应的主机的名字【IETF��2616].RFC

3.1.6

��请求URI�Request-Uri

一种全球统一资源标识符,用于指定请求的资源[IETF��2616].RFC

3.1.7

��字符串

一列非空八位字节[IETF��26161.RFC

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消息头

字段的机制(如IETF2616所述)可能会改变Set-cookie头字段的语义,因为Set-cookie使用%x2CRFC(",")

字符的方法与这种方法冲突。

4i月及务器要求

5.1概述

本条描述了关于cookie和Set-cookie消息头的语法和语义概要。��

5.2Set-cookie

5.2.1语法

Set-cookie响应消息头��中包含了消息头的名字‘`Set-cookie",后跟一个“:’’和一个cookie。每个cookie都

以一个名/值对(name-value-pari)开头,后跟零个到多个属性/值对)。服务器在发送(attribute-value

Set-cookie消息头时应该遵循如下语法:

set-cookie-header="Set-cookie:"SPset-cookie-stringSPset-cookie-header="Set-cookie:"����

set-cookie-string=cookie-pair*(’丫,SPcookie-av)set-cookie-string=cookie-pair*(’丫,SP����

cookie-pair=cookie-name’一”cookie-value����

cookie-name=token�����

ookie-value=*cookie-octet/(DQUOTE*cookie-octetDQUOTE)*cookie-octetcookie-value=*cookie-octet/(DQUOTE����

cookie-octet=%x21/%x23-2B/%x2D-3A/%x3C-5B/�5D-7E�����

;除CTLs.������������

2

丫D厅2918-2015

;空白分隔符双引号、逗号、分号、����������

;和反斜杠以外的US-ASCII字符����������

token=<token,参见IETFRFC2616第2.2节>����

cookie-av=expires-av/max-age-av/domain-av/path-av/����

secure-av/httponly-av/extension-av����

e��Tres-av=’飞即ires="sane-cookie-date����

ane-cookie-date=<rfcl123-date,见IETFRFC2616,第3.3.1节>123-date,见IETFRFCsane-cookie-date=<rfcl����

max-age-av="Max-Age="non-zero-digit*DIGITnon-zero-digitmax-age-av="Max-Age="����

;在实际操作中�����������

;expires-av和max-age-av字段的取值�����������

;都被限制于用户代理所能表示的范围������������以内

non-zero-di颐t=%x31-39������������

;数字1到9�����������

domain-av="Domain="domain-valuedomain-av="Domain="����

domain-value=<subdomain>�����

;定义于IETFRFC1034第3.5节�����������

;改进于IETF1123第2.1节RFC�����������

path-av="Path="path-valuepath-av="Path="����

path-value=*<除CTLs和“;”以外的任意字符>path-value���

secure-av�Secure"�����

httponly-av="HttpOnly"����

extension-av=*<除CTLs和“;”以外的任意字符>=extension-av����

需要注意的是,规定了上面某些语法术语的标准使用了与本标准不��同的语法标注方式(本标准使用

的是IETFRFC5234定义的ABNF体系)。

cookie-value的语义在本标准中没有定义。��

为了兼容更广泛的用户代理,想要在cookie-value中存储任意数据的服务器需要对数据进行编码,例��

如,采��Base644648)RFC(IETF。

set-cookie-string中由cookie-av组成的部分通常被称为属性��。为了最广泛地兼容用户代理,服务器不

应该在同一个set-cookie-std吨中产生两个同名的属性(6.4讲解了用户代理对这种情况的处理)。

服务器不应该在同一个响应中向用户代理发送包含多个具有相同的cookie-name的Set-cookie消息头��

(6.3中讲解了用户代理是如何处理这种情况的)���

如果服务器同时向用户代理发送包��Set-cookie消息头��的多个响应(例如,当与用户代理的通讯在多

个套接字上并发进行时),这些响应会造成“竟争情况”,从而导致不可预测的行为.

由于一些现有的用户代理对用两位数表示的年的解释并不相同,为了避免兼容性的问题,服务器在��

上述各字段的定义中,如果用到日期,应该使用IETFRFC1123规定的日期格式。这种格式要求用四位数

字表示年。

丫D汀2918-2015

注1:一些用户代理将cookie中的数据作��为32位UNIXtime暄来存储和处理。在一些操作系统上支持timet处理的库中

的执行漏洞可能会导致这些用户代理在2038年后不能正确地处理日期。

5.2.2语义(非规范)

概述

5.2.2描述了Set-cookie消息头的简化语义。这些简化的语义有助于理解最常见的服务器cookie用法。��

完整的语义描述详见第6章。

当用户代理收到Set-cookie消息头时,用户代理存储其中的cookie及其属性。随后,当用户代理发出��

HTF清求时,用户代理将适用并未过期的cookie包括��cookie消息头中。

如果用户代理收到的新cooki。和它之前储存过的某个cookie有相同的cookie名((cookie-name)、域值��

(domain-value)和路径(path-value),则已存储的cookie会被驱逐并被新的。ookie替代。

需要注意的是,通过向用户代理发送过期日期为过去某一时间点的新cookie,服务器可以删除旧的��

cookieo

除非cookie的属性有其他定义��,cookie只能被返回到源服务器(而不是其它地方。例如,某个子域)。

此cookie会在当前会话结束时过期(由用户代理定义)。用户代理会忽略无法识别的cookie属性(但不是

整个cookie)。

5.2.2.2过期属性

过期属性通过定��义cookie过期的日期和时间来规��cookie的最长生命周期。然而,本标准并不强制要

求用户代理将该cookie保存到过期。实际上,因为存储压力或隐私原因,用户代理经常会驱逐cookieo

最大存活时间属性

最大存活时间属性通过规��定cookie经过多少秒才过期,来规定cookie的最长生命周期。然而,本标准

并不强制要求用户代理将��cookie保存指定的时长。实际上,因为存储压力或隐私原因,用户代理经常

会驱逐cookieo

注:当前有些��用户代理并不支持最大存活时间属性。这些用户代理会忽略这一属性。

如��cookie同时有最大存活时间属性和过期属性,最大存活时间属性优先控制cookie的过期日期。如��

果cookie既没有最大存活时间属性,也没有过期属性,用户代理会保��cookie直到“当前会话结束”(会话

结束时间由用户代理定义)。

域属性

域属性规定了cookie将被发送到哪些主机。例如,如果某个cookie的域属性值为“",那��

么当用户代理向,或者~.发出HTTP请求时,就会把该

cookie包括在cookie消息头里(注意:如果%x2E(’’.,’)出现在域属性值的开头,%x2Ee,’)将被忽略,尽管

它是不允许出现的字符;如果%x2E("")出现在域属性值的结尾,用户代理会忽略此域属性)如果服务器

省略了域属性,用户代理会仅��cookie返回到源服务器。

注意:当前有些用户代理将源服务器名作为缺省值来处理域属性省略的情况。例如,如果��

返回的Set-cookie消息头没有域属性,这些用户代理会错误地将域属性设置为默认值“,从而

导致将cookie也发送到.

丫D汀2918-2015

cookie的域属性必须包含源服务器,否则用户代理会拒绝��cookie。例如,如果cookie来自��

,用户代理会接受域属性值为’''.或“"的cook

定制服务

    相似标准推荐

    更多>