rfc2964.txt

RFC规范的翻译稿

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：牛韬（NT  [e-mail]）
译文发布时间：2001-5-11
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                            K. Moore
Request for Comments: 2964                        University of Tennessee
BCP: 44                                                          N. Freed
Category: Best Current Practice                                  Innosoft
                                                             October 2000


超文本传输协议(HTTP)状态管理的应用
(RFC 2964  Use of HTTP State Management)

本备忘录的状态

   本文档描述了Internet社区的最通用的实践（惯例），需要进一步探讨和建议
进行完善。本备忘录的发布没有限制。


版权公告

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

IESG 注解

   The IESG 注解这种机制应用于包含.local 顶级域名 (TLD)在内，在处理主机名称不含任
何点在内的情况下，如果没有注册一个真正的.local顶级域的话，这种机制可能无法动作。

摘要

  这种机制在“HTTP状态管理体制”（RFC-2965）中已经描述了，其原描述文档（RFC-2109），
能用于许多不同的目标。然而，许多当前的和潜在的对于这个协议的应用存在争议，因为它
们有重要的用户隐私和在安全上的牵连。这个备忘录识别了那些既不被IETF所推荐，或被认
为是有害的和不安全的超文本协议（HTTP）在某些细节上的应用。本备忘录也附加了一个HTTP
状态管理协议中未曾包含的考虑安全方面的详细的文档。

1、介绍
   HTTP状态管理机制非常有用，但也存在着很大的争议。它的实用性缘于众多的HTTP应用
程序可以得益于它能保存HTTP传输状态的能力，而不需对这种状态在统一资源定位器（URL）
中进行编码。而对它存在争议是因为它在成完成任务时的不确定性和较差的兼容性。由于这
些应用导致了大量的公众的批评因为他们的存在，导致了网上隐私的保密造成了的威胁。
   用户，确实通过漏洞将一些敏感的信息泄漏给第三方，例如一个用户访问了某个网站。而
通过漏洞，将该用户的信息记录了下来。那儿同时也有其它的HTTP状态管理的用户在，这是
不适当的，即使他们没有对用户隐私的威胁。

在RFC-2965文档中已被详细说明的的HTTP状态管理协议IETF并不推荐使用，本备忘录正是
为此对其应用进行识别，HTTP状态管理协议被认为存在一定的危害性，因此并不被人看好。

本文档偶尔使用一些用黑体字表示的术语，当下面这些术语如"必须", "不必", "应当", "
不会", 和 "可以"以黑体出现时，说明使用它们在说明书中有特定的要求，有关这些术语含
义的讨论，如"必须", "应当", 和 "可以"，请参阅[RFC-1123]；术语"不必" 和 "不会"是在
用法上进行了逻辑的扩展。

2、HTTP状态管理的应用
  HTTP状态管理的目标是基于HTTP的服务建立一个有状态的可以持续穿过多重HTTP来处理
事务的“对话”。一个单独的对话可以包括与多重服务器主机进行事务处理。多个客户在对于
一个特定的用户的对话数据被其它客户共享（例如，通过一个文件系统）时，同样可以被一
个对话所包括。换句话说，对话保留了用户与一个服务之间的状态，面不是两个特定客户端
之间的状态。

  使用“无屏蔽”的HTTP协议也同样以相似的性能完成任务，认识这一点很重要。并且/或
者动态的产生HTML，而没有状态管理的扩展。例如，状态信息能够从服务到用户通过嵌入到
一个或在HTTP的重定向中显现的多个统一资源定位器的对话的标示符中，或动态的产生
HTML；并且状态信息可以从用户返回到这个服务当这URL出现一个GET或POST请求时。HTML
表格也能用于传递从服务到客户的状态信息并返回，而不必要让用户知道发生了什么。

不管怎样，HTTP状态管理工具提供功能的确是比普通的HTTP和HTML增加了更多。在实践中
这些附加的功能包括：

  （1）在两个用户之间互换URL，在有状态的会话中资源的存取，而没有与其它会话关联的
状态信息的泄漏。（例如，“这儿有FooCorp的网络目录入口的URL，而你正想要从这家公司
买拖鞋”）
(2)	不用“缓冲猝发”维持会话状态的能力。那就是，从URL中隔离出会话状态允许一
个页面缓冲来维护唯一的一个已命名的资源的副本。如果此状态在会话细节URL
中维持，缓冲很有可能不得不维持几个同样的拷贝。

(3)与其它的维持会话状态的技术相比，它具有使用最低的服务器配置和最小限度的费用
的优点。

  （4）不管是否用户已经通过一个特定的“主页”或“入口”进入,都可以在用户对服务进
行存取的任何时间联系用户与会话。


   (5)   能够将会话信息保存在一个稳定的存储容器中，因此一个“会话”能够穿过客户的
干扰，以及系统的重新起动和客户端或系统的崩溃。.

2.1.  推荐的应用

   当需要穿过多重HTTP处理事务，此时维持用户与服务之间的状态使用HTTP状态的管理是
很合适的。假如：
（1）	用户知道会话正在维持并且用户对其表示赞成,

（2）	用户可以在任何时间删除与这样一个会话相关联的状态信息，

（3）	通过跟踪用户的使用该服务的方法获取的信息，如果未经用户的直接允许，是不会透
露给其它的人员的。

（4）	会话信息无法自己获取敏感信息并且也不能被用于获取敏感信息，要偷听者无法从中
得到任何可用信息。

（5）	最后一点很重要因为cookies 通常是明文发送的，因此，很容易被偷听者窃取。

 一个推荐的应用的例子就是“购物车”，购物车的存在对于用户来说是非常清楚和明白的，
用户可以明确的“清空”他或她的购物车（或者通过请求来清空或购买货物），因此将导致对
共享状态的放弃，这项服务不会不经用户允许，而向第三方公开用户的购物习惯和浏览习惯。
  注意HTTP状态管理协议有效的允许一个服务提供者拒供应服务，或提供一个限制级别的服
务，如果说某个用户或一个用户的客户的维持会话状态的请求无法兑现。相反的，缺少合法
的禁止，服务也许会拒绝提供服务，或者提供一个限制级的服务，在这些条件下。从一个纯
实践的角度考虑，如果说客户端不提供此项服务，那么利用HTTP状态管理设计的服务也许无
法完全的运作。这样的服务器应当能够轻松的处理这种情形并向用户解释为什么无法享用全
部的服务。
  

2.2.  存在问题的应用

   下面有关HTTP状态管理的应用被认为是不适当的,从反面进行了阐述：

2.2.1.  向第三方泄漏的信息

   不经用户的正式同意，HTTP 状态管理一定不要应用于泄漏用户或有关用户浏览习惯的信
息给第三方，除了该用户和服务外。
这种用法是禁止的，即使是把用户的名字或其它的可对其进行标识的标识符泄漏给第三方，
因为此状态管理机制自己提供了一个可用于编译有关用户信息的标识符。

   因为这些实际情况使得HTTP状态管理机制倍受人们的指责，他们倾向于限制HTTP状态管
理的效果，因此它被认为对于网络的操作是有害的。

2.2.2.  作为鉴定机制使用Use as an Authentication Mechanism

   通常认为HTTP状态管理机制作为鉴定机制使用是不合适的。HTTP状态管理并不是专门为
这种应用而设计的，因此它在鉴定认证的保护上的安全措施是缺乏的，不论是协议的说明书
还是对于普遍配置HTTP的客户或服务器。绝大多数HTTP会话是不加密的，因此“cookies"
可能会因此被泄漏给偷听者。此外HTTP客户端和服务器又有这个特点：仅仅经过简单的甚至
是根本没有保护就对"cookies"进行明文存储来防止信息的泄漏。HTTP状态管理因此应当不
用于鉴定机制来保护信息避免其泄漏给未经授权的第三方，即使是HTTP会话是经过加密的。