超文本传输协议（HTTP Protocol）
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 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）
向内和向外指的是消息的请求和应答路径:"向内"即"移向原服务器","向外"即"移向用户代理".
Copyright www.cnpaf.net (2007). All Rights Reserved.
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”。
*规则
前面的字符"*"表示重复。完整的形式是"*元素",表示元素至少出现次，至多出现次。默认值是0和无穷大，所以"*(元素)"允许任何数值，包括零；"1*元素"至少需要一次；"1*2element"允许一次或两次。
[规则]
方括号里是任选元素；"[foo bar]"相当于"*1(foo bar)".
N 规则
特殊的重复：“(元素)”相当于“*(元素)”； 也就是说，(元素)正好出现了次。这样2DIGIT是一个两位数字，3ALPHA是一个由三个字符组成的字符串。
#规则
类似于"*",结构"#"是用来定义一系列元素的。完整的形式是"#元素,表示至少个元素，至多个元素，元素之间被一个或多个逗号(",")以及可选的线性白色空间(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 =
LF =
SP =
HT =
<"> =
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版本
Copyright www.cnpaf.net (2007). All Rights Reserved.
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/~smith/home.html
http://ABC.com:/~smith/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消息
Copyright www.cnpaf.net (2007). All Rights Reserved.
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请求接收者可以尝试使用试探的方法（例如检测ＵＲＩ路径对于特定的主机是唯一的这个性质）．
５.3请求报头域
请求的报头域允许客户传递关于请求，客户自己的附加信息给服务器．这些域作为请求修饰成分，和程序语言中方法调用的参数有差不多的含义．
请求报头 ＝ 接收(Accept) ;14.1节
|接收Charset (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节
随着协议版本的变化,请求报头域的名字可以可靠的扩展．然而新的或扩展的报头域可以给出请求报头域的语法，其前提是通信中所有部分承认它们是请求报头域．不被承认的报头域被当作实体报头域．
６ 应答
接收和翻译一个请求信息后，服务器发出一个HTTP应答信息．
应答 ＝状态行 ;6.1节
*((常规报头(general-header） ; 4.5节
|应答报头(response-header) ;6.2节
|实体报头(entity-header)CRLF) ;7.1节
CRLF
[应答正文] ;7.2节
6.1 状态行
应答信息的第一行是状态行,由协议版本以及数字状态码和相关的文本说明组成,各部分间用空格符隔开，除了最后的回车或换行外，中间不允许有回车换行．
状态行 ＝ 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节: 没找到
|"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版本不支持
|扩展码
扩展码 =3DIGIT
注解短语=*
HTTP状态码是可扩展的．HTTP应用程序不需要理解所有已注册状态码的含义，尽管那样的理解显而易见是很合算的．但是，应用程序必须了解由第一位数字指定的状态码的类型，任何未被识别的应答应被看作是该类型的Ｘ00状态，有一个例外就是未被识别的状态码不能缓存．例如，如果客户机收到一个未被识别的状态码431， Copyright www.cnpaf.net (2007). All Rights Reserved.
则可以安全的假定请求有错，且其对待应答的情况是仿佛客户端收到的是400状态码．在这种情况下，用户代理应当把实体和应答一起提交给用户，因为实体很可能包括说明不平常状态的人认可读的信息．
６.2应答报头域
应答头允许服务器传送应答的附加信息,这些信息不能放在状态行里.这些报头域给出有关服务器的信息以及请求URI指定的资源的下一步的通路．
应答报头 = 接收范围 ; 14.5节
|生存时间 ; 14.6节
|Etag ; 14.19节
|位置 ; 14.30节
|代理认证 ; 14.33节
|等会再试 ; 14.37节
|服务器 ; 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
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 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）
向内和向外指的是消息的请求和应答路径:"向内"即"移向原服务器","向外"即"移向用户代理".
Copyright www.cnpaf.net (2007). All Rights Reserved.
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”。
*规则
前面的字符"*"表示重复。完整的形式是"*元素",表示元素至少出现次，至多出现次。默认值是0和无穷大，所以"*(元素)"允许任何数值，包括零；"1*元素"至少需要一次；"1*2element"允许一次或两次。
[规则]
方括号里是任选元素；"[foo bar]"相当于"*1(foo bar)".
N 规则
特殊的重复：“(元素)”相当于“*(元素)”； 也就是说，(元素)正好出现了次。这样2DIGIT是一个两位数字，3ALPHA是一个由三个字符组成的字符串。
#规则
类似于"*",结构"#"是用来定义一系列元素的。完整的形式是"#元素,表示至少个元素，至多个元素，元素之间被一个或多个逗号(",")以及可选的线性白色空间(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 =
LF =
SP =
HT =
<"> =
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版本
Copyright www.cnpaf.net (2007). All Rights Reserved.
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/~smith/home.html
http://ABC.com:/~smith/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消息
Copyright www.cnpaf.net (2007). All Rights Reserved.
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请求接收者可以尝试使用试探的方法（例如检测ＵＲＩ路径对于特定的主机是唯一的这个性质）．
５.3请求报头域
请求的报头域允许客户传递关于请求，客户自己的附加信息给服务器．这些域作为请求修饰成分，和程序语言中方法调用的参数有差不多的含义．
请求报头 ＝ 接收(Accept) ;14.1节
|接收Charset (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节
随着协议版本的变化,请求报头域的名字可以可靠的扩展．然而新的或扩展的报头域可以给出请求报头域的语法，其前提是通信中所有部分承认它们是请求报头域．不被承认的报头域被当作实体报头域．
６ 应答
接收和翻译一个请求信息后，服务器发出一个HTTP应答信息．
应答 ＝状态行 ;6.1节
*((常规报头(general-header） ; 4.5节
|应答报头(response-header) ;6.2节
|实体报头(entity-header)CRLF) ;7.1节
CRLF
[应答正文] ;7.2节
6.1 状态行
应答信息的第一行是状态行,由协议版本以及数字状态码和相关的文本说明组成,各部分间用空格符隔开，除了最后的回车或换行外，中间不允许有回车换行．
状态行 ＝ 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节: 没找到
|"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版本不支持
|扩展码
扩展码 =3DIGIT
注解短语=*
HTTP状态码是可扩展的．HTTP应用程序不需要理解所有已注册状态码的含义，尽管那样的理解显而易见是很合算的．但是，应用程序必须了解由第一位数字指定的状态码的类型，任何未被识别的应答应被看作是该类型的Ｘ00状态，有一个例外就是未被识别的状态码不能缓存．例如，如果客户机收到一个未被识别的状态码431， Copyright www.cnpaf.net (2007). All Rights Reserved.
则可以安全的假定请求有错，且其对待应答的情况是仿佛客户端收到的是400状态码．在这种情况下，用户代理应当把实体和应答一起提交给用户，因为实体很可能包括说明不平常状态的人认可读的信息．
６.2应答报头域
应答头允许服务器传送应答的附加信息,这些信息不能放在状态行里.这些报头域给出有关服务器的信息以及请求URI指定的资源的下一步的通路．
应答报头 = 接收范围 ; 14.5节
|生存时间 ; 14.6节
|Etag ; 14.19节
|位置 ; 14.30节
|代理认证 ; 14.33节
|等会再试 ; 14.37节
|服务器 ; 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