summaryrefslogtreecommitdiffstats
path: root/tdeioslave/http/kcookiejar/rfc2109
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2013-01-27 01:04:16 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2013-01-27 01:04:16 -0600
commit5159cd2beb2e87806a5b54e9991b7895285c9d3e (patch)
tree9b70e8be47a390f8f4d56ead812ab0c9dad88709 /tdeioslave/http/kcookiejar/rfc2109
parentc17cb900dcf52b8bd6dc300d4f103392900ec2b4 (diff)
downloadtdelibs-5159cd2beb2e87806a5b54e9991b7895285c9d3e.tar.gz
tdelibs-5159cd2beb2e87806a5b54e9991b7895285c9d3e.zip
Rename a number of libraries and executables to avoid conflicts with KDE4
Diffstat (limited to 'tdeioslave/http/kcookiejar/rfc2109')
-rw-r--r--tdeioslave/http/kcookiejar/rfc21091179
1 files changed, 1179 insertions, 0 deletions
diff --git a/tdeioslave/http/kcookiejar/rfc2109 b/tdeioslave/http/kcookiejar/rfc2109
new file mode 100644
index 000000000..432fdcc6e
--- /dev/null
+++ b/tdeioslave/http/kcookiejar/rfc2109
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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
+ impact can largely be confined to Common Gateway Interface (CGI)
+ programs, unless the server provides more sophisticated state
+ management support. (See Implementation Considerations, below.)
+
+4.1 Syntax: General
+
+ The two state management headers, Set-Cookie and Cookie, have common
+ syntactic properties involving attribute-value pairs. The following
+ grammar uses the notation, and tokens DIGIT (decimal digits) and
+ token (informally, a sequence of non-special, non-white space
+ characters) from the HTTP/1.1 specification [RFC 2068] to describe
+ their syntax.
+
+ av-pairs = av-pair *(";" av-pair)
+ av-pair = attr ["=" value] ; optional value
+ attr = token
+ value = word
+ word = token | quoted-string
+
+ Attributes (names) (attr) are case-insensitive. White space is
+ permitted between tokens. Note that while the above syntax
+ description shows value as optional, most attrs require them.
+
+ NOTE: The syntax above allows whitespace between the attribute and
+ the = sign.
+
+4.2 Origin Server Role
+
+4.2.1 General
+
+ The origin server initiates a session, if it so desires. (Note that
+ "session" here does not refer to a persistent network connection but
+ to a logical session created from HTTP requests and responses. The
+ presence or absence of a persistent connection should have no effect
+ on the use of cookie-derived sessions). To initiate a session, the
+ origin server returns an extra response header to the client, Set-
+ Cookie. (The details follow later.)
+
+ A user agent returns a Cookie request header (see below) to the
+ origin server if it chooses to continue a session. The origin server
+ may ignore it or use it to determine the current state of the
+
+
+
+Kristol & Montulli Standards Track [Page 3]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ session. It may send back to the client a Set-Cookie response header
+ with the same or different information, or it may send no Set-Cookie
+ header at all. The origin server effectively ends a session by
+ sending the client a Set-Cookie header with Max-Age=0.
+
+ Servers may return a Set-Cookie response headers with any response.
+ User agents should send Cookie request headers, subject to other
+ rules detailed below, with every request.
+
+ An origin server may include multiple Set-Cookie headers in a
+ response. Note that an intervening gateway could fold multiple such
+ headers into a single header.
+
+4.2.2 Set-Cookie Syntax
+
+ The syntax for the Set-Cookie response header is
+
+ set-cookie = "Set-Cookie:" cookies
+ cookies = 1#cookie
+ cookie = NAME "=" VALUE *(";" cookie-av)
+ NAME = attr
+ VALUE = value
+ cookie-av = "Comment" "=" value
+ | "Domain" "=" value
+ | "Max-Age" "=" value
+ | "Path" "=" value
+ | "Secure"
+ | "Version" "=" 1*DIGIT
+
+ Informally, the Set-Cookie response header comprises the token Set-
+ Cookie:, followed by a comma-separated list of one or more cookies.
+ Each cookie begins with a NAME=VALUE pair, followed by zero or more
+ semi-colon-separated attribute-value pairs. The syntax for
+ attribute-value pairs was shown earlier. The specific attributes and
+ the semantics of their values follows. The NAME=VALUE attribute-
+ value pair must come first in each cookie. The others, if present,
+ can occur in any order. If an attribute appears more than once in a
+ cookie, the behavior is undefined.
+
+ NAME=VALUE
+ Required. The name of the state information ("cookie") is NAME,
+ and its value is VALUE. NAMEs that begin with $ are reserved for
+ other uses and must not be used by applications.
+
+
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 4]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ The VALUE is opaque to the user agent and may be anything the
+ origin server chooses to send, possibly in a server-selected
+ printable ASCII encoding. "Opaque" implies that the content is of
+ interest and relevance only to the origin server. The content
+ may, in fact, be readable by anyone that examines the Set-Cookie
+ header.
+
+ Comment=comment
+ Optional. Because cookies can contain private information about a
+ user, the Cookie attribute allows an origin server to document its
+ intended use of a cookie. The user can inspect the information to
+ decide whether to initiate or continue a session with this cookie.
+
+ Domain=domain
+ Optional. The Domain attribute specifies the domain for which the
+ cookie is valid. An explicitly specified domain must always start
+ with a dot.
+
+ Max-Age=delta-seconds
+ Optional. The Max-Age attribute defines the lifetime of the
+ cookie, in seconds. The delta-seconds value is a decimal non-
+ negative integer. After delta-seconds seconds elapse, the client
+ should discard the cookie. A value of zero means the cookie
+ should be discarded immediately.
+
+ Path=path
+ Optional. The Path attribute specifies the subset of URLs to
+ which this cookie applies.
+
+ Secure
+ Optional. The Secure attribute (with no value) directs the user
+ agent to use only (unspecified) secure means to contact the origin
+ server whenever it sends back this cookie.
+
+ The user agent (possibly under the user's control) may determine
+ what level of security it considers appropriate for "secure"
+ cookies. The Secure attribute should be considered security
+ advice from the server to the user agent, indicating that it is in
+ the session's interest to protect the cookie contents.
+
+ Version=version
+ Required. The Version attribute, a decimal integer, identifies to
+ which version of the state management specification the cookie
+ conforms. For this specification, Version=1 applies.
+
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 5]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+4.2.3 Controlling Caching
+
+ An origin server must be cognizant of the effect of possible caching
+ of both the returned resource and the Set-Cookie header. Caching
+ "public" documents is desirable. For example, if the origin server
+ wants to use a public document such as a "front door" page as a
+ sentinel to indicate the beginning of a session for which a Set-
+ Cookie response header must be generated, the page should be stored
+ in caches "pre-expired" so that the origin server will see further
+ requests. "Private documents", for example those that contain
+ information strictly private to a session, should not be cached in
+ shared caches.
+
+ If the cookie is intended for use by a single user, the Set-cookie
+ header should not be cached. A Set-cookie header that is intended to
+ be shared by multiple users may be cached.
+
+ The origin server should send the following additional HTTP/1.1
+ response headers, depending on circumstances:
+
+ * To suppress caching of the Set-Cookie header: Cache-control: no-
+ cache="set-cookie".
+
+ and one of the following:
+
+ * To suppress caching of a private document in shared caches: Cache-
+ control: private.
+
+ * To allow caching of a document and require that it be validated
+ before returning it to the client: Cache-control: must-revalidate.
+
+ * To allow caching of a document, but to require that proxy caches
+ (not user agent caches) validate it before returning it to the
+ client: Cache-control: proxy-revalidate.
+
+ * To allow caching of a document and request that it be validated
+ before returning it to the client (by "pre-expiring" it):
+ Cache-control: max-age=0. Not all caches will revalidate the
+ document in every case.
+
+ HTTP/1.1 servers must send Expires: old-date (where old-date is a
+ date long in the past) on responses containing Set-Cookie response
+ headers unless they know for certain (by out of band means) that
+ there are no downsteam HTTP/1.0 proxies. HTTP/1.1 servers may send
+ other Cache-Control directives that permit caching by HTTP/1.1
+ proxies in addition to the Expires: old-date directive; the Cache-
+ Control directive will override the Expires: old-date for HTTP/1.1
+ proxies.
+
+
+
+Kristol & Montulli Standards Track [Page 6]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+4.3 User Agent Role
+
+4.3.1 Interpreting Set-Cookie
+
+ The user agent keeps separate track of state information that arrives
+ via Set-Cookie response headers from each origin server (as
+ distinguished by name or IP address and port). The user agent
+ applies these defaults for optional attributes that are missing:
+
+ VersionDefaults to "old cookie" behavior as originally specified by
+ Netscape. See the HISTORICAL section.
+
+ Domain Defaults to the request-host. (Note that there is no dot at
+ the beginning of request-host.)
+
+ Max-AgeThe default behavior is to discard the cookie when the user
+ agent exits.
+
+ Path Defaults to the path of the request URL that generated the
+ Set-Cookie response, up to, but not including, the
+ right-most /.
+
+ Secure If absent, the user agent may send the cookie over an
+ insecure channel.
+
+4.3.2 Rejecting Cookies
+
+ To prevent possible security or privacy violations, a user agent
+ rejects a cookie (shall not store its information) if any of the
+ following is true:
+
+ * The value for the Path attribute is not a prefix of the request-
+ URI.
+
+ * The value for the Domain attribute contains no embedded dots or
+ does not start with a dot.
+
+ * The value for the request-host does not domain-match the Domain
+ attribute.
+
+ * The request-host is a FQDN (not IP address) and has the form HD,
+ where D is the value of the Domain attribute, and H is a string
+ that contains one or more dots.
+
+ Examples:
+
+ * A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
+ would be rejected, because H is y.x and contains a dot.
+
+
+
+Kristol & Montulli Standards Track [Page 7]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ * A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
+ be accepted.
+
+ * A Set-Cookie with Domain=.com or Domain=.com., will always be
+ rejected, because there is no embedded dot.
+
+ * A Set-Cookie with Domain=ajax.com will be rejected because the
+ value for Domain does not begin with a dot.
+
+4.3.3 Cookie Management
+
+ If a user agent receives a Set-Cookie response header whose NAME is
+ the same as a pre-existing cookie, and whose Domain and Path
+ attribute values exactly (string) match those of a pre-existing
+ cookie, the new cookie supersedes the old. However, if the Set-
+ Cookie has a value for Max-Age of zero, the (old and new) cookie is
+ discarded. Otherwise cookies accumulate until they expire (resources
+ permitting), at which time they are discarded.
+
+ Because user agents have finite space in which to store cookies, they
+ may also discard older cookies to make space for newer ones, using,
+ for example, a least-recently-used algorithm, along with constraints
+ on the maximum number of cookies that each origin server may set.
+
+ If a Set-Cookie response header includes a Comment attribute, the
+ user agent should store that information in a human-readable form
+ with the cookie and should display the comment text as part of a
+ cookie inspection user interface.
+
+ User agents should allow the user to control cookie destruction. An
+ infrequently-used cookie may function as a "preferences file" for
+ network applications, and a user may wish to keep it even if it is
+ the least-recently-used cookie. One possible implementation would be
+ an interface that allows the permanent storage of a cookie through a
+ checkbox (or, conversely, its immediate destruction).
+
+ Privacy considerations dictate that the user have considerable
+ control over cookie management. The PRIVACY section contains more
+ information.
+
+4.3.4 Sending Cookies to the Origin Server
+
+ When it sends a request to an origin server, the user agent sends a
+ Cookie request header to the origin server if it has cookies that are
+ applicable to the request, based on
+
+ * the request-host;
+
+
+
+
+Kristol & Montulli Standards Track [Page 8]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ * the request-URI;
+
+ * the cookie's age.
+
+ The syntax for the header is:
+
+ cookie = "Cookie:" cookie-version
+ 1*((";" | ",") cookie-value)
+ cookie-value = NAME "=" VALUE [";" path] [";" domain]
+ cookie-version = "$Version" "=" value
+ NAME = attr
+ VALUE = value
+ path = "$Path" "=" value
+ domain = "$Domain" "=" value
+
+ The value of the cookie-version attribute must be the value from the
+ Version attribute, if any, of the corresponding Set-Cookie response
+ header. Otherwise the value for cookie-version is 0. The value for
+ the path attribute must be the value from the Path attribute, if any,
+ of the corresponding Set-Cookie response header. Otherwise the
+ attribute should be omitted from the Cookie request header. The
+ value for the domain attribute must be the value from the Domain
+ attribute, if any, of the corresponding Set-Cookie response header.
+ Otherwise the attribute should be omitted from the Cookie request
+ header.
+
+ Note that there is no Comment attribute in the Cookie request header
+ corresponding to the one in the Set-Cookie response header. The user
+ agent does not return the comment information to the origin server.
+
+ The following rules apply to choosing applicable cookie-values from
+ among all the cookies the user agent has.
+
+ Domain Selection
+ The origin server's fully-qualified host name must domain-match
+ the Domain attribute of the cookie.
+
+ Path Selection
+ The Path attribute of the cookie must match a prefix of the
+ request-URI.
+
+ Max-Age Selection
+ Cookies that have expired should have been discarded and thus
+ are not forwarded to an origin server.
+
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 9]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ If multiple cookies satisfy the criteria above, they are ordered in
+ the Cookie header such that those with more specific Path attributes
+ precede those with less specific. Ordering with respect to other
+ attributes (e.g., Domain) is unspecified.
+
+ Note: For backward compatibility, the separator in the Cookie header
+ is semi-colon (;) everywhere. A server should also accept comma (,)
+ as the separator between cookie-values for future compatibility.
+
+4.3.5 Sending Cookies in Unverifiable Transactions
+
+ Users must have control over sessions in order to ensure privacy.
+ (See PRIVACY section below.) To simplify implementation and to
+ prevent an additional layer of complexity where adequate safeguards
+ exist, however, this document distinguishes between transactions that
+ are verifiable and those that are unverifiable. A transaction is
+ verifiable if the user has the option to review the request-URI prior
+ to its use in the transaction. A transaction is unverifiable if the
+ user does not have that option. Unverifiable transactions typically
+ arise when a user agent automatically requests inlined or embedded
+ entities or when it resolves redirection (3xx) responses from an
+ origin server. Typically the origin transaction, the transaction
+ that the user initiates, is verifiable, and that transaction may
+ directly or indirectly induce the user agent to make unverifiable
+ transactions.
+
+ When it makes an unverifiable transaction, a user agent must enable a
+ session only if a cookie with a domain attribute D was sent or
+ received in its origin transaction, such that the host name in the
+ Request-URI of the unverifiable transaction domain-matches D.
+
+ This restriction prevents a malicious service author from using
+ unverifiable transactions to induce a user agent to start or continue
+ a session with a server in a different domain. The starting or
+ continuation of such sessions could be contrary to the privacy
+ expectations of the user, and could also be a security problem.
+
+ User agents may offer configurable options that allow the user agent,
+ or any autonomous programs that the user agent executes, to ignore
+ the above rule, so long as these override options default to "off".
+
+ Many current user agents already provide a review option that would
+ render many links verifiable. For instance, some user agents display
+ the URL that would be referenced for a particular link when the mouse
+ pointer is placed over that link. The user can therefore determine
+ whether to visit that site before causing the browser to do so.
+ (Though not implemented on current user agents, a similar technique
+ could be used for a button used to submit a form -- the user agent
+
+
+
+Kristol & Montulli Standards Track [Page 10]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ could display the action to be taken if the user were to select that
+ button.) However, even this would not make all links verifiable; for
+ example, links to automatically loaded images would not normally be
+ subject to "mouse pointer" verification.
+
+ Many user agents also provide the option for a user to view the HTML
+ source of a document, or to save the source to an external file where
+ it can be viewed by another application. While such an option does
+ provide a crude review mechanism, some users might not consider it
+ acceptable for this purpose.
+
+4.4 How an Origin Server Interprets the Cookie Header
+
+ A user agent returns much of the information in the Set-Cookie header
+ to the origin server when the Path attribute matches that of a new
+ request. When it receives a Cookie header, the origin server should
+ treat cookies with NAMEs whose prefix is $ specially, as an attribute
+ for the adjacent cookie. The value for such a NAME is to be
+ interpreted as applying to the lexically (left-to-right) most recent
+ cookie whose name does not have the $ prefix. If there is no
+ previous cookie, the value applies to the cookie mechanism as a
+ whole. For example, consider the cookie
+
+ Cookie: $Version="1"; Customer="WILE_E_COYOTE";
+ $Path="/acme"
+
+ $Version applies to the cookie mechanism as a whole (and gives the
+ version number for the cookie mechanism). $Path is an attribute
+ whose value (/acme) defines the Path attribute that was used when the
+ Customer cookie was defined in a Set-Cookie response header.
+
+4.5 Caching Proxy Role
+
+ One reason for separating state information from both a URL and
+ document content is to facilitate the scaling that caching permits.
+ To support cookies, a caching proxy must obey these rules already in
+ the HTTP specification:
+
+ * Honor requests from the cache, if possible, based on cache validity
+ rules.
+
+ * Pass along a Cookie request header in any request that the proxy
+ must make of another server.
+
+ * Return the response to the client. Include any Set-Cookie response
+ header.
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 11]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ * Cache the received response subject to the control of the usual
+ headers, such as Expires, Cache-control: no-cache, and Cache-
+ control: private,
+
+ * Cache the Set-Cookie subject to the control of the usual header,
+ Cache-control: no-cache="set-cookie". (The Set-Cookie header
+ should usually not be cached.)
+
+ Proxies must not introduce Set-Cookie (Cookie) headers of their own
+ in proxy responses (requests).
+
+5. EXAMPLES
+
+5.1 Example 1
+
+ Most detail of request and response headers has been omitted. Assume
+ the user agent has no stored cookies.
+
+ 1. User Agent -> Server
+
+ POST /acme/login HTTP/1.1
+ [form data]
+
+ User identifies self via a form.
+
+ 2. Server -> User Agent
+
+ HTTP/1.1 200 OK
+ Set-Cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
+
+ Cookie reflects user's identity.
+
+ 3. User Agent -> Server
+
+ POST /acme/pickitem HTTP/1.1
+ Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
+ [form data]
+
+ User selects an item for "shopping basket."
+
+ 4. Server -> User Agent
+
+ HTTP/1.1 200 OK
+ Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
+ Path="/acme"
+
+ Shopping basket contains an item.
+
+
+
+
+Kristol & Montulli Standards Track [Page 12]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ 5. User Agent -> Server
+
+ POST /acme/shipping HTTP/1.1
+ Cookie: $Version="1";
+ Customer="WILE_E_COYOTE"; $Path="/acme";
+ Part_Number="Rocket_Launcher_0001"; $Path="/acme"
+ [form data]
+
+ User selects shipping method from form.
+
+ 6. Server -> User Agent
+
+ HTTP/1.1 200 OK
+ Set-Cookie: Shipping="FedEx"; Version="1"; Path="/acme"
+
+ New cookie reflects shipping method.
+
+ 7. User Agent -> Server
+
+ POST /acme/process HTTP/1.1
+ Cookie: $Version="1";
+ Customer="WILE_E_COYOTE"; $Path="/acme";
+ Part_Number="Rocket_Launcher_0001"; $Path="/acme";
+ Shipping="FedEx"; $Path="/acme"
+ [form data]
+
+ User chooses to process order.
+
+ 8. Server -> User Agent
+
+ HTTP/1.1 200 OK
+
+ Transaction is complete.
+
+ The user agent makes a series of requests on the origin server, after
+ each of which it receives a new cookie. All the cookies have the
+ same Path attribute and (default) domain. Because the request URLs
+ all have /acme as a prefix, and that matches the Path attribute, each
+ request contains all the cookies received so far.
+
+5.2 Example 2
+
+ This example illustrates the effect of the Path attribute. All
+ detail of request and response headers has been omitted. Assume the
+ user agent has no stored cookies.
+
+ Imagine the user agent has received, in response to earlier requests,
+ the response headers
+
+
+
+Kristol & Montulli Standards Track [Page 13]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
+ Path="/acme"
+
+ and
+
+ Set-Cookie: Part_Number="Riding_Rocket_0023"; Version="1";
+ Path="/acme/ammo"
+
+ A subsequent request by the user agent to the (same) server for URLs
+ of the form /acme/ammo/... would include the following request
+ header:
+
+ Cookie: $Version="1";
+ Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
+ Part_Number="Rocket_Launcher_0001"; $Path="/acme"
+
+ Note that the NAME=VALUE pair for the cookie with the more specific
+ Path attribute, /acme/ammo, comes before the one with the less
+ specific Path attribute, /acme. Further note that the same cookie
+ name appears more than once.
+
+ A subsequent request by the user agent to the (same) server for a URL
+ of the form /acme/parts/ would include the following request header:
+
+ Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"
+
+ Here, the second cookie's Path attribute /acme/ammo is not a prefix
+ of the request URL, /acme/parts/, so the cookie does not get
+ forwarded to the server.
+
+6. IMPLEMENTATION CONSIDERATIONS
+
+ Here we speculate on likely or desirable details for an origin server
+ that implements state management.
+
+6.1 Set-Cookie Content
+
+ An origin server's content should probably be divided into disjoint
+ application areas, some of which require the use of state
+ information. The application areas can be distinguished by their
+ request URLs. The Set-Cookie header can incorporate information
+ about the application areas by setting the Path attribute for each
+ one.
+
+ The session information can obviously be clear or encoded text that
+ describes state. However, if it grows too large, it can become
+ unwieldy. Therefore, an implementor might choose for the session
+ information to be a key to a server-side resource. Of course, using
+
+
+
+Kristol & Montulli Standards Track [Page 14]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ a database creates some problems that this state management
+ specification was meant to avoid, namely:
+
+ 1. keeping real state on the server side;
+
+ 2. how and when to garbage-collect the database entry, in case the
+ user agent terminates the session by, for example, exiting.
+
+6.2 Stateless Pages
+
+ Caching benefits the scalability of WWW. Therefore it is important
+ to reduce the number of documents that have state embedded in them
+ inherently. For example, if a shopping-basket-style application
+ always displays a user's current basket contents on each page, those
+ pages cannot be cached, because each user's basket's contents would
+ be different. On the other hand, if each page contains just a link
+ that allows the user to "Look at My Shopping Basket", the page can be
+ cached.
+
+6.3 Implementation Limits
+
+ Practical user agent implementations have limits on the number and
+ size of cookies that they can store. In general, user agents' cookie
+ support should have no fixed limits. They should strive to store as
+ many frequently-used cookies as possible. Furthermore, general-use
+ user agents should provide each of the following minimum capabilities
+ individually, although not necessarily simultaneously:
+
+ * at least 300 cookies
+
+ * at least 4096 bytes per cookie (as measured by the size of the
+ characters that comprise the cookie non-terminal in the syntax
+ description of the Set-Cookie header)
+
+ * at least 20 cookies per unique host or domain name
+
+ User agents created for specific purposes or for limited-capacity
+ devices should provide at least 20 cookies of 4096 bytes, to ensure
+ that the user can interact with a session-based origin server.
+
+ The information in a Set-Cookie response header must be retained in
+ its entirety. If for some reason there is inadequate space to store
+ the cookie, it must be discarded, not truncated.
+
+ Applications should use as few and as small cookies as possible, and
+ they should cope gracefully with the loss of a cookie.
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 15]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+6.3.1 Denial of Service Attacks
+
+ User agents may choose to set an upper bound on the number of cookies
+ to be stored from a given host or domain name or on the size of the
+ cookie information. Otherwise a malicious server could attempt to
+ flood a user agent with many cookies, or large cookies, on successive
+ responses, which would force out cookies the user agent had received
+ from other servers. However, the minima specified above should still
+ be supported.
+
+7. PRIVACY
+
+7.1 User Agent Control
+
+ An origin server could create a Set-Cookie header to track the path
+ of a user through the server. Users may object to this behavior as
+ an intrusive accumulation of information, even if their identity is
+ not evident. (Identity might become evident if a user subsequently
+ fills out a form that contains identifying information.) This state
+ management specification therefore requires that a user agent give
+ the user control over such a possible intrusion, although the
+ interface through which the user is given this control is left
+ unspecified. However, the control mechanisms provided shall at least
+ allow the user
+
+ * to completely disable the sending and saving of cookies.
+
+ * to determine whether a stateful session is in progress.
+
+ * to control the saving of a cookie on the basis of the cookie's
+ Domain attribute.
+
+ Such control could be provided by, for example, mechanisms
+
+ * to notify the user when the user agent is about to send a cookie
+ to the origin server, offering the option not to begin a session.
+
+ * to display a visual indication that a stateful session is in
+ progress.
+
+ * to let the user decide which cookies, if any, should be saved
+ when the user concludes a window or user agent session.
+
+ * to let the user examine the contents of a cookie at any time.
+
+ A user agent usually begins execution with no remembered state
+ information. It should be possible to configure a user agent never
+ to send Cookie headers, in which case it can never sustain state with
+
+
+
+Kristol & Montulli Standards Track [Page 16]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ an origin server. (The user agent would then behave like one that is
+ unaware of how to handle Set-Cookie response headers.)
+
+ When the user agent terminates execution, it should let the user
+ discard all state information. Alternatively, the user agent may ask
+ the user whether state information should be retained; the default
+ should be "no". If the user chooses to retain state information, it
+ would be restored the next time the user agent runs.
+
+ NOTE: User agents should probably be cautious about using files to
+ store cookies long-term. If a user runs more than one instance of
+ the user agent, the cookies could be commingled or otherwise messed
+ up.
+
+7.2 Protocol Design
+
+ The restrictions on the value of the Domain attribute, and the rules
+ concerning unverifiable transactions, are meant to reduce the ways
+ that cookies can "leak" to the "wrong" site. The intent is to
+ restrict cookies to one, or a closely related set of hosts.
+ Therefore a request-host is limited as to what values it can set for
+ Domain. We consider it acceptable for hosts host1.foo.com and
+ host2.foo.com to share cookies, but not a.com and b.com.
+
+ Similarly, a server can only set a Path for cookies that are related
+ to the request-URI.
+
+8. SECURITY CONSIDERATIONS
+
+8.1 Clear Text
+
+ The information in the Set-Cookie and Cookie headers is unprotected.
+ Two consequences are:
+
+ 1. Any sensitive information that is conveyed in them is exposed
+ to intruders.
+
+ 2. A malicious intermediary could alter the headers as they travel
+ in either direction, with unpredictable results.
+
+ These facts imply that information of a personal and/or financial
+ nature should only be sent over a secure channel. For less sensitive
+ information, or when the content of the header is a database key, an
+ origin server should be vigilant to prevent a bad Cookie value from
+ causing failures.
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 17]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+8.2 Cookie Spoofing
+
+ Proper application design can avoid spoofing attacks from related
+ domains. Consider:
+
+ 1. User agent makes request to victim.cracker.edu, gets back
+ cookie session_id="1234" and sets the default domain
+ victim.cracker.edu.
+
+ 2. User agent makes request to spoof.cracker.edu, gets back
+ cookie session-id="1111", with Domain=".cracker.edu".
+
+ 3. User agent makes request to victim.cracker.edu again, and
+ passes
+
+ Cookie: $Version="1";
+ session_id="1234";
+ session_id="1111"; $Domain=".cracker.edu"
+
+ The server at victim.cracker.edu should detect that the second
+ cookie was not one it originated by noticing that the Domain
+ attribute is not for itself and ignore it.
+
+8.3 Unexpected Cookie Sharing
+
+ A user agent should make every attempt to prevent the sharing of
+ session information between hosts that are in different domains.
+ Embedded or inlined objects may cause particularly severe privacy
+ problems if they can be used to share cookies between disparate
+ hosts. For example, a malicious server could embed cookie
+ information for host a.com in a URI for a CGI on host b.com. User
+ agent implementors are strongly encouraged to prevent this sort of
+ exchange whenever possible.
+
+9. OTHER, SIMILAR, PROPOSALS
+
+ Three other proposals have been made to accomplish similar goals.
+ This specification is an amalgam of Kristol's State-Info proposal and
+ Netscape's Cookie proposal.
+
+ Brian Behlendorf proposed a Session-ID header that would be user-
+ agent-initiated and could be used by an origin server to track
+ "clicktrails". It would not carry any origin-server-defined state,
+ however. Phillip Hallam-Baker has proposed another client-defined
+ session ID mechanism for similar purposes.
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 18]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+ While both session IDs and cookies can provide a way to sustain
+ stateful sessions, their intended purpose is different, and,
+ consequently, the privacy requirements for them are different. A
+ user initiates session IDs to allow servers to track progress through
+ them, or to distinguish multiple users on a shared machine. Cookies
+ are server-initiated, so the cookie mechanism described here gives
+ users control over something that would otherwise take place without
+ the users' awareness. Furthermore, cookies convey rich, server-
+ selected information, whereas session IDs comprise user-selected,
+ simple information.
+
+10. HISTORICAL
+
+10.1 Compatibility With Netscape's Implementation
+
+ HTTP/1.0 clients and servers may use Set-Cookie and Cookie headers
+ that reflect Netscape's original cookie proposal. These notes cover
+ inter-operation between "old" and "new" cookies.
+
+10.1.1 Extended Cookie Header
+
+ This proposal adds attribute-value pairs to the Cookie request header
+ in a compatible way. An "old" client that receives a "new" cookie
+ will ignore attributes it does not understand; it returns what it
+ does understand to the origin server. A "new" client always sends
+ cookies in the new form.
+
+ An "old" server that receives a "new" cookie will see what it thinks
+ are many cookies with names that begin with a $, and it will ignore
+ them. (The "old" server expects these cookies to be separated by
+ semi-colon, not comma.) A "new" server can detect cookies that have
+ passed through an "old" client, because they lack a $Version
+ attribute.
+
+10.1.2 Expires and Max-Age
+
+ Netscape's original proposal defined an Expires header that took a
+ date value in a fixed-length variant format in place of Max-Age:
+
+ Wdy, DD-Mon-YY HH:MM:SS GMT
+
+ Note that the Expires date format contains embedded spaces, and that
+ "old" cookies did not have quotes around values. Clients that
+ implement to this specification should be aware of "old" cookies and
+ Expires.
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 19]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+10.1.3 Punctuation
+
+ In Netscape's original proposal, the values in attribute-value pairs
+ did not accept "-quoted strings. Origin servers should be cautious
+ about sending values that require quotes unless they know the
+ receiving user agent understands them (i.e., "new" cookies). A
+ ("new") user agent should only use quotes around values in Cookie
+ headers when the cookie's version(s) is (are) all compliant with this
+ specification or later.
+
+ In Netscape's original proposal, no whitespace was permitted around
+ the = that separates attribute-value pairs. Therefore such
+ whitespace should be used with caution in new implementations.
+
+10.2 Caching and HTTP/1.0
+
+ Some caches, such as those conforming to HTTP/1.0, will inevitably
+ cache the Set-Cookie header, because there was no mechanism to
+ suppress caching of headers prior to HTTP/1.1. This caching can lead
+ to security problems. Documents transmitted by an origin server
+ along with Set-Cookie headers will usually either be uncachable, or
+ will be "pre-expired". As long as caches obey instructions not to
+ cache documents (following Expires: <a date in the past> or Pragma:
+ no-cache (HTTP/1.0), or Cache-control: no-cache (HTTP/1.1))
+ uncachable documents present no problem. However, pre-expired
+ documents may be stored in caches. They require validation (a
+ conditional GET) on each new request, but some cache operators loosen
+ the rules for their caches, and sometimes serve expired documents
+ without first validating them. This combination of factors can lead
+ to cookies meant for one user later being sent to another user. The
+ Set-Cookie header is stored in the cache, and, although the document
+ is stale (expired), the cache returns the document in response to
+ later requests, including cached headers.
+
+11. ACKNOWLEDGEMENTS
+
+ This document really represents the collective efforts of the
+ following people, in addition to the authors: Roy Fielding, Marc
+ Hedlund, Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare.
+
+
+
+
+
+
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 20]
+
+RFC 2109 HTTP State Management Mechanism February 1997
+
+
+12. AUTHORS' ADDRESSES
+
+ David M. Kristol
+ Bell Laboratories, Lucent Technologies
+ 600 Mountain Ave. Room 2A-227
+ Murray Hill, NJ 07974
+
+ Phone: (908) 582-2250
+ Fax: (908) 582-5809
+ EMail: dmk@bell-labs.com
+
+
+ Lou Montulli
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd.
+ Mountain View, CA 94043
+
+ Phone: (415) 528-2600
+ EMail: montulli@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kristol & Montulli Standards Track [Page 21]
+