rfc2964.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页

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


                      Use of HTTP State Management

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

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

IESG Note

   The IESG notes that this mechanism makes use of the .local top-level
   domain (TLD) internally when handling host names that don't contain
   any dots, and that this mechanism might not work in the expected way
   should an actual .local TLD ever be registered.

Abstract

   The mechanisms described in "HTTP State Management Mechanism" (RFC-
   2965), and its predecessor (RFC-2109), can be used for many different
   purposes.  However, some current and potential uses of the protocol
   are controversial because they have significant user privacy and
   security implications.  This memo identifies specific uses of
   Hypertext Transfer Protocol (HTTP) State Management protocol which
   are either (a) not recommended by the IETF, or (b) believed to be
   harmful, and discouraged.  This memo also details additional privacy
   considerations which are not covered by the HTTP State Management
   protocol specification.

1.  Introduction

   The HTTP State Management mechanism is both useful and controversial.
   It is useful because numerous applications of HTTP benefit from the
   ability to save state between HTTP transactions, without encoding
   such state in URLs.  It is controversial because the mechanism has
   been used to accomplish things for which it was not designed and is
   not well-suited.  Some of these uses have attracted a great deal of
   public criticism because they threaten to violate the privacy of web



Moore & Freed            Best Current Practice                  [Page 1]

RFC 2964              Use of HTTP State Management          October 2000


   users, specifically by leaking potentially sensitive information to
   third parties such as the Web sites a user has visited.  There are
   also other uses of HTTP State Management which are inappropriate even
   though they do not threaten user privacy.

   This memo therefore identifies uses of the HTTP State Management
   protocol specified in RFC-2965 which are not recommended by the IETF,
   or which are believed to be harmful and are therefore discouraged.

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   appear capitalized, they are being used to indicate particular
   requirements of this specification.  A discussion of the meanings of
   the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the
   terms "MUST NOT" and "SHOULD NOT" are logical extensions of this
   usage.

2.  Uses of HTTP State Management

   The purpose of HTTP State Management is to allow an HTTP-based
   service to create stateful "sessions" which persist across multiple
   HTTP transactions.  A single session may involve transactions with
   multiple server hosts.  Multiple client hosts may also be involved in
   a single session when the session data for a particular user is
   shared between client hosts (e.g., via a networked file system).  In
   other words, the "session" retains state between a "user" and a
   "service", not between particular hosts.

   It's important to realize that similar capabilities may also be
   achieved using the "bare" HTTP protocol, and/or dynamically-generated
   HTML, without the State Management extensions.  For example, state
   information can be transmitted from the service to the user by
   embedding a session identifier in one or more URLs which appear in
   HTTP redirects, or dynamically generated HTML; and the state
   information may be returned from the user to the service when such
   URLs appear in a GET or POST request.  HTML forms can also be used to
   pass state information from the service to the user and back, without
   the user being aware of this happening.

   However, the HTTP State Management facility does provide an increase
   in functionality over ordinary HTTP and HTML.  In practice, this
   additional functionality includes:

   (1)   The ability to exchange URLs between users, of resources
         accessed during stateful sessions, without leaking the state
         information associated with those sessions.  (e.g. "Here's the
         URL for the FooCorp web catalog entry for those sandals that
         you wanted.")



Moore & Freed            Best Current Practice                  [Page 2]

RFC 2964              Use of HTTP State Management          October 2000


   (2)   The ability to maintain session state without "cache-busting".
         That is, separating the session state from the URL allows a web
         cache to maintain only a single copy of the named resource.  If
         the state is maintained in session-specific URLs, the cache
         would likely have to maintain several identical copies of the
         resource.

   (3)   The ability to implement sessions with minimal server
         configuration and minimal protocol overhead, as compared to
         other techniques of maintaining session state.

   (4)   The ability to associate the user with session state whenever a
         user accesses the service, regardless of whether the user
         enters through a particular "home page" or "portal".

   (5)   The ability to save session information in stable storage, so
         that a "session" can be maintained across client invocations,
         system reboots, and client or system crashes.

2.1.  Recommended Uses

   Use of HTTP State Management is appropriate whenever it is desirable
   to maintain state between a user and a service across multiple HTTP
   transactions, provided that:

   (1)   the user is aware that session state is being maintained and
         consents to it,

   (2)   the user has the ability to delete the state associated with
         such a session at any time,

   (3)   the information obtained through the ability to track the
         user's usage of the service is not disclosed to other parties
         without the user's explicit consent, and

   (4)   session information itself cannot contain sensitive information
         and cannot be used to obtain sensitive information that is not
         otherwise available to an eavesdropper.

   This last point is important because cookies are usually sent in the
   clear and hence are readily available to eavesdroppers.

   An example of such a recommended use would be a "shopping cart",
   where the existence of the shopping cart is explicitly made known to
   the user, the user can explicitly "empty" his or her shopping cart
   (either by requesting that it be emptied or by purchasing those





Moore & Freed            Best Current Practice                  [Page 3]

RFC 2964              Use of HTTP State Management          October 2000


   items) and thus cause the shared state to be discarded, and the
   service asserts that it will not disclose the user's shopping or
   browsing habits to third parties without the user's consent.

   Note that the HTTP State Management protocol effectively allows a
   service provider to refuse to provide a service, or provide a reduced
   level of service, if the user or a user's client fails to honor a
   request to maintain session state.  Absent legal prohibition to the
   contrary, the server MAY refuse to provide the service, or provide a
   reduced level of service, under these conditions.  As a purely
   practical consideration, services designed to utilize HTTP State
   Management may be unable to function properly if the client does not
   provide it.  Such servers SHOULD gracefully handle such conditions
   and explain to the user why the full level of service is not
   available.

2.2.  Problematic Uses

   The following uses of HTTP State Management are deemed inappropriate
   and contrary to this specification:

2.2.1.  Leakage of Information to Third Parties

   HTTP State Management MUST NOT be used to leak information about the
   user or the user's browsing habits to other parties besides the user
   or service, without the user's explicit consent.  Such usage is
   prohibited even if the user's name or other externally-assigned
   identifier are not exposed to other parties, because the state
   management mechanism itself provides an identifier which can be used
   to compile information about the user.

   Because such practices encourage users to defeat HTTP State
   Management mechanisms, they tend to reduce the effectiveness of HTTP
   State Management, and are therefore considered detrimental to the
   operation of the web.

2.2.2.  Use as an Authentication Mechanism

   It is generally inappropriate to use the HTTP State Management
   protocol as an authentication mechanism.  HTTP State Management is
   not designed with such use in mind, and safeguards for protection of
   authentication credentials are lacking in both the protocol
   specification and in widely deployed HTTP clients and servers.  Most
   HTTP sessions are not encrypted and "cookies" may therefore be
   exposed to passive eavesdroppers.  Furthermore, HTTP clients and
   servers typically store "cookies" in cleartext with little or no
   protection against exposure.  HTTP State Management therefore SHOULD




Moore & Freed            Best Current Practice                  [Page 4]