Use of HTTP State Management
RFC 2964

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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]