投递文章
投稿指南
说明
本文档规定了互联网社区的标准组协议，并需要讨论和建议以便更加完善。请参考
“互联网官方协议标准”（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迫切需要一个新的版本,以便使两个通信应用程序能够确定彼此的真实性能。
这里规定的协议叫做擧TTP/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）
实体是请求或响应的有效承载信息。一个实体包含元信息和内容，元信息以实体头域（entity-header 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）需要代理授权和代理识别，但不修改请求或响应。非透明代理（non-transparent proxy）需修改请求或响应，以便为用户代理（user agent）提供附加服务，附加服务包括组注释服务，媒体类型转换，协议简化，或者匿名过滤等。除非透明行为或非透明行为经明确指出，否则，HTTP代理既是透明代理也是非透明代理。
网关（gateway）
网关其实是一个服务器，扮演着代表其它服务器为客户端提供服务的中间者。与代理（proxy）不同，网关接收请求，仿佛它就是请求资源的源服务器。请求的客户端可能觉察不到它正在同网关通信。
隧道（tunnel）
隧道也是一个中间程序，它一个在两个连接之间充当盲目中继（blind relay）的中间程序。一旦隧道处于活动状态，它不能被认为是这次HTTP通信的参与者，虽然HTTP请求可能已经把它初始化了。当两端的中继连接都关闭的时候，隧道不再存在。
缓存（cache）
缓存是程序响应消息的本地存储。缓存是一个子系统，控制消息的存储、取回和删除。缓存里存放可缓存响应（cacheable response）为的是减少对将来同样请求的响应时间和网络带宽消耗。任一客户端或服务器都可能含有缓存，但高速缓存不能被一个充当隧道（tunnel）的服务器使用。
可缓存（cacheable）
我们可以说响应（response）是可缓存的，如果一个缓存（cache）为了响应后继请求而被允许存储响应消息（response message）的副本。确定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）".
1.4 总体操作
HTTP协议是一种请求/响应协议。 与服务器建立连接后，客户端以请求方法，URI和协议版本号，然后紧接着跟随一个类MIME（MIME-like）消息，这个类MIME消息包括请求修饰符，客户信息和可能的消息主体。服务器以一个状态行并跟随一个类MIME（MIME-like）消息响应，状态行包含消息的协议版本和成功出错的状态码，类MIME消息包含服务器信息，实体元信息，和可能的实体。HTTP和MIME之间的关系如附录19.4节所阐述。
大部分的HTTP通信是由用户代理（user agent）开始的，由应用到一个需要源服务器资源的请求构成。最简单的情形，可以经用户代理（UA）和源服务器（O）之间的单一连接（v）完成。
请求链（Request chain）--------------------- ----------à
用户代理（UA）----------------单一连接（v）--------------源服务器（O）
<---------------------------------------响应链（response chain）
当一个或多个中间者在请求/响应链中出现的时候，会出现更复杂的情形。常见的中间者有三种：代理（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的服务器，与此同时，它还在处理A的请求。
任何非隧道的通信成员都可能会采用一个内部缓存（cache）来处理请求。如果沿着链的通信成员对请求采用了缓存响应，请求/响应链就会大大缩短。下图阐明了一个最终请求响应链，这是在假定B拥有一个来自O（通过C）的以前请求的响应副本，但此响应尚未被UA或A缓存。
请求链（request chain）---------->
UA-----v----------A-----v-----B-----C----O
<---------响应链 （response chain）
并不是所有的响应都能有效地缓存，一些请求可能含有修饰符，这些修饰符对缓存动作有特殊的要求。缓存动作和缓存响应的HTTP行为要求将在第13节定义。
实际上，目前万维网上有多种结构和配置的缓存（cache）和代理（proxy）正在被使用。这些系统包括节省带宽的缓存代理（proxy cache），可以广播或多点传送缓存数据的系统，通过CD-ROM分配缓存数据子集的机构，等等。HTTP系统（http system）会被应用于宽带连接的企业局域网中的协作，并且可以通过PDA进行低耗无线的，断续连接的访问。HTTP1.1的宗旨是为了支持各种各样的已经部署的配置，同时引进一种协议结构，让它满足那些需要较高可靠性，即使不能达到较高可靠性的要求，也要也让它至少可以指示故障的网络应用的要求。
HTTP通信通常发生在TCP/IP连接上。默认端口是TCP 80，不过其它端口也可以使用。这并不妨碍HTTP的实现被应用于互联网（internt）或其它网的协议之上。Http仅仅期望的是一个可靠的传输（译注：HTTP一般建立在传输层协议之上）；任何提供这种保证的协议都可以被使用；协议传输数据单元（transport data unit）与HTTP/1.1请求和响应的消息结构之间的映象已经超出了本说明书的范围。
大部分HTTP/1.0的实现都是针对每个请求/响应交换产生一个新的连接。而http/1.1中，一个连接可以被用于一个或更多请求/响应交换，虽然连接可能会因为各种原因中断（见第8.1节）。
2 符号习惯和一般语法
2.1 扩充的BNF（扩充的 巴科斯-诺尔范式）
本文档规定的所有机制都用两种方法描述：散文体（prose）和类似于RFC 822的扩充Backus-Naur Form（BNF）。要理解本规范，使用者需熟悉符号表示法。扩充BNF结构如下：
名字（name）=定义（definition）
名字（name）就是代表规则的名字（译注：如：CRLF，DIGIT等等都是规则名），规则名里不能包含“<”和“>”，通过等于号把规则名和规则定义（definiation）分离开。空白（white space）是有意义的，因为可以用缩进（indentation，译注：缩进就是空白，后面会讲到LWS） 把规则定义显示成多行。某些基本规则（basic rule，译注：2.2节说明基本规则的语法）使用大写字母包含在规则定义里， 你如SP，LWS，HT，CRLF，DIGIT，ALPHA，等等。尖括号可以包含在规则定义里，只要它们的存在有利于识别规则名（译注：LWS，HT等都是规则名）。
“字面文本”（“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）
用分号引导注释。
隐含的（implied） *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 （注释）= "（" *（ ctext | quoted-pair | comment ） "）"
ctext = <除"（" 和 "）"以外的任意TEXT >
如果一个TEXT若被包含在双引号里，则当作一个字。
quoted-string = （ <"> *（qdtext | quoted-pair ） <"> ）
qdtext = <any TEXT except <">>
斜划线（"""）可以被作为单个字符的引用机制，但是必须要在引号和注释区之内。
quoted-pair = """ CHAR
3 协议参数
3.1 HTTP版本
HTTP使用一个“<major>.<minor>”数字模式来指明协议的版本号。协议的版本号是为了让发送端指明消息的格式和它的能力，这是为了进一步的HTTP通信，而不仅仅是获得通信的特征。协议版本是不需要修改的，当消息组件的增加不会影响通信行为或着只增加了扩展的域值。<minor>数字是递增的，当协议会因为添加一些特征而做了修改的时候。但这些变化不会影响通常的消息解析算法，但是它会给消息添加语意（semantic）并且会暗示发送者具有额外的能力。<major>数字也是不断递增的，当协议的消息格式每次发生变化时。
HTTP消息的版本在HTTP-Version域被指明，HTTP-Version域在消息的第一行中。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
注意major和minor数字必须被看成两个独立整数，每个整数都可以递增，并且可以增大到大于一位数的整数，如HTTP/2.4比HTTP/2.13低，而HTTP/2.4又比HTTP/12.3低。前导0必须被接收者忽略并且不能被发送者发送。
一个应用程序发送请求或响应消息，如果请求或响应消息里的HTTP-Version是”HTTP/1.1”，那么此应用程序必须条件遵循此协议规范。最少条件遵循此规范的应用程序应该把”HTTP/1.1”包含在他们的消息里，并且对任何不兼容HTTP/1.1的消息必须这么做。关于何时发送特定的HTTP-Version值的细节，参见RFC2145。
应用程序的HTTP版本是应用程序最少条件遵循的最高HTTP版本。
代理（proxy）和网关（gateway）应用程序需要被仔细对待，当转发（forwarding）消息的协议版本不同于代理或网关应用程序的协议版本。因为消息里协议版本说明了发送者处理协议的能力，所以一个代理/网关千万不要发送一个高于该代理/网关应用程序协议版本的消息。如果代理或网关接收了一个更高版本的消息，它也必须要降低请求的版本，要么以一个错误响应，要么切换到隧道行为（tunnel behavior）。
由于自从RFC 2068[33]发布后，产生了与HTTP/1.0代理（proxy）的互操作问题，所以缓存代理（caching proxy）必须能改变请求（request），使请求能到达他们能支持的最高版本，但网关（gateway）可以这么做也可以不这么做，而tunnel不能这么做。代理（Proxy）/网关（gateway）的响应（Response）必须和请求（request）的HTTP版本的major数字相同。
注意：在HTTP版本间的转换可能包含头域（header field）的改变，而这些改变会可能会根据HTTP版本而被要求或被拒绝。
3.2 统一资源标识符（URI）
URIs的许多名字已为人所知：WWW地址，通用文档标识符，通用资源标识符[3]，以及后来的统一资源定位器（URL）[4]和统一资源名称（URN）[20]。就HTTP而言，统一资源定位器只是格式化的字符串，它通过名称，地址，或任何别的特征识别资源。
3.2.1一般语法
根据使用的背景，HTTP里的URI可以表示成绝对（absoulute）形式或相对形式（相对于已知的URL）。两种形式的区别是根据这样的事实：绝对URI总是以一个方案（scheme）名作为开头，其后是一个冒号。关于URL更详尽的信息请参看"统一资源标识符（URI）:一般语法和语义"，RFC 2396 [42]（代替了RFCs 1738 [4]和RFC 1808 [11]）。本规范采用了RFC 2396里的"URI-reference"，"absoluteURI"，"relativeURI"，"port"，"host"，"abs_path"，"rel_path",和"authority"的定义格式。
HTTP协议不对URI的长度作事先的限制，服务器必须能够处理它们资源的URI，并且应该能够处理无限长度的URI，这种无效长度的URL可能会在客户端以GET形式的请求产生。服务器应该返回414状态码（此状态码代表Request-URI太长），如果服务器不能处理太长的URI的时候。
注:服务器在依赖大于255字节的URI时应谨慎，因为一些旧的客户或代理实现可能不支持这些长度。
3.2.2 http URL
通过HTTP协议，http方案（http scheme）被用于定位网络资源（resourse）的位置。本节定义了这种方案的语法和语义。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
如果端口为空或未给出，就假定为80。语义即：已识别的资源放在服务器上，在那台主机的那个端口上监听TCP连接。这时资源的请求的URI为绝对路径（5.1.2节）。无论什么可能的时候，URL里使用IP地址都是应该避免的（参看RFC 1900 [24]）。如果绝对地址（abs_path）没有出现在URL里，那么应该给出"/"。如果代理（proxy）收到一个主机（host）名，但是这个主机名不是全称的域名（fully quanlified domain name），则代理应该把它的域名加到主机名上。如果代理（proxy）接收了一个全称的域名，代理不必改变主机。
3.2.3 URI 比较
当比较两个URI是否匹配时，客户应该对整个URI比较时应该区分大小写，并且一个字节一个字节的比较。 但下面有些特殊情况：
- 一个为空或未给定的端口等同于URI-refernece（见RFC 2396）里的默认端口;
- 主机（host）名的比较必须不必分大小写;
- 方案（scheme）名的比较必须是不区分大小写的;
- 一个空绝对路径（abs_path）等同于"/"。
除了"保留（reserved）"和"不安全（unsafe）"字符集里的字符（参见RFC 2396 [42]） ，其它字符都等效于它们的"%HEXHEX"编码.
例如,以下三个URI是等同的:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
3.3 日期/时间格式（Date/Time Formats）
3.3.1完整日期 （Full Date）
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里定义的日期格式来填充头域（header field）用到日期的地方。
注:日期值的接收者被鼓励能健壮的接收可能由非HTTP应用发来的日期值，例如有时可以通过代理（proxy）/网关（gateway）向SMTP或NNTP获得或转发消息。
所有的HTTP日期/时间都必须以格林威治时间（GMT）表示。对HTTP而言，GMT完全等同于UTC（世界协调时间）。前两种日期/时间格式里包含“GMT”，它是时区的三个字面的简写，并且当读到一个asctime格式时必须先被假定是GMT时间。HTTP日期（HTTP-date）区分大小写，不能包含一个额外的LWS，除非此LWS作为在下面的Http-date语法中指定的SP。
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对日期/时间格式的要求仅仅应用在协议的消息（译注:原文是protocol stream，便于理解这里译作消息）里。客户和服务器不必把这种格式应用于用户呈现（user presentation），请求记录日志，等等。.
3.3.2 Delta Seconds
一些HTTP头域（header field）允许用整数秒表示时间值，整数秒用十进制表示，此整数秒表示消息被接收后时间。
delta-seconds = 1*DIGIT
3.4 字符集
HTTP使用术语"字符集"的定义，这和MIME中所描述的是一样.
本文档中的术语"字符集"涉及到一种方法，此方法是用一个或多个表将一个节序列转换成一个字符序列（译注：从这里来看，这应该是一种映射关系，表保存了映射关系）。注意反方向的无条件转换（译注:从一个字符序列到一个字节序列的转换）是不需要的，因为并不是所有的字符都能在一个给定的字符集里得到，一个字符集可能提供多个字节序列表征一个特定的字符。这个定义是为了允许不同种类的字符编码从单一简单表映射（如US-ASCII）到复杂表的转换方法如ISO-2022技术用到的。然而，与MIME字符集名字相关的定义必须要充分说明从字节到字符的映射。特别的，使用外部轮廓信息来精确确定映射是不允许的.
注:这里使用的术语"字符集"一般的被称作一种"字符编码"。不过既然HTTP和MIME在同一机构注册，术语统一是很重要的。
HTTP字符集是用不区分大小写的标记（token）表示。所有的标记集由IANA字符集注册机构[19]定义。
charset = token
尽管HTTP允许用任意标记（token）作为字符集（charset）值，但任何标记值如果它已经在IANA字符集注册机构注册了则必须表示在该注册机构定义的字符集。对那些非IANA定义的字符集，应用程序应该限制使用。
HTTP协议的实现者应该注意IETF字符集的要求[38][41].
3.4.1丢失的字符集（Missing Charset）
一些HTTP/1.0应用程序当他们解析Content-Type头时，当发现没有字符集参数（charset parameter，译注:Content-Type: text/plain; charset=UTF-8，此时charset=UTF-8就是字符集参数）可用时，这意味着接收者必须猜测实体主体（entity body，译注：这里翻译成“实体主体”因为Content-Type头是实体头，消息头可以分为实体头，常用头，请求头，响应头，在译文中多次用到“头”和“头域”，如消息头，消息头域，其实是同一个意思，HTTP1.1协议有时候概念并不是完全统一的）的字符集是什么。如果发送者希望避免这种情况，他应该在Content-Type头域里包含一个字符集参数，即使字符集是ISO-8859-1也应该这样做，这样就不会让接收者产生混淆。
不幸的是，一些旧的HTTP/1.0客户端不能处理在Content-Type头域里明确指定的字符集参数。HTTP/1.1接收端必须要认真对待发送者提供的字符集；并且当用户代理（user agent，译注：如浏览器，可认为是接收端）开始显示一个文档时，虽然用户代理可以猜测文档的字符集，但如果content-type头域里提供了字符集，并且用户代理也支持这种字符集的显示，不管用户代理是否愿意，它必须要利用这种字符集。参见3.7.1节。
3.5 内容编码（Content Codings）
内容编码值（content coding value）表示一种已经或可以应用于实体的编码转换（encoding transformation）。内容编码主要用于文档的压缩或其它有效的变换，但这种变换需要不能丢失文档的媒体类型（media type，译注：文档一般会有媒体类型，这通过在content-type里指定）的特性，也不能丢失文档的信息（译注：就像有损压缩和无损压缩，前者不会丢失信息，后者会丢失信息）。实体经常被编码的储存，然后直接传送，接收端只能解码。
content-coding = token
所有内容编码值（content-coding value）是不区分大小写的。HTTP/1.1在接收译码 （14.3节）和内容译码（Content-Encoding）（14.11节）头域里使用内容编码值（content-coding value）。尽管该值描述了内容编码，更重要的是它指出了一种解码机制，利用这种机制对实体的编码进行解码。
网络分配数字权威（ （IANA）充当内容编码值标记（token）的注册机构。最初，注册表里包含下列标记:
gzip（压缩程序）
一种由文件压缩程序"gzip"（GNU zip）产生的编码格式（在RFC 1952中描述）。这种编码格式是一种具有32位CRC的Lempel-Ziv编码（LZ77）。
compress（压缩）
一种由UNIX文件压缩程序"compress"产生的编码格式。这种编码格式是一种具有可适应性的Lempel-Ziv-Welch编码（LZW）。
对于将来的编码，用程序名识表征编码格式是不可取。在这里用到他们是因为他们在历史的作用，虽然这样做并不好。为了同以前的HTTP实现相兼容，应用程序应该将"x-gzip"和"x-compress"分别等同于"gzip"和"compress"。
deflate（缩小）
deflate编码是由RFC 1950 [31]定义的"zlib"编码格式与RFC 1951 [29]里描述的"deflate"压缩机制的组合的产物。
identity（一致性）
Identity是缺省编码；指明这种编码表明不进行任何编码转换。这种内容编码仅被用于接收译码（Accept-Encoding）头域，但不能被用在内容译码（Content-Encoding）头域。.
新的内容编码值标记（token）应该被注册；为了实现客户和服务器间的互操作性，实现新值的内容编码算法规范应该能公开利用并且能独立实现，并且与本节中被定义的内容编码目的相一致。
3.6 传输编码 （Transfer Codings）
传输编码值（transfer-coding value，译注：transfer coding和和transfer-coding这两个术语在本协议规范里所表达的意思其实没什么太大区别，“transfer-coding”可能更能表达语意，因为它是规则中的规则名，见下面红字的规则）被用来表示一个已经，能够，或可能应用于一个实体的编码转换，传输编码是为了能够确保网络安全传输。这不同于内容编码（content coding），因为传输编码（transfer coding）是消息的属性而不是实体的属性。
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *（ ";" parameter ）
参数（parameter）采用属性/值对的形式.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
所有传输编码值（transfer-coding value，译注：上面红体字等号右边规则表达式所表达的值）是大小写不敏感。传输编码值在TE头域（14.39节）和在传输译码（Transfer-encoding） 头域中（14.41节）被运用。
无论何时，传输编码（transfer-coding）应用于一个消息主体（message body）时，如果存在多个传输编码，则这些传输编码中必须包括“块”（"chunked"）传输编码，除非通过关闭连接而中断消息。当“块”（“chunked”）传输编码被用于传输编码时，它必须是应用于消息主体的最后传输编码。"块"（"chunked"）传输编码最多只能用于消息主体（message-body）一次。规定了上述规则后，接收者就可以确定消息的传输长度（transfer-length）（4.4节）
传输编码与MIME[7]的内容传输译码（Content-Transfer-Encoding，译注：transfer应该是转移，迁移的意思，又例如HTTP协议，应该翻译成“超文本转移协议”，但是历史上都翻译成“超文本传输协议”，所以这里翻译成“超文本传输协议”）值有相类似型，它被定义能够实现在7位传输服务上保证二进制数据的传输安全。不过，传输编码与内容传输译码（Content-Transfer-Encoding）对纯8位传输协议有不同的关注点。在HTTP中，消息主体存在不安全的隐患，因为有时候很难确定消息主体的长度，在共享的传输上加密数据也会带来安全性问题（7.2.2节）。
网络分配数字权威（IANA）担任注册传输编码值标（token）记的角色。起初,注册包含如下标记:"块"（3.6.1节）,"身份"（3.6.2节）,"gzip"（3.5节）,"压缩"（3.5节）,和"缩小"（3.5节）.
新的传输编码值标记应该注册，这同新的内容编码值标记也需要注册一样。.
接收端接收到一个带有传输编码（transfer-coding）（译注：通过消息头域transfer-encoding指明此实体主体的传输编码）的实体主体（entity body），如果它不能对这个编码后的实体主体进行解码，那么它应返回501（不能实现），并且要切断联系。服务器不能向HTTP/1.0客户发送传输编码.
3.6.1块传输编码（Chunked Transfer Coding）
块编码（chunked encoding）改变消息主体使消息主体（message body，译注：消息主体与实体主体是有区别的，后面章节将会介绍）成块发送。每一个块有它自己的大小（size）指示器，在所有的块之后会紧接着一个可选的包含实体头域的尾部（trailer）。这允许发送端能动态生成内容，并能携带有用的信息，这些信息能让接收者判断消息是否接收完整。
Chunked-Body（块正文） = *chunk（块）
last-chunk（最后块）
trailer（尾部）
CRLF
chunk（块） = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*（"0"） [ chunk-extension ] 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）
chunk-size是用16 进制数字字符串。块编码（chunked encoding）以任一大小为0的块结束，紧接着是尾部（trailer），尾部以一个空行终止。
尾部（trailer）允许发送端在消息的末尾包含附加的HTTP头域（header field）。Trailer头域（Trailer header field，译注：Trailer头是常用消息头，在14.40节说明）被应用来指明哪些头域被包含在块编码的尾部（trailer） （见14.40节）
如果服务器要用块传输编码进行响应，它不能包含尾部（trailer），除非以下至少一条为真：
a）如果此响应的请求包括一个TE头域，并且它指明了传输编码中的“trailers”是可接受的，当响应的传输编码（transfer-coding）是块编码时。这在14.39节中描述；或者
b）如果服务器是响应的源服务器，并且接收端接收块传输编码响应但不会去理会响应的尾部（trailer，译注：尾部包含头域，头域就是消息的元数据（metadata））并且这种方式源服务器是可以接受的，这时服务器是不需要把尾部（trailer）包含进消息的块传输编码中去的。换句话说，源服务器原意接受尾部（trailer）可能会在到达客户端时被丢弃的可能性。
此要求防止了一种互操作性的失败，当消息被一个HTTP/1.1（或更迟的）代理（proxy）接收并且转到一个HTTP/1.0的接收端的时候。
在附录19.4.6节介绍了一个例子，这个例子介绍怎样对一个块正文（chunked-body）进行解码。
所有HTTP/1.1应用程序必须能接收和解码块（chunked）传输译码，并且必须忽略它们不能理解的块扩展（chunk-extentsion，译注：见上面的规则表达式）.
3.7 媒体类型（Media Type）
HTTP在Content-Type（14.17节）实体头域和Accept请求头域里利用网络媒体[17]类型，这是为了提供公开的，可扩展的数据打印和类型协商。
media-type = type "/" subtype *（ ";" parameter ）
type = token
subtype = token
参数（parameter）以一种属性/值对的形式跟随type/subtype（如3.6节定义） 。
类型（type），子类型（subtype），和参数（parameter）里属性名称是大小写不敏感的。参数值有可能是大小写敏感的，也可能不是，这根据参数里属性名的语意。线性空白（LWS）不能被用于类型（type）和子类型（subtype）之间，也不能用于参数的属性和值之间。参数的出现或不出现对处理媒体类型（media-type）可能会有帮助，这取决于它在媒体类型注册表里的定义。
注意一些旧的HTTP应用程序不能识别媒体类型的参数（parameter）。当向一个旧的HTTP应用程序发送数据时，发送端只有在被type/subtype定义需要时才使用类型参数（parameter）。
媒体类型（media-type）值需要被注册到网络数字分配权威（IANA[19]）里。媒体类型的注册程序在RFC 1590[17]中大概描述。使用未经注册的媒体类型是不被鼓励的。
3.7.1规范化和文本缺省 （Canonicalization and Text Defaults）
网络媒体类型以规范化的格式被注册。一个实体主体（entity-body）通过HTTP消息传输，它必须在传输前以一种合适的规范化的格式表征除了文本类型（text type），文本类型将会在下一段阐述。
当消息以一种规范化的格式表现时，文本类型的子类型（subtype）运用GRLF作为文本里的换行符。HTTP放松了这个要求，并且允许文本媒体以一个CR或LF代表一个换行符传输，并且这样做要贯穿整个实体主体（entity-body）。HTTP应用程序必须能接收CRLF，CR和LF作为在文本媒体一个换行符。另外，如果文本字符集（character set）不能用字节13和10来分别地表征CR和LF因为存在一些多字节字符，HTTP允许应用字符集里等价于CR和LF的字节序列来表示换行符。对换行符的灵活处理只能应用于实体主体里的文本媒体；在HTTP消息结构里，一个单独的CR或LF都不能代替CRLF（如头域和多边界体（multipart boundaries）结构里）。
如果一个实体主体（entity-body）用内容编码（content-coding）进行编码，原始数据（译注：被编码前的数据）在被编码前必须是一种定义的媒体类型格式。.
"charset"参数（parameter）被应用于一些媒体类型，来定义数据的字符集（见3.4节）。当发送者没有在媒体类型（media-type）里指明charset参数（parameter）时，文本类型的子媒体类型（subtype）被认为是缺省的ISO-8859-1字符集当被接收者接收后。数据必须被合适的字符集标识。3.4.1节描述了兼容性问题。
3.7.2多部分类型（Multipart type）
MIME提供了一系列"多部分"类型---在单个消息主体内包装一个或多个实体。所有的多部分类型共享一个公共的语法（这在RFC 2046[40]的5.1.1节中描述），并且包含一个边界（boundary）参数作为多部分媒体类型值的一部分。多部分类型的消息主体是一个协议元素，并且必须用CRLF来标识体部分（body-part，译注：见RFC 2046 的5节）之间的换行。
不同于RFC 2046里的多部分消息类型的描述，HTTP1.1规定任何多部分类型的消息尾声（epilogue，译：见RFC 2046对多部分消息类型的规则描述）必须不能存在；HTTP应用程序不能传输尾声（epilogue）（即使原始的多部分消息尾部包含一个尾声）。存在这些限制是为了保护多部分消息主体的自我定界的特性，因为多部分边界的结束（译注：根据RFC2046中定义，多部分边界结束后可能还会有尾声）标志着消息主体的结束。
通常，HTTP把一个多部分类型的消息主体（message-body）和任何其他媒体类型的消息主体相同对待：严格看作有用的负载体。有一个例外就是"multipart/byterange"类型（附录19.2），当它出现在206（部分内容）响应时，此响应会被一些HTTP缓存机制解析，缓存机制将会在13.5.4节和14.16节介绍。在其它情况下，一个HTTP用户代理会遵循MIME用户代理一样的或者相似的行为，这依赖于接收何种多部分类型。一个多部分类型消息的每一个体部分（bady-part）里的MIME头域对于HTTP并没有太大意义除了MIME语意。
通常， 一个HTTP用户代理应该遵循与一个MINE用户代理相同或相似。如果一个应用程序收到一个不能识别的多部分子类型，这个应用程序必须将它视为"multipart/mixed"。
注:"multipart/form-data"类型已经被规范的定义为传送窗体数据（译注：一般用窗体上传数据时，上传的数据类型就是为multipart/form-data类型），当用POST请求方法处理数据时。这在RFC 1867[15]里定义。
3.8 产品标记 （product Tokens）
产品标记用产品名和版本号识别通讯应用软件。很多头域都会利用产品标记，它允许构成应用程序重要部分的子产品被以空白分隔列举。通常，产品以应用程序的重要性的顺序来列举的。
product = token ["/" product-version]
product-version = token
例:
User-Agent:CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
产品标示应言简意赅。它们不能用来做广告或其他不重要的信息。虽然任一标记可能出现product-version里，但这个标记仅能用来做一个版本 （i.e., 同产品中的后续版本应该在product-version上有区别）
3.9 质量值（Quality Values）
HTTP内容协商（content negotiation，12节介绍）运用短“浮点”数字（short floating point number）来表针不同协商参数的相对重要性。重要性的权值被规范化成一个从0到1的实数。0是最小值，1是最大值。如果一个参数的质量值（quanlity value）为0，那么这个参数的内容不被客户端接受。HTTP/1.1应用程序不能产生多于三位小数的实数。下面规则限定了这些值。
qvalue = （ "0" [ "." 0*3DIGIT ] ）
| （ "1" [ "." 0*3（"0"） ] ）
"质量值" 是一个不当的用词，因为这些值仅仅表现一中相对的降级。
3.10 语言标签 （Language Tags）
一个语言标签表征一种自然语言，这种自然语言能说，能写，或者被用来人与人之间的沟通。计算机语言明显不包括在内的。HTTP在Accept-Language和Content-Language头域里应用到语言标签（language tag）。
HTTP语言标签的语法和注册和RFC 1766[1]中定义的一样。总之，一个语言标签是由一部分或多部分构成：一个主语言标签和可能为空的子标签系列。
Language-tag = primary-tag*（"-" subtag）
primary = 1*8ALPHA
subtag = 1*8ALPHA
标签中不允许出现空格，标签大小写不敏感（case-insensitive）。由IANA来管理语言标签中的名字。典型的标签包括:
en, en-US, en-cockney, i-cherokee, x-pig-latin
上面的任意两个字母的主标签是一个ISO-639语言的缩，并且两个大写字母的子标签是一个ISO-3166的国家代码。（上面的最后三个标签是未经注册的标签；但是除最后一个之外所有的标签都会将来注册）。
3.11 实体标签 （Entity Tags）
实体标签被用于比较相同请求资源中两个或更多实体。HTTP/1.1在ETag（14.19节），If-match（14.24节），If-None-match（14.26节）和If-Rang（14.27节）头域中运用实体标签。关于它们怎样被当作一个缓存验证器（cache validator）而使用和比较在13.3.3节被定义。一个实体标签由一个给定的晦涩的引用字符串（opaque quoted string），还可能前面带一个弱指示器组成。
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
一个“强实体标签”如果被一个资源的两个实体里共享，那么这两个实体必须在字节上等价。
一个“弱实体标签”是以"W/"前缀的，它可能会被一个资源的两个实体共享，如果这两个实体是等价的，并且能彼此之间能互相替代，并且也不会在语义上有太大改变。一个弱实体标签只能用于弱比较（weak comparison）。
在一个特定资源的所有实体版本里，一个实体标签必须能唯一。一个给定的实体标签值可以被于不同的URI请求用来获得的实体。相同实体标签值运用于不同URI请求获得的实体，并不意味着这些实体是等价的。
3.12 范围单位（Range Units）
HTTP/1.1允许一个客户请求响应实体的一部分。HTTP/1.1在Range（14.35节）和Content-Range（14.16节）头域里应用范围单位（range units）。任何实体根据不同的结构化单元都能被分解是子范围
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
HTTP/1.1中定义的唯一的范围单位是"bytes"。HTTP/1.1实现时可能忽略其他单位指定的范围。
HTTP/1.1被设计允许应用程序实现不依靠有关对范围的了解。
4 HTTP消息
4.1 消息类型（Message Types）
HTTP消息由从客户到服务器的请求和从服务器到客户的响应组成.
HTTP-message = Request|Response ;HTTP/1.1
请求（第5节）和响应（第6节）消息利用RFC 822[9]定义的常用消息的格式，这种消息格式是用于传输实体（消息的负载）。两种类型的消息由开始行（start-line），零个或更多个头域（经常被称作“头”），一个指示头域结束的空行（也就是，一个以CRLF为前缀的什么也没有的行），一个可有可无的消息主体（message-body）。
generic-message = start-line
*（message-header CRLF）
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
为了健壮性，服务器应该忽略任意请求行（Request-Line）前面的空行。换句话说，如果服务器开始读消息流的时候发现了一个CRLF，它应该忽略这个CRLF。
一般一个有问题的HTTP/1.0客户端会在POST请求消息之后产生额外的CRLF。为了重述什么是BNF明确禁止的，一个HTTP/1.1客户端不能在请求前和请求后加一些不必要的CRLF。
4.2 消息头 （Message Headers）
HTTP头域包括常用头（4.5节），请求头（5.3节），响应头（6.2节）和实体头（7.1节）域。它们遵循RFC822[0]3.1节中给出的同一个常规的格式。每一个头域由一个名字（域名）跟随一个":"和域值构成。域名是大小写不敏感的。域值前面可能有任意数量的LWS的。但SP（空格）是首选的。头域能被延升多行，通过在这些行前面加一些SP或HT。应用程本应该遵循“常用格式”当产生HTTP消息时，因为可能存在一些应用程序，他们不能接收任何常用形式之外的形式。.
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *（ field-content | LWS ）
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
filed-content不包括任何前导或后续的LWS（线性空白）:线性空白出现在域值（filed-value）的第一个非空白字符之前或最后一个非空白字符之后。前导或后续LWS可能会被移除而不会改变域值的语意。任何出现在filed-content之间的LWS可能会被一个SP代替在解析域值之前或把这个消息往下流传递时。.
不同域名的头域被接收的顺序是不重要的。然而，首先发送常用头域，然后紧接着是请求头域或者是响应头域，然后是以实体头域结束，这样做是一个好的的方法。
多个消息头域使用同一个域名（filed-name）可能会出现在一些消息中，如果一个头域的域值被定义成一个以逗号隔开的列表。把相同名的多个头域结合成一个“域名：域值”对的形式而不改变消息的语意，可以通过把每一个后续的域值加到第一个里，每一个域值用逗号隔开。同名的头域的接收顺序对合并的域值的解释有重要意义，所以代理（proxy）不能改变域值的顺序，当它把此消息再次转发时。
4.3 消息主体 （Message Body）
HTTP消息的消息主体用来承载请求和响应的实体主体（entity-body）。这些消息主体（message-body）仅仅当传输编码（transfer-coding）应用于传输译码（Transfer-Encoding）头域时才和实体主体（entity-body）不同，其它情况消息主体和实体主体相同。传输译码头域在14.41节阐述。
message-body=entity-body|<entity-body encoded as per Transfer-Encoding>
传输译码头域被用来指明应用程序的传输编码，它是为了保证安全和适合的消息传输。传输译码（Transfer-Encoding）头域是消息的属性，而不是实体的属性，并且沿着请求/响应链能被添加或删除。（然而，3.6节描述了一些限制当使用某个传输编码时）
什么时候消息主体（message-body）允许出现在消息中，这根据不同请求和响应来决定的。
请求中消息主体（message-body）的存在是被请求中消息头域中是否存在内容长度（Content-Length）或传输译码（Transfer-Encoding）头域来暗示的。一个消息主体（message-body）不能被包含在请求里如果请求方法（见5.1.1节）不允许请求里包含实体主体（entity-body）。一个服务器应该能阅读或再次转发请求里的消息主体；如果请求方法不允许包含一个实体主体（entity-body），那么消息主体应该被忽略当服务器处理这个请求时。
对于响应消息，消息里是否包含消息主体依赖相应的请求方法和响应状态码。所有HEAD请求方法的请求的响应消息不能包含消息主体，即使实体头域出现在请求里。所有1XX（信息的），204（无内容的）和304（没有修改的）的响应都不能包括一个消息主体（message-body）。所有其他的响应必须包括消息主体，虽然它可能长度为零.
4.4 消息的长度（Message Length）
一条消息的传输长度（transfer-length）是消息主体（message-body）的长度，当消息主体出现在消息中时；那就是说在实体主体被应用了传输编码（transfer-coding）后。当消息中出现消息主体时，消息主体的传输长度（transfer-length）由下面（以优先权的顺序）决定：:
1。任何不能包含消息主体（message-body）的消息（这种消息如1xx,204和304响应和任何HEAD请求的响应）总是被头域后的第一个空行（译注:CRLF）终止，不管消息里是否有实体头域（entity-header fields）。
2。如果Transfer-Encoding头域（见14.41节）出现，并且它的域值不是”identity”，那么传输长度（transfer-length）被“块”传输编码定义，除非消息因为关闭连接而被终结了。
3。如果Content-Length头域（属于实体头域）（见14.13节）出现，那么它的十进制值（以字节表示）就代表实体主体长度（entity-length，译注：实体长度其实就是实体主体的长度，以后把entity-length翻译成实体主体的长度）也代表传输长度（transfer-length）。Content-Length头域不能包含在消息中，如果实体主体长度（entity-length）和传输长度（transfer-length）两者不相等（也就是说，消息里应用了传输译码（Transfer-Encoding）头域）。如果一个消息即有传输译码（Transfer-Encoding）头域并且也Content-Length头域，后者会被忽略。
4。如果消息用到媒体类型“multipart/byteranges”，并且传输长度（transfer-length）另外也没有指定，那么这种自我定界的媒体类型定义了传输长度（transfer-length）。这种媒体类型不能被利用除非发送者知道接收者能怎样去解析它； HTTP1.1客户端请求里如果出现Range头域并且带有多个字节范围（byte-range）指示符，这就意味着客户端能解析multipart/byteranges响应。
一个Range请求头域可能会被一个不能理解multipart/byteranges的HTTP1.0代理（proxy）再次转发；在这种情况下，服务器必须能定界此消息利用这节的1,3或5项里定义的方法。
5。通过服务器关闭连接能确定消息的传输长度。（关闭连接并不能用来指明请求消息体的结束，因为这样可以让服务器没有机会继续给予响应）。
为了与HTTP/1.0应用程序兼容，包含HTTP/1.1消息主体的请求必须包括一个有效的内容长度（Content-Length）的头域，除非服务器是和HTTP/1.1遵循的。如果一个请求包含一个消息主体并且没有给出内容长度（Content-Length），那么服务器应该以400响应（错误的请求）如果他不能判断消息长度的话，或者以411响应（要求长度）如果它坚持想要收到一个有效内容长度（Content-length）。
所有的能接收实体的HTTP/1.1应用程序必须能接受"chunked"的传输编码（3.6节），因此可以允许这种机制来处理消息当消息的长度不能被提前决定时。
消息不能同时都包括内容长度（Content-Length）头域和非identity传输编码。如果消息包括了一个非identity的传输编码，内容长度（Content-Length）头域必须被忽略.
当内容长度（Content-Length）头域出现一个具有消息主体（message-body）的消息里，它的域值必须精确匹配消息主体里字节数量。HTTP/1.1用户代理必须通知用户当一个无效的长度接收了。
4.5 常用头域（General Header Fields）
有一些头域即适用于请求也适用于响应消息，但是这些头域并不适合被传输的实体。这些头域只能应用与被传输的消息。
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
常用头域的名能被扩展，但这要和协议版本的变化相结合。然而，新的或实验性的头域可能被赋予常用头域的语意，如果通信里的所有参与者都认为他们是常用头域。不被识别的头域会被作为实体头（entity-header）头域来看待。
5 请求（Request）
一个请求消息是从客户端到服务器端的，在消息首行里包含方法，资源指示符，协议版本。
Request = Request-Line ; Section 5.1
*（（ general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ） CRLF） ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
5.1 请求行 （Request-Line）
请求行（Request-Line）是以一个方法标记开始，后面跟随Request-URI和协议版本，最后以CRLF结束。元素是以SP字符分隔。CR或LF是不被允许的除了最后的CRLF。
Request-Line =Method SP Request-URL SP HTTP-Version CRLF
5.1.1方法 （Method）
方法标记指示了在被Request-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
Extension-method = token
资源允许的方法由Allow头域指定（14.7节）。响应的返回码总是通知客户是否一个方法对一个资源在当前是被允许的，因为被允许的方法集合能被动态的改变。一个源服务器应该返回405状态码（方法不能允许）如果此方法对于一个请求资源在服务器那里不被允许，并且返回501状态码（没有实现）如果此方法不被源服务器识别或实现。方法GET和HEAD必须被所有常规目的的服务器支持。所有其它的方法是可选的；然而，如果上面的所有方法都被实现，这些方法必须遵循的语意和第9节指定的相同。
5.1.2请求URL（Request-URI）
Request-URI是一种全球统一资源标识符（３.2 节），并且它指定请求的资源。
Request-URI ="*" | absoluteURI | abs_path | authotity
Request-URI的OPTIONS依赖于请求的性质。星号"*"意味着请求不能应用于一个特定的资源，但是能应用于服务器，并且只能被允许当使用的方法不能应用于资源的时候。举例如下
OPTIONS * HTTP/1.1
当向代理（proxy）提交请求时，绝对URI（absoluteRUI）是不可缺少的。代理（proxy）可能会被要求再次转寄此请求。注意：代理可能再次提交此请求到另一个代理或直接给源服务器。为了避免循环请求，代理（proxy）必须能识别所有的服务器名字，包括任何别名，本地变量，数字IP地址。一个请求行（Request-Line）的例子如下：
ＧET http://www.w3.org/pub/www/TheProject.html HTTP/1.1
为了未来HTTP版本的所有请求能迁移到绝对URI（absoluteURI）地址，所有基于ＨTTP/1.1的服务器必须接受绝对URL地址，即使HTTP/1.1的客户端只向代理产生给绝对URI（absoluteURI）。
authority部分只被用于CONNECT方法（９.9节）．
Request-URI大多数情况是被用于指定一个源服务器或网关（gateway）上的资源。这种情况下，URI的绝对路径（abs_path）必须被用作Request-URI，并且此URI（authority）的网络位置必须在Host头域里指出。例如：客户希望直接从源服务器获取资源，这种情况下，它可能会建立一个TCP连接，此连接是特定于主机”www.w3.org”的80端口的，这是会发送下面行：
GET /pub/WWW/TheProject.html HTTP/1.1
Host：www.w3.org
接下来是请求的其他部分，注意绝对路径不能是空的；如果在原始的URI里没有出现绝对路径，必须给出"／"（服务器根目录）．
Request-URI是以3.2.1节里指定的格式传输。如果Request-URI用"%HEX HEX"[42]编码，源服务器为了解析请求必须能解码它。服务器接收到一个无效的Request-URI时必须以一个合适的状态码响应。
透明代理（proxy）不能重写接收到的Request-URI里的”abs_path”当它转寄此请求到下一个服务器时，除了根据上面声明的把一个空的abs_path用”/”代替。
注：不重写的规则防止了代理（proxy）改变请求的意思，当源服务器不能正确的利用非保留（non-reserved）的URI字符时 。实现者应该知道某些pre-HTTP/1.1代理（proxy）能重写Request-URI。
5.2请求资源 （The Resource Identified by a Request）
请求里资源的精确定位是由请求里的Request-URI和Host头域决定的。
如果源服务器资源不依赖于请求的Host头域指定的主机（译注：可能会存在虚拟主机），那么它会忽略请求的头域当它决定其资源的时候。（对于一个支持Host的HTTP/1.1服务器，在19.6.1.1节描述了其他的需求）.
源服务器如果根据请求里的主机区别资源（这是因为存在虚拟主机和虚拟主机名），它必须遵循下面的规则去决定请求的资源当出现一个HTTP/1.1请求时：
１． 如果Request-URI是绝对地址（absoluteURI），这时请求里的主机存在于Request-URI里。任何出现在请求里Host头域值应当被忽略。
２． 假如Request-URI不是绝对地址（absoluteURI），并且请求包括一个Host头域，则主机由该Host头域值决定．
３． 假如由规则１或规则２定义的主机是一个无效的主机，则应当以一个400（错误请求）错误消息返回。
缺少Host头域的HTTP/1.0请求的接收者可能会推测决定什么样的资源被请求（例如：检查URI的路径对于某个特定的主机是唯一的）。
5.3请求报头域 （Request Header Fields）
请求头域允许客户端传递请求的附加信息和客户端自己的附加信息给服务器。这些头域作为请求的修饰符，这和程序语言方法调用的参数语义是一样的。
请求头（request-header） = Accept ;14.1节
| Accept-Charset ;14.2节
|Accept-Encoding ;14.3节
|Accept-Language ;14.4节
|Authorization ;14.8节
|Expect ;14.20节
|From ;14.22节
|Host ;14.23节
|If-Match ;14.24节
|If-Modified-Since ;14.25节
| If-None-Match ;14.26节
| If-Range ;14.27节
| If-Unmodified-Since ;14.28节
| Max-Forwards ;14.31节
| Proxy-Authorization ;14.34节
| Range ;14.35节
| Referer ;14.36节
|TE ;14.39节
| User-Agent ;14.43节
请求头域的名字是能结合于协议版本而能被扩展的。然而新的或实验性的头域应该被给出请求头域的语义如果通信的所有方都把它看作请求头域。不能识别的头域会被看作实体头域（entity-header）。
６ 响应 （Response）
接收和翻译一个请求消息后，服务器发出一个HTTP响应消息。
response ＝Status-Line ;6.1节
*（（ general-header） ; 4.5节
| response-header ;6.2节
| entity-header）CRLF） ;7.1节
CRLF
[ message-body ] ;7.2节
6.1 状态行 （Status-Line）
响应消息的第一行是状态行（stauts-Line），由协议版本以及数字状态码和相关的文本短语组成,各部分间用空格符隔开，除了最后的回车或换行外，中间不允许有回车换行．
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1状态码与原因短语 （Status Code and Reason Phrase）
状态码是试图理解和满足请求的三位数字的整数码，这些码的完整定义在第十章。原因短语（Reason-Phrase）是为了给出的关于状态码的文本描述。状态码用于控制条件，而原因短语（Reason-Phrase）是让用户便于阅读。客户端不需要检查和显示原因短语。
状态码的第一位数字定义响应类型。后两位数字没有任何分类角色。第一位数字有五种值：
-1xx: 报告的 - 接收到请求，继续进程.
-2xx 成功 - 步骤成功接收，被理解，并被接受
-3xx 重发 - 为了完成请求,必须采取进一步措施.
-4xx 客户端出错 - 请求包括错的顺序或不能完成.
-5xx 服务器出错 - 服务器无法完成显然有效的请求.
下面列举了为HTTP/1.1定义的态码值，和对应的原因短语（Reason-Phrase）的例子。原因短语在这里例举只是建议性的----它们也许被一个局部的等价体代替而不会影响此协议的语义。
Status-Code ＝
"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节: 没找到
|"405" ; 10.4.6节: 不允许的方式
|"406" ; 10.4.7节: 不接受
|"407" ; 10.4.8节: 需要代理验证
|"408" ; 10.4.9节： 请求超时
|"409" ; 10.4.10节； 冲突
|"410" ; 10.4.11节： 停止
|"411" ; 10.4.12节： 需要的长度
|"412" ； 10.4.13节； 预处理失败
|"413" ; 10.4.14节： 请求实体太大
|"414" ; 10.4.15节； 请求-URI太大
|"415" ; 10.4.16节： 不支持的媒体类型
|"416" ； 10.4.17节： 请求的范围不满足
|"417" ; 10.4.18节： 期望失败
|"500" ; 10.5.1节: 服务器内部错误
|"501" ; 10.5.2节: 不能实现
|"502" ; 10.5.3节: 坏网关
|"503" ; 10.5.4节: 服务不能实现
|"504" ; 10.5.5节: 网关超时
|"505" ; 10.5.6节: HTTP版本不支持
|扩展码
extension-code =3DIGIT
Reason-Phrase = *<TEXT,excluding CR,LF>
HTTP状态码是可扩展的。HTTP应用程序不需要理解所有已注册状态码的含义，尽管那样的理解显而易见是很合算的。但是，应用程序必须了解由第一位数字指定的状态码的类型，任何未被识别的响应应被看作是该类型的x00状态，有一个例外就是未被识别的响应不能缓存。例如，如果客户端收到一个未被识别的状态码431，则可以安全的假定请求有错，并且它会对待此响应就像它接收了一个状态码是400的响应。在这种情况下，用户代理（user agent）应当把实体和响应一起提交给用户，因为实体很可能包括人可读的关于解释不正常状态的信息。
６.2响应头域 （Response Header Fields）
响应头域允许服务器传送响应的附加信息，这些信息不能放在状态行（Status-Line）里.。这些头域给出有关服务器的信息以及请求URI（Request-URI）指定的资源的更进一步的访问。
response-header = Accept-Ranges ; 14.5节
|Age ; 14.6节
|Etag ; 14.19节
|Location ; 14.30节
|Proxy-Autenticate ; 14.33节
|Retry-After ; 14.37节
|Server ; 14.38节
|Vary ; 14.44节
|WWW-Authenticate ; 14.47节
响应头域的名字能依赖于协议版本的变化而扩展。然而，新的或者实验性的头域可能会给于响应头域的语义如果通信的成员都能识别他们并把他们看作响应头域。不被识别的头域被看作实体头域。
7 实体（Entity）
如果不被请求的方法或响应的状态码所限制，请求和响应消息都可以传输实体。 实体包括实体头域（entity-header）与实体主体（entity-body），而有些响应只包括实体头域（entity-header）。
在本节中的发送者和接收者是否是客户端或服务器，这依赖于谁发送或谁接收此实体。
7.1 实体报文域（Entity Header Fields）
实体（entity-header）头域定义了关于实体主体的的元信息，或在无主体的情况下定义了请求的资源的元信息。有些元信息是可选的；一些是必须的。
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
扩展头机制允许在不改变协议的前提下定义额外的实体头域，但不保证这些域在接收端能够被识别。未被识别的头域应当被接收者忽略，且必须被透明代理（transparent proxy）转发。
7.2 实体主体（Entity Body）
由HTTP请求或响应发送的实体主体（如果存在的话）的格式与编码方式应由实体的头域决定。
Entity-body= *OCTET
如4。3节所述，实体主体（entity-body）只有当消息主体存在时时才存在。实体主体（entity-body）从消息主体通过传输译码头域（Transfer-Encoding）译码得到，传输译码用于确保消息的安全和合适的传输。
7.2.1类型（Type）
当消息包含实体主体（entity-body）时，主体的数据类型由实体头域Content-Type和Content-Encoding决定。这些头域定义了两层的顺序的编码模型：
Entity-body：=Content-Encoding（ Content-Type（ data） ）
Content-Type指定了下层数据的媒体类型。Content-Encoding可能被用来指定附加的应用于数据的内容编码，经常用于数据压缩的目的，内容编码是请求资源的属性。没有缺省的译码。
任一包含了实体主体的HTTP/1.1消息都应包括Content-Type头域以定义实体主体的媒体类型。如果并且只有媒体类型没有通过Content-Type头域指定时，接收者可能会尝试猜测媒体类型，这通过观察实体主体的内容并且/或者通过观察URI指定资源的扩展名。如果媒体类型仍然不知道，接收者应该把类型看作”application/octec-stream”。
7.2.2实体主体长度（Entity Length）
消息的实体主体长度指的是消息主体在被应用于传输编码（transfer-coding）之前的长度。4.4节定义了怎样去确定消息主体的传输长度。
8 连接
8.1 持续连接（Persistent Connection）。
8.1.1目的
在持续连接之前，为获取每一个URL指定的资源都必须建立了独立的TCP 连接， 这就加重了HTTP服务器的负担，易引起互联网的阻塞。嵌入的图片与其它相关数据通常使用户在短时间内对同一服务器提交多个请求。目前已有针对这些性能问题的分析以及原型实现的结果[26][30]。 对其他方法也有了初步探究，如T/TCP [27]。
持续HTTP 连接有着诸多的优点：
--- 通过建立与关闭较少的TCP连接，不仅节省了路由器与主机（客户端，服务器，代理服务器，网关，隧道或缓存）的CPU时间，还节省了主机用于TCP协议控制块的内存。
---能在连接上进行流水线请求方式。 流水线请求方式能允许客户端执行多次请求而不用等待每一个请求的响应（译注：即客户端可以发送请求而不用等待以前的请求的响应到来后再发请求），并且此时只进行了一个TCP连接，从而效率更高，减少了时间。
--- 网络阻塞会被减少，这是由于TCP连接后减少了包的数量，并且由于允许TCP有充分的时间去决定网络阻塞的状态。
--- 因为无须在创建TCP连接时的握手上耗费时间，而使后续请求的等待时间减少。
---HTTP改进的越来越好，因为在不需要关闭TCP连接的代价下可以报告错误。将来的HTTP版本客户端可以乐观的尝试一个新的特性，但是如果和老的服务器通信时，在错误被报告后就要用旧的语义而进行重新尝试连接。
HTTP实现应该实现持久连接。
8.1.2总体操作
HTTP/1.1 与早期HTTP 版本的一个显著区别在于持续连接是任何HTTP/1.1连接的缺省方式。也就是说，除非另有指定，客户端总应当假定服务器会保持持续连接，即便在接到服务器的出错响应时也应如此。
持续连接提供了一种可以由客户端或服务器发信号来终止TCP连接的机制。利用Connect头域（14。10节）可以产生终止连接信号。一旦出现了终止连接的信号，客户端便不可再向此连接提出任何新请求。
8.1.2.1 协商（Negotiation）
除非请求的Connect头域中包含了"close"标签，HTTP/1.1服务器总可以假定HTTP/1.1 客户端想要维持持续连接（persistent connection）。如果服务器想在发出响应后立即关闭连接，它应当发送一个含”close”的Connect头域。
一个HTTP/1.1客户端可能期望保持连接一直开着，但这必须是基于服务器响应里是否包含一个Connect头域并且此头域里是否包含”close”。如果客户端不想为更多的请求维持连接，它应该发送一个值为”close”的Connect头域。
如果客户端和服务器之一在发送的Connect头域里包含”close”，那么客户端的请求将会变为此连接的最后一个请求。。
客户端和服务器不应该认为持续连接是低于1.1的HTTP版本所拥有的，除非它被显示地指明了。19.6.2节指出了跟HTTP/1.1客户端兼容的更多信息。
8.1.2.2 流水线（pilelining）
支持持续连接（persistent conncetio）的客户端可以以流水线的方式发送请求（即无须等待响应而发送多个请求）。服务器必须按接收请求的顺序发送响应。
假定持续连接并且在连接建立后进行流水线方式请求的客户端应该准备去重新尝试他们的连接如果第一个流水线请求方式尝试失败。如果客户端重新尝试连接，在客户端知道连接是持续之前客户端不能进行流水线发送请求。客户端必须准备去重新发送请求如果服务器在响应所有对应的请求之前关闭连接
客户端不应该利用非等幂的方法或者非等幂的方法序列（见9.1.2节）进行流水线方式的请求。否则一个过早的传输层连接的终止可能会导致不确定的结果。一个可能希望发送一个非等幂方法请求的客户端只有接收了上次它发出请求的响应后才能再次发送请求给服务器。
8.1.3代理服务器 （Proxy Servers）
它是非常重要的因为代理服务器正确地实现了Connect头域的属性，这在14.10节指出了。
代理服务器必须分别向和它相连的客户端或者源服务器（或其他的代理服务器）指明持续连接。每一个持续连接只能应用于一个传输层连接。
代理服务器不能和一个HTTP/1.0客户端建立一个HTTP/1.1持续连接（但是参见RFC2068[33]里的关于许多HTTP/1.1客户端利用Keep-Alive头域的问题的讨论）。
8.1.4实际的考虑 （Practical Considerations）
服务器通常有一个时限值，超过一定时间即不再维持处于非活动的连接。代理服务器会选一个较高的值，因为客户端很可能会与同一服务器建立多个连接。持续连接方式的采用对于客户端与服务器的时限均未提出任何要求。
当客户端或服务器希望超时终止时， 它应该按规范终止传输连接。客户端与服务器端应始终注意对方是否终止了连接，并适当的予以响应。若客户端或服务器未能及时检测到对方已终止了连接，将会造成不必要的网络资源浪费。
客户端，服务器，或代理服务器可能在任意时刻会终止传输连接。比如，客户端可能正想发出新的请求，而此时服务器却决定关闭"闲置"的连接。在服务器看来，连接已经因为闲置被关闭了， 但客户端认为我正在请求。
这表明客户端，服务器与代理服务器必须有能力从异步的连接终止事件中恢复。只要请求是等幂的（见9.1.2节），客户端软件应该能重新打开传输层连接并重新传输遗弃的请求序列而不需要用户进行交互来实现。对非等幂方法的请求不能自动进行重试请求，尽管客户代理（user agent）可能能提供一个人工操作去重试这些请求。应该用用户代理（user-agent）软件对应用程序语义识别的确认来替代用户的确认。如果再次重试请求失败，那么就不能再进行重复请求了。
服务器尽可能应该在每次连接中至少响应一个请求。除非出于网络或客户端的故障，服务器不应在传送响应的中途断开连接。
使用持续连接的客户端应限制与某一服务器同时连接的个数。单用户客户端不应与任一服务器或代理服务器保持两个以上的连接。代理服务器与其它服务器或代理服务器之间应维护2*N个连接，其中N是同时在线的用户数。这些准则是为了改善响应时间和和避免阻塞。
8.2 消息传送要求（Message Transmission Requirements）
8.2.1持续连接与流量控制 （Persistent Connections and Flow Control）
HTTP/1.1服务器应当保持持续连接并使用TCP流量控制机制来解决临时过载，而不是在终止连接后指望客户端的重试。后一方法会恶化网络阻塞。
8.2.2监视连接中出错状态的消息
HTTP/1.1（或更新）客户端应在发送消息主体的时候同时监视网络连接是否处于出错状态。若客户端发现了错误，它应当立即停止消息主体的的传送。若正文是以块传输编码方式发送的（3.6节），可以用长度为零的块和空尾部来提前标记报文结束。若消息主体前有Content-Length头域，则客户端必须关闭连接。
8.2.3 100状态码的用途
100状态码（继续，见10.1.1节）的目的在于允许客户端判定服务器是否愿意接受客户端发来的消息主体（基于请求头域）在客户端发送此请求消息主体前。 在有些情况下，如果服务器拒绝查看消息主体，这时客户端发送消息主体是不合适的或会降低效率。
HTTP/1.1客户端的要求：
--- 若客户端要在发送请求消息主体之前等候100（继续）响应，则它必须发送一个Expect请求头域（见14.20节），并且值是”100-continue”。
--- 客户端不能发送一个值是”100-continue”的Expect请求头域，如果此客户端不打算发送带消息主体的请求。
由于存在旧的实现方法，协议允许二义性的情形存在，这在客户端在发送”Expect:100-continue”后而没有接收一个417（期望失败）状态码或着100（继续）状态码的情况下发生。因此，当一个客户端发送此头域给一个源服务器（可能通过代理），此服务器也没有以100（继续）状态码响应，那么客户端不应该在发送请求消息的主体前无限等待。
HTTP’/1.1源服务器的要求：
--- 当接收一个包含值为”100-contitue”的Expect请求头域的请求时，源服务器必须或者以100（继续）状态码响应并且继续从输入流里接收数据，或者以final状态码响应。源服务器不能在发送100（继续）状态码响应之前接收请求主体。如果服务器以final状态码响应后，它可能会关闭传输层连接或者它也可能会继续接收或遗弃剩余的请求。但是既然它返回了一个final状态码的响应，它就不能再去那个执行请求的方法（如：POST方法，PUT方法）。
--- 如请求消息不含值为"100-continue"的Expect请求头域， 源服务器不应发送100（继续）响应。当请求来自HTTP/1.0（或更早）的客户端时也不得发送100（继续）响应。对此规定有一例外：为了与RFC 2068兼容，源服务器可能会发送一个100（继续）状态响应以响应HTTP/1.1的PUT或POSt请求，虽然这些请求中没有包含值为”100-continue”的Expect请求头域。这个例外的目的是为了减少任何客户端因为等待100（继续）状态响应的延时，但此例外只能应用于HTTP/1.1请求，并不适合于其他HTTP版本的请求。
--- 若已经接收到部分或全部请求的消息的主体，源服务器可以不需要发100（继续）响应。
--- 发送100（继续）响应的源服务器必须最终能发送一个final状态响应，一旦请求消息主体被它接收到并且已经被它处理了，除非源服务器过早切断了传输层连接。
--- 若源服务器接收到不含值为"100-contitue"的Expect请求头域的请求，该请求含有请求消息主体，而服务器在从传输层连接上接收整个请求消息主体前返回一个final的状态响应，那么此源服务器不能关闭传输层连接直到它接收了整个请求或者直到客户端关闭了此连接。否则客户端可能不会信任接收此响应消息。然而，这一要求不应该被解释用来防止服务器抵抗服务攻击，或者防止服务器被客户端实现攻击。
对HTTP/1.1代理服务器的要求：
--- 若代理服务器接到一个请求，此请求包含值为"100-continue"的Expect请求头域，并且代理服务器可能知道下一站点的服务器遵循HTTP/1.1或更高版协议，或者不知道下一站点服务器的HTTP版本，那么它必须包含此Expect头域来转发此请求。
--- 若代理服务器知道下一站点服务器版本是HTTP/1.0或更低，则它不能转发此请求，并且它必须以417（期望失败）状态响应。
--- 代理服务器应当维护一个缓存，以记录最近访问下一站点服务器的HTTP版本号。
--- 若接收到的请求来自于版本是HTTP/1.0（或更低）的客户端，并且此请求不含值为"100-continue"的Expect请求头域，那么代理服务器不能转发100（继续）响应。 这一要求可覆盖1xx响应转发的一般规则（参见10.1节）。
8.2.4服务器过早关闭连接时客户端的行为
如果HTTP/1.1 客户端发送一条含有消息主体的请求消息，但不含值为"100-continue"的Expect请求头域，并且客户端直接与HTTP/1.1源服务器相连，并且客户端在接收到服务器的状态响应之前看到了连接的关闭，那么客户端应该重试此请求。在重试时，客户端可以利用下面的算法来获得可靠的响应。
1． 向服务器发起一新连接。
2． 发送请请求头域。
3． 初始化变量R，使R的值为通往服务器的往返时间的估计值（比如基于建立连接的时间），或在无法估计往返时间时设为一常数值5秒。
4． 计算T=R*（2**N），N为此前重试请求的次数。
5． 等待服务器出错响应，或是等待T秒（两者中时间较短的）。
6． 若没等到出错响应，T秒后发送请求的消息主体。
7． 若客户端发现连接被提前关闭，转到第1步，直到请求被接受，接收到出错响应，或是用户因不耐烦而终止了重试过程。
在任意点上，客户端如果接收到服务器的出错响应，客户端
--- 不应再继续发送请求， 并且
--- 应该关闭连接如果客户端没有完成发送请求消息。
９ 方法定义（Method Definitions）
HTTP/1.1常用方法的定义如下。虽然方法可以被展开，但新加的方法不能认为能分享与扩展的客户端和服务器同样的语义。
Hst请求头域（见13.23节）必须能在所有的HTTP/1.1请求里出现。
9.1 安全和等幂（Idempotent）方法
9.1.1安全方法（Safe Methods）
实现者应当知道软件是代表用户在互联网上进行交互，并且应该小心地允许用户知道任何它们可能采取的动作(action)，这些动作可能给他们自己或他人带来无法预料的结果。
特别的，GET和HEAD方法仅仅应该获取资源而不是执行动作（action）。这些方法应该被考虑是“安全”的。可以让用户代理用其他的方法，如：POST，PUT，DELETE，这样用户代理就能知道这些方法可能会执行不安全的动作。
自然的，保证当服务器由于执行GET请求而不能产生副作用是不可能的；实际上，一些动态的资源会考虑这个特性。用户并没有请求这些副作用，因此不需要对这些副作用负责。
9.1.2等幂方法（Idempotent Mehtods）
方法可以有等幂的性质因为（除了出错或终止问题）N>0个相同请求的副作用同单个请求的副作用的效果是一样（译注：等幂就是值不变性，相同的请求得到相同的响应结果，不会出现相同的请求出现不同的响应结果）。方法GET，HEAD，PUT，DELETE都有这种性质。同样，方法OPTIONS和TRACE不应该有副作用，因此具有内在的等幂性。然而，有可能几个请求的序列是不等幂的，即使在那样的序列中所有方法都是等幂的。（如果整个序列整体的执行的结果总是相同的，并且此结果不会因为序列的整体，部分的再次执行而改变，那么此序列是等幂的。）例如，一个序列是非等幂的如果它的结果依赖于一个值，此值在以后相同的序列里会改变。
根据定义，一个序列如果没有副作用，那么此序列是等幂的（假设在资源集上没有并行的操作）。
9.2 OPTIONS（选项）
OPTIONS方法表明请求想得到请求/响应链上关于此请求里的URI（Request-URI）指定资源的通信选项信息。此方法允许客户端去判定请求资源的选项和/或需求，或者服务器的能力，而不需要利用一个资源动作（译注：使用POST，PUT，DELETE方法）或一个资源获取（译注：用GET方法）方法。
这种方法的响应是不能缓存的.。
如果OPTIONS请求消息里包括一个实体主体（当请求消息里出现Content-Length或者Transfer-Encoding头域时），那么媒体类型必须通过Content-Type头域指明。虽然此规范没有定义如何使用此实体主体，将来的HTTP扩展可能会利用OPTIONS请求的消息主体去得到服务器得更多信息。一个服务器如果不支持OPTION请求的消息主体，它会遗弃此请求消息主体。
如果请求URI是一个星号（"*"）,，OPTIONS请求将会应用于服务器的所有资源而不是特定资源。因为服务器的通信选项通常依赖于资源，所以”*”请求只能在“ping”或者“no-op”方法时才有用；它干不了任何事情除了允许客户端测试服务器的能力。例如：它能被用来测试代理是否遵循HTTP/1.1。
如果请求URI不是一个星号（"*"）,，OPTIONS请求只能应用于请求URI指定资源的选项。
200响应应该包含任何指明选项性质的头域，这些选项性质由服务器实现并且只适合那个请求的资源（例如，Allow头域），但也可能包一些扩展的在此规范里没有定义的头域。如果有响应主体的话也应该包含一些通信选项的信息。这个响应主体的格式并没有在此规范里定义，但是可能会在以后的HTTP里定义。内容协商可能被用于选择合适的响应格式。如果没有响应主体包含，响应就应该包含一个值为“0”的Content-Length头域。
Max-Forwards请求头域可能会被用于针对请求链中特定的代理。当代理接收到一个OPTIONS请求，且此请求的URI为absoluteURI，并且此请求是可以被转发的，那么代理必须要检测Max-Forwards头域。如果Max-Forwards头域的值为“0”，那么此代理不能转发此消息；而是，代理应该以它自己的通信选项响应。如果Max-Forwards头域是比0大的整数值，那么代理必须递减此值当它转发此请求时。如果没有Max-Forwards头域出现在请求里，那么代理转发此请求时不能包含Max-Forwards头域。
9.3 GET
GET方法意思是获取被请求URI（Request-URI）指定的信息（以实体的格式）。如果请求URI涉及到一个数据生成过程，那么这个生成的数据应该被作为实体在响应中返回，但这并不是过程的资源文本，除非资源文本恰好是过程的输出（译注：URI指示的资源是动态生成的）。
如果请求消息包含 If-Modified-Since,，If-Unmodified-Since，If-Match,，If-None-Match,或者 If-Range头域,，GET的语义将变成“条件（conditionall） GET”。一个条件GET方法会请求满足条件头域的实体。条件GET方法的目的是为了减少不必要的网络使用，这通过利用缓存的实体的更新，从而不用多次请求或传输客户已经拥有的数据。.
如果请求方法包含一个Range头域，那么GET方法就变成“部分Get”方法。一个部分GET会请求实体的一部分，这在14.35节里描述了。 部分GET方法的目的是为了减少不必要的网络使用，这通过允许获取部分实体，从而不需要传输客户端已经拥有的数据。
GET请求的响应是可缓存的（cacheable）如果此响应满足第13节HTTP缓存的要求。
看15.1.3节关于GET请求用于表单时安全考虑。
9.4 HEAD
HEAD方法和GET方法一致，除了服务器不能在响应里返回消息主体。HEAD请求响应里HTTP头域里的元信息应该和GET请求响应里的元信息一致。此方法被用来获取请求实体的元信息而不需要传输实体主体（entity-body）。此方法经常被用来测试超文本链接的有效性，可访问性，和最近的改变。.
HEAD请求的响应是可缓存的，因为响应里的信息可能被用于更新以前的那个资源的缓存实体.。如果出现一个新的域值指明了缓存实体和当前源服务器上实体的不同（可能因为Content-Length，Content-MD5，ETag或Last-Modified值的改变），那么缓存（cache）必须认为此缓存项是过时的（stale）。
9.5 POST
POST 方法被用于请求源服务器接受请求中的实体作为请求资源的一个新的从属物。POST被设计涵盖下面的功能。
-已存在的资源的注释；
-发布消息给一个布告板，新闻组，邮件列表，或者相似的文章组。
-提供一个数据块，如提交一个表单给一个数据处理过程。
-通过追加操作来扩展数据库。
POST方法的实际功能是由服务器决定的，并且经常依赖于请求URI（Request-URI）。POST提交的实体是请求URI的从属物，就好像一个文件从属于一个目录，一篇新闻文章从属于一个新闻组，或者一条记录从属于一个数据库。
POST方法执行的动作可能不会对请求URI所指的资源起作用。在这种情况下，200（成功）或者204（没有内容）将是适合的响应状态，这依赖于响应是否包含一个描述结果的实体。
如果资源被源服务器创建，响应应该是201（Created）并且包含一个实体，此实体描述了请求的状态并且此实体引用了一个新资源和一个Location头域（见14.30节）。
POST方法的响应是可缓存的。除非响应里有Cache-Control或者Expires头域指示其响应不可缓存。然而，303（见其他）响应能被利用去指导用户代理（agent）去获得可缓存的响应。
POST 请求必须遵循8.2节里指明的消息传输需求。
参见15.1.3节关于安全性的考虑.
9.6 PUT
PUT方法请求服务器去把请求里的实体存储在请求URI（Request-URI）标识下。如果请求URI（Request-URI）指定的的资源已经在源服务器上存在，那么此请求里的实体应该被当作是源服务器此URI所指定资源实体的修改版本。如果请求URI（Request-URI）指定的资源不存在，并且此URI被用户代理（user agent，译注：用户代理可认为是客户浏览器）定义为一个新资源，那么源服务器就应该根据请求里的实体创建一个此URI所标识下的资源。如果一个新的资源被创建了，源服务器必须能向用户代理（user agent） 发送201（已创建）响应。如果已存在的资源被改变了，那么源服务器应该发送200（Ok）或者204（无内容）响应。如果资源不能根据请求URI创建或者改变，一个合适的错误响应应该给出以反应问题的性质。实体的接收者不能忽略任何它不理解的Content-*（如：Content-Range）头域，并且必须返回501（没有被实现）响应。
如果请求穿过一个缓存（cache），并且此请求URI（Request-URI）指示了一个或多个当前缓存的实体，那么这些实体应该被看作是旧的。PUT方法的响应不应该被缓存。
POST方法和PUT方法请求最根本的区别是请求URI（Request-URI）的含义不同。POST请求里的URI指示一个能处理请求实体的资源（译注：此资源可能是一段程序，如jsp里的servlet） 。此资源可能是一个数据接收过程，一个网关（gateway，译注：网关和代理服务器的区别是：网关可以进行协议转换，而代理服务器不能，只是起代理的作用，比如缓存服务器其实就是一个代理服务器），或者一个单独接收注释的实体。而PUT方法请求里有一个实体一一用户代理知道URI意指什么，并且服务器不能把此请求应用于其他URI指定的资源。如果服务器期望请求被应用于一个不同的URI，那么它必须发送301（永久移动了）响应；用户代理可以自己决定是否重定向请求。
一个独立的资源可能会被许多不同的URI指定。如：一篇文章可能会有一个URI指定当前版本，此URI区别于其文章其他特殊版本的URI。这种情况下，一个通用URI的PUT请求可能会导致其资源的其他URI被源服务器定义。
HTTP/1.1没有定义PUT方法对源服务器的状态影响。
PUT请求必须遵循8.2节中的消息传输要求。
除非特别指出，PUT方法请求里的实体头域应该被用于资源的创建或修改。
9.7 DELETE（删除）
DELETE方法请求源服务器删除请求URI指定的资源。此方法可能会在源服务器上被人为的干涉（或其他方法）。客户端不能保证此操作能被执行，即使源服务器返回成功状态码。然而，服务器不应该指明成功除非它打算删除资源或把此资源移到一个不可访问的位置。
如果响应里包含描述成功的实体，响应应该是200（Ok）；如果DELETE动作没有通过，应该以202（已接受）响应；如果DELETE方法请求已经通过了，但响应不包含实体，那么应该以204（无内容）响应。
如果请求穿过缓存，并且请求URI（Request-URI）指定一个或多个缓存当前实体，那么这些缓存项应该被认为是旧的。DELETE方法的响应是不能被缓存的。
9.8 TRACE
TRACE方法被用于激发一个远程的，应用层的请求消息回路（译注：TRACE方法让客户端测试到服务器的网络通路，回路的意思如发送一个请返回一个响应，这就是一个请求响应回路，）。最后的接收者或者是接收请求里Max-Forwards头域值为0源服务器或者是代理服务器或者是网关。TRACE请求不能包含一个实体。
TRACE方法允许客户端知道请求链的另一端接收什么，并且利用那些数据去测试或诊断。Via头域值（见14.45）有特殊的用途，因为它可以作为请求链的跟踪信息。利用Max-Forwards头域允许客户端限制请求链的长度去测试一串代理服务器是否在无限回路里转发消息。
如果请求是有效的，响应应该在响应实体主体里包含整个请求消息，并且响应应该包含一个Content-Type头域值为”message/http”的头域。TRACE方法的响应不能不缓存。
9.9 CONNECT（连接）
HTTP1.1协议规范保留了CONNECT方法，此方法是为了能用于能动态切换到隧道的代理服务器（proxy，译注：可以为代理，也可以是代理服务器）。
10.状态码定义
每一个状态码在下面定义，包括此状态码依赖于方法的描述和响应里需要的任何元信息的描述。
10.1 通知的 1xx
这类状态代码指明了一个备用的响应，包含一个Status-Line和可选的头域，并且一一个空行结束（译注：空行就是CRLF）。没有必须的头域对这类状态码。因为HTTP/1.0没有定义任何1xx状态码，所以服务器不能发送一个1xx响应给一个HTTP/1.1客户端，除了实验性的目的。
客户端必须能准备去接受一个或多个1xx状态响应优先于一个常规响应，即使客户端不期望100（继续）状态响应。不被客户端期望的1xx状态响应可能会被用户代理忽略。
代理服务器必须能转发1xx响应，除非代理服务器和它的客户端的连接关闭了，或者除非代理服务器自己响应请求并产生1xx响应。（例如：如果代理服务器添加了”Expect:100-continue”头域当转发请求时，那么它不必转发相应的100（继续）响应。）
10.1.1 100 继续 （Continue）
100状态响应告诉客户端应该继续请求。100响应是个中间响应，它被用于通知客户端请求的初始部分已经被接收了并且此请求还没有被服务器丢弃。客户端应该继续发送请求的剩余部分，或者如果此请求已经完成了，客户端会忽略此100响应。服务器必须发送一个final响应在请求接收后。见8.2.3节关于此状态码的讨论和使用。
10.1.2 101切换协议 （Switching Protocols）
服务器理解和愿意遵循客户端这样的请求，此请求通过Upgrade消息头域（见14.42节）指明在连接上应用层协议的改变。 服务器将会切换到响应里Upgrade头域里指明的协议，然后紧接着跟随一个结束此101响应的空行。
只有当协议切换时能受益，协议才应该切换。例如，当传输资源时，切换到一个新的HTTP版本比旧的版本要好，或者切换到一个实时的，同步的协议带来好处时，我们都应该考虑切换。
10.2 成功 2xx
这类状态码指明客户端的请球已经被服务器成功的接收了，理解了，并且接受了。
10.2.1 200 OK
此状态码指明客户端请求已经成功了。响应返回的信息依赖于请求里的方法，例如：
GET 请求资源的相应的实体已经包含在响应里并返回给客户端。
HEAD 相应于请求资源实体的实体头域已经被包含在无消息主体的响应里。
POST 响应里已经包含一个实体，此实体描述或者包含此POST动作执行的结果
TRACE 响应里包含一个实体，此实体包含终端对服务器接的请求消息。
10.2.2 201 已创建（Created）
请求已经被服务器满足了并且已经产生了一个新的资源。新创建的资源的URI在响应的实体里返回，但是此资源最确定的URI是在Location头域里给出的。响应应该含有一实体，此实体包含此资源的特性和位置，用户或用户代理能从这些特性和位置里选择最合适的。实体格式被Content-Type头域里媒体类型指定。源服务器必须能在返回201状态码之前建立资源。如果动作（译注：这里指能创建资源的方法，如POST方法）不能被立即执行，那么服务器应该以202（接受）响应代替。
一个201响应可以包含一个ETag响应头域，此头域为请求的变量（译注：变量的含义见第1.3节“变量”的解释）指明当前的实体标签（entity tag）值，当资源被创建时，见14.19节。
10.2.3 202 接受（Accepted）
请求已经被接受了，但是还没有对此请求处理完。请求可能处理完也可能没有最终被处理完，因为当处理发生的时候服务器可能会发现此请求不能被处理。
202响应是非委托的。这是为了允许服务器为其他处理（如：每天执行一次的过程）而接受一个请求从而不需要用户代理和服务器之间在处理完成之前必须进行持久连接。响应里的实体应该包含请求当前状态的声明并且应该包含一个状态监视指针或一些用户期望何时请求被满足的评估。
10.2.4 203 非权威信息（Non-Authoritative information）
此状态码响应指明响应里的实体头域里的元信息对源服务器来说是没有意义的，这些元信息是从局部的或第三方的响应副本里得到的。这些元信息可能是源服务器版本的子集或超集。如，包含一个存在本地的资源注释信息就可以产生一个源服务器能理解的元信息的超集。203响应状态码的使用并不是必须的并且只有在响应是非200（Ok）响应时才是合适的。
10.2.5 204 无内容 （No Content）
服务器已经满足了请求但不需要返回一个实体，并且可能只想返回更新了的元信息。204状态响应可能包含一个新的或更新了的，和请求变量（译注：变量是资源的一种表现形式，这和rest架构里的定义是一样的，所以这里我们可以理解请求变量是请求资源的一种表现形式）相联系的元信息（元信息以实体头域的形式表式）。
利用此204响应，客户端如果是一个用户代理，它就可以不用改变引起请求发送的文档视图（译注：如一篇html文档在浏览器里呈现的样子）。204状态响应主要的目的是允许输入，而不必引起用户代理当前文档视图的改变，虽然一些新的或更新了的元信息可能会应用于用户代理视图里的此文档。
204响应不能包含一个消息主体，并且在头域后包含一个空行结束。
10.2.6 205 重置内容（Reset Content）
205状态响应是服务器告诉用户代理应该重置引起请求被发送的文档视图。此响应主要的目的是清空文档视图表单里的输入框以便用户能输入其它信息。此响应不能包含一个实体。
10.2.7 206 部分内容（Partial Content）
服务器已经完成了客户端对资源的部分GET请求。请求必须包含一个Range头域（14.35节）用来指出想要的范围，并且也有可能包含一个If-Range头域（见14.27节）来使请求成为一个条件请求。
206状态的响应必须包含以下的头域：
- 或者Content-Range头域，此头域指明了响应里的范围；或者一个值为”multipart/byteranges”的Content-Type头域和为每部分指明范围的Content-Range头域。如果一个Content-Length头域出现在响应里，它的值必须是实际的消息主体的字节数。
- Date头域
- ETag 和/或 Content-Location头域，如果这些头域已经在以前相同请求的200响应里返回过。
- Expire，Cache-Control，和/或者Vary头域，如果域值与同一变量以前响应中的域值不一样。
如果206响应是使用了强缓存验证（见13.3.3）的If-Range请求的结果，那么此响应不应该包含其他的实体头域。如果响应是使用了弱缓存验证的If-Range请求的结果，那么响应不能包含其他的实体头域；这能防止出现在缓存的实体主体和更新的头域之间的不一致性。其他的情况下，响应必须包含所有的实体头域，这些头域可能已经在以前的相同请求的200响应里返回过。
缓存不能把206响应和以前的缓存内容结合如果ETag或Last-Modified头域并不能精确匹配，见13.5.4。
一个不能支持Range和Content-Range头域的缓存不能缓存206（部分的）响应。
10.3 重新定向 3xx.
这类状态码指明用户代理需要更进一步的动作去完成请求。进一步的动作可能被用户代理自动执行而不需要用户的交互，并且进一步动作请求的方法必须为GET或HEAD。一个客户端应该发现无限的重定向回路，因为此回路能产生网络拥挤。
注意：以前此规范版本建议一个最多能有五个重定向。内容开发者应该知道客户端可能存在这个限制。
10.3.1 300 多个选择.（Multiple Choices）
资源对应有多个表现形式，客户端请求资源的表现形式对应于其中的一个，每个表现形式都有一个指向自己的位置(location)，并且代理驱动协商（agent-driven negotiation）能选择一个更适的表现形式并重定向请求到那个表现形式的位置。
除非是HEAD请求，否则300状态响应应该包含一个实体，此实体包含一个资源特性和位置列表，从这个列表里用户或用户代理能选择最合适的资源的表现形式。实体格式被Content-Type头域里的媒体类型指定。依赖于此格式和用户代理的能力，用户代理选择最合适的表现形式的行为可能会被自动执行。然而，此规范并没有定义自动执行行为的标准。
如果服务器能确定更好的表现形式，它应该为此表现形式在Location头域里包含一个特定的URI来指明此表现形式的位置；用户代理可能会利用此Location头域自动重定向。300状态响应是可缓存的除非被特别指明。
10.3.2 301 永久移动 （Moved Permanently）
请求资源被赋于一个新的永久的URI，并且任何将来对此资源的引用都会利用此301状态响应返回的URI。具有链接编辑能力的客户端应该能自动把请求URI的引用转到到服务器返回的新的引用下。此响应是能缓存的除非另外声明。
新的永久URI应该在响应中被Location头域给定。除非请求方法是HEAD，否则此响应的头域应该包含对此新URI超文本链接的一个超文本提示。
如果客户端接收了一个301状态响应，此响应相应的请求的方法不是GET或HEAD，那么用户代理不能自动重定向请求，除非它能被用户确认，因为这可能会改变请求提交的条件。
注意：当客户端在接收了301状态码响应后，会重定向POST请求，一些已经存在的HTTP/1.0用户代理将错误的把此请求变成一个GET请求。
10.3.3 302 发现(Found)
请求的资源放在一个不同的暂时的URI下。因为重定向可能会偶尔被改变，客户端应该继续利用请求URI(Request-URI)为将来的请求。302响应是只有在Cache-Control或Expires头域指明的情况下才能被缓存。
临时的URI应该在Location头域里指定。除非请求方法是HEAD，否则响应的实体应该包含指向此新URI的超文本链接的短超超文本提示。
如果302状态代码在一个不是GET和HEAD方法请求的响应中，用户代理不能自动重定向请求除非用户确认可以自动重定向，因为这能改变请求提交的的条件。
注意：RFC1945和RFC2068指定客户端不能在重定向请求的时候改变请求方法。然而，大多数用户代理实现把302响应看成是303响应，根据Location头域值的URI执行GET请求，不管原始的请求方法。303和307状态响应的目的是为使服务器明白客户端期望哪种类型的重定向。
10.3.4 303 见其他(See Other)
请求的响应被放在一个不同的URI下，并且应该用GET方法获得那个资源。此方法的存在主要是允许POST执行脚本的输出重定向到用户选择的资源。新的URI并不是原始请求资源的代替引用。303响应不能被缓存，但是再次重定向请求的响应应该被缓存。
不同的URI应该在Location头域里指定。除非请求方法是HEAD，303响应的实体应该包含一个短的指向新的URI链接的超文本提示。
注意：许多HTTP/1.1以前版本的用户代理不能理解303状态响应。当这些客户端比较关注于互操作性的时候，302状态码应该被代替利用，因为大多用户代理对302响应的理解就是303响应。
10.3.5 304 没有被改变(Not Modified)
如果客户端已经执行了条件GET请求，并且访问服务器资源是允许的，但是服务器上的文档并没有被改变，那么服务器应该以此状态码响应。304响应不能包含一个消息主体(message-body)，并且在头域后面总是以一个空行结束。
此响应必须包含下面的头域：
-Date，除非14.18.1指明的那些规则下Date是可以遗漏的。如果时钟不准确的源服务器遵循这些规则，并且代理服务器和客户端在接收了一个没有Date头域的响应后加上了自己的Date（这在RFC 2086里声明了，见14.19节），缓存将会正确地操作。
-ETag 和/或 Content-Location，如果这些头域已经在相请求的200响应里出现过。
Expires，Cache-Control，和/或 Vary，如果这些头域的域值可能与以前相同请求的响应的域值不一致。
如果条件GET用强缓存验证（见13.3.3）节，那么响应不应该包含其他的实体头域。当条件GET用于弱缓存验证时，那么响应不能包含其他的实体头域；这能防止缓存的实体主体和更新了的头域之间的不一致性。
如果304响应指明实体不能被缓存，那么此缓存必须遗弃此响应，并且以无条件请求重复请求。
如果缓存利用一个304响应去更新一个缓存项，那么此缓存必须更新缓存项里关于响应里新的域值的那些域值。
10.3.6 305 使用代理服务器 （User Proxy）
请求资源必须能通过代理服务器访问，代理服务器的地址在响应的Location头域里指定。Location头域指定了代理服务器的URI。接收者被期望通过代理服务器重复此请求，305响应必须能被源服务器产生。
注意：RFC 2068并没有说明305响应的目的是重定向一个独立请求，并且只能被源服务器产生。不注意这些限制会有重要的安全后果。
10.3.7 306没有使用的（unused）
306状态码被用于此规范以前的版本，是不再使用的意思，并且此状态码被保留。
10.3.8 307临时重发（Temporary Redirect）
请求的资源临时存在于一个不同的URI下。由于重新向可能会偶尔改变，所以客户端应该继续利用此请求URI（Request-URI）为将来的请求。307响应只有被Cache-Control或Expire头域指明时才能被缓存。
临时URI应该在响应的Location头域里给定。除非请求方法是HEAD，否则响应的实体应该包含一个指向新URI的超文本链接提示，因为许多HTTP/1.1以前的用户代理不能理解307状态响应。因此，此提示应该包含用户重复原始请求到新的URI的必需的信息。
如果307状态响应.对应的请求的方法不是GET或HEAD，那么用户代理不能自动重定向此请求除非它能被用户确认它可以重定向，因为这可能改变请求提交的条件。
10.4 客户错误 4xx
状态码4xx类的目的是为了指明客户端出现错误的情况。除了当响应一个HEAD请求，服务器应该包含一个实体，此实体包含一个此错误请求的解释。此状态码对所有请求方法都是适合的。用户代理应该展示任何响应里包含的实体给用户。
如果客户端发送数据，利用TCP的服务器实现应该小心确保客户端回复包含在响应里的接收包，这在服务器关闭此输入连接前。如果在关闭连接后，客户端继续发送数据给服务器，那么服务器的TCP栈将发送一个重置包给客户端，
10.4.1 400 坏请求（Bad Request）
请求不能被服务器理解，由于错误的语法。客户端不应该没有改变请求而重复请求。
10.4.2 401 未授权的 （Unauthorized）
请求需要用户授权。响应必须包含一个WWW-Authenticate头域（见14.47），此头域包含一个适用于请求资源的授权的激发。客户端会以一个Authorization头域重复此请求。如果请求包含了一个授权证书，如果服务器以401响应，它指明这些证书的授权被拒绝。如果401响应包含一个同样的授权激发和以前的响应一样，并且用户代理已经尝试至少授权了一次，那么用户应该被呈现包含在响应里的实体，因为这些实体可能包含相关的诊断信息。HTTP授权访问在“HTTP Authentication：Basic and Digest Access Authentication”[43]里解释。
10.4.3 402 必需的支付 （Payment Required）
此状态码为将来的应用保留。
10.4.4 403 禁用 （Forbidden）
服务器理解此请求，但拒绝满足此请求。授权是没有作用的并且请求不能被重复。如果请求方法是HEAD并且服务器想让客户端知道请求为什么不能被满足，那么服务器起应该在响应实体里描述此拒绝的原因。如果服务器不希望告诉客户端拒绝的原因，那么404状态码(Not Found)响应将被使用。
10.4.5 404 没有找到（Not Found）
服务器并没有找到任何可以匹配请求URI的资源。条件是长期的还是暂时的也没有被服务器指明。410（Gone）状态响应应该被使用，如果服务器知道一个旧的资源不能长期的使用并且没有转发地址时。 此状态码通常别用于当服务器不希望指出为什么请求被拒绝，或者没有任何其他响应是适合的。
10.4.6 405 不被允许的方法（Method Not Allowed）
此状态码表示请求行（Request-Line）里的方法对此资源来说不被允许。响应必须包含一个Allow头域，此头域包含以一系列对此请求资源有效的方法。
10.4.7 406 不接受的 （Not Acceptable）
根据客户端请求的接受头域（译注：如：Accept, Accept-Charset, Accept-Encoding, 或者 Accept-Language），服务器不能产生让客户端可以接受的响应。
除非是HEAD请求，响应应该包含一个实体，此实体包含一系列实体的特性和位置，通过他们用户或用户代理能选择最合适的资源的表现形式。实体格式被媒体类型指定。依赖于此格式和用户代理的能力，选择最合适的会被自动执行。然而，此规范并没有定义自动执行选择的标准。
注意：HTTP/1.1服务器被允许返回这样的响应，此响应根据接受头域（译注：如：Accept, Accept-Charset, Accept-Encoding, or Accept-Language）是不可接受的。在一些情况下，这可能更倾向于发送一个406响应。用户代理被鼓励观察响应来决定是否此响应是可接受的。
如果响应是不可接受的，用户代理应该暂时停止更多的数据的接收并且询问用户去决定进一步的动作。
10.4.8 407 代理服务器授权所需（Proxy Authentication Required）
此状态码和401（Unauthorized）相似，但是指明客户端必须首先利用代理服务器对自己授权。代理服务器必须返回一个Proxy-Authenticate头域（见14.33节），此头域包含一个适用于代理服务器的授权激发。客户端可能会重复此请求利用一个合适的Proxy-Autorization头域（见14.34节）。HTTP访问授权在“HTTP Authentication；Basic and Digest Access Authentication”[43]。
10.4.9 408 请求超时（Request Timeout）
客户端在服务器等待的时间里不能产生请求。客户端端可能在以后会重复此请求。
10.4.10 409 冲突 （Confilict）
请求不能完成由于和当前资源的状态冲突。此状态码只被允许出现在期望用户可能能解决此冲并且能重新提交此请求的情况下。响应主体应该包含足够的为用户认识此资源冲突的信息。理想的情况下，响应实体应该包含足够为用户或用户代理解决此问题的信息；然而，这是不可能的并且也是不需要的。
冲突最可能发生在响应PUT请求的时候。例如，如果版本被使用并且被提交的实体包含资源的改变，这些改变和以前的请求的改变想冲突，那么服务器应该使用409响应去指明它不能完成此请求。在这种情况下，此响应实体应该包含这两个版本的不同，响应的格式在响应的Content-Type头域里指定。
10.4.11 410 不存在（gone）
请求资源不再可以在服务器上得到并且也不知道转发地址（译注：转向此资源的地址）。此条件是长期条件。具有链接编辑能力的客户端应该在用户确认后删除请求URI的引用。如果服务器不知道或不能方便判定条件是否是长期的，那么此404（没有发现）状态响应将被代替利用。响应是可缓存的，除非另外申明。
410响应主要的目的是通知接收者资源不能被得到并且告诉接收者指向那个资源的连接已经被移动了。这样一个事件对时间要求比较严格的服务来说是比较普遍的，并且对属于个人但已经不在服务器站点工作的人的资源来说，这个事件来也是比较普遍的。把所有长期不能得到的资源标记成“gone”或保持这些标记任意长时间，这是没有必要的。
10.4.12 411 必需的长度 （Length Required）
此响应服务器拒绝接受没有包含Content-Length头域的请求。客户端可以重复此请求如果它添加了一个有效的Content-Length头域，此头域包含了请求消息里消息主体的长度。
10.4.13 412 先决条件失败 （Precondition Failed）
先决条件在一个或多个请求头域里指定，412响应是表明先决条件在服务器上测试等于false。此响应允许客户端把先决条件放到请求消息的元信息里（头域数据）。
10.4.14 413 请求实体太大
服务器拒绝处理请求因为请求实体太大以致达到服务器不愿意去处理。服务器可能关闭此连接去防止客户端继续请求。
如果条件是暂时的，服务器应该包含一个Retry-After头域用来指明此请求是暂时的并且什么时间后客户端应该重试。
10.4.15 414 请求URI太长（Request-URI Too Long）
服务器拒绝为请求服务因为此请求URI太长了以至于服务器不能理解。这种情况是很少的，只发生在当客户端把POST请求不合适地转换为带有大量查询信息的GET请求时。
10.4.16 415 不被支持的媒体类型（Unsupported Media Type）
服务器拒绝为请求服务因为请求的实体的格式不能被请求的资源支持。
10.4.17 416 请求范围不满足 （Requested Range Not Satisfiable）
服务器返回一个此状态码的响应，如果请求包含一个Range请求头域（见14.35节），并且此头域里range-specifier值不和选择资源的当前的extent值重叠，并且请求没有包含一个If-Range请求头域。（对byte-ranges来说，这意味着byte-range-spec的所有first-byte-pos
值大于选择的资源的当前长度。
当此状态码响应在一个byte-range请求后返回时，此响应应该包含一个Content-Range实体头域用来指定选择资源的当前长度（见14.16节）。此响应不能利用multipart/byteranges媒体类型。
10.4.18 417 期望失败
Expect请求头域里指定的希望不能被服务器满足，或者，如果服务器是代理服务器，服务器有有不确定的理由确定请求不能被下一站的服务器满足。
10.5 服务器错误 5xx （Server Error）
这类状态码指明服务器处理请求时产生错误或不能处理请求。除了HEAD请求，服务器应该包含一个实体，此实体用来解释错误，和是否是暂时或长期条件。用户代理应该展示实体给用户。此响应状态码能应用于任何请求方法。
10.5.1 500 服务器内部错误 （Internal Server Error）
服务器遇到了一个意外条件，此条件防止服务器满足此请求。
10.5.2 501 不能实现 （Not Implemented）
服务器不能支持满足请求的功能需求。这个响应是很合适的当服务器不能识别请求方法时并且不能支持它请求的资源的时候。
10.5.3 502 坏网关 （Bad Gateway）
此响应说明：服务器，当作为网关或代理时，它从上行服务器接收了一个无效的响应并尝试满足客户端的请求。
10.5.4 503 难以获得的服务.（Service Unavailable）
服务器不能处理请求由于服务器暂时的过载或维护。这就是说这是暂时条件，此条件将会在一些延时后被减轻。延迟的长度可以在Retry-After头域里指定。如果没有Retry-After被给，那么客户端应该处理此响应就像它处理500响应一样。
注意：503状态码的存在并不是意指服务器当产生过载时必须利用它。一些服务器可能希望拒绝此连接。
10.5.5 504 网关超时（Gateway Timeout）
服务器，当作为网关或代理服务器时，不能接收一个从被URI指定的上行服务器的响应（例如：HTTP，FTP，LDAP服务器）或者它为完成请求而需要访问的一些其他的辅助性服务器（例如：DNS服务器）。
注意：一些部署的代理服务器将会返回400或500响应当DNS查找超时。
10.5.6 505 HTTP版本不支持 （HTTP version Not Supported）
服务器不能支持，或拒绝支持，此HTTP协议版本消息。505响应指明服务器不能或不愿意完成这样的请求，这在3.1中描述了。此响应应该包含一个实体，此实体描述了为什么此协议版本不被支持和其他的能被服务器支持的协议版本。
11.入口验证（Access Authentication）
HTTP提供一些可选的响应授权激发机制，这些机制能被用于服务器激发客户端请求并且使客户端授权。常用访问授权框架，还有“basic”和“digest”授权规范，都在“HTTP Authentication：basic and Digest Access Authentication”[43]规范里指定。HTTP/1.1规范采用了“激发（chanllenge）”和“证书（credentials）”的定义。
12.内容协商 （Content Negotiation）
大多数响应包含一个实体，此实体包�