加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 HTTP协议(RFC2616)中文版

HTTP协议(RFC2616)中文版.pdf

HTTP协议(RFC2616)中文版

piyush
2010-08-21 0人阅读 举报 0 0 暂无简介

简介:本文档为《HTTP协议(RFC2616)中文版pdf》,可适用于IT/计算机领域

超文本传输协议HTTP(修订版)译者:孙超进email:sunchaojincom说明本文档规定了互联网社区的标准组协议并需要讨论和建议以便更加完善。请参考“互联网官方协议标准”(STD)来了解本协议的标准化状态。本协议不限流传发布。版权声明Copyright(C)TheInternetSociety()AllRightsReserved摘要超文本传输协议(HTTP)是一种为分布式协作式的超媒体信息系统。它是一种通用的无状态(stateless)的协议除了应用于超文本传输外它也可以应用于诸如名称服务器和分布对象管理系统之类的系统这可以通过扩展它的请求方法错误代码和消息头来实现。HTTP的一个特性就是是数据表现形式是可以定义的和可协商性的这就允许系统能独立于于数据传输被构建。HTTP在年WWW全球信息刚刚起步的时候就得到了应用。本说明书详细阐述了HTTP协议是RFC的修订版。目录(略)引论目的超文本传输协议(HTTP)是一种为分布式的协作的超媒体信息系统它是面向应用层的协议。在年WWW全球信息刚刚起步的时候HTTP就得到了应用。HTTP的第一个版本叫做HTTP,是一种为互联网原始数据传输服务的简单协议。由RFC定义的HTTP进一步完善了这个协议。它允许消息以类MIME消息的格式传送它包括传输数据的元信息和对请求响应语义的修饰。但是HTTP没有充分考虑到分层代理缓存的以及持久连接和虚拟主机的需求的影响。并且随着不完善的HTTP应用程序的激增这就迫切需要一个新的版本以便能使两个通信程序能够确定彼此的真实能力。此规范定义的协议叫做“HTTP”这个协议与HTTP相比此规范更为严格以确保各个协议的特征得到可靠实现。实际的信息系统除了简单的获取信息之外还要求更多的功能包括查找(search)终端更新(frontendupdate)和注解(annotation)。HTTP为请求提供可扩充方法集和消息头集。HTTP是建立在统一资源标识符(URI)的约束上的作为一个地址(URL)或名称(URN)以指定被一个方法使用的资源。消息以一种类似于互联网邮件消息格式来传输的互联网消息格式定义于多目的互联网邮件扩展(MIME)里。HTTP也是用于用户代理(useragents)和其它互联网系统的代理网关之间通信的通信协议这些互联网系统可能由SMTP,NNTP,FTPGopher和WAIS协议支持。通过这种方式HTTP允许不同的应用程序对资源进行基本的超媒体访问。要求本文的关键词“必须”("MUST"),“不能”("MUSTNOT")“需要”("REQUIRED")“应该”("SHALL")“不应该”("SHALLNOT")“应该”("SHOULD")“不应该”("SHOULDNOT")“建议的”("RECOMMENDED")“可能”("MAY")和“可选的”("OPTIONAL")将由RFC解释。一个应用程序如果不能满足协议提供的一个或多个MUST或REQUIRED等级的要求是不符合要求的。一个应用程序如果满足所有必须(MUST)或需要的(REQUIRED)等级以及所有应该(SHOULD)等级的要求则被称为非条件遵循(unconditionallycompliant)的若满足所有必须(MUST)等级的要求但不能满足所有应该(SHOULD)等级的要求则被称为条件遵循的(conditionallycompliant)。术语本说明用到了若干术语以表示HTTP通信中各参与者和对象扮演的不同角色。连接(connection)为通信而在两个程序间建立的传输层虚拟电路。消息(message)HTTP通信中的基本单元。它由一个结构化的八比特字节序列组成与第章定义的句法相匹配并通过连接得到传送。请求(request)一种HTTP请求消息参看第章的定义。响应(response)一种HTTP响应消息参看第章的定义。资源(resource)一种网络数据对象或服务可以用第节定义的URI指定。资源可以以多种表现方式(例如多种语言数据格式大小和分辨率)或者根据其它方面而而不同的表现形式。实体(entity)实体是请求或响应的有效承载信息。一个实体包含元信息和内容元信息以实体头域(entityheaderfield)形式表示内容以消息主体(entitybody)形式表示。在第章详述。表现形式(representation)一个响应包含的实体是由内容协商(contentnegotiation)决定的。如第章所述。有可能存在一个特定的响应状态码对应多个表现形式。内容协商(contentnegotiation)当服务一个请求时选择资源的一种适当的表示形式的机制(mechanism)如第节所述。任何响应里实体的表现形式都是可协商的(包括错误响应)。变量(variant)在某个时刻一个资源对应的表现形式(representation)可以有一个或多个(译注:一个URI请求一个资源但返回的是此资源对应的表现形式这根据内容协商决定)。每个表现形式(representation)被称作一个变量。‘变量’这个术语的使用并不意味着资源(resource)是由内容协商决定的。客户端(client)为发送请求建立连接的程序。用户代理(useragent)初始化请求的客户端程序。常见的如浏览器编辑器蜘蛛(可网络穿越的机器人)或其他的终端用户工具服务器(Server)服务器是这样一个应用程序它同意请求端的连接并发送响应(response)。任何给定的程序都有可能既做客户端又做服务器我们使用这些术语是为了说明特定连接中应用程序所担当的角色而不是指通常意义上应用程序的能力。同样任何服务器都可以基于每个请求的性质扮演源服务器代理网关或者隧道等角色之一。源服务器(Originserver)存在资源或者资源在其上被创建的服务器(server)被成为源服务器(originserver)。代理(Proxy)代理是一个中间程序它既可以担当客户端的角色也可以担当服务器的角色。代理代表客户端向服务器发送请求。客户端的请求经过代理会在代理内部得到服务或者经过一定的转换转至其他服务器。一个代理必须能同时实现本规范中对客户端和服务器所作的要求。透明代理(transparentproxy)需要代理认证和代理识别而不修改请求或响应。非透明代理(nontransparentproxy)需修改请求或响应以便为用户代理(useragent)提供附加服务附加服务包括组注释服务媒体类型转换协议简化或者匿名过滤等。除非透明行为或非透明行为经被显式地声明否则HTTP代理既是透明代理也是非透明代理。网关(gateway)网关其实是一个服务器扮演着代表其它服务器为客户端提供服务的中间者。与代理(proxy)不同网关接收请求仿佛它就是请求资源的源服务器。请求的客户端可能觉察不到它正在同网关通信。隧道(tunnel)隧道也是一个中间程序它一个在两个连接之间充当盲目中继(blindrelay)的中间程序。一旦隧道处于活动状态它不能被认为是这次HTTP通信的参与者虽然HTTP请求可能已经把它初始化了。当两端的中继连接都关闭的时候隧道不再存在。缓存(cache)缓存是程序响应消息的本地存储。缓存是一个子系统控制消息的存储、获取和删除。缓存里存放可缓存的响应(cacheableresponse)为的是减少对将来同样请求的响应时间和网络带宽消耗。任一客户端或服务器都可能含有缓存但缓存不能存在于一个充当隧道(tunnel)的服务器里。可缓存的(cacheable)我们说响应(response)是可缓存的如果这个响应可以被缓存(cache)保存其副本为的是能响应后续请求。确定HTTP响应的缓存能力(cacheability)在节中有介绍。即使一个资源(resourse)是可缓存的也可能存在缓存是否能利用此缓存副本为某个特定请求的约束。第一手的(firsthand)如果一个响应直接从源服务器或经过若干代理(proxy)并且没有不必要的延时最后到达客户端那么这个响应就是第一手的(firsthand)。如果响应通过源服务器(originserver)验证是有效性(validity)的那么这个响应也同样是第一手的。显式过期时间(explicitexpirationtime)是源服务器认为实体(entity)在没有被进一步验证(validation)的情况下缓存(cache)不应该利用其去响应后续请求的时间(译注:也就是说当响应的显式过期时间达到后缓存必须要对其缓存的副本进行重验证否则就不能去利用此副本去响应后续请求)。启发式过期时间(heuristicexpirationtime)当没有显式过期时间(explicitexpirationtime)可利用时由缓存指定过期时间年龄(age)一个响应的年龄是从被源服务器发送或被源服务器成功验证到现在的时间。保鲜寿命(freshnesslifetime)一个响应产生到过期之间的时间。保鲜(Fresh)如果一个响应的年龄还没有超过保鲜寿命(freshnesslifetime)那么它就是保鲜的。陈旧(Stale)一个响应的年龄已经超过了它的保鲜寿命(freshnesslifetime)那么就是陈旧的语义透明(semanticallytransparent)缓存(cache)可能会以一种语意透明(semanticallytransparent)的方式工作。这时对于一个特定的响应使用缓存既不会对请求客户端产生影响也不会对源服务器产生影响缓存的使用只是为了提高性能。当缓存(cache)具有语意透明时客户端从缓存接收的响应跟直接从源服务器接收的响应完全一致(除了使用hopbyhop头域)。验证器(Validator)验证器其实是协议元素(例如:实体标签(entitytag)或最后修改时间(lastmodifiedtime)等)这些协议元素被用于识别缓存里保存的副本(即缓存项)是否等价于源服务器的实体的副本。上游下游(upstreamdownstream)上游和下游描述了消息的流动:所有消息都是从上游流到下游。内向外向(inboundoutbound)内向和外向指的是消息的请求和响应路径:“内向”即“移向源服务器”“外向”即“移向用户代理(useragent)”。总体操作HTTP协议是一种请求响应型的协议。客户端给服务器发送请求的格式是一个请求方法(requestmethod)URI协议版本号然后紧接着一个包含请求修饰符(modifiers)客户端信息和可能的消息主体的类MIME(MIMElike)消息。服务器对请求端发送响应的格式是以一个状态行(statusline)其后跟随一个包含服务器信息、实体元信息和可能的实体主体内容的类MIME(MIMElike)的消息。其中状态行(statusline)包含消息的协议版本号和一个成功或错误码。HTTP和MIME之间的关系如附录节所阐述。大部分的HTTP通信是由用户代理(useragent)发起的由应用于一个源服务器资源的请求构成。最简单的情形这可以通过用户代理(UA)和源服务器(O)之间的单一连接(v)来实现。请求链(Requestchain)用户代理(UA)单一连接(v)源服务器(O)<响应链(responsechain)有可能在请求响应链中出现一个或多个中间者(intermediares)这是比较复杂的情形。常见的中间者(intermediares)有三种:代理(proxy)网关(gateway)和隧道(tunnel)。代理(proxy)是一种转发代理(aforwardingagent)它接收绝对URI(absouluteurl相对于相对url)请求重写全部或部分消息然后把格式化后的请求发送到URI指定的服务器上。网关是一种接收代理(receivingagent)它充当一个在服务器之上的层(layer)必要时它会把请求翻译成为下层服务器的协议。隧道不改变消息而充当两个连接之间的中继点它用于通信需要穿过中间者(如防火墙)甚至当中间者不能理解消息内容的时候。请求链(requestchain)UAvAvBvCvO<响应链(responsechain)上图显示了用户代理(useragent)和源服务器之间的三个中间者(AB和C)。整条链的请求或响应将会通过四个被隔离开的连接。这个不同点很重要因为某些HTTP通信选项有可能只能采用最近的非隧道邻接点的连接有可能只采用链的端点(endpoint)或者也有可能只采用于链上所有连接。图表尽管是线性的每个参与者可能忙于多个并发的通信。例如B可以接收来自不是A的许多客户端的请求并且/或者可以把请求转发到不是C的服务器与此同时C正在处理A的请求。通信中任何非隧道成员都可能会采用一个内部缓存(internalcache)来处理请求。如果沿着链的成员有请求已缓存的响应请求响应链就会大大缩短。下图阐明了一个最终请求响应链假定B拥有一个来自于O(通过C)的以前请求响应的缓存副本并且此请求的响应并未被UA或A缓存。请求链(requestchain)>UAvAvBCO<响应链(responsechain)并不是所有的响应都能有效地缓存一些请求可能含有修饰符(modifiers)这些修饰符对缓存动作有特殊的要求。HTTP对缓存行为(behavior)和可缓存响应(cacheableresponses)的定义在第章定义。实际上目前万维网上有多种被实践和部署的缓存和代理的体系结构和配置。这些系统包括节省带宽的缓存代理(proxycache)层次(hierarchies)系统可以广播(broadcast)或多播(multicast)缓存数据的系统通过CDROM发布缓存数据子集的机构等等。HTTP系统(httpsystem)会被应用于宽带连接的企业局域网中的协作并且可以被用于PDAs进行低耗无线断续连接访问。HTTP的宗旨是为了支持各种各样的已经部署的配置同时引进一种协议结构让它满足可以建立高可靠性的web应用程序即使不能达到这种要求也至少可以可靠的定位故障。HTTP通信通常发生在TCPIP连接上。默认端口是TCP不过其它端口也可以使用。但并不排除HTTP协议会在其它协议之上被实现。HTTP仅仅期望的是一个可靠的传输(译注:HTTP一般建立在传输层协议之上)所以任何提供这种保证的协议都可以被使用协议传输数据单元(transportdataunit)与HTTP请求和响应的消息结构之间的映象已经超出了本规范的范围。大部分HTTP的实现都是对每个请求响应交换(exchange)产生一个新的连接。而HTTP中一个连接可以用于一个或更多请求响应交换虽然连接可能会因为各种原因中断(见第节)。符号习惯和一般语法扩充的BNF(扩充的巴科斯诺尔范式)本文档规定的所有机制都用两种方法描述:散文体(prose)和类似于RFC的扩充BackusNaurForm(BNF)。要理解本规范使用者需熟悉符号表示法。扩充BNF结构如下:名字(name)=定义(definition)名字(name)就是代表规则的名字规则名里不能包含“<”和“>”通过等号把规则名和规则定义(definiation)分离开。空格只有在采用延续行缩进来指定跨度多于一行的规则定义的时候才有意义。某些基本规则(basicrules)使用大写字母包含在规则定义里如SPLWSHTCRLFDIGITALPHA等等。尖括号可以包含在规则定义里只要它们的存在有利于区分规则名的使用。“字面文本”(“literal”)字面文本(literaltext)两边用引号。除非声明字面文本大小写不敏感(译注:如HEX="A"|"B"|"C"|"D"|"E"|"F"|"a"|"b"|"c"|"d"|"e"|"f"|DIGIT里的AB,CD等等都是字面文本(literaltext))。规则|规则由竖线(“|”)分开的元素是可选的例如“yes|no”表示yes或no都是可接受的。(规则规则)围在括号里的多个元素视作一个元素。所以“(elem(foo|bar)elem)”符合的字符串是“elemfooelem”和“elembarelem”。*规则前面的字符“*”表示重复。完整的形式是“<n>*<m>元素”表示元素至少出现<n>次至多出现<m>次。默认值是和无穷大所以"*(元素)"允许任何数值包括零"*元素"至少出现一次"*element"允许出现一次或两次。规则方括号里是任选元素“foobar”相当于“*(foobar)”。N规则特殊的重复:“<n>(元素)”与“<n>*<n>(元素)”等价就是说(元素)正好出现<n>次。这样DIGIT是一个两位数字ALPHA是一个由三个字符组成的字符串。#规则类似于“*”结构“#”是用来定义一系列元素的。完整的形式是<n>#<m>元素表示至少<n>个元素至多<m>个元素元素之间被一个或多个逗号(“,”)以及可选的线性空白(LWS)隔开了。这就使得表示列表这样的形式变得非常容易像(*LWSelement*(*LWS","*LWSelement))就可以表示为#element无论在哪里使用这个结构空元素都是允许的但是不计入元素出现的次数。换句话说“(element),,(element)”是允许的但是仅仅视为两个元素。因此在至少需要一个元素的地方必须存在至少一个非空元素。默认值是和无穷大这样“#element”允许任意零个或多个元素“#element”需要至少一个“#element”允许一个或两个元素。注释(comment)用分号引导注释。隐含的*LWS本规范所描述的语法是基于字(wordbased)的。除非特别注明线性空白(LWS)可以出现在任何两个相邻字之间(标记(token)或引用字符串(quotedstring))以及相邻字和间隔符之间但是这并没有改变对一个域的解释。任何两个标记(token)之间必须有至少一个分割符否则将会被理解为只是一个标记。基本规则(basicrule)下面的规则贯穿于本规范的全文此规则描述了基本的解析结构。USASCII(美国信息交换标准码)编码字符集是由ANSIX定义的。OCTET(字节)=<任意八比特的数据序列>CHAR=<任意ASCII字符(ascii码值从到的字节)>UPALPHA=<任意大写字母"A""Z">LOALPHA=<任意小写字母"a""z">ALPHA=UPALPHA|LOALPHADIGIT=<任意数字>CTL=<任意控制字符(ascii码值从到的字节)及删除键DEL(>CR=<USASCIICR,回车()>LF=<USASCIILF,换行符()>SP=<USASCIISP,空格()>HT=<USASCIIHT,水平制表()><">=<USASCII双引号()>HTTP将CRLF的序列定义为任何协议元素的行尾标志但这个规定对实体主体(endtitybody)除外(要求比较松的应用见附录)。实体主体(entitybody)的行尾标志是由其相应的媒体类型定义的如节所述。CRLF=CRLFHTTP的消息头域值可以折叠成多行但紧接着的被折叠行由空格(SP)或水平制表(HT)折叠标记开始。所有的线性空白(LWS)包括被折叠行的折叠标记(空格SP或水平制表键HT)具有同SP一样的语义。接收者在解析域值并且将消息转送到下游(downstream)之前可能会将任何线性空白(LWS)替换成单个SP(空格)。LWS=CRLF*(SP|HT)下面的TEXT规则仅仅适用于头域内容和值的描述不会被消息解释器解析。TEXT里的字可以包含不仅仅是ISO里的字符集也可以包含RFC里规定的字符集。TEXT=<除CTLs以外的任意OCTET但包括LWS>一个CRLF只有作为HTTP消息头域延续的一部分时才在TEXT定义里使用。十六进制数字字符用在多个协议元素(protocolelement)里。HEX="A"|"B"|"C"|"D"|"E"|"F"|"a"|"b"|"c"|"d"|"e"|"f"|DIGIT许多HTTP的消息头域值是由LWS或特殊字符分隔的字构成的。这些特殊字符必须先被包含在引用字符串(quotedstring)里之后才能用于参数值(如节定义)里。token(标记)=*<除CTLs与分割符以外的任意CHAR>separators(分割符)="("|")"|"<"|">"|""|","|""|":"|""|<">|""|""|""|""|"="|"{"|"}"|SP|HT通过用圆括号括起来注释(comment)可以包含在一些HTTP头域里。注释只能被包含在域值定义里有“comment”的域里。在其他域里圆括号被视作域值的一部分。comment(注释)="("*(ctext|quotedpair|comment)”)"ctext=<除"("和")"以外的任意TEXT>如果一个TEXT若被包含在双引号里则当作一个字。quotedstring=(<">*(qdtext|quotedpair)<">)qdtext=<anyTEXTexcept<">>斜划线("")可以被作为单字符的引用机制但是必须要在quotedstring和comment构造之内。quotedpair=""CHAR协议参数HTTP版本HTTP使用一个“<major><minor>”数字模式来指明协议的版本号。为了进一步的理解HTTP通信协议的版本号指示了发送端指明消息的格式和能力而不仅仅是通过双方通信而获得的通信特性。当消息元素的增加不会影响通信行为或扩展了域值时协议版本是不需要修改的。当协议会因为添加一些特征而做了修改时<minor>数字就会递增。这些修改不会影响通常的消息解析算法但它会给消息添加额外的语意(semantic)并且会暗示发送者具有额外的能力。协议的消息格式发生变化时<major>数字就会增加。HTTP消息的版本在HTTPVersion域被指明HTTPVersion域在消息的第一行中。HTTPVersion="HTTP"""*DIGIT""*DIGIT注意major和minor数字必须被看成两个独立整数每个整数都可以递增并且可以增大到大于一位数的整数如HTTP比HTTP低而HTTP又比HTTP低。前导必须被接收者忽略并且不能被发送者发送。一个应用程序如果发送或响应消息里的包含HTTPVersion为“HTTP”的消息那么此应用程序必须至少条件遵循此协议规范。最少条件遵循此规范的应用程序应该把“HTTP”包含在他们的消息的HTTPVersion里并且对任何不兼容HTTP的消息也必须这么做。关于何时发送特定的HTTPVersion值的细节参见RFC。应用程序的HTTP版本是应用程序最少条件遵循的最高HTTP版本。当代理或网关应用程序转发(forwarding)消息的协议版本不同于代理或网关应用程序本身协议版本的时候代理(proxy)和网关(gateway)应用程序就要小心。因为消息里协议版本说明了发送者处理协议的能力所以一个代理网关千万不要发送一个高于该代理网关应用程序协议版本的消息。如果代理或网关接收了一个更高版本的消息它必须要么使协议的版本降低要么以一个错误响应或者要么切换到隧道行为(tunnelbehavior)。自从RFC发布后由于存在与HTTP代理(proxy)的互操作问题所以缓存代理(cachingproxies)必须能提升请求的版本到他们能支持的程度但网关(gateway)可以这么做也可以不这么做而隧道(tunnels)却不能这么做。代理(Proxy)网关(gateway)的响应(Response)必须和请求(request)的主版本(majorversion)号保持一致。注意:HTTP版本间的转换可能会对消息头域(headerfields)在版本里有或没有而进行改变。通用资源标识符(URI)URIs有许多名字已为人所知:WWW地址通用文档标识符通用资源标识符以及后来的统一资源定位器(URL)和统一资源名称(URN)。就HTTP而言通用资源标识符(URI)只是简单的格式化字符串通过名称位置或其它特征识别一个资源。一般语法根据使用的背景HTTP里的URIs可以表示成绝对(absoulute)形式或相对形式(相对URI基于根URI)。两种形式的区别是根据这样的事实:绝对URI总是以一个模式(scheme)名作为开头其后是一个冒号。关于URL更详尽的语法和含义请参看“统一资源标识符(URI):一般语法和语义”RFC(代替了RFCs和RFC)。本规范采用了RFC里的”URIreference”"absoluteURI""relativeURI""port""host""abspath""relpath",和"authority"的定义格式。HTTP协议不对URI的长度作事先的限制服务器必须能够处理任何他们提供资源的URI并且应该能够处理无限长度的URIs这种无效长度的URL可能会在客户端以基于GET方式的请求时产生。如果服务器不能处理太长的URI的时候服务器应该返回状态码(此状态码代表RequestURI太长)。注:服务器在依赖大于字节的URI时应谨慎因为一些旧的客户或代理实现可能不支持这些长度。HTTPURL在HTTP协议里http模式(httpscheme)被用于定位网络资源(resourse)的位置。本节定义了httpURLs这种特定模式(scheme)的语法和语义。httpURL="http:"""host":"portabspath""query如果端口为空或未给出就假定为。它的语义即:已识别的资源存放于正在监听tcp连接的那个端口的服务器上并且请求资源的的RequestUR为绝对路径(节)。无论什么可能的时候URL里使用IP地址都是应该避免的(参看RFC)。如果绝对地址(abspath)没有出现在URL里那么应该给出""。如果代理(proxy)收到一个主机(host)名但是这个主机名不是全称域名(fullyquanlifieddomainname)则代理应该把它的域名加到主机名上。如果代理(proxy)接收了一个全称域名代理不能改变主机(host)名称。URI比较当比较两个URI是否匹配时客户应该对整个URI比较时应该区分大小写并且一个字节一个字节的比较。但下面有些特殊情况:一个为空或未给定的端口等同于URIrefernece(见RFC)里的默认端口主机(host)名的比较必须不区分大小写模式(scheme)名的比较必须是不区分大小写的一个空绝对路径(abspath)等同于""。除了“保留(reserved)”和“不安全(unsafe)”字符集里的字符(参见RFC)其它字符和它们的"HEXHEX"编码的效果一样。例如,以下三个URI是等同的:http:abccom:~smithhomehtmlhttp:ABCcomEsmithhomehtmlhttp:ABCcom:esmithhomehtml日期时间格式(DateTimeFormats)完整日期(FullDate)HTTP应用曾经一直允许三种不同日期时间格式:Sun,Nov::GMTRFC,updatedbyRFCSunday,Nov::GMTRFC,obsoletedbyRFCSunNov::ANSIC'sasctime()format第一种格式是作为Internet标准提出来的它是一个国定长度的由RFC(RFC的升级版本)定义的一个子集。第二种格式使用比较普遍但是基于废弃的RFC协议并且没有年份。如果HTTP客户端和服务器要解析日期他们必须能接收所有三种格式(为了兼容HTTP)但是它们只能用RFC里定义的日期格式来填充头域(headerfield)的值里用到HTTPdate的地方。注:日期值的接收者被鼓励能可靠地接收来自于非HTTP应用程序发送的的日期值例如有时可以通过代理(proxy)网关(gateway)向SMTP或NNTP获取或提交消息。所有的HTTP日期时间都必须以格林威治时间(GMT)表示。对HTTP而言GMT完全等同于UTC(世界协调时间)。前两种日期时间格式里包含“GMT”它是时区的三个字面的简写并且当读到一个asctime格式时必须先被假定是GMT时间。HTTP日期(HTTPdate)区分大小写不能在此语法中除SP之外包含一个多余的LWS。HTTPdate=rfcdate|rfcdate|asctimedaterfcdate=wkday","SPdateSPtimeSP"GMT"rfcdate=weekday","SPdateSPtimeSP"GMT"asctimedate=wkdaySPdateSPtimeSPDIGITdate=DIGITSPmonthSPDIGITdaymonthyear(eg,Jun)date=DIGIT""month""DIGITdaymonthyear(eg,Jun)date=monthSP(DIGIT|(SPDIGIT))monthday(eg,Jun)time=DIGIT":"DIGIT":"DIGIT::::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对日期时间格式的要求仅仅应用在协议流的使用。客户和服务器不必把这种格式应用于用户呈现(userpresentation)请求记录日志等等。DeltaSeconds(秒间隔)一些HTTP头域(headerfield)允许时间值以秒为单位以十进制整数表示此值代表消息接收后的时间。deltaseconds=*DIGIT字符集(CharacterSets)HTTP使用术语“字符集”的定义这和MIME中所描述的是一样本文档中的术语“字符集”涉及到一种方法此方法是用单个或多个表将一个字节序列转换成一个字符序列(译注:从这里来看这应该是一种映射关系表保存了映射关系)。注意在反方向上无条件的转换是不成立的因为并不是所有的字符都能在一个给定的字符集里得到一个字符集里可能提供多个字节序列表征一个特定的字符。这个定义为的是允许不同种类的字符编码从单一简单表映射(如USASCII)到复杂表的转换方法例如利用ISO技术。然而相关于MIME字符集名字的定义必须要充分指定从字节到字符的映射。特别是利用外部外围信息来精确确定映射是不允许的注:这里使用的术语“字符集”一般的被称作一种“字符编码”。不过既然HTTP和MIME在同一机构注册术语统一是很重要的。HTTP字符集的标记(token)是用不区分大小写的。所有的标记由IANA字符集注册机构定义。charset=token尽管HTTP允许用任意标记(token)作为字符集(charset)值但这个标记已经在IANA字符集注册机构注册过了那么这个标记必须代表在该注册机构定义的字符集。对那些非IANA定义的字符集应用程序应该限制使用。HTTP协议的实现者应该注意IETF字符集的要求丢失字符集(MissingCharset)一些HTTP应用程序当他们解析ContentType头时当发现没有字符集参数(charsetparameter译注:ContentType:textplaincharset=此时charset=就是字符集参数)可用时这意味着接收者必须猜测实体主体(entitybody)的字符集到底是什么。如果发送者希望避免这种情况他应该在ContentType头域里包含一个字符集参数即使字符集是ISO的也应该指明这样就不会让接收者产生混淆。不幸的是一些旧的HTTP客户端不能处理在ContentType头域里明确指定的字符集参数。HTTP接收端必须要认真对待发送者提供的字符集并且当用户代理(useragent译注:如浏览器)开始呈现一个文档时虽然用户代理可以猜测文档的字符集但如果contenttype头域里提供了字符集并且用户代理也支持这种字符集的显示不管用户代理是否愿意它必须要利用这种字符集。参见节。内容编码(ContentCodings)内容编码(contentcoding)的值表示一种曾经或能被应用于一个实体的编码转换(encodingtransformation)。内容编码主要用于文档的压缩或其它有效的变换但这种变换必须不能丢失文档的媒体类型的特性并且不能丢失文档的信息(译注:就像有损压缩和无损压缩前者不会丢失信息后者会丢失信息)。实体经常被编码后保存然后传送出去并且在接收端被解码。contentcoding=token所有内容编码(contentcoding)的值是不区分大小写的。HTTP在接受译码(AcceptEncoding节)和内容译码(ContentEncoding)(节)头域里使用内容编码(contentcoding)的值。尽管该值描述了内容编码更重要的是它指出了一种解码机制利用这种机制对实体的编码进行解码。网络分配数字权威((IANA)充当内容编码的值标记(token)注册机构。最初注册表里包含下列标记:gzip(压缩程序)一种由文件压缩程序"gzip"(GNUzip)产生的编码格式(在RFC中描述)。这种编码格式是一种具有位CRC的LempelZiv编码(LZ)。compress(压缩)一种由UNIX文件压缩程序"compress"产生的编码格式。这种编码格式是一种具有可适应性的LempelZivWelch编码(LZW)。对于将来的编码用程序名识表征编码格式是不可取。在这里用到他们是因为他们在历史的作用虽然这样做并不好。为了同以前的HTTP实现相兼容应用程序应该将"xgzip"和"xcompress"分别等同于"gzip"和"compress"。deflate(缩小) deflate编码是由RFC定义的"zlib"编码格式与RFC里描述的"deflate"压缩机制的组合的产物。identity(一致性)Identity是缺省编码指明这种编码表明不进行任何编码转换。这种内容编码仅被用于接受译码(AcceptEncoding)头域里但不能被用在内容译码(ContentEncoding)头域里。新的内容编码的值标记(token)应该被注册为了实现客户和服务器间的互操作性实现新值的内容编码算法规范应该能公开利用并且能独立实现并且与本节中被定义的内容编码目的相一致。传输编码(TransferCodings)传输编码(transfercoding译注:transfercoding和和transfercoding这两个术语在本协议规范里所表达的意思其实没什么太大区别“transfercoding”可能更能表达语意因为它是规则中的规则名)的值被用来表示一个曾经能够或可能应用于一个实体的编码转换传输编码是为了能够确保网络安全传输。这不同于内容编码(contentcoding)因为传输编码(transfercoding)是消息的属性而不是实体的属性。transfercoding="chunked"|transferextensiontransferextension=token*(""parameter)参数(parameter)采用属性值对的形式parameter=attribute"="valueattribute=tokenvalue=token|quotedstring所有传输编码的值是大小写不敏感。传输编码的值在TE头域(节)和在传输译码(Transferencoding)头域中(节)被运用。无论何时传输编码(transfercoding)应用于一个消息主体(messagebody)时如果存在多个传输编码则这些传输编码中必须包括“块”("chunked")传输编码除非通过关闭连接而使消息结束。当“块”(“chunked”)传输编码被用于传输编码时它必须是应用于消息主体的最后传输编码。"块"("chunked")传输编码最多只能用于消息主体(messagebody)一次。规定了上述规则后接收者就可以确定消息的传输长度(transferlength)(节)传输编码与MIME的内容传输译码(ContentTransferEncodingMIME)的值相似它被定义能够实现在位传输服务上保证二进制数据的安全传输。不过传输编码与内容传输译码(ContentTransferEncoding)对纯位传输协议有不同的侧重点。在HTTP中消息主体存在不安全的特性是因为有时候很难确定消息主体的长度(节)和在共享的传输上加密数据。网络分配数字权威(IANA)担任注册传输编码的值标记(token)的角色。起初,注册包含如下标记:"块"(节),"身份"(节),"gzip"(节),"压缩"(节),和"缩小"(节)新的传输编码的值标记应该注册这同新的内容编码的值标记也需要注册一样。如果接收端接收到一个经过传输编码编码过的实体主体(entitybody)但它不能对这个编码后

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/21

HTTP协议(RFC2616)中文版

仅供在线阅读

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利