HTTP超文本传输协议书应用讲解1.1中文（完整版）

..HTTP超文本传输协议-HTTP/1.1中文版摘要超文本传输协议〔HTTP是一种为分布式,合作式,多媒体信息系统服务,面向应用层的协议。它是一种通用的,不分状态〔stateless>的协议,除了诸如名称服务和分布对象管理系统之类的超文本用途外,还可以通过扩展它的请求方式,错误代码和报头来完成许多任务。HTTP的一个特点是数据表示方式的典型性和可协商性允许独立于传输数据而建立系统。在1990年WWW全球信息刚刚起步的时候HTTP就得到了应用。HTTP的第一个版本叫做HTTP/0.9,是一种为互联网原始数据传输服务的简单协议。由RFC1945定义的HTTP/1.0进一步完善了这个协议。它允许消息以类似MIME的格式传送,包括有关数据传输的维护信息和关于请求/应答的句法修正。但是,HTTP/1.0没有充分考虑到分层代理,高速缓存的作用以及对稳定连接和虚拟主机的需求。并且随着不完善的进程应用的激增,HTTP/1.0迫切需要一个新的版本,以便使两个通信应用程序能够确定彼此的真实性能。这里规定的协议叫做"HTTP/1.1".这个协议与HTTP/1.0相比,要求更为严格,以确保各项功能得到可靠实现。实际的信息系统除了简单的检索外,要求更多的功能性〔functionality>,包括查找<search>,前端更新<front-endupdate>和注解<annotation>。HTTP允许可扩充的方法集和报头集以指示请求的目的[47]。它是建立在统一资源标识符〔URI[3]提供的地址〔URL[4]和名字〔URN上[20],以指出方法应用于哪个资源的。消息以类似于一种叫做多用途网络邮件扩展〔MIME[7]的互联网邮件的格式传送。HTTP也是用于用户代理之间及代理/网关到其他网络系统的通用通信协议,这样的网络系统可能由SMTP,NNTP,FTP,Gopher和WAIS协议支持。这样,HTTP允许不同的应用程序对资源进行基本的超媒体访问。1.3术语本说明用到了若干术语,以表示HTTP通信中各参与者和对象扮演的不同角色。连接〔Connection

为通信而在两个程序间建立的传输层虚拟电路。消息<Message>

HTTP通信中的基本单元。它由一个结构化的八比特字节序列组成,与第4章定义的句法相匹配,并通过连接得到传送。请求<Request>

一种HTTP请求消息,参看第5章的定义。应答<Response>

一种HTTP应答消息,参看第6章的定义。资源<Resource>

一种网络数据对象或服务,可以用第3.2节定义的URI描述。资源可以以多种表现方式〔例如多种语言,数据格式,大小和解决方案或其他不同的途径获得。实体<Entity>

作为请求或应答的有效负荷而传输的信息.一个实体包含报头形式的维护信息和消息体形式的内容,由第7节详述.表示方法<Representation>

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

为请求服务时选择适当表示方法的机制〔mechanism>,如第12节所述.任何应答里实体的表示方法都是可协商的<包括出错应答>.变量〔Variant>

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

为发送请求建立连接的程序.用户代理<Useragent>

初始化请求的客户端程序.常见的如浏览器,编辑器,蜘蛛<网络穿越机器人>,或其他的终端用户工具.服务器<Server>

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

给定的资源驻留或创建的地方.代理服务器〔Proxy

一个既做服务器又做客户端的中介程序.,其用途是代表其他客户发送请求.请求在内部得到服务,或者经过一定的翻译转至其他服务器.一个代理服务器必须能同时履行本说明中客户端和服务器要求."透明代理"〔transparentproxy是一种除了必需的验证和鉴定外不修改请求或相应的代理."非透明代理"〔non-transparentproxy是一种修改请求或应答以便为用户代理提供附加服务的代理,附加服务包括类注释服务,媒体类型转换,协议简化,或者匿名滤除等.除非经明确指出,HTTP代理要求对两种代理都适用.网关〔gateway

为其他服务器充当中介的服务器.与代理服务器不同,网关接收请求,仿佛它就是被请求资源所在的原服务器;提出请求的客户可能觉察不到它正在同网关通信.

一个在两个连接之间充当盲目中继〔blindrelay>的中间程序.一旦有效,隧道便不再被认为是HTTP通信的用户,虽然隧道可能已经被HTTP请求初始化了.当两端的中继连接都关闭的时候,隧道不再存在.高速缓存〔Cache

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

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

如果一个应答直接到来并且没有缘于原服务器,或若干代理服务器的不必要的延时,那么这个应答就是直接的.如果它的有效性已经被原服务器直接认证,那么这个应答也同样是第一手的.明确终止时间〔explicitexpirationtime原服务器预算一个实体在无需进一步确认的情况下不再被高速缓存返回的时间.探索终止时间〔heuristicexpirationtime当没有外在的终止时间可利用时,由高速缓存所指定的终止时间.年龄〔Age

一个应答的年龄是从它被发送,或被原服务器成功确认到现在的时间.保鲜寿命〔Freshnesslifetime

一个应答生成和过期之间的时间长度.保鲜〔Fresh如果一个应答的年龄还没有超过保鲜寿命,它就是保鲜的.陈旧〔Stale

一个应答的年龄已经超过了它的保鲜寿命,就是陈旧的.语义透明〔semanticallytransparent

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

一个用来查找一个高速缓存记录是否是一个实体的等效拷贝的协议元素<例如,一个实体标记〔entitytag或最终更改时间〔Last-Modifiedtime>>.上游/下游〔upstream/downstream上游和下游描述了消息的流动:所有消息都从上游流到下游.向内/向外〔inbound/outbound

向内和向外指的是消息的请求和应答路径:"向内"即"移向原服务器","向外"即"移向用户代理".1．4总体操作HTTP协议是一种请求/应答协议。与主机建立连接后,客户以请求方法,URI和协议版本的形式向服务器发送请求,继以类MIME信息,其中包括请求修改,客户信息和可能的正文内容。服务器用包括消息协议版本和成功或错误代码的状态进行应答,继以包括服务器信息,实体维护信息和可能的实体内容的类MIME消息。HTTP和MIME之间的关系如附录19.4节所阐述。大部分的HTTP通信由用户代理引发,由应用到一些原服务器上资源的请求构成。最简单的情形,可以经用户代理〔UA和原服务器〔O之间的单一连接〔v完成。请求链------------------------>用户代理<UA>-------------------单一连接〔v>-------------------原服务器〔O<-----------------------应答链当一个或一个以上的中介在请求/应答链中出现的时候,会出现更复杂的情形。常见的中介形式有三种：代理,网关和隧道。代理是一种转送工具,它接收绝对形式的URI请求,重写全部或部分消息,然后把重新格式化后的请求发送到URI确定的服务器上。网关是一种接收工具,它充当其他服务器的上层,必要时将请求翻译为下层服务器的协议。隧道不改变消息而充当两个连接之间的中继点；它用于通信需要穿过中介〔如防火墙,甚至中介不能理解信息内容的时候。

请求链-------------------------------------->UA-----v-----A-----v-----B-----v-----C-----v-----O<-------------------------------------应答链上图显示了用户代理和原服务器之间的三个中介〔A,B和C>。游历整条链的请求或应答消息需通过四个独立的连接。这个特性很重要,因为某些HTTP通信选项只能应用于到最近的非隧道邻居,链的终点的连接,或者沿着链的所有连接。图表尽管是线性的,每部分可能都在忙于多路同时通信。例如,B可以接收来自不同于A的许多客户的请求,并且／或者转送到不同于C的服务器,与此同时,它还在处理A的请求。任何非隧道的通信成员都可以使用内部的高速缓存来处理请求。高速缓存的作用是如果沿着链的一个成员对请求采用了高速缓冲的应答,请求/应答链就会大大缩短。以下图解作为结果产生的链,假定B拥有来自O〔通过C的一个从前应答的备份,请求尚未被UA或A缓存。

请求链---------->UA-----v----------A-----v-----B-----C----O<---------应答链并不是所有的应答都能有效地缓存,一些请求可能含有修改量,对缓存动作有特殊的要求。缓存动作和缓存应答的HTTP要求将在第13节定义。实际上,目前万维网上有多种结构和配置的高速缓存和代理被实验或使用。这些系统包括节省越洋带宽的全国代理层,广播或多点通信缓存接口,通过CD-ROM分配子缓存数据的机构,等等。HTTP系统应用在宽频带连接的企业局域网中,通过PDAs的低耗无线连接和断续连接的访问。HTTP1.1的目标是支持各种各样的应用配置,引进协议结构满足那些需要较高可靠性,可以排除故障或至少指示故障的网络应用的要求。HTTP通信在通常发生在TCP/ＩＰ连接上。默认端口是TCP80,不过其它端口也可以使用。在互联网或其他网络上,这并不妨碍HTTP应用在其他协议的顶端。http仅仅期望可靠的传输；任何提供这种保证的协议都可以使用；协议传输数据单元的HTTP/1.1请求和应答结构的映象已经超出了本说明书的范围。在http/1.0中,大部分的实现为每个请求/应答交换使用了新连接。而http/1.1中,一个连接可以用于一个或更多请求/应答交换,虽然连接可能会因为各种原因中断〔见第8.1节。3.3日期/时间格式3.3.1完整日期历史上的HTTP应用一直允许三种不同的表示日期/时间印记的格式:Sun,06Nov199408:49:37GMT;RFC822,updatedbyRFC1123

Sunday,06-Nov-9408:49:37GMT;RFC850,obsoletedbyRFC1036

SunNov608:49:371994;ANSIC'sasctime<>format第一种格式是作为Internet标准提出来的,它表示一个由RFC1123[8]<RFC822[9]的升级版本>定义的固定长度的子集.第二种格式使用比较普遍,但是基于废弃的RFC850[12],需要<应该>用四位数表示年份.对日期值进行语法分析的HTTP/1.1客户和服务器必须接受所有三种格式<为了同HTTP/1.0兼容>,虽然它们必须只产生RFC1123格式以在头域里表示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","SPdate1SPtimeSP"GMT"

rfc850-date=weekday","SPdate2SPtimeSP"GMT"

asctime-date=wkdaySPdate3SPtimeSP4DIGIT

date1=2DIGITSPmonthSP4DIGIT

;daymonthyear<e.g.,02Jun1982>

date2=2DIGIT"-"month"-"2DIGIT

;day-month-year<e.g.,02-Jun-82>

date3=monthSP<2DIGIT|<SP1DIGIT>>

;monthday<e.g.,Jun2>

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.2Delta秒一些HTTP头域收到消息后,允许以十进制整数秒表示的时间值.

delta-seconds=1*DIGIT3.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"<GNUzip>---如RFC1952所描述---生成的编码格式.这种格式是一种32位CRCLempel-Ziv编码<LZ77>.[译者注]CRC:循环冗余校验compress〔压缩

由通用UNIX文件压缩程序"compress"生成的编码格式.这种格式是一种具有可适应性的Lempel-Ziv-Welch编码.

对未来的编码来说,用程序名识别编码格式是不可取,令人气馁的.在这里他们的用处是作为历史实践的代表而不是好的方案.为了同以前的HTTP实现相兼容,应用应该将"x-gzip"和"x-compress"分别等同于"gzip"和"compress".

deflate〔缩小

RFC1950[31]定义的"zlib"格式与RFC1951[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成块传输代码〔ChunkedTransferCoding成块编码更改消息主体,为的是将它以一系列大块的形式传送,每一个连同它自己尺寸的指示器,被一个包含实体头域的可随意选择的trailer跟随.这允许有力量的地生产同接受所必需的消息一起转化的内容,从而检验它已经获得全部消息.

Chunked-Body=*chunk<大块>

大块-正文last-chunk<最后-大块>

trailer<追踪者>

CRLFchunk=chunk-size[chunk-extension]CRLF

大块=大块-尺寸[大块-扩展]CRLF

chunk-dataCRLF

大块-数据CRLF

chunk-size=1*HEX

大块数据

last-chunk=1*<"0">[chunk-extension]CRLF

最后-大块=1*<"0">[大块-扩展]CRLFchunk-extension=*<";"chunk-ext-name["="chunk-ext-val]>

大块-扩展大块-外部-名称大块-外部-值

chunk-ext-name=token

大块-外部-名称=标记

chunk-ext-val=token|quoted-string

大块-外部-值=标记|引用-串

chunk-data=chunk-size<OCTET>

大块-数据=大块-尺寸<八位子节>

trailer=*<entity-headerCRLF>

追踪者=*<实体-领先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]>注册.媒体类型的注册程序在RFC1590[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多部分类型〔Multiparttype>MIME提供了一系列"多重部分"类型---在单个消息体内一个或多个实体的包装.所有的多重部分类型共享一个公共的序列,就像RFC2046的5.1.1节中定义的那样.

必须包括一个作为媒体类型值一部分的边界参数.这个消息体自成为一个要素协议,因此在两部分间只能用CRLF来表现行的间断.不同于RFC2046,任一多重消息的末尾必须为空;HTTP应用程序不能传送末尾<即使原始的多重部分包含一个末尾>.存在这些制约为的是保护一个多重部分消息实体的固有本质,结束多重部分边界已经在消息体的"结尾"加以表明.通常,HTTP将一个消息体视为与任何其他媒体类型无异:严格如有效负载.当消息体出现在206应答时,有一个例外就是"多重部分/字符串"类型<附录19.2>,将会被一些HTTP隐藏装置打断,就像13.5.4和14.16节中描述的那样.除此情况外,一个HTTP用户代理应该遵循与一个MINE用户代理相同或相似的行为,在多重部分类型收据之上.MIME头域在一个多重部分消息体的每一个部分里,对超过MIME意义的定义的HTTP没有任何意义.通常,一个HTTP用户代理应该遵循与一个MINE用户代理相同或相似的行为,在多重部分类型收据之上.如果一个应用程序收到一个不能识别的多重部分亚类型,这个应用程序必须将它视为与"多重部分/混合"相等.注:"多重部分/形态-数据"形式已被在适合于通过POST请求方法处理的传送形式数据明确定义,就像在RFC1867[15]中描述的那样.3.8产品标记产品标记被用来承认通过软件名和译本识别它们自己的通讯应用软件.很多域还把产品标记用于认可次级产品,专业产品构成应用软件中有重要意义的部分被一一列出,用白色间隔分开.按照惯例,按产品对于识别应用软件的重要性的顺序列出它们.产品=标示["/"产品-版本]

产品-版本=标示例:

用户-代理:CERN-LineMode/2.15libwww/2.17b3

服务器:Apache/0.8.4

产品标示应言简意赅.它们不能用来做广告或其他不重要的信息.虽然任一标示可能出现在产品-版本上,但这个标示仅能被用来做一个版本标识<i.e.,同类产品中成功的版仅区别在产品值的产品版本部分3.9质量值<QualityValues>HTTP内容流通<12节>运用简短的"浮点"数字来表明不同可流通参数之间的重要联系<"重要性">.一个重要性从0到1规格化了一个真实的数字,0是最小值,是最大值.如果一个参数为0的质量值,那么这个参数的内容不被客户接受.HTTP/1.1应用软件不能产生多于小数点后三位数字.这些值的用户配置也应受限于这种方式.

qvalue=<"0"["."0*3DIGIT]>

|<"1"["."0*3<"0">]>"质量值"是一个不当的用词,因为这些值仅仅表现想要得到的质量中的降级关系.3.10语言标记一个语言标记和自然的语言一样说,写,或被人类用于与其他人传递信息.计算机语言明显不包括在内.HTTP在认可语言和目录语言域内运用语言标记.HTTP语言标记的语法和注册像RFC1766[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范围单位<RangeUnits>HTTP/1.1允许一个客户要求单独部分的应答实体被包括在应答内.HTTP/1.1在范围<14.35节>和目录范围头域<14.16节>运用范围单位.一个实体可根据不同的结构单位分解成子区域.范围-单位=字节-单位|其他-范围-单位

字节-单位="字节"

其他-范围-单位=标记HTTP/1.1中定义的唯一的范围单位是"字节".HTTP/1.1实现时可能忽略其他单位指定的范围。

HTTP/1.1的设计允许应用软件不依靠有关范围的知识而实现

4HTTP消息4.1消息类型HTTP消息由从客户到服务器的请求和从服务器到客户的回答组成.

HTTP-消息=请求|回答;HTTP/1.1消息

请求<第五节>和回答<第六节>的消息是用一般的消息格式RFC822[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<要求XX>如果它坚持想要收到一个有效内容的长度.所有的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地址．请求行举例如下：

ＧEThHTTP/1.1为了在未来的HTTP版本的所有请求中转换绝对URL地址,所有基于ＨTTP/1.1的服务器必须接受绝对URL地址的组成,虽然基于HTTP/1.1的客户机将只产生请求发给代理服务器主机<authority>组成部分只是在连接方法<CONNECT>中用到〔９.9节．最通用形式的请求ＵＲI用于标识在原服务器或网关上的资源.这种情况下,绝对ＵＲＬ路径必须作为请求ＵＲＬ传送〔看３.２.１节,绝对路径,ＵＲＩ局域网地址<authority><必须输入主机报头域．例如,希望直接得到原服务器顶层资源的客户机将在"ｗｗｗ．ｗ３．ｏｒｇ"主机的端口８０建立ＴＣＰ连接发送以下行：

GET/pub/WWW/TheProject.htmlHTTP/1.1

接下来是请求的其他部分,注意绝对路径不能是空的；假如没有初始的URI,必须给出"／"〔服务器根目录．请求ＵＲＬ用在3.2.1节里说明的格式传输．如果用"%HEXHEX"[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原因短语CRLF6.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,则可以安全的假定请求有错,且其对待应答的情况是仿佛客户端收到的是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。连接8。1持续连接。8。1。1目的在持续连接之前,为获取每一URL都建立了独立的TCP连接,这就加重了HTTP服务器的负担,易引起INTERNET阻塞。嵌入式图片与其它相关数据通常使用户在短时间内对同一服务器提交多个请求。目前已有针对这些性能问题的分析以及原型实施的结果[26],[30]。实施的具体过程和对实际HTTP/1。1〔RFC2068的测试均显示了良好的结果[39]。对其他方法也有了初步探究,如T/TCP[27]。持续HTTP连接有着诸多的优点：---通过建立与关闭较少的连接,不仅节省了路由器与主机〔客户机,服务器,代理服务器,网关,隧道或高速缓冲存储机的CPU时间,还节省了主机用于TCP协议控制块的内存。---HTTP请求与应答可以进入连接流水线。流水线方式使得客户无须挨个等待应答即发起多个请求,从而更充分的利用了单个的TCP连接,减少了崩溃时间。---在减少TCP连接中数据包个数的同时,使TCP有了充裕的时间来确定网络的拥塞状况,缓解了网络拥塞。---因为无须在创建TCP连接握手上耗费时间,而使连续请求造成的延迟现象得到改善。---由于出错不会导致TCP连接的关闭,HTTP可以更好的实现自我完善。使用较新版HTTP的用户会乐于尝试一些新功能,与旧版服务器通信时,则会在接到出错报告后用旧模式重试。HTTP的实现应当采用持续连接。8。1。2总体操作HTTP/1.1与早期HTTP版本的一个显著区别在于持续连接是任何HTTP连接的缺省方式。也就是说,除非另有指定,客户机总应当假定服务器会保持持续连接,即便在接到服务器的出错应答时也应如此。持续连接提供了一种可以由客户机或服务器发信号终止TCP连接的机制。终止连接的信号利用了"连接"报头域〔14.10节。一旦出现了终止连接的信号,客户机便不可再向此连接提出任何新请求。8。1。2。1谈判除非请求的连接报头域中包括了"终止连接"的符号,HTTP/1。1服务器总可以假定HTTP/1。1客户机想要维持持续连接。如果服务器想在发出应答后立即终止连接,它应当发送一个含有终止要求的连接报头域。无论是客户机或服务器发起终止连接,这都是本次连接的最后一个请求。除非经明确指出,客户机与服务器不应假定低版HTTP会自动采用持续连接方式。请参见19。6。2节关于与HTTP/1。0客户机后向兼容性的有关内容。为了维持持续连接,连接中的报文都必须有如4。4节所述的自定义报文长度〔即不是由连接终止定义的长度。8。1。2。2流水线支持持续连接的客户机可以以流水线方式发送请求〔即无须等待应答而发送多个请求。服务器则必须将其应答按接到请求的顺序发出。建立连接后立即采用持续连接与流水线方式的客户机应作好初次流水线尝试失败后重试的准备,而不可在持续连接尚未确定时就连续发送请求。客户机还必须为服务器在发出所有应答之前就结束连接的情况作好重发请求的准备。客户机不应该用非等幂方法或非等幂方法序列〔参见9。1。2节连发请求。否则,过早终止的传输层连接会导致不确定的结果。8。1。3代理服务器使代理服务器正确地实现14。10节所规定的连接报头域的属性是非常关键的。代理服务器必须独立于它所连接的客户机,原服务器〔或其它代理服务器而发出持续连接的信号。每一持续连接仅针对传输层链接。代理服务器不可与一台HTTP/1.0客户机建立HTTP/1。1持续连接〔请参见RFC2068[33]中关于HTTP/1。0客户机上实现"维持活跃态"报头问题的探讨及资料8。1。4实际的考虑服务器通常有一个时限值,超过一定时间即不再维系处于非活跃态的连接。代理服务器会选一个较高的值,因为客户机很可能会与同一服务器建立多个连接。持续连接方式的采用对于客户机与服务器的时限均未提出任何要求。当客户机或服务器希望超时终止时,它应按规范终止传输连接。客户端与服务器端应始终注意对方是否终止了连接,并适当的予以应答。若客户机或服务器未能及时检测到对方已终止了连接,将会造成不必要的网络资源浪费。客户机,服务器,或代理服务器可能在任意时刻终止传输连接。比如,客户机可能正想发出新的请求,而此时服务器却决定关闭"闲置"的连接。在服务器看来,连接是在闲置状况下被关闭的,而客户机却以为请求在进行中。这表明客户机,服务器与代理服务器必须有能力从非同步的连接终止事件中恢复。只要请求序列是等幂的〔参见9。1。2节,客户端软件就应自动重新发起传输层连接并重传被废弃的请求序列。对非等幂方法或序列不可自动重试,但用户代理可以向手工操作员提供重发请求的机会。用户代理软件对应用程序基于句法理解的确认可以用来代替人工方式。若重试失败,则不应允许再试。服务器在每次连接中只要有可能,总应至少应答一个请求。除非出于网络或客户端的故障,服务器不应在传送应答的中途断开连接。使用持续连接的客户机应限制与某一服务器同时连接的个数。单用户客户机不应与任一服务器或代理服务器保持两个以上的连接。代理服务器与其它服务器或代理之间应维护2*N个连接,其中N是同时在线的用户数。设定这一规则是为了改进HTTP应答时间且避免拥塞。8。2报文传输要求、8。2。1持续连接与流量控制HTTP/1。1服务器应当保持持续连接并使用TCP的流量控制机制来解决临时过载,而不是在终止连接后指望客户端的重试。后一方法会恶化网络阻塞。8。2。2监视连接中出错状态的报文发送报文正文的HTTP/1。1〔或更新客户机应在传输请求的同时监视连接是否处于出错状态。若客户机发现了错误,它应当立即停止正文的传送。若正文是以块编码方式发送的〔3。6节,可以用一长度为零的块和空报尾来提前标记报文结束。若正文前有"内容长度"报头,则客户机必须关闭连接。8。2。3100号状态的用途100号状态的目的在于帮助那些发送含有请求正文的请求报文的客户机在发送请求正文之前推测服务器看到请求报头后是否愿意接收请求。有些时候,如果服务器不看正文就弃置报文的话,客户机对正文的发送就多此一举了。对HTTP/1。1客户机的要求：---若客户机在发送请求正文之前等候100〔继续应答,则它必须发送填有"100--继续"期望的"期待请求"报头域〔14。20节。---若客户机不需要发送请求正文,则它不得发送填有"100--继续"期望的"期待请求"报头域〔14。20节。由于存在旧的实现方法,协议允许出现诸如客户机发出了"期望：100-继续"却没接到417〔期望失败或100〔继续状态的混乱局面存在。因此,当客户机将这一报头域发给它从未接到100〔继续状态的原服务器〔通常是通过代理时,客户机不应在发送请求正文前无限期地等待。对HTTP/1。1原服务器的要求：---在接到"期望"请求报头域填有"100-继续"期望的请求时,原服务器必须以100〔继续状态应答并继续读入数据流,或者以终止状态码应答。原服务器在发送100〔继续应答之前不得等待。若以终止状态码应答,它既可关闭传输层连接,也可继续读入数据而丢弃请求的剩余部分。但此时它不得按客户机所请求的方式运行。---如请求报文不含填有"100-继续"的"期望"报头域,原服务器不应发送100〔继续应答。当请求来自HTTP/1。0〔或更早客户机时也不得发送100〔继续应答。对此规定有一例外：为了与RFC2068兼容,服务器对于未含填有"100-继续"的"期望"报头域的PUT或POST请求可以应答100〔继续状态。这一例外的目的在于尽量减少由100〔继续状态的未申明等待引起的客户机处理延迟,仅适用于HTTP/1。1请求,和其它HTTP版本的请求无关。---若已经接到相应请求的部分或全部请求正文,原服务器可以免发100〔继续应答。---一旦请求正文被收到处理,发出100〔继续应答的原服务器除非过早切断传输层连接,否则最终必须发送终止状态码。---若原服务器接到不含填有"100-继续"的"期望"报头域的请求,该请求含有请求正文,而服务器又在从传输层连接读入正文之前就应答了终止状态码,则服务器不应在读完全部请求或客户机终止连接前关闭连接。否则,客户机可能无法可靠地接收应答报文。然而,这一要求在阐释中不应阻止服务器防卫拒绝服务的攻击或有严重缺陷的客户程序。对代理服务器的要求：---若代理服务器接到包含填有"100-继续"的"期望"报头域的请求,且代理服务器要么知道下一站服务器遵循HTTP/1。1或更高版协议,要么不知下一站服务器的HTTP版本,则它必须连同"期望"报头域一起转发此请求。---若且代理服务器知道下一站服务器版本是HTTP/1。0或更低,则它不得转发此请求,而应应答以417〔期望失效状态。---代理服务器应当维护一高速缓存,以记录新近访问到的下一站点服务器的HTTP版本号。---若接到的请求来自于版本是HTTP/1。0〔或更低的客户机,不含填有"100-继续"的"期望"报头域的请求,则代理服务器不得转发100〔继续应答。这一要求可覆盖1xx应答转发的一般规则〔参见10。1节。8．2．4服务器过早关闭连接时客户机的行为如果HTTP/1。1客户机发出一条含有请求正文但不含填有"100-继续"的"期望"报头域的请求,并且客户机直接与HTTP/1。1原服务器相连,在从服务器处接到任何状态信息之前就发现连接被关闭,那么客户机应当重试请求。在重试时,客户机何以采用如下所述的"二进制指数后退算法"以确保获得可靠应答：1．向服务器发起一新连接。

2．发送请求的报头。

3．初始化变量R为通往服务器的往返时间的估计值〔比如基于建立连接的时间,或在无法估计往返时间时设为一常数值5秒。

4．计算T=R*〔2**N,N为此前重试请求的次数。

5．等待服务器发来的出错应答或是T秒〔两者中时间较短的。

6．若没等到出错应答,T秒后发送请求正文。

7．若客户机发现连接被提前终止,转到第1步,直到请求被接受,接到出错应答,或是用户因不耐烦而终止了重试进程。在任意环节上,客户机如果接到出错状态,

---不应再继续,并且

---如完成请求报文的发送则应终止连接９方法定义HTTP/1.1常规方法的定义如下.虽然这个定义可以展开,但附加的方法不能被假定分享和个别扩展的客户机和服务器同样的语义.主机请求应答报头<14.23节>必须符合所有的HTTP/1.1请求.9.1安全和等幂<Idempotent>方法9.1.1安全方法实现程序应当知道软件通过在Internet上的交互来扮演用户,且应该仔细的允许用户知道任何它们可能采取的行动,这些行动可能给他们自己或他人带来无法预料的结果.特别的.这样的惯例已经形成,就是GET和HEAD方法除了补救外不应该有别的采取措施的含义.这些方法应该被看作"安全".这允许用户代理描绘其他方法,像POST,PUT,DELETE,在某种意义上,用户知道某种不安全的行为被请求的事实.自然,随着GET请求的实现,不可能保证服务器不产生副作用;事实上,一些动态的资源考虑到那样的特征.在这里重要的区别是用户没有请求副作用,因此不应该为此承担责任.9.1.2等幂方法方法也可以等幂的性质,这种情况下<除了出错或终止问题>N>0个同样请求的副作用和单个请求一样.方法GET,HEAD,PUT,DELETE都有这种性质.而且,方法OPTIONS和TRACE不应该有副作用,等幂就是这样的含义.然而,有可能几个请求的序列是不等幂的,即使在那样的序列中所有方法单独实现都是等幂的<如果整个序列整体的实现结果总是相同的,即不因序列整体,部分的重新实现而变化,则序列是等幂的>.例如,如果一个序列实现的结果依赖一个序列中后来可以修改的值,则该序列不是等幂的.没有副作用的序列是等幂的<倘若在同样的资源配置下不同时操作>9.2OPTIONS<选项OPTIONS方法描述了在请求URI确定的请求/应答过程中通信条件是否可行的信息.该方法允许客户机确定条件或设备,其与资源或服务器的没有暗示资源操作或初始化资源重建的情况下的性能有关,这种方法的应答是不能缓存的.如果OPTIONS请求包括一个实体<用来指示内容长度或传输码的存在>,接着媒体类型应该有一个内容内型域来确定.虽然这种规定对那样的主体没有定义任何功能,未来HTTP的扩展可以用OPTIONS域来安排更多细节性的有关服务器的询问.一台不支持扩展的服务器可以抛弃请求正文.如果请求URI是一个星号<"*">,OPTIONS