📄 rfc2774.txt
字号:
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
<!doctype html ...
一个遵守这篇规范的终端接收者受到强制请求必须按如下列出的步骤处理请求：
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.1 200 OK
Ext:
Cache-Control: no-cache="Ext"
...
如果强制请求已经被一个HTTP/1.0中介代理传送，接着这就被直接地在请求线指示或是通过标
题字段的HTTP/1.1地使用。如果真是这样，服务器必须包括一个等于或早于数据标题字段值的失效
标题字段（见第9节，缓冲考虑的讨论）：
HTTP/1.1 200 OK
Date: Sun, 25 Oct 1998 08:12:31 GMT
Expires: Sun, 25 Oct 1998 08:12:31 GMT
Ext:
Cache-Control: no-cache="Ext", max-age=3600
...
如果任何的Hop-by-Hop强制扩展声明在已实现的扩展中，那么服务器必须在响应中包含一个
C-Ext响应标题字段。C-Ext响应标题字段必须被连接标题字段所保护（见[5]，第14.10节）。
HTTP/1.1 200 OK
C-Ext:
Connection: 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.,“ARPA Internet文本信息的格式标准”，STD11,RFC 822,1982年8月。
[2] Berners-Lee, T.,Fielding, R. 与 H. Frystyk,“超文本传输协议——HTTP/1.0”，
RFC 1945,1996年5月。
[3] Bradner, S., “Internet 标准方法——修订3”，BCP 9,RFC 2026,1996年10月。
[4] Freed, N. 与 N. Borenstein,“多用途的Internet邮件扩展（MIME）第二部分：媒介类
型”，RFC 2046，1996年11月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. 与 T.Berners-Lee,“超文本传输
协议——HTTP/1.1”，RFC 2068，1997年三月。
[6] Bradner, S., “关键字用于使用在RFCs指出要求水平 ”，BCP 14,RFC 2119,1997年3
月。
[7] Masinter, L.,“超文本Coffee Pot控制协议 (HTCPCP/1.0) ”，RFC 2324，1 1998年4
月。
[8] Berners-Lee, T., Fielding, R. 与 L. Masinter,“统一资源标识符URI): 普通语法”，
RFC 2396，1998年8月。
[9] Nielsen, H., Connolly, D. 与 R. Khare,“PEP – HTTP扩展机制”，正在发展中。
12. 感谢
Roy Fielding, Rohit Khare, Yaron Y. Goland, 和 Koen Holtman，特别感谢他们在这篇规范
书中所有段落注释中所作出的努力。同样感谢Josh Cohen, Ross Patterson, Jim Gettys, Larry
Masinter，和所有与PEP [9]有关的人。
所有环球网协会（W3C）职员的贡献是HTTP活跃性的一部分(见
“http://www.w3.org/Protocols/Activity”）。
13. 作者地址
Henrik Frystyk Nielsen
微软公司
1 Microsoft Way
Redmond, WA 98052, USA
EMail: frystyk@microsoft.com
Paul J. Leach
微软公司
1 Microsoft Way
Redmond, WA 98052, USA
EMail: paulle@microsoft.com
Scott Lawrence
Agranat Systems, Inc.
5 Clocktower Place, Suite 400
Maynard, MA 01754, USA
EMail: lawrence@agranat.com
14. 交互式协议概要
下面的表格总结了适应或不适应HTTP代理和源服务器的强制建议的实力与范围标准的成果。这
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -