组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：boniter（boniter@etang.com） 译文发布时间：2001-11-7 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保 留本文档的翻译及版权信息。 Network Working Group H.Nielsen RFC: 2774 P. Leach Category: Experimental Microsoft S. Lawrence Agranat Systems 2000年2月 HTTP扩展框架 （RFC2774——An HTTP Extension Framework） 本备忘录的状态 本备忘录为Internet定义了一个实验的协议。它本不属于任何已详细说明的Internet标准。 仍需进一步的探讨和改进。此备忘录的发行是无约束的。 版权声明 Copyright (C) The Internet Society (2000). All Rights Reserved. IESG 注释 这篇文章最初是作为推荐标准而提出的。但是，由于最终确认时的综合考虑以及在HTTP工 作组中，它是作为一篇实验性文档而提出的。这并不是说这篇文章有任何技术上的缺陷；更 恰当地说，这更全面地涉及到是否这篇文章确实在HTTP的变革方面提出了与社会上大多数人 不同的新的见解。再此决定之前需要更多的研究和讨论。 同样需要注意的是当HTTP被用作其它协议的基础时，它可能有必要和应该适当地用到一些 其它扩展的机制，增加或代替一些东西，在这里会详细说明。因此这篇文章不应该被看作是 扩展HTTP的蓝图，但它所详细说明的机制可能在具体情况中非常有用。 概要 应用程序的广泛延伸已经提出了各式各样的HTTP协议的扩展。当前的协作横跨了一个巨 大的范围，包括分布式创造，协作，打印，和细微的程序响应机制。这些HTTP的扩展并不是并 列同等的，因为还没有任何的框架标准来定义它们，因此它们便相互独立起来。这篇文章描述 了一个一般性的HTTP扩展机制，试图缓和这些独立的协议和公众规范之间的矛盾，并让那些使 用HTTP协议的客户端，服务器和代理兼容这些扩展的应用程序。这个提议用全球化独一无二的 标识符连接了每一个扩充，而且用HTTP的标题字段来显示这些扩展的标识符，并讲述了与他们 有关的通讯延伸的信息。 目录 1. 序论 3 2. 协定表记法 3 3. 扩展申明 3 3.1 标题字段前缀 4 4. 扩展标题字段 5 4.1 End-to-End 扩展 5 4.2 Hop-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.1 Proxy 的源服务器用户代理 11 15.3 通过 HTTP/1.0 Proxy 的源服务器用户代理 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. 协定表记法 这篇说明书使用了与 RFC 2068 [5] 相同的表记法惯例和基本分析构架。特别是BNF的结构记法， 例如文章中的"token", "quoted-string", "Request-Line", "field-name", 和 "absoluteURI"，与 RFC 2068 [5] 所解释的一样。 文档中的关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",和"OPTIONAL"与 RFC 2119 [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节描述的方法被定义。 扩展声明的例子是： “http://www.company.com/extension”；ns=11 “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, and C-Opt。（见第4.1节与第4.2节；同样在附录14中，有一张源服务器 与代理的交互作用表。） 这标题字段是普通的标题字段，就像扩展实际应用于HTTP信息中所描述的一样。如果适当的话， 可选择的声明也许能被应用于任何的HTTP信息（见第5节，怎样将强制扩展声明应用于请求中和第6 节，在响应中怎样应用它们）。 4.1 End-to-End 扩展 End-to-End声明必须被传送带扩展的最终接受者。全面的标题字段Man和Opt是End-to-End标题 字段并被如下定义： 强制 =“Man”“：”1#ext-decl 可选择 =“Opt”“：”1#ext-decl 例如 HTTP/1.1 200 OK Content-Length: 421 Opt: "http://www.digest.org/Digest"; ns=15 15-digest: "snfksjgor2tsajkt52" …… 一个End-to-End强制扩展声明的最终接受者必须运用扩展声明，像第5节和第6节所描述的一样。 4.2 Hop-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" ":" 1#ext-decl 例如 M-GET / HTTP/1.1 Host: some.host C-Man: "http://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-resource HTTP/1.1 Man: "http://www.copyright.org/rights-management"; ns=16 16-copyright: http://www.copyright.org/COPYRIGHT.html 16-contributions: http://www.copyright.org/PATCHES.html Host: www.w3.org Content-Length: 1203 Content-Type: text/html