rfc2817.txt

RFC文档

	一个源服务器接收到对自己的连接请求可以用2xx状态码响应，表示连接已经建立。
	如果在任何时候任何一方断连，任何来自于该端的数据将传送到另一方，之后另一方
的连接也被代理终止。若有到先断连一端的数据未传送，这些数据都将被丢弃。


6 使用4xx（客户错误）状态码的原理
	可靠的，共同协商的升级特性需要一个明确的失败信号。426升级请求状态码允许服务
器明确地声明必须提供一个给定资源想要的协议扩展。
	起先看起来，响应应具有重定向的某种形式(3xx码)，类似到一个https:URI的旧式重
定向。但不理解升级机制的用户代理使得不能这样做。
	设想某个3xx代码已被赋与“需要升级”的含义；一个不能识别它的用户代理将把它
当做300。它可能在响应中寻找一个“Location”头并试图重复对头部域中的URL的请求。
由于它不知道升级以合并TLS层，它最终在新的URL上会再次失败。

7 .IANA的考虑
	如BCP 26[10]中描述的，IANA将为二种名字空间登记：
	HTTP状态码
	HTTP升级记号

7.1 HTTP状态码登记
	HTTP状态码的登记定义了在HTTP响应的状态行中的状态码记号。这个名字空间的初始
值是由这些定义的：
1.	HTTP/1.1标准草案
2.	Web分布式创作及版本[4][定义420-424]
3.	WebDAV高级集合[5]（正在制订）[定义425]
4.	第6节[定义426]
要加入到该名字空间的值应该以标准记录文档格式提交IETF应用组。任何这种文档应该通
过HTTP/1.1[1]草案的状态词“过时”或“更新”使得可追踪来源。

7.2 HTTP升级记号登记

	HTTP升级记号登记为产品记号定义了名字空间，该名字空间用于在升级HTTP头部域中
分辩协议。每一个登记的记号应该同一个或一组规范相联系并有相联系的信息。
	HTTP/1.1[1]标准草案定义了这些遵从产品生产的记号：
	产品（product）= 记号["/" 产品版本]
	产品版本 = 记号

	如BCP 26[10]中描述的，登记应该基于先来先服务的原则。这些定义不需要是IETF文
档或是IESG关注的课题，但应该遵守下列原则：
1.	一个记号一旦登记，就永远是登记了的。
2.	登记必须指定一个负责登记的团体。
3.	登记必须指定一个联系办法。
4.	登记必须指定记号需要的文档。
5.	负责的团体可以随时改变登记项。IANA将记录下所有这种改变，并使它对需要的人可
用。
6.	对一个“产品”记号第一次登记负责的团体在他们能够登记前必须同意同“产品”记号
一起的“版本”记号的晚些时候的登记。
7.	若确实需要，IESG可以重新指定一个记号的负责团体。通常这只是在负责团体无法联
系到时才会这样。

	本规范定义协议记号“TLS/1.0”作为TLS协议[6]定义的协议的标识符号。
	并不要求升级记号的定义是公众可用的，但登记的联系信息应该是。

8.安全考虑
	潜在的中间人攻击（删除升级头部）和目前http/https混用一样：
. 移去升级头与重写网页来将https://links改变为http://links类似。
. 只有在服务器首先通过安全或不安全的通道公开这类信息才会造成这种风险。
. 若客户知道服务器可处理TLS，它就会坚持发送不带选项如OPTIONS的升级请求。
. 最后如https:定义警告的，“用户应该仔细检查服务器提供的证书以确定是否符合他
们的期望。

	此外，对于未明确激活TLS的客户，服务器可在响应中使用除了101或426的升级头来
通告TLS能力。既然TLS能力应该作为服务器的特性而不是就在手边的资源，它应一次发送
就足够，让客户知道这个事实以在需要时使用。

8.1 https:URI方案含义

	本备忘录没有影响‘https’的含义，广泛采用的超文本内容可以使用‘http’来区分
安全和不安全的资源。
连接时安全特性的选择留给客户和服务器。这允许每一方用任何可用的信息作出决
定。例如，用户代理可以依靠有关网络安全方面的用户设置，如“对不在我的本地网络上
的所有POST操作都要求使用TLS”，或服务器可应用如‘本页面的FORM的提交和处理必须
用TLS’等资源存取规则。

8.2 CONNECT的安全考虑

	一个类属的TCP通道是充满安全风险的。首先，这种授权应该被限制在一小部分端
口。这里定义的升级机制只是在80端口的隧道上需要。第二，既然隧道数据对代理不透
明，对其它众所周知和保留端口的隧道有额外的风险。例如，假定一个HTTP客户连接到25
端口，他可以通过SMTP传播垃圾邮件。

参考
   [1]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic
        Syntax", RFC 2396, August 1998.

   [3]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [4]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
        "Web Distributed Authoring and Versioning", RFC 2518, February
        1999.

   [5]  Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
        Protocol",  Work In Progress.

   [6]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
        1999.

   [7]  Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
        1999.

   [8]  Luotonen, A., "Tunneling TCP based protocols through Web proxy
        servers",  Work In Progress.  (Also available in: Luotonen, Ari.
        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)

   [9]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
        1999.

   [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

作者地址
   Rohit Khare
   4K Associates / UC Irvine
   3207 Palo Verde
   Irvine, CA  92612
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.4K-associates.com/

   Scott Lawrence
   Agranat Systems, Inc.
   5 Clocktower Place
   Suite 400
   Maynard, MA  01754
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.agranat.com/

附录A　致谢
   The CONNECT method was originally described in a Work in Progress
   titled, "Tunneling TCP based protocols through Web proxy servers",
   [8] by Ari Luotonen of Netscape Communications Corporation.  It was
   widely implemented by HTTP proxies, but was never made a part of any
   IETF Standards Track document. The method name CONNECT was reserved,
   but not defined in [1].

   The definition provided here is derived directly from that earlier
   memo, with some editorial changes and conformance to the stylistic
   conventions since established in other HTTP specifications.

   Additional Thanks to:

   o  Paul Hoffman for his work on the STARTTLS command extension for
      ESMTP.
   o  Roy Fielding for assistance with the rationale behind Upgrade:
      and its interaction with OPTIONS.
   o  Eric Rescorla for his work on standardizing the existing https:
      practice to compare with.
   o  Marshall Rose, for the xml2rfc document type description and tools
      [9].
   o  Jim Whitehead, for sorting out the current range of available HTTP
      status codes.
   o  Henrik Frystyk Nielsen, whose work on the Mandatory extension
      mechanism pointed out a hop-by-hop Upgrade still requires
      tunneling.
   o  Harald Alvestrand for improvements to the token registration
      rules.

完整版权声明
   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

致谢
   Funding for the RFC Editor function is currently provided by the
   Internet Society.
RFC2817—Upgrading to TLS Within HTTP/1.1               在HTTP/1.1中升级到TLS


1
RFC文档中文翻译计划