datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

HTTP State Management Mechanism
RFC 2109

Document type: RFC - Historic (February 1997; No errata)
Obsoleted by RFC 2965
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2109 (Historic)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                         D. Kristol
Request for Comments: 2109        Bell Laboratories, Lucent Technologies
Category: Standards Track                                    L. Montulli
                                                 Netscape Communications
                                                           February 1997

                    HTTP State Management Mechanism

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

1.  ABSTRACT

   This document specifies a way to create a stateful session with HTTP
   requests and responses.  It describes two new headers, Cookie and
   Set-Cookie, which carry state information between participating
   origin servers and user agents.  The method described here differs
   from Netscape's Cookie proposal, but it can interoperate with
   HTTP/1.0 user agents that use Netscape's method.  (See the HISTORICAL
   section.)

2.  TERMINOLOGY

   The terms user agent, client, server, proxy, and origin server have
   the same meaning as in the HTTP/1.0 specification.

   Fully-qualified host name (FQHN) means either the fully-qualified
   domain name (FQDN) of a host (i.e., a completely specified domain
   name ending in a top-level domain such as .com or .uk), or the
   numeric Internet Protocol (IP) address of a host.  The fully
   qualified domain name is preferred; use of numeric IP addresses is
   strongly discouraged.

   The terms request-host and request-URI refer to the values the client
   would send to the server as, respectively, the host (but not port)
   and abs_path portions of the absoluteURI (http_URL) of the HTTP
   request line.  Note that request-host must be a FQHN.

Kristol & Montulli          Standards Track                     [Page 1]
RFC 2109            HTTP State Management Mechanism        February 1997

   Hosts names can be specified either as an IP address or a FQHN
   string.  Sometimes we compare one host name with another.  Host A's
   name domain-matches host B's if

   * both host names are IP addresses and their host name strings match
     exactly; or

   * both host names are FQDN strings and their host name strings match
     exactly; or

   * A is a FQDN string and has the form NB, where N is a non-empty name
     string, B has the form .B', and B' is a FQDN string.  (So, x.y.com
     domain-matches .y.com but not y.com.)

   Note that domain-match is not a commutative operation: a.b.c.com
   domain-matches .c.com, but not the reverse.

   Because it was used in Netscape's original implementation of state
   management, we will use the term cookie to refer to the state
   information that passes between an origin server and user agent, and
   that gets stored by the user agent.

3.  STATE AND SESSIONS

   This document describes a way to create stateful sessions with HTTP
   requests and responses.  Currently, HTTP servers respond to each
   client request without relating that request to previous or
   subsequent requests; the technique allows clients and servers that
   wish to exchange state information to place HTTP requests and
   responses within a larger context, which we term a "session".  This
   context might be used to create, for example, a "shopping cart", in
   which user selections can be aggregated before purchase, or a
   magazine browsing system, in which a user's previous reading affects
   which offerings are presented.

   There are, of course, many different potential contexts and thus many
   different potential types of session.  The designers' paradigm for
   sessions created by the exchange of cookies has these key attributes:

      1.  Each session has a beginning and an end.

      2.  Each session is relatively short-lived.

      3.  Either the user agent or the origin server may terminate a
          session.

      4.  The session is implicit in the exchange of state information.

Kristol & Montulli          Standards Track                     [Page 2]
RFC 2109            HTTP State Management Mechanism        February 1997

4.  OUTLINE

   We outline here a way for an origin server to send state information
   to the user agent, and for the user agent to return the state
   information to the origin server.  The goal is to have a minimal
   impact on HTTP and user agents.  Only origin servers that need to
   maintain sessions would suffer any significant impact, and that

[include full document text]