HTTP State Management Mechanism
RFC 2965

Document Type RFC - Historic (October 2000; Errata)
Obsoleted by RFC 6265
Obsoletes RFC 2109
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2965 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         D. Kristol
Request for Comments: 2965        Bell Laboratories, Lucent Technologies
Obsoletes: 2109                                              L. Montulli
Category: Standards Track                             Epinions.com, Inc.
                                                            October 2000

                    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.

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

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

   This document reflects implementation experience with RFC 2109 and
   obsoletes it.

1.  TERMINOLOGY

   The terms user agent, client, server, proxy, origin server, and
   http_URL have the same meaning as in the HTTP/1.1 specification
   [RFC2616].  The terms abs_path and absoluteURI have the same meaning
   as in the URI Syntax specification [RFC2396].

Kristol & Montulli          Standards Track                     [Page 1]
RFC 2965            HTTP State Management Mechanism         October 2000

   Host name (HN) means either the host domain name (HDN) 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 is a HN.

   The term effective host name is related to host name.  If a host name
   contains no dots, the effective host name is that name with the
   string .local appended to it.  Otherwise the effective host name is
   the same as the host name.  Note that all effective host names
   contain at least one dot.

   The term request-port refers to the port portion of the absoluteURI
   (http_URL) of the HTTP request line.  If the absoluteURI has no
   explicit port, the request-port is the HTTP default, 80.  The
   request-port of a cookie is the request-port of the request in which
   a Set-Cookie2 response header was returned to the user agent.

   Host names can be specified either as an IP address or a HDN string.
   Sometimes we compare one host name with another.  (Such comparisons
   SHALL be case-insensitive.)  Host A's name domain-matches host B's if

      *  their host name strings string-compare equal; or

      * A is a HDN string and has the form NB, where N is a non-empty
         name string, B has the form .B', and B' is a HDN 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.

   The reach R of a host name H is defined as follows:

      *  If

         -  H is the host domain name of a host; and,

         -  H has the form A.B; and

         -  A has no embedded (that is, interior) dots; and

         -  B has at least one embedded dot, or B is the string "local".
            then the reach of H is .B.

Kristol & Montulli          Standards Track                     [Page 2]
RFC 2965            HTTP State Management Mechanism         October 2000

      *  Otherwise, the reach of H is H.

   For two strings that represent paths, P1 and P2, P1 path-matches P2
   if P2 is a prefix of P1 (including the case where P1 and P2 string-
   compare equal).  Thus, the string /tec/waldo path-matches /tec.

   Because it was used in Netscape's original implementation of state
   management, we will use the term cookie to refer to the state
Show full document text