RFC2774HTTP 扩展框架Word文档格式.docx
《RFC2774HTTP 扩展框架Word文档格式.docx》由会员分享，可在线阅读，更多相关《RFC2774HTTP 扩展框架Word文档格式.docx（18页珍藏版）》请在冰豆网上搜索。
同样需要注意的是当HTTP被用作其它协议的基础时，它可能有必要和应该适当地用到一些其它扩展的机制，增加或代替一些东西，在这里会详细说明。
因此这篇文章不应该被看作是扩展HTTP的蓝图，但它所详细说明的机制可能在具体情况中非常有用。
概要
应用程序的广泛延伸已经提出了各式各样的HTTP协议的扩展。
当前的协作横跨了一个巨大的范围，包括分布式创造，协作，打印，和细微的程序响应机制。
这些HTTP的扩展并不是并列同等的，因为还没有任何的框架标准来定义它们，因此它们便相互独立起来。
这篇文章描述了一个一般性的HTTP扩展机制，试图缓和这些独立的协议和公众规范之间的矛盾，并让那些使用HTTP协议的客户端，服务器和代理兼容这些扩展的应用程序。
这个提议用全球化独一无二的标识符连接了每一个扩充，而且用HTTP的标题字段来显示这些扩展的标识符，并讲述了与他们有关的通讯延伸的信息。
目录
1.序论3
2.协定表记法3
3.扩展申明3
3.1标题字段前缀4
4.扩展标题字段5
4.1End-to-End扩展5
4.2Hop-by-Hop扩展5
4.3标题字段扩展响应6
5．强制HTTP请求6
5.1强制请求的实现7
6.强制HTTP响应7
7.510不扩展8
8.发布扩展8
9.缓冲考虑8
10.安全考虑9
11.参考书目9
12.感谢9
13.作者地址9
14.交互式协议概要10
15.例子11
15.1使用源服务器的代理11
15.2通过HTTP/1.1Proxy的源服务器用户代理11
15.3通过HTTP/1.0Proxy的源服务器用户代理12
全部版权陈述13
感谢14
1.序论
这个提议原意是用来缓和私人协定和大众规范的冲突；
并调和由软件构成的HTTP客户与服务器之间的动态扩展矛盾。
其扩展能力的方式如下：
o扩展单一的HTTP信息；
o引入新的符号；
o为新的应用程序开起源HTTP协议；
o协议间的转换，这些协议一旦开启，就能在原始的一堆协议中不受约束的运行；
这个提议预计在如下地方起作用：
o一些当事人创建并详细说明了一个扩展；
他们指定给其一个全球内唯一的URI，而且制定了在这个地址可用扩展的一个或多个表现法（见第8节）。
o一个实现此扩展机制（后来称为代理）的HTTP用户或服务器通过在HTTP信息中的扩展声明所涉及到的URI定义了这个扩展的用途（见第3节）。
o实现扩展声明的HTTP应用程序（后来成为终端）能演绎怎样合适的中断基于扩展声明的延伸信息。
这个建议使用了HTTP/1.1的特性，并通过让扩展程序与现有的HTTP应用程序共存的方式实现与HTTP/1.0相兼容。
应用程序实现此建议必须基于HTTP/1.1（或者是HTTP的更高版本）。
2.协定表记法
这篇说明书使用了与RFC2068[5]相同的表记法惯例和基本分析构架。
特别是BNF的结构记法，例如文章中的"
token"
"
quoted-string"
Request-Line"
field-name"
和
"
absoluteURI"
，与RFC2068[5]所解释的一样。
文档中的关键字"
MUST"
MUSTNOT"
REQUIRED"
SHALL"
SHALLNOT"
SHOULD"
SHOULDNOT"
RECOMMENDED"
MAY"
和"
OPTIONAL"
与RFC2119[6]所解释的一样。
这个建议不同于详细说明的URLs[8]的特点，不能潜在地用URNs来表达（见第8节）。
因此，更多一般性的术语URI[8]贯穿于这篇规范书的始终。
3.扩展申明
扩展申明适用于指示已经适用于一个信息的扩展和可能保留的标题namespace的一部分，藉着标题字段的前缀来进行识别（见3.1）。
这个区段定义了扩展声明的本身；
第四节定义了正在使用扩展声明的标题字段的设定。
这个规范并不定义任何适用于信息扩展的分枝或是两个扩展在逻辑上能或是不能在同一信息中共存。
它只是一个用来描述被应用的扩展和最终接受者为了在信息中合理地解释扩展声明可能或必须做的一个框架。
扩展声明的语法如下：
ext-decl=<
>
（绝对URI|字段名）<
[namespace][decl-扩展]
namespace="
;
"
ns"
="
标题前缀
标题前缀=2*DIGIT
decl-扩展=*（decl-ext）
decl-ext="
表征["
（表征|引用串）]
一个扩展被一个绝对的全球独一无二的URI或字段名所识别。
一个字段名必须在IETF标准方面唯一的叙述一个标题字段的定义，见RFC[3]。
一个URI能清楚地从冒号（“：
”）标记识别一个字段名。
标题名的支持如同扩展提供了使分散的扩展到扩展的转变策略一样，按照IETF标准定义RFC映射在全球独一无二的URI空间和在IETF标准定义RFC的特征之间，这个特征已按照第8节描述的方法被定义。
扩展声明的例子是：
“
“Range”
一个代理人可能使用decl-扩展机制来包含可选择的扩展声明参数但不能保证这些参数能被接受者清楚地辨认出来。
一个代理人不能使用decl-扩展来通过扩展例证数据，这些数据可能通过标题字段前缀的值进行验证（见第3.1节）。
为被识别的decl-ext参数应该被忽略并且在转寄扩展声明是不能被代理移动。
3.1标题字段前缀
标题字段前缀是一个动态产生的串。
所有在信息中与此串相匹配的标题字段，使用串的前缀匹配，属于此扩展声明。
标题字段前缀允许一个扩展声明动态地保留在一个协议信息中的标题空间的子空间，为了避免标题字段名的冲突并允许多样化的声明使用适用于相同信息的没有冲突的同一扩展。
使用标题前缀的标题字段有如下形式：
前缀标题=匹配的前缀字段名
匹配的前缀=标题前缀“-”
线性的白色空间（LWS）不能在标题前缀与“-”或匹配的前缀与字段名之间被使用。
串的前缀匹配算法则被用于匹配的前缀串。
使用数字的一个组合的前缀格式和“-”保证没有扩展生命能保留全部的标题字段名空间。
标题前缀机制已超过了其他的引用参数实现交互扩展的解决办法，因为它的建立是基于或因此考虑到使得新的扩展与现有的HTTP特征更容易整合的标题。
代理不允许在同一信息中重复地使用标题前缀，除非扩展明确规定（见第4.1节的一个扩展声明的最终接受者的讨论）。
客户端在产生标题前缀值时，就像在响应中多样化的标题字段的简便用途一样，在此多样化被认为是需求扩展声明的功能，应该尽可能地一致（见[5]，第13.6节）。
包含在变化的标题字段值中的前缀标题的标题字段的服务器必须同样包含相应的扩展声明的域名，作为其值的一部分。
例如，如果一个响应依赖于16-use-transform的标题字段的值，而这个字段在请求中已被可选择的扩展声明所定义，那么在响应中的多样化的标题字段可能如下：
Vary：
Opt，16-use-transform
需要注意的，标题前缀的一致性不是在信息中包含一个扩展声明的替代：
带标题前缀值的标题字段在同一信息中的扩展声明中不被定义，在这篇规范书中也不被定义。
标题前缀值的例子如下：
12
15
23
旧的应用软件可能介绍独立于此扩展机制的标题字段，就可能造成与前缀机制描述的标题字段的潜在冲突。
为了使这种风险最小化，前缀必须包含至少两个阿拉伯数字。
4.扩展标题字段
这个提议介绍了两种类型的扩展声明的实力：
强制性的和可选择性的，和这两种类型扩展声
的应用范围：
Hop-by-Hop及End-to-End（见第4.1节与第4.2节）。
一个强制的扩展声明指出最终接受者在处理信息或是提交错误报告时必须参考并使用由扩展给定的规则（见第5节和第7节）。
一个可选择的扩展声明指出扩展最终接受者在处理信息时可能参考或使用由扩展声明给定的规则，或是完全忽视扩展声明。
代理也许就不能识别是否最终接受者明白通过可选择性扩展或是简单地忽视扩展声明后扩展所涉及的。
扩展的实力与范围的合并详细说明了一个2*2的矩阵，由于四个新的全面的HTTP标题字段而十分著名：
Man,Opt,C-Man,andC-Opt。
（见第4.1节与第4.2节；
同样在附录14中，有一张源服务器与代理的交互作用表。
）
这标题字段是普通的标题字段，就像扩展实际应用于HTTP信息中所描述的一样。
如果适当的话，可选择的声明也许能被应用于任何的HTTP信息（见第5节，怎样将强制扩展声明应用于请求中和第6节，在响应中怎样应用它们）。
4.1End-to-End扩展
End-to-End声明必须被传送带扩展的最终接受者。
全面的标题字段Man和Opt是End-to-End标题字段并被如下定义：
强制=“Man”“：
”1#ext-decl
可选择=“Opt”“：
例如
HTTP/1.1200OK
Content-Length:
421
Opt:
http:
//www.digest.org/Digest"
ns=15
15-digest:
snfksjgor2tsajkt52"
……
一个End-to-End强制扩展声明的最终接受者必须运用扩展声明，像第5节和第6节所描述的一样。
4.2Hop-by-Hop扩展
Hop-by-Hop扩展声明只对单一的HTTP连接有意义。
在HTTP/1.1，C-Man，C-Opt和所有被C-Man,C-Opt定义的由匹配标题前缀值的标题字段必须被连接标题字段所保护。
也就是说，这些标题字段将被包含，作为连接标题字段指示（见[5]，第14.10节）。
这两个标题字段有如下语法：
c-mandatory="
C-Man"
:
1#ext-decl
c-optional="
C-Opt"
例如
M-GET/HTTP/1.1
Host:
some.host
C-Man:
//www.digest.org/ProxyAuth"
ns=14
14-Credentials="
g5gj262jdw@4df"
Connection:
C-Man,14-Credentials
一个Hop-by-Hop强制扩展声明的最终接受者必须运用扩展声明，像第5节和第6节所描述的一样。
4.3标题字段扩展响应
两个标题字段扩展响应被用于指出一个包含被最终接受者实行的强制扩展声明的请求，像第5.1节所描述的一样。
标题字段扩展响应专门被用于确认扩展的服务，并不能携带其他任何信息。
Ext标题字段被用于指示所有在请求中被实行的End-to-End强制扩展声明：
ext=“Ext”“：
”
C-Ext标题字段响应别用于指示所有在请求中被实行的Hop-by-Hop强制扩展声明：
c-ext=“C-Ext”“：
在HTTP/1.1中，C-Ext标题字段必须被标题连接所保护（见[5]，第14.10节）。
Ext和C-Ext标题字段并不互相排斥；
它们能在同一信息中同时出现，就像第5.1节所描述的一样。
5．强制HTTP请求
一个HTTP请求，如果它包含至少一个强制扩展声明（使用Man或C-Man标题字段），就被称为强制请求。
强制请求的方法名必须被加上前缀“M-”。
例如，一个客户端可能在HTTP输出中表示管理约束权限如下：
M-PUT/a-resourceHTTP/1.1
Man:
//www.copyright.org/rights-management"
ns=16
16-copyright:
http:
//www.copyright.org/COPYRIGHT.html
16-contributions:
//www.copyright.org/PATCHES.html
www.w3.org
1203
Content-Type:
text/html
<
!
doctypehtml...
一个遵守这篇规范的终端接收者受到强制请求必须按如下列出的步骤处理请求：
1.识别所有的强制扩展声明（包括Hop-by-Hop和End-to-End）；
服务器可能忽视可选择声明，并不影响处理HTTP信息的结果；
2.检查1）中已识别的扩展而且决定他们是否用来支持此信息。
如果不，返回510（无扩展）状态码（见第7节）；
3.如果2）的结果并不是返回510（无扩展）状态码，那么按照扩展的语义和已存在的在HTTP/1.1[5]中或HTTP的更高版本中详细说明了的HTTP方法名处理请求。
HTTP方发明可以通过忽略方法名前缀“M-”来获得。
4.如果3）中的赋值成功而且强制请求完成。
服务器必须像第5.1节所定义的作出响应。
一台服务器不能不了解和服从在请求中的所有强制扩展就实现请求。
一个不作为强制扩展声明终端用户的代理在推进信息时不能移动扩展声明或是方法名前缀“M-”
（见第5.1节，在强制扩展声明已经实现后怎样进行探测）。
一台服务器接收到一条HTTP/1.0（或更早版本的HTTP）信息，包含了连接标题必须，对此字段
中的每一个连接记号，像连接记号用同样的名字移动并忽视任何来源于信息的标题字段。
一台服务器收到没有任何强制扩展声明来遵从并包含方法名前缀“M-”的强制扩展声明，必须
返回510（无扩展）响应。
扩展名“M-”被此建议保留并不能用于其它的HTTP扩展。
5.1强制请求的实现
一台服务器不能要求实现任何扩展请求，除非它明白并能服从请求中的所有强制扩展声明。
这
一部分定义了一个以某种方式把信息传送给客户端的机制，它能与已存在的HTTP应用程序共同实行
并能阻止损坏的服务器发送错误的信息，不理解方法就用200（OK）响应完成扩展请求。
如果任何End-to-End强制扩展声明是在已完成的扩展中，那么服务器就必须在响应中包含一个
Ext响应标题字段。
为避免一个Ext响应标题字段不注意地在一个HTTP/1.1高速缓冲寄存器中缓冲，
响应必须包含无缓冲，缓冲控制指示。
如果响应以其他方式进行缓冲，无缓冲，缓冲控制指示应该
被限制在Ext标题字段内起作用：
HTTP/1.1200OK
Ext:
Cache-Control:
no-cache="
Ext"
...
如果强制请求已经被一个HTTP/1.0中介代理传送，接着这就被直接地在请求线指示或是通过标
题字段的HTTP/1.1地使用。
如果真是这样，服务器必须包括一个等于或早于数据标题字段值的失效
标题字段（见第9节，缓冲考虑的讨论）：
Date:
Sun,25Oct199808:
12:
31GMT
Expires:
max-age=3600
如果任何的Hop-by-Hop强制扩展声明在已实现的扩展中，那么服务器必须在响应中包含一个
C-Ext响应标题字段。
C-Ext响应标题字段必须被连接标题字段所保护（见[5]，第14.10节）。
C-Ext:
C-Ext
需要注意的是，Ext和C-Ext标题字段并不互相排斥；
它们能在完成强制请求时，包括Hop-by-Hop
和End-to-End强制扩展声明，同时在一个响应中出现。
6.强制HTTP响应
一台服务器在HTTP响应中并不包含强制扩展声明，除非它是给一个强制HTTP请求做的应答，
而且这个请求的定义允许强制响应或是服务器更先进足以使接受者操纵扩展响应。
一台服务器可能
在任何HTTP响应中包含可选择的扩展声明（见第4节）。
如果客户是包含强制扩展声明的强制HTTP响应的终端接收者，客户或者不明白或者不想用这扩
展声明，那么它应该放弃完全响应，把它视为一个500（Internet服务器错误）响应。
7.510不扩展
访问资源的机制并不在请求中。
服务器应该返回所有发出扩展请求的客户的必要信息。
扩展怎
样详细地告知用户并不在这篇规范的讨论范围。
如果510响应包含了在初始请求中不存在的扩展信息，那么如果有理由相信它能根据510响应
中提供的信息通过修改请求来实现扩展机制，客户端就有可能重复地发出请求。
相反的，客户端可
能对用户呈现出任何包含在510请求中的实体，这个实体可能与诊断信息相关。
8.发布扩展
当扩展协议的详细说明应该在扩展标识符的地址发布时，这篇规范就不需要它。
唯一绝对的需
求是扩展标识符应该是全球独一无二的标识符，而且这个独特的名字被用于独特的语义。
同样的，不需要应用程序来尝试包含在扩展声明中的扩展标识符的解析工作。
唯一绝对的需求
是应用程序不需与它不能识别的扩展（不管它是否尝试解决扩展标识符）保持一致。
这篇文档没有
为多久或多频繁一个应用程序可能尝试解析扩展标识符提供任何方针。
扩展标识符与规范的结合可能由发布规范来完成，这篇规范就涉及到扩展标识符。
强类推荐扩展标识符的完整性和持续性应该在扩展的寿命中被毫无疑问的维护和保持。
应该注
意不发布涉及到相同名字的有冲突的规范。
即使当扩展规范在URI地址是可利用的，还必须小心在
这个URI地址，扩展规范不随时间而发生变化。
一个代理可能把标识符与老的语义结合，其它的可
能把它与心的语义结合。
扩展标识符的能在如下排列的不同表现中可利用：
o由扩展语义定义的易读规格（见[7]中的例子），
o由扩展定义的实现语义的可下载的代码，
o由扩展提供的正式接口描述，
o由扩展语义定义的机器可读规格。
例如，一个执行规范的软件组件可能向人们易读的规格一样（通过商定的内容所区别）寄居在
相同的地址。
人们易读的表现法适用于证明扩展和鼓励使用，在软件的组件允许客户端及服务器的
动态扩展。
9.缓冲考虑
使用由这篇文档定义的句法结构的扩展的用途可能在HTTP响应信息的可缓冲性，除了在第5.1
节所描述的，有附加的含义。
扩展信息的创始人应该能够从扩展机制中决定是否扩展的存在与响应信息的缓存约束相抵触。
如果一个扩展在响应的可缓冲性方面不需要很紧的约束，创造者必须包含适当的有缓冲标题字段的
组合（缓冲控制，变更，期限），与有扩展语义的组合的必须级别所对应。
10.安全考虑
动态的扩展便利装置，如简介中描述的一样，包括了某一方公司（执行的提供者）所写的软件
必须在另一个权威机构（生产主机软件的公司）下执行。
这就使得主机公司对各式各样的由提供者
进行攻击的木马开放，或是伪装在供应商名下执行的恶意的第三方公司。
可以参考，RFC2046[4]中
的例子，第4.5.2节关于这种风险的讨论。
11.参考书目
[1]Crocker,D.,“ARPAInternet文本信息的格式标准”，STD11,RFC822,1982年8月。
[2]Berners-Lee,T.,Fielding,R.与H.Frystyk,“超文本传输协议——HTTP/1.0”，
RFC1945,1996年5月。
[3]Bradner,S.,“Internet标准方法——修订3”，BCP9,RFC2026,1996年10月。
[4]Freed,N.与N.Borenstein,“多用途的Internet邮件扩展（MIME）第二部分：
媒介类
型”，RFC2046，1996年11月。
[5]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.与T.Berners-Lee,“超文本传输协议——HTTP/1.1”，RFC2068，1997年三月。
[6]Bradner,S.,“关键字用于使用在RFCs指出要求水平
”，BCP14,RFC2119,1997年3月。
[7]Masinter,L.,“超文本CoffeePot控制协议（HTCPCP/1.0）
”，RFC2324，11998年4月。
[8]Berners-Lee,T.,Fielding,R.与L.Masinter,“统一资源标识符URI）:
普通语法”，RFC2396，1998年8月。
[9]Nielsen,H.,Connolly,D.与R.Khare,“PEP–HTTP扩展机制”，正在发展中。
12.感谢
RoyFielding,RohitKhare,YaronY.Goland,和KoenHoltman，特别感谢他们在这篇规范
书中所有段落注释中所作出的努力。
同样感谢JoshCohen,RossPatterson,JimGettys,LarryMasinter，和所有与PEP[9]有关的人。
所有环球网协会（W3C）职员的贡献是HTTP活跃性的一部分（见“http:
//www.w3.org/Protocols/Activity”）。
13.作者地址
HenrikFrystykNielsen
微软公司
1MicrosoftWay
Redmond,WA98052,USA
EMail:
frystyk@
升级会员 