RFC2616------超⽂本传输协议HTTP1.1说明
本⽂档规定了互联⽹社区的标准组协议，并需要讨论和建议以便更加完善。请参考
“互联⽹官⽅协议标准”（STD 1）来了解本协议的标准化状态。本协议不限流传发布。
版权声明
Copyright （C） The Internet Society （1999）. All Rights Reserved.
摘要
超⽂本传输协议（HTTP）是⼀种为分布式，协作式的，超媒体信息系统。它是⼀种通⽤的，⽆
状态（stateless）的协议，除了应⽤于超⽂本传输外，它也可以应⽤于诸如名称服务器和分布
对象管理系统之类的系统，这可以通过扩展它的请求⽅法，错误代码和消息头[47]来实现。
HTTP的⼀个特性就是是数据表现形式是可以定义的和可协商性的，这就允许系统能独⽴于于
数据传输被构建。
HTTP 在1990 年WWW 全球信息刚刚起步的时候就得到了应⽤。本说明书详细阐述了
HTTP/1.1 协议，是RFC 2068的修订版[33]。
⽬录（略）
1 引论
1.1 ⽬的
超⽂本传输协议（HTTP）是⼀种为分布式的，协作的，超媒体信息系统，它是⾯向应⽤层的
协议。在1990年WWW全球信息刚刚起步的时候HTTP就得到了应⽤。HTTP的第⼀个版本叫做
HTTP/0.9，是⼀种为互联⽹原始数据传输服务的简单协议。由RFC 1945[6]定义的HTTP/1.0进⼀
步完善了这个协议。它允许消息以类MIME消息的格式传送，它包括传输数据的元信息和对请
求/响应语义的修饰。但是，HTTP/1.0没有充分考虑到分层代理，缓存的，以及持久连接和虚拟
主机的需求的影响。并且随着不完善的HTTP/1.0应⽤程序的激增，这就迫切需要⼀个新的版本，
以便能使两个通信程序能够确定彼此的真实能⼒。
此规范定义的协议叫做“HTTP/1.1”，.这个协议与HTTP/1.0相⽐，此规范更为严格，以确保
各个协议的特征得到可靠实现。
实际的信息系统除了简单的获取信息之外，还要求更多的功能，包括查（search），终端更
新（front-end update）和注解（annotation）。HTTP为请求提供可扩充⽅法集和消息头集
[47]。HTTP是建⽴在统⼀资源标识符（URI）[3]的约束上的，作为⼀个地址（URL）[4]或名称
（URN）[20]，以指定被⼀个⽅法使⽤的资源。消息以⼀种类似于互联⽹邮件[9]消息格式来传
输的，互联⽹消息格式定义于多⽬的互联⽹邮件扩展（MIME）[7]⾥。
HTTP也是⽤于⽤户代理（user agents）和其它互联⽹系统的代理/⽹关之间通信的通信协议，
这些互联⽹系统可能由SMTP[16],NNTP[13],FTP[18]，Gopher[2]和WAIS[10]协议⽀持。通过
这种⽅式，HTTP允许不同的应⽤程序对资源进⾏基本的超媒体访问。
1.2 要求
本⽂的关键词“必须”（ "MUST"）,，“不能”（"MUST NOT"），“需要”（
"REQUIRED"）， “应该”（"SHALL"），“不应该”（"SHALL NOT"），“应该”
（ "SHOULD" ） ， “ 不应该” （ "SHOULD NOT" ） ， “ 建议的” （
"RECOMMENDED"），“可能”（"MAY"）， 和“可选的”（ "OPTIONAL"）将由RFC
2119[34]解释。
⼀个应⽤程序如果不能满⾜协议提供的⼀个或多个MUST或REQUIRED等级的要求，是不符
合要求的。⼀个应⽤程序如果满⾜所有必须（MUST）或需要的（REQUIRED）等级以及所有
应该（SHOULD）等级的要求，则被称为⾮条件遵循（unconditionally compliant）的；若满
⾜所有必须（MUST）等级的要求但不能满⾜所有应该（SHOULD）等级的要求则被称为条件
遵循的（conditionally compliant）。
1.3 术语
本说明⽤到了若⼲术语，以表⽰HTTP通信中各参与者和对象扮演的不同⾓⾊。
连接（connection）
为通信⽽在两个程序间建⽴的传输层虚拟电路。
消息（message）
HTTP通信中的基本单元。它由⼀个结构化的⼋⽐特字节序列组成，与第4章定义的句法相匹
配，并通过连接得到传送。
请求（request）
⼀种HTTP请求消息，参看第5章的定义。
响应（response）
⼀种HTTP响应消息，参看第6章的定义。
资源（resource）
⼀种⽹络数据对象或服务，可以⽤第3.2节定义的URI指定。资源可以以多种表现⽅式（例如
多种语⾔，数据格式，⼤⼩和分辨率）或者根据其它⽅⾯⽽⽽不同的表现形式。
实体（entity）
实体是请求或响应的有效承载信息。⼀个实体包含元信息和内容，元信息以实体头域（entityheader field）形式表⽰，内容以消息主体（entity-body）形式表⽰。在第7章详述。
表现形式 （representation）
⼀个响应包含的实体是由内容协商（content negotiation）决定的。如第12章所述。有可能存在
⼀个特定的响应状态码对应多个表现形式。
内容协商（content negotiation）
当服务⼀个请求时选择资源的⼀种适当的表⽰形式的机制（mechanism），如第12节所述。任
何响应⾥实体的表现形式都是可协商的（包括错误响应）。
变量（variant）
在某个时刻，⼀个资源对应的表现形式（representation）可以有⼀个或多个（译注：⼀个
URI请求⼀个资源，但返回的是此资源对应的表现形式，这根据内容协商决定）。每个表现形
式（representation）被称作⼀个变量。 ‘变量’这个术语的使⽤并不意味着资源
（resource）是由内容协商决定的.。
客户端（client）
为发送请求建⽴连接的程序.。
⽤户代理（user agent）
初始化请求的客户端程序。常见的如浏览器，编辑器，蜘蛛（可⽹络穿越的机器⼈），或其他
的终端⽤户⼯具.
服务器（Server）
服务器是这样⼀个应⽤程序，它同意请求端的连接，并发送响应（response）。任何给定的程
序都有可能既做客户端⼜做服务器；我们使⽤这些术语是为了说明特定连接中应⽤程序所担当
的⾓⾊，⽽不是指通常意义上应⽤程序的能⼒。同样，任何服务器都可以基于每个请求的性质
扮演源服务器，代理，⽹关，或者隧道等⾓⾊之⼀。
源服务器（Origin server）
存在资源或者资源在其上被创建的服务器（server）被成为源服务器（origin server）。
代理（ Proxy）
代理是⼀个中间程序，它既可以担当客户端的⾓⾊也可以担当服务器的⾓⾊。代理代表客户端
向服务器发送请求。客户端的请求经过代理，会在代理内部得到服务或者经过⼀定的转换转⾄
其他服务器。⼀个代理必须能同时实现本规范中对客户端和服务器所作的要求。透明代理
（transparent proxy）需要代理认证和代理识别，⽽不修改请求或响应。⾮透明代理（nontransparent proxy）需修改请求或响应，以便为⽤户代理（user agent）提供附加服务，附加
服务包括组注释服务，媒体类型转换，协议简化，或者匿名过滤等。除⾮透明⾏为或⾮透明⾏
为经被显式地声明，否则，HTTP代理既是透明代理也是⾮透明代理。
⽹关（gateway）
⽹关其实是⼀个服务器，扮演着代表其它服务器为客户端提供服务的中间者。与代理（proxy）
不同，⽹关接收请求，仿佛它就是请求资源的源服务器。请求的客户端可能觉察不到它正在同
⽹关通信。
隧道（tunnel）
隧道也是⼀个中间程序，它⼀个在两个连接之间充当盲⽬中继（blind relay）的中间程序。⼀旦
隧道处于活动状态，它不能被认为是这次HTTP通信的参与者，虽然HTTP请求可能已经把它
初始化了。当两端的中继连接都关闭的时候，隧道不再存在。
缓存（cache）
缓存是程序响应消息的本地存储。缓存是⼀个⼦系统，控制消息的存储、获取和删除。缓存⾥存
放可缓存的响应（cacheable response）为的是减少对将来同样请求的响应时间和⽹络带宽消
耗。任⼀客户端或服务器都可能含有缓存，但缓存不能存在于⼀个充当隧道（tunnel）的服务器
⾥。
可缓存的（cacheable）
我们说响应（response）是可缓存的，如果这个响应可以被缓存（cache）保存其副本，为的
是能响应后续请求。确定HTTP响应的缓存能⼒（cacheability）在13节中有介绍。即使⼀个资
源（resourse）是可缓存的，也可能存在缓存是否能利⽤此缓存副本为某个特定请求的约束。
第⼀⼿的（first-hand）
如果⼀个响应直接从源服务器或经过若⼲代理（proxy），并且没有不必要的延时，最后到达
客户端，那么这个响应就是第⼀⼿的（first-hand）。
如果响应通过源服务器（origin server）验证是有效性（validity）的，那么这个响应也同样是 第⼀⼿的。
显式过期时间（explicit expiration time）
是源服务器认为实体（entity）在没有被进⼀步验证（validation）的情况下，缓存（cache）
不应该利⽤其去响应后续请求的时间（译注：也就是说，当响应的显式过期时间达到后，缓存
必须要对其缓存的副本进⾏重验证，否则就不能去利⽤此副本去响应后续请求）。
启发式过期时间（heuristic expiration time）
当没有显式过期时间（explicit expiration time）可利⽤时，由缓存指定过期时间.
年龄（age）
⼀个响应的年龄是从被源服务器发送或被源服务器成功验证到现在的时间。
保鲜寿命（freshness lifetime）
⼀个响应产⽣到过期之间的时间。
保鲜（Fresh）
如果⼀个响应的年龄还没有超过保鲜寿命（freshness lifetime），那么它就是保鲜的.。
陈旧（Stale）
⼀个响应的年龄已经超过了它的保鲜寿命（freshness lifetime），那么就是陈旧的.
语义透明（semantically transparent）
缓存（cache）可能会以⼀种语意透明（semantically transparent）的⽅式⼯作。这时，对于 ⼀个特定的响应，使⽤缓存既不会对请求客户端产⽣影响也不会对源服务器产⽣影响，缓存的
使⽤只是为了提⾼性能。当缓存（cache）具有语意透明时，客户端从缓存接收的响应跟直接从 源服务器接收的响应完全⼀致（除了使⽤hop-by-hop头域）。
验证器（Validator）
验证器其实是协议元素（例如：实体标签（entity tag）或最后修改时间（last-modified time） 等），这些协议元素被⽤于识别缓存⾥保存的副本（即缓存项）是否等价于源服务器的实体的
副本。
上游/下游（upstream/downstream）
上游和下游描述了消息的流动：所有消息都是从上游流到下游。
内向/外向（inbound/outbound）
内向和外向指的是消息的请求和响应路径：“内向”即“移向源服务器”，“外向”即“移向
⽤户代理（user agent）”。cacheable
1.4 总体操作
HTTP 协议是⼀种请求/响应型的协议。 客户端给服务器发送请求的格式是⼀个请求⽅法 （request method），URI，协议版本号，然后紧接着⼀个包含请求修饰符（modifiers），客 户端信息，和可能的消息主体的类MIME（MIME-like）消息。服务器对请求端发送响应的格式
是以⼀个状态⾏（status line），其后跟随⼀个包含服务器信息、实体元信息和可能的实体主体 内容的类MIME（MIME-like）的消息。其中状态⾏（status line）包含消息的协议版本号和⼀ 个成功或错误码。HTTP和MIME之间的关系如附录19.4节所阐述。
⼤部分的HTTP通信是由⽤户代理（user agent）发起的，由应⽤于⼀个源服务器资源的请求
构成。最简单的情形，这可以通过⽤户代理（UA）和源服务器（O）之间的单⼀连接（v）来实 现。
请求链（Request chain）-------------------------------------- ----------
⽤户代理（UA）----------------单⼀连接（v）--------------源服务器（O）
<----------------------------------------------------------响应链（response chain）
有可能在请求/响应链中出现⼀个或多个中间者（intermediares），这是⽐较复杂的情形。常见 的中间者（intermediares）有三种：代理（proxy），⽹关（gateway）和隧道（tunnel）。代 理（proxy）是⼀种转发代理（a forwarding agent），它接收绝对URI（absoulute url，相对 于相对url）请求，重写全部或部分消息，然后把格式化后的请求发送到URI指定的服务器上。
⽹关是⼀种接收代理（receiving agent），它充当⼀个在服务器之上的层（layer），必要时它 会把请求翻译成为下层服务器的协议。隧道不改变消息⽽充当两个连接之间的中继点；它⽤于
通信需要穿过中间者（如防⽕墙）甚⾄当中间者不能理解消息内容的时候。
请求链（request chain）----------------------------------------
UA-----v-----A-----v-----B-----v-----C------------v-----------------O
<----------------------------------------响应链（response chain）
上图显⽰了⽤户代理（user agent）和源服务器之间的三个中间者（A，B和C）。整条链的请
求或响应将会通过四个被隔离开的连接。这个不同点很重要，因为某些HTTP通信选项有可能
只能采⽤最近的⾮隧道邻接点的连接，有可能只采⽤链的端点（end-point），或者也有可能只 采⽤于链上所有连接。图表尽管是线性的，每个参与者可能忙于多个并发的通信。例如，B可以
接收来⾃不是A的许多客户端的请求，并且／或者可以把请求转发到不是C的服务器，与此同
时C正在处理A的请求。
通信中任何⾮隧道成员都可能会采⽤⼀个内部缓存（internal cache）来处理请求。如果沿着链
的成员有请求已缓存的响应，请求/响应链就会⼤⼤缩短。下图阐明了⼀个最终请求响应链，假
定B拥有⼀个来⾃于O（通过C）的以前请求响应的缓存副本，并且此请求的响应并未被UA
或A缓存。
请求链（request chain）---------->
UA-----v----------A-----v-----B-----C----O
<---------响应链 （response chain）
并不是所有的响应都能有效地缓存，⼀些请求可能含有修饰符（modifiers），这些修饰符对缓
存动作有特殊的要求。HTTP对缓存⾏为（behavior）和可缓存响应（cacheable responses）
的定义在第13章定义。
实际上，⽬前万维⽹上有多种被实践和部署的缓存和代理的体系结构和配置。这些系统包括节
省带宽的缓存代理（proxy cache）层次（hierarchies）系统，可以⼴播（broadcast）或多播 （multicast）缓存数据的系统，通过CD-ROM发布缓存数据⼦集的机构，等等。HTTP系统
（http system）会被应⽤于宽带连接的企业局域⽹中的协作，并且可以被⽤于PDAs进⾏低耗
⽆线断续连接访问。HTTP1.1的宗旨是为了⽀持各种各样的已经部署的配置，同时引进⼀种协
议结构，让它满⾜可以建⽴⾼可靠性的web应⽤程序，即使不能达到这种要求，也⾄少可以可
靠的定位故障。
HTTP通信通常发⽣在TCP/IP连接上。默认端⼝是TCP 80，不过其它端⼝也可以使⽤。但并不
排除HTTP协议会在其它协议之上被实现。HTTP仅仅期望的是⼀个可靠的传输（译注：HTTP
⼀般建⽴在传输层协议之上）；所以任何提供这种保证的协议都可以被使⽤；协议传输数据单
元（transport data unit）与HTTP/1.1请求和响应的消息结构之间的映象已经超出了本规范的
范围。
⼤部分HTTP/1.0 的实现都是对每个请求/响应交换（exchange）产⽣⼀个新的连接。⽽
HTTP/1.1中，⼀个连接可以⽤于⼀个或更多请求/响应交换，虽然连接可能会因为各种原因中
断（见第8.1节）。
2 符号习惯和⼀般语法
2.1 扩充的BNF（扩充的 巴科斯-诺尔范式）
本⽂档规定的所有机制都⽤两种⽅法描述：散⽂体（prose）和类似于RFC 822 的扩充
Backus-Naur Form（BNF）。要理解本规范，使⽤者需熟悉符号表⽰法。扩充BNF结构如下：
名字（name）=定义（definition）
名字（name）就是代表规则的名字，规则名⾥不能包含“<”和“>”，通过等号把规则名和规
则定义（definiation）分离开。空格只有在采⽤延续⾏缩进来指定跨度多于⼀⾏的规则定义的时
候才有意义。某些基本规则（basic rules）使⽤⼤写字母包含在规则定义⾥， 如
SP，LWS，HT，CRLF，DIGIT，ALPHA，等等。尖括号可以包含在规则定义⾥，只要它们的
存在有利于区分规则名的使⽤。
“字⾯⽂本”（“literal”）
字⾯⽂本（literal text）两边⽤引号。除⾮声明，字⾯⽂本⼤⼩写不敏感（译注：如，HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT ⾥的A，B,C，D等等都是字 ⾯⽂本（literal text））。
规则1 | 规则2
由竖线（“|”）分开的元素是可选的，例如，“yes | no”表⽰yes或no都是可接受的。
(规则1 规则2)
围在括号⾥的多个元素视作⼀个元素。所以，“(elem (foo | bar) elem)”符合的字符串是“elem foo elem”和“elem bar elem”。
*规则
前⾯的字符“*”表⽰重复。完整的形式是“<n>*<m>元素”，表⽰元素⾄少出现<n>次，⾄多出
现<m>次。默认值是0和⽆穷⼤，所以"*（元素）"允许任何数值，包括零；"1*元素"⾄少出现⼀ 次；"1*2element"允许出现⼀次或两次。
[规则]
⽅括号⾥是任选元素；“[foo bar]”相当于“*1（foo bar）”。
N 规则
特殊的重复：“<n>（元素）”与“<n>*<n>（元素）”等价；就是说，（元素）正好出现
<n>次。这样2DIGIT是⼀个两位数字，3ALPHA是⼀个由三个字符组成的字符串。
#规则
类似于“*”，结构“#”是⽤来定义⼀系列元素的。完整的形式是<n>#<m>元素，表⽰⾄少<n>个
元素，⾄多<m>个元素，元素之间被⼀个或多个逗号（“,”）以及可选的线性空⽩（LWS）隔
开了。这就使得表⽰列表这样的形式变得⾮常容易；像
(*LWS element *(*LWS ","*LWS element))
就可以表⽰为
1#element
⽆论在哪⾥使⽤这个结构，空元素都是允许的，但是不计⼊元素出现的次数。换句话说 ， “（element ）, , （element） ”是允许的，但是仅仅视为两个元素。因此，在⾄少需要⼀个
元素的地⽅，必须存在⾄少⼀个⾮空元素。默认值是0和⽆穷⼤，这样，“#element”允许任意 零个或多个元素；“1# element”需要⾄少⼀个；“1#2element”允许⼀个或两个元素。
注释（comment）
⽤分号引导注释。
隐含的*LWS
本规范所描述的语法是基于字（word-based）的。除⾮特别注明，线性空⽩（LWS）可以出现 在任何两个相邻字之间（标记（token）或引⽤字符串（quoted-string）），以及相邻字和间
隔符之间，但是这并没有改变对⼀个域的解释。任何两个标记（token）之间必须有⾄少⼀个分
割符，否则将会被理解为只是⼀个标记。
2.2基本规则 （basic rule）
下⾯的规则贯穿于本规范的全⽂，此规则描述了基本的解析结构。US-ASCII（美国信息交换标
准码）编码字符集是由ANSI X3.4-1986[21]定义的。
OCTET（字节） = <；任意⼋⽐特的数据序列>
CHAR = <；任意ASCII字符（ascii码值从 0到127的字节）>
UPALPHA = <；任意⼤写字母"A"..."Z">
LOALPHA = <；任意⼩写字母"a"..."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <；任意数字0，1，...9>
CTL = <；任意控制字符（ascii码值从0 到 31的字节）及删除键DEL（127>
CR = <US-ASCII CR, 回车（13）>
LF = <US-ASCII LF, 换⾏符（10）>
SP = <US-ASCII SP, 空格（32）>
HT = <US-ASCII HT, ⽔平制表 （9）>
<"> = <US-ASCII双引号（34）>
HTTP/1.1 将 CR LF 的序列定义为任何协议元素的⾏尾标志，但这个规定对实体主体
（endtity-body）除外（要求⽐较松的应⽤见附录19.3）。实体主体（entity-body）的⾏尾标志 是由其相应的媒体类型定义的，如3.7节所述。
CRLF = CR LF
HTTP/1.1 的消息头域值可以折叠成多⾏，但紧接着的被折叠⾏由空格（SP）或⽔平制表 （HT）折叠标记开始。所有的线性空⽩（LWS）包括被折叠⾏的折叠标记（空格SP或⽔平制
表键HT），具有同SP⼀样的语义。接收者在解析域值并且将消息转送到下游（downstream）
之前可能会将任何线性空⽩（LWS）替换成单个SP（空格）。
LWS = [CRLF] 1*(SP | HT)
下⾯的TEXT规则仅仅适⽤于头域内容和值的描述，不会被消息解释器解析。TEXT⾥的字可以
包含不仅仅是ISO-8859-1[22]⾥的字符集，也可以包含RFC 2047⾥规定的字符集。
TEXT = <；除CTLs以外的任意OCTET，但包括LWS>
⼀个CRLF只有作为HTTP消息头域延续的⼀部分时才在TEXT定义⾥使⽤。
⼗六进制数字字符⽤在多个协议元素（protocol element）⾥。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
许多HTTP/1.1的消息头域值是由LWS或特殊字符分隔的字构成的。这些特殊字符必须先被包
含在引⽤字符串（quoted string）⾥之后才能⽤于参数值（如3.6节定义）⾥。
token （标记） = 1*<；除CTLs与分割符以外的任意CHAR >
separators（分割符） = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
通过⽤圆括号括起来，注释（comment）可以包含在⼀些HTTP头域⾥。注释只能被包含在域
值定义⾥有“comment”的域⾥。在其他域⾥，圆括号被视作域值的⼀部分。
comment （注释）= "(" *(ctext | quoted-pair | comment )” )"

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。