超文本传输协议HTTP10.docx
- 文档编号:9015407
- 上传时间:2023-05-16
- 格式:DOCX
- 页数:60
- 大小:63.08KB
超文本传输协议HTTP10.docx
《超文本传输协议HTTP10.docx》由会员分享,可在线阅读,更多相关《超文本传输协议HTTP10.docx(60页珍藏版)》请在冰点文库上搜索。
超文本传输协议HTTP10
超文本传输协议--HTTP/1.0
(HyptertextTransferProtocol–HTTP/1.0)
组织:
中国互动出版网(http:
//www.china-
RFC文档中文翻译计划(http:
//www.china-
E-mail:
ouyang@china-
译者:
黄晓东(黄晓东xdhuang@)
译文发布时间:
2001-7-14
版权:
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载,但必须
保留本文档的翻译及版权信息。
NetworkWorkingGroupT.Berners-Lee
RequestforComments:
1945MIT/LCS
Category:
InformationalR.Fielding
UCIrvine
H.Frystyk
MIT/LCS
May1996
超文本传输协议--HTTP/1.0
(HyptertextTransferProtocol–HTTP/1.0)
关于下段备忘(StatusofThisMemo)
本段文字为Internet团体提供信息,并没有以任何方式指定Internet标准。
本段文字没
有分发限制。
IESG提示(IESGNote):
IESG已在关注此协议,并期待该文档能尽快被标准跟踪文档所替代。
摘要(Abstract)
HTTP(HypertextTransferProtocol)是应用级协议,它适应了分布式超媒体协作系统对
灵活性及速度的要求。
它是一个一般的、无状态的、基于对象的协议,通过对其请求方法
(requestmethods)进行扩展,可以被用于多种用途,比如命名服务器(nameserver)及分
布式对象管理系统。
HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输
的数据。
HTTP自从1990年就在WWW上被广泛使用。
该规范反映了“HTTP/1.0”的普通用法。
1.介绍(Introduction)
1.1目的(Purpose)
HTTP(HypertextTransferProtocol)是应用级协议,它适应了分布式超媒体协作系统对灵活性及速度的要求。
它是一个一般的、无状态的、基于对象的协议,通过对其请求方法(requestmethods)进行扩展,可以被用于多种用途,比如命名服务器(nameserver)及分布式对象管理系统。
HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。
HTTP自从1990年就在WWW上被广泛使用。
该规范反映了“HTTP/1.0”的普通用法。
该规范描述了在大多数HTTP/1.0客户机及服务器上看起来已经实现的特性。
规范将被分成两个部分:
HTTP特性的实现是本文档的主要内容,而其它不太通行的实现将被列在附录D中。
实用的信息系统需要更多的功能,而不仅仅是数据的获取,包括搜索、前端更新及注解。
HTTP允许使用开放的命令集来表示请求的目的,它使用基于URI[2](UniformResourceIdentifier),即统一资源标识的规则来定位(URL[4])或命名(URN[16])方法所用到的资源。
HTTP使用与邮件(InternetMail[7])和MIME(MultipurposeInternetMailExtensions[5])相似的格式来传递消息。
HTTP也作为用户代理、代理服务器/网关与其它Internet协议进行通讯的一般协议,这些协议是,SMTP[12],NNTP[11],FTP[14],Gopher[1],andWAIS[8]等。
HTTP允许不同的应用可以进行基本的超媒体资源访问,并简化用户代理的实现。
1.2术语(Terminology)
本规范用了许多与参与方、对象及HTTP通讯相关的术语,如下:
连接(connection)
两个应用程序以通讯为目的在传输层建立虚拟电路。
消息(message)
HTTP通讯的基本单元,在连接中传输的结构化的、有顺序的字节(其含义在第四
节中定义)。
请求(request)
HTTP的请求消息(在第五节定义)
回应(response)
HTTP的回应消息(在第六节定义)
资源(resource)
网络上可以用URI来标识的数据对象或服务(见3.2节)
实体(entity)
可被附在请求或回应消息中的特殊的表示法、数据资源的表示、服务资源的回应等,由实体标题(entityheader)或实体主体(entitybody)内容形式存在的元信息组成。
客户端(client)
指以发出请求为目的而建立连接的应用程序。
用户代理(useragent)
指初始化请求的客户端,如浏览器、编辑器、蜘蛛(web爬行机器人)或其它终端用户工具。
服务器(server)
指接受连接,并通过发送回应来响应服务请求的应用程序。
原始服务器(originserver)
存放资源或产生资源的服务器。
代理(proxy)
同时扮演服务器及客户端角色的中间程序,用来为其它客户产生请求。
请求经过变换,被传递到最终的目的服务器,在代理程序内部,请求或被处理,或被传递。
代理必须在消息转发前对消息进行解释,而且如有必要还得重写消息。
代理通常被用作经过防火墙的客户端出口,用以辅助处理用户代理所没实现的请求。
网关(gateway)
服务器之间的服务器。
与代理不同,网关接受请求就好象它就是被请求资源所在的原始服务器,发出请求的客户端可能并没有意识到它在与网关进行通讯。
网关是网络防火墙服务器端的门户。
对非HTTP系统资源进行访问时,网关做为中间的协议翻译者。
隧道(tunnel)
隧道就好象连接两端看不见的中继器。
处于激活状态时,它虽然是由HTTP请求来初始化的,但它并不参与HTTP通讯。
当需要中继连接的两端关闭后,隧道也自然终止。
在入口有需求及中间程序无法或不该解释要中继的通讯时,通常要用到隧道技术。
缓存(cache)
指程序本地存储的回应消息和用来控制消息存储、重获、删除的子系统。
缓存回应的目的是为减少请求回应时间,以及未来一段时间对网络带宽的消耗。
任何客户端及服务端都可以包含缓存。
服务器在以隧道方式工作时不能使用缓存。
任何指定的程序都有能力同时做为客户端和服务器。
我们在使用这个概念时,不是看程序功能上是否能实现客户及服务器,而是看程序在特定连接时段上扮演何种角色(客户或服务器)。
同样,任何服务器可以扮演原始服务器、代理、网关、隧道等角色,行为的切换取决于每次请求的内容。
1.3概述(OverallOperation)
HTTP协议是基于请求/回应机制的。
客户端与服务器端建立连接后,以请求方法、URI、协议版本等方式向服务器端发出请求,该请求可跟随包含请求修饰符、客户信息、及可能的请求体(body)内容的MIME类型消息。
服务器端通过状态队列(statusline)来回应,内容包括消息的协议版本、成功或错误代码,也跟随着包含服务器信息、实体元信息及实体内容的MIME类型消息。
绝大多数HTTP通讯由用户代理进行初始化,并通过它来组装请求以获取存储在一些原始服务器上的资源。
在最简单的情况下,通过用户代理(UA)与原始服务器(O)之间一个简单的连接(v)就可以完成。
requestchain------------------------>
UA-------------------v-------------------O
<-----------------------responsechain
更复杂的情况是当请求/回应链之间存在一个或更多中间环节。
总体看来,有三种中间环节:
代理(proxy)、网关(gateway)、隧道(tunnel)。
代理(proxy)是向前推送的代理人(agent),它以绝对形式接收URI请求,重写全部或部分消息,并将经过改写的请求继续向URI中指定的服务器处推送。
网关是接收代理,它处于服务器层之上,在必要时候,它用服务器可识别的协议来传递请求。
隧道不改变消息,它只是连接两端的中继点。
在有中间层(如防火墙)或中间层无法解析消息内容的情况下,需要靠隧道技术来帮助通讯穿越中间层。
requestchain-------------------------------------->
UA-----v-----A-----v-----B-----v-----C-----v-----O
<-------------------------------------responsechain
上面的图形表示在用户代理和原始服务器之间有三个中间层(A,B和C)。
由图可见,请求或回应消息在整个信息链上运行需要通过四个单独的连接,它与在此之前介绍的简单情况是有区别的,而且此区别是十分重要的。
因为HTTP通讯选项可以设置成几种情况,如只与最近的非隧道邻居连接、只与信息链末端连接、或者可与链中全部环节连接等等。
虽然上面的图是线性的,而实际上每个参与环节都在同时与多方进行通讯活动。
例如,B在接受除A之外其它客户端请求的同时,向除C之外的其它服务器推送请求,在这个时刻,它可能接受到A的请求,并给予处理。
参与通讯的任何一方如果没有以隧道方式进行工作,必须要借助内部缓存机制来处理请求,如果链上某个参与方碰巧缓存了某个请求的回应,那就相应于缩短了请求/回应链。
下面的图例演示了当B缓存了从O经由C过来的回应信息,而UA和A没缓存的情况:
requestchain---------->
UA-----v-----A-----v-----B------C------O
<---------responsechain
并非所有的回应都可以被缓存,某些请求所包含的修饰符中可能对缓存行为进行了特别指明。
一些基于HTTP/1.0的应用使用了启发式的方法来描述哪些回应可被缓存,而哪些则不可以,但遗憾的是,这些规则并没有形成标准。
在Internet上,HTTP通讯往往基于TCP/IP的连接方式。
缺省的端口是TCP80[15]口,但也可以使用其它端口。
并不排除基于Ineternet上的其它协议或网络协议的HTTP实现方式,HTTP只是假定传输是可靠的,因而任何能提供这种保证的协议都可以被使用。
至于HTTP/1.0请求和回应在数据传输过程中的数据结构问题,不在本文讨论范围之内。
实验室应用除外,当前的做法是客户端在每次请求之前建立连接,而服务器端在发送回应后关闭此连接。
不管客户端还是服务器端都应注意处理突发的连接中断,因为双方都有可能因为用户操作、自动超时、程序失败等原因关闭与对方的连接。
在这种情况下,不管请求处于什么样的状态,如单方或双方同时关闭连接,都会导致当前的请求被终止。
1.4HTTPandMIME
HTTP/1.0使用了多种结构来定义MIME,详见RFC1521[5]。
附录C描述了Internet承认的Internet介质类型与mail介质类型的不同工作方式,并给出二者区别的基本解释。
2.标志转换及通用语法(NotationalConventionsandGenericGrammar)
2.1补充反馈方式(AugmentedBNF)
与RFC822[7]很类似,本文对所有机制的说明都是以散文和补充反馈的方式来描述的。
对于实现者来说,要想理解这些约定,必须对这些符号很熟悉。
补充反馈方式(augmentedBNF)包括下面的结构:
要解释的名词=名词解释(name=definition)
规则的名字(name)就是它本身(不带任何尖括号,“<”,“>”),后面跟个等号=,然后就是该规则的定义。
如果规则需要用多个行来描述,利用空格进行缩进格式排版。
某些基本的规则使用大写,如SP,LWS,HT,CRLF,DIGIT,ALPHA,等等。
定义中还可以使用尖括号来帮助理解规则名的使用。
字面意思("literal")
文字的字面意思放在引号中间,除非特别指定,该段文字是大小写敏感的。
规则1|规则2(rule1|rule2)
“|”表示其分隔的元素是可选的,比如,“是|否”要选择‘是’或‘否’。
(规则1 规则2)((rule1rule2))
在圆括号中的元素表明必选其一。
如(元素1(元素2|元素3)元素4)可表明两种意思,即“元素1 元素2 元素4”和“元素1 元素3 元素4”
*规则(*rule)
在元素前加星号“*”表示循环,其完整形式是“
缺省值是0到无限,例如,“1*元素”意思是至少有一个,而“1*2元素”表明允许有1个或2个。
[规则]([rule])
方括号内是可选元素。
如“[元素1 元素2]”与“*1(元素1 元素2)”是一回事。
N 规则(Nrule)
表明循环的次数:
“
因而,2DIGIT就是2位数字,3ALPHA就是由三个字母组成字符串。
#规则(#rule)
“#”与“*”类似,用于定义元素列表。
完整形式是“
空元素在结构中可被任意使用,但不参与元素个数的计数。
也就是说,“(元素1),,(元素2)”仅表示2个元素。
但在结构中,应至少有一个非空的元素存在。
缺省值是0到无限,即“#(元素)”表示可取任何数值,包括0;而“1#元素”表示至少有1个;而“1#2元素”表示有1个或2个。
;注释(;comment)
分号后面是注释,仅在单行使用。
隐含*LWS(implied*LWS)
本文的语法描述是基于单词的。
除非另有指定,线性空格(LWS)可以两个邻近符号或分隔符(tspecials)之间任意使用,而不会对整句的意思造成影响。
在两个符号之间必须有至少一个分隔符,因为它们也要做为单独的符号来解释。
实际上,应用程序在产生HTTP结构时,应当试图遵照“通常方式”,因为现在的确有些实现方式在通常方式下无法正常工作。
2.2基本规则(BasicRules)
下面的规则将用于本文后面对结构基本解析。
US-ASCII编码字符集定义[17]。
OCTET=<8-bit的顺序数据,即bytes>
CHAR=
UPALPHA=
LOALPHA=
ALPHA=UPALPHA|LOALPHA
DIGIT=
CTL=
CR=
LF=
SP=
HT=
<">=
HTTP/1.0规定,除实体主体(Entity-Body,见附录B容错应用)外,所有协议元素的行结束标志都是CRLF(按字节顺序)。
在实体主体内部的行结束标志定义及其对应的介质类型定义,见3.6节的描述。
CRLF=CRLF
HTTP/1.0的头可以折成许多行,只要每个后续行以空格或水平制表符开头。
所有的线性空格(LWS),同空格(SP)有相同的语义。
LWS=[CRLF]1*(SP|HT)
实际上,有些应用并没有考虑处理这样多行的头,所以从兼容性上考虑,HTTP/1.0应用最好不要产生折成多行的头。
TEXT规则只是用于描述消息解释器不关心的域的内容及其取值。
文本内容可包含不同于US-ASCII的字符。
TEXT=<除了控制字符(CTLs)之外的任何OCTET,包括LWS>
在标题域中的收件人域如包含US-ASCII字符集以外的字符,这些字符将按照ISO-8859-1标准来解释。
十六进制数字型字符在几个协议元素中到。
HEX="A"|"B"|"C"|"D"|"E"|"F"
|"a"|"b"|"c"|"d"|"e"|"f"|DIGIT
许多HTTP/1.0头域的内容由被LWS分隔的单词或特殊字符组成,这些特殊字符必须置于引号中间的字符串内,作为参数值使用。
Word=符号(token)|被引号引起来的字符串
token=1*<除控制字符(CTLs)或tspecials之外的任意字符>
tspecials="("|")"|"<"|">"|"@"
|","|";"|":
"|"\"|<">
|"/"|"["|"]"|"?
"|"="
|"{"|"}"|SP|HT
在HTTP头域中可用括号表示注释文字。
注释只允许写在包含注释的域,做为域值定义的一部分。
在除此之外其它域中,括号将被视为域值。
comment="("*(ctext|comment)")"
ctext=<除圆括号外的任何TEXT>
被双引号圈中的文本字符串将被视为一个单词。
quoted-string=(<">*(qdtext)<">)
qdtext=<除了双引号及控制字符之外的任何字符,包括LWS>
在HTTP/1.0中不允许使用后斜线“\”来引用单字符。
3.协议参数(ProtocolParameters)
3.1HTTP版本(HTTPVersion)
HTTP采用主从(
协议的版本政策倾向于让发送方表明其消息的格式及功能,而不仅仅为了获得通讯的特性,这样做的目的是为了与更高版本的HTTP实现通讯。
只增加扩展域的值或增加了不影响通讯行为的消息组件都不会导致版本数据的变化。
当协议消息的主要解析算法没变,而消息语法及发送方的隐含功能增加了,将会导致从版本号(
HTTP消息的版本由消息第一行中的HTTP版本域来表示。
如果消息中的协议版本没有指定,接收方必须假定它是符合HTTP/0.9的简单标准。
HTTP-Version="HTTP""/"1*DIGIT"."1*DIGIT
注意,主从版本应当被看作单独的整数,因为它们都有可能增加,从而超过一位整数。
因而,HTTP/2.4比HTTP/2.13版本低,而HTTP/2.13又比HTTP/12.3版本低。
版本号前面的0将被接收方忽略,而在发送方处也不应产生。
本文档定义了HTTP协议的0.9及1.0版本。
发送完整请求(Full-Request)及完整回应(Full-Response)消息的应用必须指明HTTP的版本为“HTTP/1.0”。
HTTP/1.0服务器必须:
o识别HTTP/0.9及HTTP/1.0请求命令中的请求队列(Request-Line)的格式。
o理解任何HTTP/0.9及HTTP/1.0中的合法请求格式。
o使用与客户端相同版本的协议进行消息回应。
HTTP/1.0客户端必须:
o识别HTTP/1.0回应中状态队列(Status-Line)的格式。
o理解HTTP/0.9及HTTP/1.0中合法回应的格式。
当代理及网关收到与其自身版本不同的HTTP请求时,必须小心处理请求的推送,因为协议版本表明发送方的能力,代理或网关不应发出高于自身版本的消息。
如果收到高版本的请求,代理或网关必须降低该请求的版本,并回应一个错误。
而低版本的请求也应在被推送前升级。
代理或网关回应请求时必须遵照前面列出的规定。
3.2统一资源标识(UniformResourceIdentifiers)
URI有许多名字,如WWW地址、通用文件标识(UniversalDocumentIdentifiers)、通用资源标识(UniversalResourceIdentifiers[2]),以及最终的统一资源定位符(UniformResourceLocators(URL)[4])和统一资源名(URN)。
在涉及HTTP以前,URI用简单格式的字符串描述-名字、位置、或其它特性,如网络资源。
3.2.1一般语法(GeneralSyntax)
在HTTP中URI可以用绝对形式表示,也可用相对于某一基本URI[9]的形式表示,具体取决于它们的使用方式。
这两种形式的不同在于绝对URI总是以方法名称后跟“:
”开头。
URI=(absoluteURI|relativeURI)["#"fragment]
absoluteURI=scheme":
"*(uchar|reserved)
relativeURI=net_path|abs_path|rel_path
net_path="//"net_loc[abs_path]
abs_path="/"rel_path
rel_path=[path][";"params]["?
"query]
path=fsegment*("/"segment)
fsegment=1*pchar
segment=*pchar
params=param*(";"param)
param=*(pchar|"/")
scheme=1*(ALPHA|DIGIT|"+"|"-"|".")
net_loc=*(pchar|";"|"?
")
query=*(uchar|reserved)
fragment=*(uchar|reserved)
pchar=uchar|":
"|"@"|"&"|"="|"+"
uchar=unreserved|escape
unreserved=ALPHA|DIGIT|safe|extra|national
escape="%"HEXHEX
reserved=";"|"/"|"?
"|":
"|"@"|"&"|"="|"+"
extra="!
"|"*"|"'"|"("|")"|","
safe
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 超文本 传输 协议 HTTP10