Http1.1协议

中国协议分析网 http://www.cnpaf.net

Network Working Group(网络工作组) R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes(过时弃用）: 2068 J. Gettys
Category: Standards Track （类别:标准组） Compaq/W3C
J. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June 1999

超文本传输协议-HTTP/1.1

说明
本文档规定了互联网社区的标准组协议，并需要讨论和建议以便更加完善。请参考
“互联网官方协议标准”（STD 1）来了解本协议的标准化状态。本协议不限流传发布。

版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) http://www.cnpaf.net(2007). 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 相比，要求更为严格，以确保各项功
能得到可靠实现。

实际的信息系统除了简单的检索外，要求更多的功能性（functionality)，包括查找(search)，
前端更新(front-end update)和注解(annotation)。HTTP 允许可扩充的方法集和报头集以指示请
求的目的[47]。它是建立在统一资源标识符（URI）[3]提供的地址（URL）[4]和名字（URN）
上[20]，以指出方法应用于哪个资源的。消息以类似于一种叫做多用途网络邮件扩展（MIME）
[7] 的互联网邮件的格式传送。

HTTP 也是用于用户代理之间及代理/网关到其他网络系统的通用通信协议，这样的网络系统
可能由 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)
作为请求或应答的有效负荷而传输的信息.一个实体包含报头形式的维护信息和消息体形式
的内容,由第 7 节详述.

表示方法(Representation)
一个应答包含的实体是由内容协商决定的,如第 12 章所述.一个特定的应答状态所对应的表
示方法可能有多个.

内容协商(Content Negotiation)
为请求服务时选择适当表示方法的机制（mechanism),如第 12 节所述.任何应答里实体的表示
方法都是可协商的(包括出错应答).

变量（Variant)
在任何给定时刻,与一个资源对应的表示方法可以有一个或更多.每个表示方法称作一个变量.
使用变量这个术语并不必然意味着资源是由内容协商决定的.

客户机（Client）
为发送请求建立连接的程序.

用户代理(User agent)
初始化请求的客户端程序.常见的如浏览器,编辑器,蜘蛛(网络穿越机器人),或其他的终端用
户工具.

服务器(Server)
同意连接以便通过发回应答为请求提供服务的应用程序.任何给定的程序都有可以既做客户
端又做服务器;我们使用这些术语仅指特定连接中程序完成的任务,而不是指通常意义上程序
的性能.同样,任何服务器都可以基于每个请求的性质扮演原服务器,代理,网管,或者隧道等诸
角色之一。

原服务器（Origin server)
给定的资源驻留或创建的地方.

代理服务器（ Proxy）
一个既做服务器又做客户端的中介程序.,其用途是代表其他客户发送请求.请求在内部得到


服务,或者经过一定的翻译转至其他服务器.一个代理服务器必须能同时履行本说明中客户端
和服务器要求.“透明代理”（transparent proxy）是一种除了必需的验证和鉴定外不修改请求
或相应的代理.“非透明代理” （non-transparent proxy）是一种修改请求或应答以便为用户代理
提供附加服务的代理,附加服务包括类注释服务,媒体类型转换,协议简化,或者匿名滤除等.除
非经明确指出,HTTP 代理要求对两种代理都适用.

网关（gateway）
为其他服务器充当中介的服务器.与代理服务器不同,网关接收请求,仿佛它就是被请求资源
所在的原服务器;提出请求的客户可能觉察不到它正在同网关通信.
一个在两个连接之间充当盲目中继（blind relay)的中间程序.一旦有效,隧道便不再被认为是
HTTP 通信的用户,虽然隧道可能已经被 HTTP 请求初始化了.当两端的中继连接都关闭的时
候,隧道不再存在.

高速缓存（Cache）
一个程序应答信息的本地存储和控制此信息存储、检索和删除的子系统,一个高速缓冲存储
器存储应答为的是减少对将来同样请求的应答时间和网络带宽消耗,任一客户或服务器都可
能包含一个高速缓存,但高速缓存不能应用于一个充当隧道的服务器.

可缓存（Cacheable）
如果一个高速缓存允许存储应答信息的一份拷贝运用于应答后继请求的拷贝,一个应
答就是可缓存的.用来确定 HTTP 应答的缓存能力（cacheability）的规则在 13 节中有定义.
即使一个资源是可缓存的,也可能对一个高速缓存能否将缓存拷贝用于某特定请求存在附加
的约束.

直接（first-hand）
如果一个应答直接到来并且没有缘于原服务器,或若干代理服务器的不必要的延时,那么
这个应答就是直接的.如果它的有效性已经被原服务器直接认证,那么这个应答也同样是第一
手的.

明确终止时间（explicit expiration time）
原服务器预算一个实体在无需进一步确认的情况下不再被高速缓存返回的时间.

探索终止时间（heuristic expiration time）
当没有外在的终止时间可利用时, 由高速缓存所指定的终止时间.

年龄（Age）
一个应答的年龄是从它被发送,或被原服务器成功确认到现在的时间.

保鲜寿命（Freshness lifetime）
一个应答生成和过期之间的时间长度.

保鲜（Fresh）
如果一个应答的年龄还没有超过保鲜寿命,它就是保鲜的.


陈旧（Stale）
一个应答的年龄已经超过了它的保鲜寿命,就是陈旧的.

语义透明（semantically transparent）
当它的使用除了改善性能外既未影响请求客户机也未影响原服务器时, 高速缓存对于某特
定的应答就是工作于语义透明方式了.当高速缓存语义透明时,客户恰好收到与原服务器直接
处理请求后得到的应答（除了逐段转接的报头部分）完全相同的应答。

有效性判别器（Validator）
一个用来查找一个高速缓存记录是否是一个实体的等效拷贝的协议元素(例如,一个实体标
记（entity tag）或最终更改时间（Last-Modified time)).

上游/下游（upstream/downstream）
上游和下游描述了消息的流动:所有消息都从上游流到下游.

向内/向外（inbound/outbound）
向内和向外指的是消息的请求和应答路径:"向内"即"移向原服务器","向外"即"移向用户代理
".

1。4 总体操作

HTTP 协议是一种请求/应答协议。与主机建立连接后，客户以请求方法，URI 和协议版本
的形式向服务器发送请求，继以类 MIME 信息，其中包括请求修改，客户信息和可能的正
文内容。
服务器用包括消息协议版本和成功或错误代码的状态进行应答，继以包括服务器信息，实体
维护信息和可能的实体内容的类 MIME 消息。HTTP 和 MIME 之间的关系如附录 19.4 节所
阐述。

大部分的 HTTP 通信由用户代理引发，由应用到一些原服务器上资源的请求构成。最简单的
情形，可以经用户代理（UA）和原服务器（O）之间的单一连接（v）完成。请求链
------------------------>用户代理(UA)-------------------单一连接（v)-------------------原服务器（O）
<-----------------------应答链

当一个或一个以上的中介在请求/应答链中出现的时候，会出现更复杂的情形。常见的中介
形式有三种：代理，网关和隧道。代理是一种转送工具，它接收绝对形式的 URI 请求，重
写全部或部分消息，然后把重新格式化后的请求发送到 URI 确定的服务器上。网关是一种
接收工具，它充当其他服务器的上层，必要时将请求翻译为下层服务器的协议。隧道不改变
消息而充当两个连接之间的中继点；它用于通信需要穿过中介（如防火墙），甚至中介不能
理解信息内容的时候。
请求链 -------------------------------------->UA-----v-----A-----v-----B-----v-----C-----v-----O
<-------------------------------------应答链


上图显示了用户代理和原服务器之间的三个中介（A，B 和 C)。游历整条链的请求或应答消
息需通过四个独立的连接。这个特性很重要，因为某些 HTTP 通信选项只能应用于到最近的
非隧道邻居，链的终点的连接，或者沿着链的所有连接。图表尽管是线性的，每部分可能都
在忙于多路同时通信。例如，B 可以接收来自不同于 A 的许多客户的请求，并且／或者转
送到不同于 C 的服务器，与此同时，它还在处理 A 的请求。

任何非隧道的通信成员都可以使用内部的高速缓存来处理请求。高速缓存的作用是如果沿着
链的一个成员对请求采用了高速缓冲的应答，请求/应答链就会大大缩短。以下图解作为结
果产生的链，假定 B 拥有来自 O（通过 C）的一个从前应答的备份，请求尚未被 UA 或 A
缓存。
请求链---------->UA-----v----------A-----v-----B-----C----O <---------应答链

并不是所有的应答都能有效地缓存，一些请求可能含有修改量，对缓存动作有特殊的要求。
缓存动作和缓存应答的 HTTP 要求将在第 13 节定义。

实际上，目前万维网上有多种结构和配置的高速缓存和代理被实验或使用。这些系统包括节
省越洋带宽的全国代理层，广播或多点通信缓存接口，通过 CD-ROM 分配子缓存数据的机
构，等等。HTTP 系统应用在宽频带连接的企业局域网中，通过 PDAs 的低耗无线连接和断
续连接的访问。 HTTP1.1 的目标是支持各种各样的应用配置，引进协议结构满足那些需要较
高可靠性，可以排除故障或至少指示故障的网络应用的要求。

HTTP 通信在通常发生在 TCP/ＩＰ连接上。默认端口是 TCP 80,不过其它端口也可以使用。
在互联网或其他网络上，这并不妨碍 HTTP 应用在其他协议的顶端。http 仅仅期望可靠的传
输；任何提供这种保证的协议都可以使用；协议传输数据单元的 HTTP/1.1 请求和应答结构
的映象已经超出了本说明书的范围。

在 http/1.0 中，大部分的实现为每个请求/应答交换使用了新连接。而 http/1.1 中，一个连接
可以用于一个或更多请求/应答交换，虽然连接可能会因为各种原因中断（见第 8.1 节）。

2 符号惯例和一般语法

2．1 扩充 BNF

本文档规定的所有机制都用两种方法描述：散文体（prose)和类似于 RFC 822 的扩充
Backus-Naur Form(BNF)。要理解本说明书，使用者需熟悉符号表示法。扩充 BNF 包括下列
结构：

名字=定义
一条规则的名字仅仅是名字本身（没有任何"<"和">"）,跟等于号"="后面的定义是分离的。
仅当连续线的空格用来表示一条长于一行的规则时空白才是重要的。某些基本规则使用大写
字母，如 SP，LWS，HT，CRLF，DIGIT，ALPHA，等等。无论何时，只要它们的存在有
利于识别规则名字，就可以在定义的范围内使用角括号。


“文字”
文字原文使用引号。除特殊情况，原文对外界不敏感。

规则 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
无论在哪里使用这个结构，空元素都是元许的，但是不计入元素出现的次数。换句话说，“(元
素), , (元素) "是允许的，但是仅仅视为两个元素。因此，在至少需要一个元素的地方，必须
存在至少一个非空元素。默认值是 0 和无穷大，这样，“#element”允许任何数字，包括零；
“1#element”至少需要 1 个元素；“1#2element”允许 1 个或 2 个元素。

；注释
用分号引导的注释，从规则正文的右边一段距离开始直到行尾。这是做注释的简单方法，注
释与说明是同样有用的。

隐含 *LWS
本说明书所描述的语法是基于字的。除非特别注明，线性空白可出现在任何两个相邻字之间
（标记或引用字符串），以及相邻字和间隔符之间，并不改变一个域的含义。任何两个标记
之间（下面会对"token(标记)"进行定义）必须有至少一个分割符，否则将会被理解为单一标
记。


2．2 基本规则

下面的规则描述了基本的解析结构，贯穿于本说明书的全文。US-ASCII(美国信息交换标准
码)字符规定是由 ANSI X3.4-1986[21]定义的。

OCTET = <任意八比特的数据序列>
CHAR = <任意 ASCII 字符（八进制 0-127）>
UPALPHA = <任意大写字母"A"..."Z">
LOALPHA = <任意小写字母"a"..."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <任意数字 0，1，...9>
CTL = <任意控制字符(octets 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 的顺序定义为任何协议元素的行尾标志，除了报文以外（宽松应用见附
录 19.3）.报文内部的行尾标志是由它的关联媒体类型定义的，如 3.7 节所述。

CRLF = CR LF

如果延长线由空格或水平制表开始，HTTP/1.1 的报头域值可以折叠到到复合线上。所有的
线性空白，包括折叠，具有同 SP 一样的语义。接收者在解释域值或将消息转送到下游时可
以用单个 SP 替代任何线性空白。

LWS = [CRLF] 1*( SP | HT )

文本规则仅仅适用于描述域的内容和不会被消息语法分析程序解释的值。*TEST 的字可以
包含 ISO-8859-1[22]里的字符，也可以包含字符规定里的字符[14]。

TEXT = <除 CTLs 以外的任意 OCTET，但包括 LWS>

一个 CRLF 仅仅在作为报头域延续的一部分时才在 TEXT 定义里允许使用。

十六进制数字字符用在数个协议元素里。

HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT


许多 HTTP/1.1 的报头域值是由 LWS 或特殊字符分隔的字构成的。这些特殊字符必须包含
在引用字符串里，方可用在参数值（如 3.6 节定义）里。

token （标记） = 1*<除 CTLs 与分割符以外的任意 CHAR >
separators（分割符） = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT

用圆括号括起来的注释可以包含在一些 HTTP 报头域里。只有作为域值定义的一部分时注释
才是允许的。在其他域里，圆括号视作域值的一部分。

comment （注释）= "(" *( ctext | quoted-pair | comment ) ")"
ctext = <除"(" and ")"以外的任意 TEXT >

一个文本字符若在双引号里，则当作一个字。

quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <除<">以外的任意 TEXT >

反斜线("")可以用作单一字符引用结构，但仅在引用字符串或注释里。

quoted-pair = "" CHAR

3 协议参数

3.1 HTTP 版本

HTTP 使用"<主要>.<次要>"的编号方案表示协议版本。协议的版本方针是希望允许发送者
表示消息的格式和性能以便理解更深一层的 HTTP 通信，而不仅仅是当前通信获得的特征。
消息构件的增加不影响通信动作，或仅仅增加了扩展域值，版本号并没有因此变化。协议的
改变增加了一些特征，没有改变一般的消息解析规则，但是增加了消息的语义或者暗含了发
送者新增的性能，这时<次要>数字便要增大。当协议的消息格式改变时，<主要>数字增大。

HTTP 消息的版本在消息的第一行 HTTP-版本域里表示。

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT


注意主要和次要数字必须看作是两个分离的整数，二者都可以增加到比单位数还大。这样，
HTTP/2.4 的版本比 HTTP/2.3 低，依次 HTTP/2.3 的版本比 HTTP/12.3 低。首位的零必定被
接收者忽视，一定不要发送。

一个发送包含 HTTP 版本"HTTP/1.1"的请求或应答消息的应用，必须至少有条件的服从本说
明书。至少有条件服从本说明书的应用应该在消息里使用"HTTP/1.1"的 HTTP-版本，任何与
HTTP/1.0 不兼容的消息则必须这样做。关于何时发送特殊的 HTTP-版本值，更多资料请参
看
RFC 2145[36].

一项应用的 HTTP 版本是应用至少有条件服从的最高 HTTP 版本.

代理和网关转送的消息的协议版本与应用版本不同时，需要小心。既然协议版本表示发送者
的协议性能，代理/网关一定不能发送标示版本高于它本身的实际版本的消息。如果收到更
高版本的请求，代理/网关必须降低请求的版本，或者发出出错应答，或者切换到隧道动作。

由于自 RFC 2068[33]发布后发现的 HTTP/1.0 代理协同工作问题，高速缓存代理必须，网关
可以，隧道必须不将请求提升到它们支持的最高版本。代理/网关的应答的主要版本号必须
同请求相同。

注：HTTP 版本的转换可能会包含相关版本必需或禁止的头域修改。

3.2 统一资源标识符（URI）

URIs 的许多名字已为人所知：WWW 地址,通用文件标识符，通用资源标识符[3]，以及最后
统一资源定位器(URL)[4]和统一资源名称(URN)[20]的结合。只要与 HTTP 相关，统一资源
定位器只是格式化的字符串，它通过名称，地址，或任何别的特征确定了资源的位置。

3.2.1 一般语法

根据使用时的上下文，HTTP 里的 URI 可以表示成绝对形式或基于已知的 URI 的相对形式。
两种形式的区别是根据这样的事实：绝对 URI 总是以一个摘要名字作为开头，其后是一个
冒号。关于 URL 更详尽的信息请参看"统一资源标识符(URI):一般语法和语义",RFC 2396
[42](代替了 RFCs 1738 [4]和 RFC 1808 [11]).本说明书采用那份说明书里关于"URI-索引","绝
对 URI","相对 URI","端口","主机","绝对路径"和"权力"的定义.

HTTP 协议不对 URI 的长度作事先的限制.服务器必须能够处理它们服务的任何资源的 URI,
并且应该能够处理无限长度的 URI,如果它们提供可以产生这种 URI 的基于 GET 的形式.

注:服务器在依赖长于 255 字节的 URI 时应谨慎,因为一些旧的客户或代理实现可能不支持这
些长度.


3.2.2 http URL

http 方案通过 HTTP 协议定出网络资源的位置.本节定义了这种方案-http URL 特殊的语法和
语义.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

如果端口为空或未给出,就假定为 80.语义即:已识别的资源放在服务器上,在那台主机的那个
端口上监听 TCP 连接,对资源的请求的 URI 为绝对路径(5.1.2 节). 无论什么可能的时候,URL
里使用 IP 地址都是应该避免的(参看 RFC 1900 [24]).如果绝对地址没有出现在 URL 里,它用
作对资源的请求的 URI 时必须作为"/"给出.如果代理收到一个不是充分资格域名的主机名,
一定不能改变主机名.

3.2.3 URI 比较

当比较两个 URI 是否匹配时,客户应该对整个 URI 进行区分大小写,以八字节为单元的比较.
以下情况例外:

-一个为空或未给定的端口等同于那个 URI 索引里的默认端口;

-主机名的比较必须是不区分大小写的;

-方案名的比较必须是不区分大小写的;

-一个空绝对路径等同于绝对路径"/".

Characters other than those in the "reserved" and "unsafe" sets are equivalent to their ""%"
HEX HEX" encoding.
除了"保留"或"危险"集里的字符(参见 RFC 2396 [42]) ,字符等同于它们的""%" HEX HEX"编
码.

例如,以下三个 URI 是等同的:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

3.3 日期/时间格式

3.3.1 完整日期

历史上的 HTTP 应用一直允许三种不同的表示日期/时间印记的格式:


Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

第一种格式是作为 Internet 标准提出来的,它表示一个由 RFC 1123 [8](RFC 822[9]的升级版本)
定义的固定长度的子集.第二种格式使用比较普遍,但是基于废弃的 RFC 850 [12],需要(应该)
用四位数表示年份.对日期值进行语法分析的 HTTP/1.1 客户和服务器必须接受所有三种格式
(为了同 HTTP/1.0 兼容),虽然它们必须只产生 RFC 1123 格式以在头域里表示 HTTP 日期值.

注:鼓励日期值的接收者在接受可能由非 HTTP 应用发来的日期值时要坚定,这种非 HTTP 应
用有时是通过代理/网关到 SMTP 或 NNTP 检索或张贴消息.

所有的 HTTP 日期/时间印记都必须毫无例外的以格林威治平均时间(GMT)表示.为了
HTTP,GMT 完全等同于 UTC(协调世界时间).这在前两种形式里用三个字母的时区缩写
-GMT 的蕴含来表示,并且读取 ASC 时间格式时必须先被假定.HTTP 日期区分大小写,除了在
语法中作为 SP 特别包括的 LWS 外,一定不能包括额外的 LWS.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"

注意:HTTP 对日期/时间印记格式的请求仅仅应用在协议流里.客户和服务器不必为了用户简
报,请求记录及其他而使用这些格式.

3.3.2 Delta 秒

一些 HTTP 头域收到消息后,允许以十进制整数秒表示的时间值.
delta-seconds = 1*DIGIT


3.4 字符集

HTTP 使用的关于术语"字符集"的定义和 MIME 中所描述的一样.

本文档中的术语"字符集"指一种用一个或更多表格将一个八字节序列转换成一个字符序列
的方法.注意另一方向的无条件转换是不需要的,在这种转换里,并不是所有的字符都能在一
个给定字符集里得到,并且字符集可能提供多个八进制序列表示一个特定字符.这个定义将允
许各种字符编码方式,从简单的单表格映射如 US-ASCII 到复杂的表格交换方法如 ISO-2022
的技术里所使用的.然而,与 MIME 字符集名字相关联的定义必须充分说明从八字节变换到字
符所实现的映射.特别的,使用外部轮廓信息来决定精确映射是不允许的.

注:这里使用的术语"字符集"更一般的被称作一种"字符编码".不过既然 HTTP 和 MIME 使用
同样的注册表,共用术语是很重要的.

HTTP 字符集用不区分大小写的标记表示.完全标记集合由 IANA 字符集注册表[19]定义.
charset = token

尽管 HTTP 允许用任意标记作为字符集的值,任何在 IANA 字符集注册表里有预先确定值的
标记必须表示该注册表定义的字符集.对那些 IANA 定义的字符集,应用应该限制使用字符集.

实现者应该注意 IETF 字符集的要求[38][41].

3.4.1 失踪字符集

一些 HTTP/1.0 软件将没有字符集参数的内容类型头错误的理解为"接收者应该猜猜."若发送
者希望避免这种情况,可以包含一个字符集参数,即使字符集是 ISO-8859-1;当知道不会使接
收者混淆时,也应该这样做.

不幸的是,一些旧的 HTTP/1.0 不能适当处理详细的字符集参数.HTTP/1.1 接收者必须重视发
送者提供的字符集标注;当最初显示文档时，那些提供"猜"字符集服务的用户代理必须使用
内容类型域中的字符集，如果它们支持那个字符集，而不是接收者的首选项。参看 3.7.1 节。

3.5 内容编码

内容编码值表示一种已经或可以应用于实体的编码变换。内容编码主要用来允许文档压缩，
换句话说，有效的变换而不损失它的基本媒体类型的特性，也不丢失信息。经常地，实体以
编码形式储存,直接传送,只能由接收者译码.

content-coding = token

所有内容编码值都是不区分大小写的.HTTP/1.1 在接收译码(14.3 节)和内容译码(14.11 节)的
头域里使用内容编码值.尽管该值描述了内容编码,更重要的是它指出需要什么编码机制
来除去编码.


互联网赋值机构(IANA)充当内容编码值标记的注册处.最初,注册表包含下列标记:

gzip（压缩程序）
一种由文件压缩程序"gzip"(GNU zip)---如 RFC 1952 所描述---生成的编码格式.这种格式是一
种 32 位 CRC Lempel-Ziv 编码(LZ77). [译者注]CRC:循环冗余校验

compress（压缩）
由通用 UNIX 文件压缩程序"compress"生成的编码格式.这种格式是一种具有可适应性的
Lempel-Ziv-Welch 编码.
对未来的编码来说,用程序名识别编码格式是不可取,令人气馁的.在这里他们的用处是作为
历史实践的代表而不是好的方案.为了同以前的 HTTP 实现相兼容,应用应该将"x-gzip"和
"x-compress"分别等同于"gzip"和"compress".

deflate（缩小）　
RFC 1950 [31]定义的"zlib"格式与 RFC 1951 [29]描述的"deflate"压缩机制的组合.

Identity（标识）
缺省(标识)编码;无论如何,不进行转化的应用.这种内容译码仅被用于接受译码报头,并且
不能被用在内容编码报头.

新的内容译码值的标记应该注册;为了允许客户和服务器间的互用性,内容译码运算的规范
需要实现一个可被公开利用并能独立实现的新值,并且与这节中内容译码定义的目的相一致.

3.6 传输编码

传输编码值被用来表示一个已经,能够,或可能需要应用于一个实体的编码转化,为的是能
够确保通过网络安全传输.这不同于内容译码,传输译码是消息的特性而不是原始实体的特性.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )

参数采用属性/值对的形式.

参数 = 属性 "=" 值
属性 = 标记
值 = 标记 | 引用-串（quoted-string）

所有传输译码值是不直观的.HTTP/1.1 在 TE 头域(14.39 节)和传输译码头域(14.41 节)运用
传输译码.

无论何时一个传输译码都被应用于一个消息体,传输译码的设置必须包括"大块",除非消息
被结束连接停止.当"大块"传输译码被应用时,它必须是应用于消息体的最后传输译码.这些
规则允许接受从而确定消息的传输长度(4.4 节)


传输译码与 MINE[7]的内容传输译码值相类似,它被定义能够实现传送服务器超过 7 位的
二进制数据的安全传输.不过,安全传输对纯 8 位传输协议有不同的焦点.在 HTTP 中,消息体唯
一不安全的特性是确定确切的体的长度的这个难点(7.2.2 节),或在共享传输上加密的要求.

网络分配数字权威(IANA)担任了传输译码值标记注册处的角色.起初,注册包含如下标记:"
大块"(3.6.1 节),"身份"(3.6.2 节),"gzip"(3.5 节),"压缩"(3.5 节),和"缩小"(3.5 节).

新的传输译码值标记应和新的内容译码值标记以相同的方式注册(3.5 节).

服务器接收到一个不能理解的传输译码实体时应返回 501(不实现),并且切断联系.服务器不
能向 HTTP/1.0 客户发送传输译码.

3.6.1 成块传输代码（Chunked Transfer Coding）

成块编码更改消息主体,为的是将它以一系列大块的形式传送,每一个连同它自己尺寸的指
示器,被一个包含实体头域的可随意选择的 trailer 跟随.这允许有力量的地生产同接受所必需
的消息一起转化的内容,从而检验它已经获得全部消息.
Chunked-Body = *chunk(大块)
大块-正文 last-chunk(最后-大块)
trailer(追踪者)
CRLF

chunk = chunk-size [ chunk-extension ] CRLF
大块 = 大块-尺寸 [ 大块 -扩展]CRLF
chunk-data CRLF
大块-数据 CRLF
chunk-size = 1*HEX
大块数据
last-chunk = 1*("0") [ chunk-extension ] CRLF
最后-大块 = 1*("0") [大块-扩展]CRLF

chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
大块-扩展大块-外部-名称大块-外部-值
chunk-ext-name = token
大块-外部-名称= 标记
chunk-ext-val = token | quoted-string
大块-外部-值 = 标记 | 引用-串
chunk-data = chunk-size(OCTET)
大块-数据 = 大块 -尺寸(八位子节)
trailer = *(entity-header CRLF)
追踪者 = * (实体-领先 CRLF)

大块尺寸域是用 16 进制表示大块尺寸的一串数字.成块编码以任一尺寸为 0 的大块结束,
后缀以 trailer,以一个空行终止.


trailer 允许发送者在消息末尾包含附加的 HTTP 头域.trailer 头域可被应用于简要说明包含
trailer 的头域 (14.40 节)

一个服务器在应答中运用传输译码时不能在任何头域使用 trailer,除非以下至少一条为真:
a) 请求包括一个 TE 头域时表明"trailer"在应答的转移译码中是可被接受的,就像
14.39 节中描述的那样;或者
b) 服务器是为了应答的原始服务器,trailer 的域完全由随意的元数据构成,这个接收者可以
在不接受这个元数据的情况下使用消息(在一个原始服务器可接受的方式中).另一方面,原始
服务器愿意接受 trailer 域可能会在通往客户的通道上被默默放弃的这种可能性.

当消息被一个 HTTP/1.1 代理人接受并且 8 转寄至一个 HTTP/1.0 接受器时,这种需求防止
了一个互用性的失误.它避免了一个依据协议将使在代理者上安置一个可能无限大的缓冲器
成为必要的情形发生.

对一个大块主体进行解码处理的例子已在附录 19.4.6 中作过介绍

所有 HTTP/1.1 应用程序必须能接受和解码"大块"传输译码,并且必须忽略它们不理解的大
块扩展扩展名.

3.7 媒体类型

为了提供公开的,可扩展的数据输入和规范流通,HTTP 在目录类型(14.17 节)和认可(14.1 节)
头域中运用网络媒体类型.

媒体类型 = 类型 "/" 亚类型*(";" 参数 )
类型 = 标记
亚类型 = 标记

参数可能在属性/值的形式上遵循类型/亚类型.(如 3.6 节定义)

类型,亚类型,和参数属性名称是不直观的.参数值直观与否,取决于参数名称的意义.
线性的白色空间(LWS)不能被用于类型和亚类型之间,也不能用于一种属性及他的值之间.一
个参数存在与否对媒体类型的处理有着重要的意义,取决于它在媒体类型注册中的定义.

注意一些旧的 HTTP 应用软件不能识别媒体类型参数.向一个旧的 HTTP 应用软件传送数据
时,只有当类型/亚类型精确度需要时,才能实现媒体类型参数.

媒体类型值已经在网络分配数码权威(IANA[19])注册.媒体类型的注册程序在 RFC
1590[17]中略述.使用未经注册的媒体类型是不会得心应手的.

3.7.1 规范化和原文缺省

网络媒体类型以语言的语音典型形式注册.一个通过 HTTP 通讯传输的实体必须被以先于


传送的适当的规范的形式描绘,除'text'类形以外,就像下段定义的那样.

当在规范的形式中,'text'类型的媒体亚类型运用 GRLF 作为全文行的间断.HTTP 放松了这
个要求,当一个完整实体被间断完成时,允许全文媒体以简单的 GR 或 LF 独立作为一行的隔
断的传输. 在通过 HTTP 承认的原文媒体中,作为一个行的间断的代表,HTTP 应用程序必须
接受 CRLF,空的 CR,和空的 LF. 而且,如果原文在一个特性设置中被表现,没有分别用 8 位字
节 13 和 10 表示 CR 和 LF,就像某种多重字节特性设置,HTTP 允许使用任何被为了表现 CR
和 LF 在行间断中的等同的特性设置所定义的任何 8 位字节次序.这个关于行间断的伸缩性仅
仅应用于再一个实体中的原文媒体;一个空的 CR 或 LF 在任意 HTTP 控制的结构中都不能代
替 CRLF.(例如头域和多部边界)

如果一个实体把一个目录译码译成电码,在下面的译码必须被定义成在上面先被译码的形
式.

"charset"参数和一些媒体类型一起使用用来定义数据的特性设置(3.4 节).当发送者没有提
供清楚的 charset 参数,通过 HTTP 接受时"text"类型的媒体类型就被定义成有一个为
"ISO-8859-1"的默认 charset 值.特性设置的数据不同于"ISO-8859-1"或它的子集必须被标以适
当的 charset 值. 参见 3.4.1 节中兼容性问题.

3.7.2 多部分类型（Multipart type)

MIME 提供了一系列"多重部分"类型---在单个消息体内一个或多个实体的包装.所有的多
重部分类型共享一个公共的序列,就像 RFC 2046 的 5.1.1 节中定义的那样.
必须包括一个作为媒体类型值一部分的边界参数.这个消息体自成为一个要素协议,因此在
两部分间只能用 CRLF 来表现行的间断.不同于 RFC 2046,任一多重消息的末尾必须为
空;HTTP 应用程序不能传送末尾(即使原始的多重部分包含一个末尾).存在这些制约为的是
保护一个多重部分消息实体的固有本质,结束多重部分边界已经在消息体的"结尾"加以表明.

通常,HTTP 将一个消息体视为与任何其他媒体类型无异:严格如有效负载.当消息体出现在
206 应答时,有一个例外就是"多重部分/字符串"类型(附录 19.2),将会被一些 HTTP 隐藏装置打
断,就像 13.5.4 和 14.16 节中描述的那样.除此情况外,一个 HTTP 用户代理应该遵循与一个
MINE 用户代理相同或相似的行为,在多重部分类型收据之上.MIME 头域在一个多重部分消
息体的每一个部分里,对超过 MIME 意义的定义的 HTTP 没有任何意义.

通常, 一个 HTTP 用户代理应该遵循与一个 MINE 用户代理相同或相似的行为,在多重部分
类型收据之上.如果一个应用程序收到一个不能识别的多重部分亚类型,这个应用程序必须将
它视为与"多重部分/混合"相等.

注:"多重部分/形态-数据"形式已被在适合于通过 POST 请求方法处理的传送形式数据明确
定义,就像在 RFC 1867[15]中描述的那样.

3.8 产品标记

产品标记被用来承认通过软件名和译本识别它们自己的通讯应用软件.很多域还把产品标


记用于认可次级产品,专业产品构成应用软件中有重要意义的部分被一一列出,用白色间隔分
开.按照惯例,按产品对于识别应用软件的重要性的顺序列出它们.

产品 = 标示 ["/" 产品 -版本]
产品-版本 = 标示

例:
用户-代理: CERN-LineMode/2.15 libwww/2.17b3
服务器: Apache/0.8.4
产品标示应言简意赅.它们不能用来做广告或其他不重要的信息.虽然任一标示可能出现在
产品-版本上,但这个标示仅能被用来做一个版本标识(i.e., 同类产品中成功的版仅区别在产
品值的产品版本部分）

3.9 质量值(Quality Values)

HTTP 内容流通(12 节)运用简短的"浮点"数字来表明不同可流通参数之间的重要联系("重要
性").一个重要性从 0 到 1 规格化了一个真实的数字,0 是最小值,是最大值.如果一个参数为 0
的质量值,那么这个参数的内容不被客户接受.HTTP/1.1 应用软件不能产生多于小数点后三
位数字.这些值的用户配置也应受限于这种方式.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )

"质量值" 是一个不当的用词,因为这些值仅仅表现想要得到的质量中的降级关系.

3.10 语言标记

一个语言标记和自然的语言一样说,写,或被人类用于与其他人传递信息.计算机语言明显
不包括在内.HTTP 在认可语言和目录语言域内运用语言标记.

HTTP 语言标记的语法和注册像 RFC 1766[1]中定义的一样.总之,一个语言标记是由一部
分或多部分构成:一个主要语言标记和可能为空的一系列下标签.

语言标记 = 主要标记 *("_" 下标签)
主要标记 = 1*8ALPHA

下标签 = 1*8ALPHA

标签中不允许出现空格，标签对个例不敏感（case-insensitive）.由 IANA 来管理语言标
记中的名字间隔.典型的标签包括:

en, en-US, en-cockney, i-cherokee, x-pig-latin

任何两个字母的主要标签是一个 ISO-639 语言的缩写,两个大写字母的下标签是一个
ISO-3166 的国家代码.(上面的最后三个标签是未经注册的标签;除最后一个之外所有都是可


在将来注册的例子标签).

3.11 实体标签

实体标签用来从相同请求资源中比较两个或更多实体 .HTTP/1.1 在 Etag(14.19
节),If-match(14.24 节),If-None-match(14.26 节),和 If-rang(14.27 节)头域中运用实体标签.关于
它们怎样像高速缓冲存储器确认一样使用和比较的解释在 13.3.3 节中.一个实体标签由一个
给定的不透明的一行组成,可能加上一个虚弱指示器的前缀.

entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string

一个"坚固的(strong)实体标签"在两个实体八位子节相等时可能会被一个资源里的两个实
体共享.

一个"虚弱(weak)的实体标签",由"W/"前缀表示,在实体相等且可以互相替代而在语义上不
发生重大的变动时,可能会被一个资源力的两个实体共享.一个虚弱的实体标签只能在虚弱对
比时使用.

一个实体标签必须在所有与一个特殊资源相连系实体的译本中是独一无二的.一个给定的
实体标签值可以被不同的 URI 请求用来获得实体.相同实体标签值在不同 URI 请求获得实体
的联合中的运用不意味着那些实体的等同.

3.12 范围单位(Range Units)

HTTP/1.1 允许一个客户要求单独部分的应答实体被包括在应答内.HTTP/1.1 在范围
(14.35 节)和目录范围头域(14.16 节)运用范围单位.一个实体可根据不同的结构单位分解成子
区域.

范围-单位 = 字节-单位 | 其他-范围-单位
字节-单位 = "字节"
其他-范围-单位 = 标记

HTTP/1.1 中定义的唯一的范围单位是"字节".HTTP/1.1 实现时可能忽略其他单位指定的范
围。
HTTP/1.1 的设计允许应用软件不依靠有关范围的知识而实现

4 HTTP 消息


4.1 消息类型


HTTP 消息由从客户到服务器的请求和从服务器到客户的回答组成.
HTTP-消息 = 请求|回答 ;HTTP/1.1 消息
请求(第五节)和回答(第六节)的消息是用一般的消息格式 RFC 822[9]来传输实体的(消
息的有效载荷).这两种消息都是由开始行,零或者更多的头域(也叫做头),象征头结束的空行
(譬如说一个只有回车字符的行)组成,有时可能会有一个信息体.
一般的消息=开始行
*(消息头 CRLF)
CRLF
[消息的内容]
开始行 =请求行|状态行
为了健壮性,服务器必须在期望收到要求行的地方忽略任何接收到的空行.换句话说,如
果服务器在读一条信息开始的协议流时先收到了 CRLF,它必须忽略这个 CRLF.
一般一个有问题的 HTTP/1.0 客户端在 POST 请求后会产生额外的 CRLF.为了重述什么
是 BNF 明确禁止的,一个 HTTP/1.1 客户端没有必要开始和跟随一个额外的 CRLF 的请求.

4.2 消息头
HTTP 头域包括常规头(4.5 节)请求头(5.3 节),应答头(6.2 节)和实体头(7.1 节)域,它们遵循
RFC822[0]3.1 节中给出的同一个常规的格式.每一个头域由一个紧跟":"的名字和域值构成.域
名是大小写不敏感的.域值可能在任何 LWS 的前面,尽管单个的 SP 是首先的.头域能通过把各
个额外行(至少有一个 SP 或 HT)前置来扩展成多行.当产生 HTTP 结构的时,应用必须遵循"
共同格式",那儿它被知道或定义,即使有时存在一些不能接受任何东西的操作.

共同的格式.

消息-头=域名":"[域值]
域名=记号
域值=*(域的内容|LWS)
域的内容=<由八位的字节构成域值,它由文本或组合标记,分割符,和引用的字符串组成>

这个域的内容不包括任何引导的或连接的 LWS:位于域内容属性的第一个不是空白的地方的
前面或最厚的布是空白的地方的后面.去掉这些引导或连接的 LWS 可能不会影响域内容的意
思,任何位于域内容之间的 LWS 在解释域的内容或传送消息的下载流的时候可以用单个的
SP 替换.
用不同域名收到的头域的顺序不是重要的.但是,一个好的习惯是先送常规头,接着是请求头
或应答头,最后是实体头域.

多个消息头域使用同一个域可能会出现在一些消息中,在这些消息中,可能也只可能是整个域
用逗号分割的列表定义(例如,#(值)).这些必须有可能在没有改变消息的情况下被组合成一个
"域名:域值"对,在这些被逗号隔开的域中后面的域植被添加到第一个域中.那些用同一个域
名组成一个头域的顺序是重要的,因此当一个消息在传输的时候代理一定不能改变这些域值
的顺序.

4.3 消息体


HTTP 消息的消息体备用用来传输由要求和应答组成的实体.这些消息体仅仅当传输译码被
应用的时候才和实体不同,这用传输编码的头域标明(14.41 节).

消息体=实体|<编码的实体>

传输编码常用来表示那些应用程序为了安全和保证消息的正确传输的传输码.传输编码是一
种消息的属性而不是实体,因此沿着请求/应答链它可以被任何应用程序加上或去掉.

当一个消息中允许有消息体时的规则和请求应答时的不一样.

一个请求的消息体是用来传达内容长度或请求传输编码头的传输编码头域的信息.如果请
求方式的规范不允许请求中加入实体则一个请求中也必须不能包括消息体.一个服务器必须
读和处理任何请求的消息体;如果请求方法没有定义一个实体的表述,则当处理这个请求是必
须忽略消息体.

对于应答消息,一个消息是否包括消息体依赖于请求的方法和应答的状态代码(6.1.1 节).对
于所有头请求方法的应答都不能包括消息体,即使有时实体头域的存在让人相信它们包括了.
所有 1XX(信息的),204(无内容的),和 304(没有修改的)的应答都不能包括消息体.所有其他的
应答必须包括消息体,虽然它可能长度为零.

4.4 消息的长度

一条消息的传输长度是消息体出现在消息中的长度,也就是说,当传输代码被处理以后.当
一条消息包含消息体,实体的输长度有以下几条决定(以先后顺序):

1。任何回应信息不应包含在信息体中，如 1xx，204,304 回应和任何对头请求的回应。
这种情况都是在头域结束后第一行为空白行,不管实体域是否出现。

2。传输代码头域(属于 general-header 域)出现的话而且有值而不是身份，那么传输长度
就可以使用 chunked 大块来确定，除非信息由于连接关闭而中断了.

3。如果 Content-Length 头域(属于实体头)出现，那么它的值是信息体传输长度。如果传
输头域和 Content-Length 头域都出现了，而长度不一致，那么 Content-Length 头域中的值就
不该传。

4。如果被 1.0 代理传送的范围头域不能理解多部份/位范围；服务器必须采用 1，2，3
的方式界定信息体长度。

5。当服务器正在关闭连接.(正在关闭连接不能用来说明应答体的结束,因为它将导致服务
器没有可能送回一个应答信号.)

为了与 HTTP/1.0 应用程序兼容,HTTP/1.1 请求包含的消息体必须包括一个有效内容长度的
头域,除非知道服务器适应 HTTP/1.1.如果一个请求包含一个消息体并没有给出内容长度,那


个服务器会应答 400(错误的请求)如果他不能判断消息长度的话,或者应答 411(要求成都)如
果它坚持想要收到一个有效内容的长度.

所有的 HTTP/1.1 应用程序必须接受"CHUNKED"传输代码(3.6 节),因此允许这种机制来处理
消息当消息的程度不能被决定.

消息没有必要都不包括内容长度头域和 non-identity 传输代码 . 如果消息包括了一个
non-identity 传输代码,传输长度必须忽略.

当一个内容的长度在消息体允许的地方给出时,这个域值必须和消息体中八进制数一
致.HTTP/1.1 用户代理必须通报使用者当一个无效的长度被接受和发现.

4.5 常规头域

这儿有一些头域能适应一般的请求和应答消息,但是它没有应用渔船树种的实体.这些头域
只应用于那些被发射的消息.

常规的头域=高速缓存控制 ;14.9 节
|连接 ;14.10 节
|数据 ;14.18 节
|程序 ;14.32 节
|追踪 ;14.40 节
|传输编码 ;14.41 节
|升级 ;14.42 节
|路由 ;14.45 节
警告 ;14.46 节

常规头域的名字的真正扩展必须和协议版本的变化相结合。然而，新的或实验性质的头域
可能被赋予常规头域的意义，如果信息传输中的所有部分都承认它们为常规头域的话，未被
承认的头于一般当实体头域看待。

5 请求

从客户机到服务器的请求,其首行包括利用资源的方式,区分资源的标识,以及协议的版本号
请求 =请求行 ; 5.1 节
*((常规报头 ; 4.5 节
|请求报头 ; 5.3 节
实体报头)CRLF) ; 7.1 节
CRLF
[消息正文] ; 4.3 节

5.1 请求行


请求-行的开头是方法标识,接下来是请求 URL 和协议版本号,以回车换行结束.各部分之间
用空格符(SP)分隔,除了最后的回车换行外,不允许有回车(CR)和换行(LF).

请求-行 ==方式(空格) 请求 URI(空格) HTTP 版本号(回车换行)

5.1.1 方法

方法标记指的是在请求 URI 所指定的资源上所实现的方式,这种方式是条件敏感的

Method = "OPTIONS" ;9.2 节
| "GET" ;9.3 节
| "HEAD" ;9.4 节
|"POST" ;9.5 节
|"PUT" ;9.6 节
|"DELETE" ;9.7 节
|"TRACE" ;9.8 节
|"CONNECT" ;9.9 节
| 扩展方式(extension-method)

扩展方式= 标记

资源允许的方法列表能由允许(Allow)报头域详细指定．既然被允许方法的设置可以动态的
改变,返回的应答码总是通知客户机当前方法是否被允许.如果原服务器知道方法，但方法不
被请求的资源允许，原服务器应当返回状态码 405(方法不允许)．如果方法不被原服务器承
认和实现,原服务器应当返回状态码 501(没有实现）.获取(GET)和报头(HEAD)方法应当被所
有的多功能服务器支持．其他所有的方法是可选的，然而，假若以上的方法没有实现，则他
们必须被在第九章里所说明的同一种语法定义所实现．

5.1.2 请求 URL

请求 URL 是一种全球统一的应用于资源请求的资源标识符（３.2 节）．

请求 URL ="*"|绝对 URL|绝对路径|主机 authotity

请求 URI 的四个选项在一般情况下是互相关联的,星号"*"表示请求不是应用于某种特别的资
源,而是服务器本身,只有当所用的方法不是资源必要的方法才是允许的.举例如下

选项(OPTIONS)*HTTP/1.1

当代理服务器产生请求时，绝对 URI 地址是不可缺少的．代理服务器被要求转寄来自高速
缓冲存储器有效的请求或服务,返回应答．注意到代理服务器可以把请求转发给另一台代理
服务器或直接转发给绝对 URI 地址说明的服务器．为了避免请求循环，代理服务器必须识
别所有的服务器名字，包括任何别名，本地变异名，数字 IP 地址．请求行举例如下：


ＧET http://www.w3.org/pub/www/TheProject.html HTTP/1.1

为了在未来的 HTTP 版本的所有请求中转换绝对 URL 地址，所有基于ＨTTP/1.1 的服务器
必须接受绝对 URL 地址的组成，虽然基于 HTTP/1.1 的客户机将只产生请求发给代理服务器

主机(authority)组成部分只是在连接方法(CONNECT)中用到（９.9 节）．

最通用形式的请求ＵＲI 用于标识在原服务器或网关上的资源.这种情况下，绝对ＵＲＬ路径
必须作为请求ＵＲＬ传送（看３.２.１节，绝对路径），ＵＲＩ局域网地址(authority)(必须输
入主机报头域．例如，希望直接得到原服务器顶层资源的客户机将在"ｗｗｗ．ｗ３．ｏｒ
ｇ"主机的端口８０建立ＴＣＰ连接发送以下行：

GET /pub/WWW/TheProject.html HTTP/1.1
Host:www.w3.org

接下来是请求的其他部分，注意绝对路径不能是空的；假如没有初始的 URI，必须给出"／"
（服务器根目录）．

请求ＵＲＬ用在 3.2.1 节里说明的格式传输．如果用"%HEX HEX"[42]码编码,为了正确的
翻译请求，原服务器必须译码．对于有适当状态码的无效的请求，服务器必须给予应答．

当透明的代理服务器转发收到的请求ＵＲＬ地址给下一台网内的服务器时，禁止其重写 "
绝对路径"部分,上面提到的用"／"代替空的绝对地址不在此例．

注：当原服务器不恰当的用非保留ＵＲＬ字符作保留用时，"禁止重写"规则防止
代理服务器更改请求的含义，实现程序将了解前面的一些 HTTP/1.1 代理服务器就将知道改
写了请求ＵＲＩ．

5.2 请求定义的资源

一个 INTERNET 请求所定义的精确资源由请求 URL 和主机报头域所决定.

当决定 HTTP/1.1 协议标识的资源时，不允许资源与请求主机不同的原服务器可以忽略主机
报头域的值，（但看１９.６.１节了解支持 HTTP/1.1 主机上的另一种需求）.

基于主机的请求区分资源的服务器(有时指虚拟的主机或空白的主机名)必须用以下的规则
决定 HTTP/1.1 请求所请求的资源．

１．如果请求 URI 是绝对地址，主机是请求 URI 的一部分．任何主机报头域应当忽略．
２．假如请求 URI 不是绝对地址，且请求包括一个主机报头域，则主机由该域的值所决定．
３．假如由规定１或规定２定义的主机是无效的主机，则应答当是一个 400 出错信息

为了找出真正被请求的资源，一个缺乏主机标识域的 HTTP/1.0 请求接收者可以尝试使用试
探的方法（例如检测ＵＲＩ路径对于特定的主机是唯一的这个性质）．


空格符隔开，除了最后的回车或换行外，中间不允许有回车换行．

状态行＝ HTTP 版本 SP 状态码 SP 原因短语 CRLF

6.1.1 状态码与注解

状态码是试图理解和满足请求的三位数字的整数码，这些码的完整定义在第十章．注解短语
是特意给出的关于状态码的文本描述．状态码用于自动控制而注解短语是面向用户的．客户
机不需要检查和显示注解短语．

状态码的第一位数字定义应答类型．后两位数字没有任何类型任务．第一位数字有五种值：

-1xx: 报告的 - 接收到请求,继续进程.
-2xx 成功 - 操作成功的收到.
-3xx 重发 - 为了完成请求,必须采取进一步措施.
-4xx 客户端出错 - 请求包括错的顺序或不能完成.
-5xx 服务器出错 - 服务器无法完成显然有效的请求.

为 HTTP/1.1 定义的状态码单独的值，和一个相应的一系列注解短语的例子，介绍如下,这儿
列出的注解短语只是建议――它们可以被相当的没有感情色彩的协议取代．

状态码＝
"100" ; 10.1.1 节: 继续
|"101" ; 10.1.2 节: 转换协议
|"200" ; 10.2.1 节: OK
|"201" ; 10.2.2 节: 创建
|"202" ; 10.2.3 节: 接受
|"203" ; 10.2.4 节: 非权威信息

|"204" ; 10.2.5 节: 无内容
|"205" ; 10.2.6 节: 重置内容
|"206" ; 10.2.7 节: 局部内容
|"300" ; 10.3.1 节: 多样选择
|"301" ; 10.3.2 节: 永久移动
|"302" ; 10.3.3 节: 创建
|"303" ; 10.3.4 节: 观察别的部分
|"304" ; 10.3.5 节: 只读
|"305" ; 10.3.6 节: 用户代理
|"307" ; 10.3.8 节临时重发
|"400" ; 10.4.1 节: 坏请求
|"401" ; 10.4.2 节: 未授权的
|"402" ; 10.4.3 节: 必要的支付
|"403" ; 10.4.4 节: 禁用
|"404" ; 10.4.5 节: 没找到


|服务器 ; 14.38 节
|变化 ; 14.44 节
|WWW 认证 ; 14.47 节

随着协议版本的变化,应答报头可以可靠的扩展．而且，如果通信的所有组成部分都把它当
作应答报头域,新的或试验性的应答报头域可以被给定应答报头域的含义，未被承认的报头
域被当作实体报头域．

7。实体。

在未经特别规定的情况下，请求与应答的报文也可以传送实体。实体包括实体报头域与实
体正文，而有些应答只包括实体报头。在本节内，接收者与发送者既可以指用户端，也可以
指服务器，视由谁收发实体而定。

7。1 实体报文域

实体报文域定义了关于实体正文的维护信息（参数）或在无正文情况下定义了请求的资源。
，
其中一些参数是可选的，一些则是由技术指标规定必须的。

实体报头 = 允许（Allow）； 14.7 节
|内容编码； 14.11 节
|内容语言； 14.12 节
|内容长度； 14.13 节
|内容位置； 14.14 节
|内容-MD5； 14.15 节
|内容范围； 14.16 节
|内容类型； 14.17 节
|过期(Expires)； 14.21 节
|上次修改； 14.29 节
|扩展报头

扩展报头=报文报头

扩展报头机制允许在不改变协议的前提下定义额外的实体报头域，但不保证这些域在收端能
够被识别。未被识别的域应当被接收者忽略，且必须被透明转发。

7。2 实体正文。

经由 HTTP 请求或应答发送的实体正文部分（如果存在的话）的格式与编码方式应由实体报
文域决定。

实体正文= *八位字节


如 4。3 节所述，实体正文只有当报文正文存在时才存在。实体正文是通过对报文正文按某
种保证安全性且便于传输的传输编码进行解码得到的。

7。2。1。类型。

对于报文中的实体正文而言，其数据类型由报头中的"内容类型"与"内容编码"域决定。也即
定义了一个双层有序的编码模型：

实体正文=内容编码（内容类型（数据））

"内容类型"规定了基本数据的媒体类型。
"内容编码"则可用来指明对数据施加的任何附加的，通常以数据压缩为目的的编码方式，并
将其作为所请求资源的一项属性。没有缺省的编码方式。

任一包含了实体正文的 HTTP/1。1 报文都应包括"内容类型"报头域，以定义正文的媒体类
型。当且仅当"内容类型"域未给出媒体类型时，接收者才可以通过查看资源的内容，扩展
名或 URL 来猜测其媒体类型。若媒体类型仍然未知，接收者应将其作为"应用/八位字节流"
类来处理。

7。2。2 实体长度

报文的实体长度指的是在对报文进行传输编码前报文正文的长度。4。4 节定义了确定报文
正文传输长度的方法。

8。连接

8。1 持续连接。

8。1。1 目的

在持续连接之前，为获取每一 URL 都建立了独立的 TCP 连接，这就加重了 HTTP 服务器
的负担，易引起 INTERNET 阻塞。嵌入式图片与其它相关数据通常使用户在短时间内对同
一服务器提交多个请求。目前已有针对这些性能问题的分析以及原型实施的结果[26]，[30]。
实施的具体过程和对实际 HTTP/1。1（RFC 2068）的测试均显示了良好的结果[39]。对其
他方法也有了初步探究，如 T/TCP [27]。

持续 HTTP 连接有着诸多的优点：

--- 通过建立与关闭较少的连接，不仅节省了路由器与主机（客户机，服务器，代理服务器，
网关，隧道或高速缓冲存储机）的 CPU 时间，还节省了主机用于 TCP 协议控制块的内存。

--- HTTP 请求与应答可以进入连接流水线。流水线方式使得客户无须挨个等待应答即发起


多个请求，从而更充分的利用了单个的 TCP 连接，减少了崩溃时间。

--- 在减少 TCP 连接中数据包个数的同时，使 TCP 有了充裕的时间来确定网络的拥塞状况，
缓解了网络拥塞。

--- 因为无须在创建 TCP 连接握手上耗费时间，而使连续请求造成的延迟现象得到改善。

--- 由于出错不会导致 TCP 连接的关闭，HTTP 可以更好的实现自我完善。使用较新版 HTTP
的用户会乐于尝试一些新功能，与旧版服务器通信时，则会在接到出错报告后用旧模式重试。

HTTP 的实现应当采用持续连接。

8。1。2 总体操作

HTTP/1.1 与早期 HTTP 版本的一个显著区别在于持续连接是任何 HTTP 连接的缺省方式。
也就是说，除非另有指定，客户机总应当假定服务器会保持持续连接，即便在接到服务器的
出错应答时也应如此。

持续连接提供了一种可以由客户机或服务器发信号终止 TCP 连接的机制。终止连接的信号
利用了"连接"报头域（14.10 节）
。一旦出现了终止连接的信号，客户机便不可再向此连接提
出任何新请求。

8。1。2。1 谈判

除非请求的连接报头域中包括了"终止连接"的符号，HTTP/1。1 服务器总可以假定 HTTP/1。
1 客户机想要维持持续连接。如果服务器想在发出应答后立即终止连接，它应当发送一个含
有终止要求的连接报头域。

无论是客户机或服务器发起终止连接，这都是本次连接的最后一个请求。

除非经明确指出，客户机与服务器不应假定低版 HTTP 会自动采用持续连接方式。请参见
19。6。2 节关于与 HTTP/1。0 客户机后向兼容性的有关内容。

为了维持持续连接，连接中的报文都必须有如 4。4 节所述的自定义报文长度（即不是由连
接终止定义的长度）。

8。1。2。2 流水线

支持持续连接的客户机可以以流水线方式发送请求（即无须等待应答而发送多个请求）。服
务器则必须将其应答按接到请求的顺序发出。

建立连接后立即采用持续连接与流水线方式的客户机应作好初次流水线尝试失败后重试的
准备，而不可在持续连接尚未确定时就连续发送请求。客户机还必须为服务器在发出所有应
答之前就结束连接的情况作好重发请求的准备。


客户机不应该用非等幂方法或非等幂方法序列（参见 9。1。2 节）连发请求。否则，过早终
止的传输层连接会导致不确定的结果。

8。1。3 代理服务器

使代理服务器正确地实现 14。10 节所规定的连接报头域的属性是非常关键的。

代理服务器必须独立于它所连接的客户机，原服务器（或其它代理服务器）而发出持续连接
的信号。每一持续连接仅针对传输层链接。

代理服务器不可与一台 HTTP/1.0 客户机建立 HTTP/1。持续连接
1 （请参见 RFC 2068 [33] 中
关于 HTTP/1。0 客户机上实现"维持活跃态"报头问题的探讨及资料）

8。1。4 实际的考虑

服务器通常有一个时限值，超过一定时间即不再维系处于非活跃态的连接。代理服务器会选
一个较高的值，因为客户机很可能会与同一服务器建立多个连接。持续连接方式的采用对于
客户机与服务器的时限均未提出任何要求。当客户机或服务器希望超时终止时，它应按规
范终止传输连接。客户端与服务器端应始终注意对方是否终止了连接，并适当的予以应答。
若客户机或服务器未能及时检测到对方已终止了连接，将会造成不必要的网络资源浪费。

客户机，服务器，或代理服务器可能在任意时刻终止传输连接。比如，客户机可能正想发出
新的请求，而此时服务器却决定关闭"闲置"的连接。在服务器看来，连接是在闲置状况下被
关闭的，而客户机却以为请求在进行中。

这表明客户机，服务器与代理服务器必须有能力从非同步的连接终止事件中恢复。只要请求
序列是等幂的（参见 9。1。2 节），客户端软件就应自动重新发起传输层连接并重传被废弃
的请求序列。对非等幂方法或序列不可自动重试，但用户代理可以向手工操作员提供重发
请求的机会。用户代理软件对应用程序基于句法理解的确认可以用来代替人工方式。若重试
失败，则不应允许再试。

服务器在每次连接中只要有可能，总应至少应答一个请求。除非出于网络或客户端的故障，
服务器不应在传送应答的中途断开连接。

使用持续连接的客户机应限制与某一服务器同时连接的个数。单用户客户机不应与任一服务
器或代理服务器保持两个以上的连接。代理服务器与其它服务器或代理之间应维护 2*N 个
连接，其中 N 是同时在线的用户数。设定这一规则是为了改进 HTTP 应答时间且避免拥塞。

8。2 报文传输要求、

8。2。1 持续连接与流量控制

HTTP/1。1 服务器应当保持持续连接并使用 TCP 的流量控制机制来解决临时过载，而不是


在终止连接后指望客户端的重试。后一方法会恶化网络阻塞。

8。2。2 监视连接中出错状态的报文

发送报文正文的 HTTP/1。1（或更新）客户机应在传输请求的同时监视连接是否处于出错状
态。若客户机发现了错误，它应当立即停止正文的传送。若正文是以块编码方式发送的（3。
6 节）
，可以用一长度为零的块和空报尾来提前标记报文结束。若正文前有"内容长度"报头，
则客户机必须关闭连接。

8。2。3 100 号状态的用途

100 号状态的目的在于帮助那些发送含有请求正文的请求报文的客户机在发送请求正文之
前推测服务器看到请求报头后是否愿意接收请求。有些时候，如果服务器不看正文就弃置报
文的话，客户机对正文的发送就多此一举了。

对 HTTP/1。1 客户机的要求：

--- 若客户机在发送请求正文之前等候 100（继续）应答，则它必须发送填有"100--继续"期
望的"期待请求"报头域（14。20 节）。

--- 若客户机不需要发送请求正文，则它不得发送填有"100--继续"期望的"期待请求"报头域
（14。20 节）
。

由于存在旧的实现方法，协议允许出现诸如客户机发出了"期望：100-继续" 却没接到 417
（期望失败）或 100（继续）状态的混乱局面存在。因此，当客户机将这一报头域发给它
从未接到 100（继续）状态的原服务器（通常是通过代理）时，客户机不应在发送请求正
文前无限期地等待。

对 HTTP/1。1 原服务器的要求：

--- 在接到"期望"请求报头域填有"100-继续"期望的请求时，原服务器必须以 100（继续）状
态应答并继续读入数据流，或者以终止状态码应答。原服务器在发送 100（继续）应答之前
不得等待。若以终止状态码应答，它既可关闭传输层连接，也可继续读入数据而丢弃请求的
剩余部分。但此时它不得按客户机所请求的方式运行。

--- 如请求报文不含填有"100-继续"的"期望"报头域，原服务器不应发送 100（继续）应答。
当请求来自 HTTP/1。0（或更早）客户机时也不得发送 100（继续）应答。对此规定有一例
外：为了与 RFC 2068 兼容，服务器对于未含填有"100-继续"的"期望"报头域的 PUT 或 POST
请求可以应答 100（继续）状态。这一例外的目的在于尽量减少由 100（继续）状态的未申
明等待引起的客户机处理延迟，仅适用于 HTTP/1。1 请求，和其它 HTTP 版本的请求无关。

--- 若已经接到相应请求的部分或全部请求正文，原服务器可以免发 100（继续）应答。

--- 一旦请求正文被收到处理，发出 100（继续）应答的原服务器除非过早切断传输层连接，


否则最终必须发送终止状态码。

--- 若原服务器接到不含填有"100-继续"的"期望"报头域的请求，该请求含有请求正文，而服
务器又在从传输层连接读入正文之前就应答了终止状态码，则服务器不应在读完全部请求或
客户机终止连接前关闭连接。否则，客户机可能无法可靠地接收应答报文。然而，这一要
求在阐释中不应阻止服务器防卫拒绝服务的攻击或有严重缺陷的客户程序。

对代理服务器的要求：

--- 若代理服务器接到包含填有"100-继续"的"期望"报头域的请求，且代理服务器要么知道下
一站服务器遵循 HTTP/1。1 或更高版协议，要么不知下一站服务器的 HTTP 版本，则它必
须连同"期望"报头域一起转发此请求。

--- 若且代理服务器知道下一站服务器版本是 HTTP/1。0 或更低，则它不得转发此请求，而
应应答以 417（期望失效）状态。

--- 代理服务器应当维护一高速缓存，以记录新近访问到的下一站点服务器的 HTTP 版本号。

--- 若接到的请求来自于版本是 HTTP/1。0（或更低）的客户机，不含填有"100-继续"的"期
望"报头域的请求，则代理服务器不得转发 100（继续）应答。这一要求可覆盖 1xx 应答转
发的一般规则（参见 10。1 节）。

8．2．4 服务器过早关闭连接时客户机的行为

如果 HTTP/1。1 客户机发出一条含有请求正文但不含填有"100-继续"的"期望"报头域的请
求，并且客户机直接与 HTTP/1。1 原服务器相连，在从服务器处接到任何状态信息之前就
发现连接被关闭，那么客户机应当重试请求。在重试时，客户机何以采用如下所述的"二进
制指数后退算法"以确保获得可靠应答：

1．向服务器发起一新连接。
2．发送请求的报头。
3．初始化变量 R 为通往服务器的往返时间的估计值（比如基于建立连接的时间），或在无
法估计往返时间时设为一常数值 5 秒。
4．计算 T=R*（2**N）为此前重试请求的次数。
，N
5．等待服务器发来的出错应答或是 T 秒（两者中时间较短的）。
6．若没等到出错应答，T 秒后发送请求正文。
7．若客户机发现连接被提前终止，转到第 1 步，直到请求被接受，接到出错应答，或是用
户因不耐烦而终止了重试进程。

在任意环节上，客户机如果接到出错状态，
--- 不应再继续，并且
--- 如完成请求报文的发送则应终止连接


９方法定义

HTTP/1.1 常规方法的定义如下.虽然这个定义可以展开,但附加的方法不能被假定分享和个
别扩展的客户机和服务器同样的语义.

主机请求应答报头(14.23 节)必须符合所有的 HTTP/1.1 请求.

9.1 安全和等幂(Idempotent)方法

9.1.1 安全方法

实现程序应当知道软件通过在 Internet 上的交互来扮演用户,且应该仔细的允许用户知道任
何它们可能采取的行动,这些行动可能给他们自己或他人带来无法预料的结果.

特别的.这样的惯例已经形成,就是 GET 和 HEAD 方法除了补救外不应该有别的采取措施的
含义.这些方法应该被看作"安全".这允许用户代理描绘其他方法,像 POST,PUT,DELETE,在某
种意义上,用户知道某种不安全的行为被请求的事实.

自然, 随着 GET 请求的实现,不可能保证服务器不产生副作用;事实上,一些动态的资源考虑
到那样的特征.在这里重要的区别是用户没有请求副作用,因此不应该为此承担责任.

9.1.2 等幂方法

方法也可以等幂的性质,这种情况下(除了出错或终止问题)N>0 个同样请求的副作用和单个
请求一样.方法 GET,HEAD,PUT,DELETE 都有这种性质.而且,方法 OPTIONS 和 TRACE 不应
该有副作用,等幂就是这样的含义.然而,有可能几个请求的序列是不等幂的,即使在那样的序
列中所有方法单独实现都是等幂的(如果整个序列整体的实现结果总是相同的,即不因序列
整体,部分的重新实现而变化,则序列是等幂的).例如,如果一个序列实现的结果依赖一个序列
中后来可以修改的值,则该序列不是等幂的.

没有副作用的序列是等幂的(倘若在同样的资源配置下不同时操作)

9.2 OPTIONS(选项）

OPTIONS 方法描述了在请求 URI 确定的请求/应答过程中通信条件是否可行的信息.该方法
允许客户机确定条件或设备,其与资源或服务器的没有暗示资源操作或初始化资源重建的情
况下的性能有关,

这种方法的应答是不能缓存的.

如果 OPTIONS 请求包括一个实体(用来指示内容长度或传输码的存在),接着媒体类型应该有
一个内容内型域来确定.虽然这种规定对那样的主体没有定义任何功能,未来 HTTP 的扩展可
以用 OPTIONS 域来安排更多细节性的有关服务器的询问.一台不支持扩展的服务器可以抛
弃请求正文.


如果请求 URI 是一个星号("*"), OPTIONS 请求特意应用于总的服务器而不是特定的服务资
源.既然服务器的通信条件取决于资源,"*"请求只是作为"ping" 或 "no-op 类型的方法才有用;
它只能允许客户机测试服务器的性能.例如,这能被用来检测一台代理机即是否支持
HTTP/1.1.

如果请求 URI 不是一个星号("*"), OPTIONS 请求只是当和资源通信时应用于条件是否可能.

应答 200 应当包括表示服务器实现和可应用于资源的可选择的特征报头域,.可能包括这种规
范定义未定义的扩展.规范没有定义正文,但未来 HTTP 的扩展可能会定义,商议内容可能会用
于选择适当的应答格式.如果没有应答体被包括进来,应答必须包括一个值为零的内容长度域.

最大转发请求报头域可以用于请求过程中特定的代理机.当代理机收到可以继续传播的绝对
URI 的 OPTIONS 请求时,代理机必须检测最大转发域.如果最大转发域的值是零,代理机禁止
转发信息.相反的,代理机将回答它自己的通信条件.如果是大于零的整数,当代理机转发请求
时,该域的值将逐渐减小.如果请求中没有该域,则转发请求当中也会没有.

9.3 GET（获取）

GET 方法重建信息的内容(正文的形式)由请求 URI 来确定.如果请求 URI 指数据产生的过程,
它是在应答中产生,被当作正文返回的数据,而不是过程的源文本,除非文本碰巧是过程的输
出.

如果请求信息包括 If-Modified-Since, If-Unmodified-Since,If-Match, If-None-Match, or
If-Range 报头域, GET 的语义将变成"条件（conditial） GET". 只有在条件报头域(conditional
header)所描述的环境下, 条件 GET 方法请求实体被传输. "条件 GET"方法用于减少不必要的
网络使用,这种使用允许在没有多种请求或客户机已经获传输数据的情况下刷新缓存实体.

如果请求信息包括范围（Range)报头域, GET 方法的语义将变成"部分(partial)GET","部分
GET"请求只要求传输部分实体,如 14.35 节指定的那样. 部分 GET 方式通过允许当客户端没
有得到全部的传输数据时部分的重建数据来减少不必要的网络使用.

只有当 GET 请求碰到 13 章里所描述的支持 HTTP 缓存的设备时,应答才是可缓存的.

当使用表格形式时.请参看 15.1.3 节关于安全的考虑.

9.4 HEAD（报头）

除了应答中禁止返回消息正文外,HEAD 方法与 GET 方法一样.包含在 HTTP 报头以后应答报
头头请求的信息与 POST 去应答 GET 请求的信息是相同的.这种方法能用于获得关于实体更
多的信息,没有传输实体正文本身的请求暗示了这种信息.这个方法常用来检查超文本链接的
有效性,可到达性和最近的修正.


当包含在应答中的信息可以用来更新以前缓存的来自资源的实体时,对 HEAD 请求的应答是
可缓存的 .如果新域的值显示缓存的实体不同于当前的实体时 ( 这将在内容长度, 内容
-MD5,ETAG 或最后更新时间中表现出来),缓冲区就抛弃缓存的实体.

9.5 POST（张贴）
在 POST 方法适用的请求中,原服务器接收附加在请求后的实体,该实体后作为请求行里请求
URI 指定的资源的次要部分,. POST 被设计为具有如下的功的统一的方法:

- 已有资源的注解.
- 在电子布告版,新闻组,邮箱或类似的主题组贴一些信息.
- 提供数据块,像确认表单数据处理的结果.
- 通过附加的操作扩充数据库.

POST 方法实现的实际功能取决于服务器,且往往取决于请求 URI.POST 实体属于 URI,就像
文档属于包括它的目录,新闻主题属于它所在的新闻组,或纪录属于数据库.

POST 方法实现的操作不会作用于 URI 可以鉴识别的资源.在这种情况下,无论 2000(OK)还是
2004(无目录)是合适的应答状态,取决于应答是否包括描述结果的实体.

如果原服务器上已经建立了资源,应答将是 201(建立)且包括描述请求状态,指向新的资源的
实体和一个本地报头(看 14.30 节).

这种方法的应答是不可缓存的,除非应答包括合适的缓冲控制或终止报头域.然而,303(看别
的)应答可直接用于用户代理重建可缓存资源.

POST 请求必须像 8.2 节所描述的那样服从消息传输的需要.

参见 15.1.3 节关于安全性的考虑.

9.6 PUT（放置）

PUT 方法要求所附实体存储在提供的请求 URI 下.假如请求 URI 指的是已经存在的资源,所
附的实体应当被当作原服务器中已修改的版本. 假如请求 URI 指的不是已经存在的资源,而
URI 可以被客户代理定义成新的资源,原服务器可以建立该 URI 资源.假设建立了新资源,原
服务器必须通过 201(建立)应答通知用户代理.如果修改了已有资源,将发送 200(OK)或 204(无
内容)应答表示请求的成功完成.如果对于该 URI 资源不能创建或修正,将给出合理的出错应
答来反映问题所在.实体容器不能忽视任何不被理解或实现的内容-*(例如内容范围)报头,这
时必须返回 501(未实现)应答.

如果请求经过高速缓冲存储器和请求 URI 标识一个或多个当前缓存的实体,这些实体将被抛
弃.这个方法的应答是不可缓存的.


POST 和 PUT 请求基本的不同点反映在请求 URI 的不同意义.POST 方法中的 URI 标识将处
理附加实体的资源.资源可以是数据接收过程,一个网关和一些协议,或一个接收注解的分散
的实体.与之相对照的是, PUT 请求中的 URI 标识请求所附的实体-用户代理了解什么 URI 是
有意的和服务器禁止试图应用请求于别的资源.假如服务器希望请求应用于不同的 URI,

它必须是 301(永久移动)应答;用户代理可以自己决定关于是否改变请求路由.

单个的资源可以被许多不同的 URI 确定.例如,一个主题可以有一个 URI 识别当前版本,这从
URI 识别每一个特定的版本分离开来.在这种情况下,PUT 请求中一般的 URI 导致服务器,而
其他的 URI 由原服务器定义.

HTTP/1.1 没有定义 PUT 方法如何影响原服务器的状态.

PUT 请求必须服从 8.2 节描述的信息传输需要.

除了特定的实体报头说明,POST 方法中的实体头应该应用于 POST 方法创建或修改的资源.

9.7 DELETE（删除）

DELELE 方法要求原服务器释放请求 URI 指向的资源.这种方法可以通过原服务器上人的强
行干涉而制止(括其他手段).客户机不能担保操作已经实现了,即使从原服务器返回的状态码
说明操作已经成功的完成.但如果当时应答未给出的话,服务器不应该表示成功,它打算释放
资源或移到不能访问的位置.

假如应答包括描述状态的实体,成功的应答是 200(OK),如果操作仍未制定,则应答为 202(接
收),如果操作已制定但应答不包括实体,则应答为 204(无内容).

如果请求经过缓存和请求 URI 识别一个或多个当前缓存的实体,这些实体将被抛弃.这个方法
的应答是不可缓存的.

如果请求经过缓存和请求 URI 识别一个或多个当前缓存的实体,这些实体将被抛弃.这个方法
的应答是不可缓存的.

如果请求经过高速缓冲存储器和请求 URI 标识一个或多个当前缓存的实体,这些实体将被抛
弃.这个方法的应答是不可缓存的.

9.8 TRACE（跟踪）

TRACE 方法用于调用远程的,应用层循环请求消息.请求最终的接收者应当反射从客户机作
为 200 应答的实体正文收到的信息.最终的接收者也是原服务器或在请求中收到最大转发数
量值第一个代理服务器或网关 (看 14.31 节).TRACE 请求不包括实体.

TRACE 允许客户端了解在请求的另一端收到的内容和用数据测试或诊断信息.经由报头域


的值尤其重要,因为它表示请求过程的路径.最大转发数域的使用允许客户端限制请求链的长
度,这对在无限循环中找出前向路径的代理服务器是很有用的.

如果请求有效,在实体正文中应答包括整个请求信息,具有"消息/http"的内容-形式.这种方法
的应答禁止缓存.

9.9 CONNECT（连接）
本说明中保留 CONNECT 方法用于能动态建立起隧道的代理服务器(例 SSL 隧道[44]).

10.状态代码定义

每一段状态代码在下面被描述,包括他所能遵循的方法的描述和在应答中所必需的维护信
息.

10.1 信息 1xx

状态代码的类简单描述了一个临时的回答,只是由状态行和可选择的报头所组成,并且由空行
所决定,状态代码类没有所需的报头.自从 HTTP/1.0 没有定义任何 1xx 状态代码,在实验的条
件下服务器严禁发送一个 1xx 应答给 HTTP/1.0 客户.
客户必须准备在接受通常应答之前接受一个或者多个 1xx 应答，甚至客户并不期待一个 100
状态的报文。不被期待出现的 1xx 状态应答也许会被用户端的代理所忽略。

代理服务器必须转寄 1xx 应答，除非代理服务器和客户之间的联系被切断，或者除非代理服
务器本身请求 1xx 应答的发生。（举例说明如果一个代理服务器在它转寄一个请求时会加上
一个"期望:100-----继续区域",它接下来就不需要转寄 100 回答应答）.

10．1．1 100 继续

客户应该和他自己的请求继续。中间的应答被用于告知客户请求的初始部分已经收到并且
还没有被服务器所拒绝。客户应该继续发送剩下的请求，或者如果请求早已完成，那就忽略
请求。服务器必须发送一个初始回答应答当请求完成时。如果想知道这部分状态代码用法及
操作处理的详细讨论，那么请看 8.2.3 章节。

10．1．2 101 转换协议

服务器了解并且愿意顺从客户的请求，经过升级的报文报头区域，为的就是一个应用协
议的变化使之能够在连接中使用。服务器会转换协议使之成为那些通过应答升级报头的区域
定义的立即在决定 101 应答的空行之后的协议。

协议应该仅仅在这样做有利的时候实行转换。比如，转换成为一个新版本的 HTTP 协议
与老版本相比更加有利，转换成为一个实时同步的协议也许会有利,当被传送的资源需要利
用这样的特征

Http1.1协议

Recommended

Recommended

More Related Content

Similar to Http1.1协议

Similar to Http1.1协议 (20)

Recently uploaded

Recently uploaded (10)

Http1.1协议