Network Working Group D. Kristol
Request for Comments: 2109 Bell Laboratories, Lucent Technologies
Category: Standards Track L. Montulli
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.
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
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
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
* both host names are FQDN strings and their host name strings match
* 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
4. The session is implicit in the exchange of state information.
Kristol & Montulli Standards Track [Page 2]RFC 2109 HTTP State Management Mechanism February 19974. 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