source: draft-ietf-httpbis/orig/rfc2965.xml

Last change on this file was 1500, checked in by julian.reschke@…, 8 years ago

fix mime types

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 60.3 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
3<?rfc toc="yes" ?>
4<?rfc symrefs="yes" ?>
5<?rfc-ext include-references-in-index="yes" ?>
6
7<!DOCTYPE rfc [
8  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
9  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
10  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
11  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
12  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
13  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
14  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
15  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
16  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
17  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
18]>
19<rfc number="2965" obsoletes="2109" category="std" xmlns:x="http://purl.org/net/xml2rfc/ext" xmlns:grddl='http://www.w3.org/2003/g/data-view#' grddl:transformation='rfc2629grddl.xslt'>
20
21<front>
22  <title>HTTP State Management Mechanism</title>
23
24  <author initials='D. M.' surname='Kristol' fullname='David M. Kristol'>
25    <organization>Bell Laboratories, Lucent Technologies</organization>
26    <address>
27      <postal>
28        <street>600 Mountain Ave.  Room 2A-333</street>
29        <city>Murray Hill</city>
30        <region>NJ</region>
31        <code>07974</code>
32      </postal>
33      <phone>(908) 582-2250</phone>
34      <facsimile>(908) 582-1239</facsimile>
35      <email>dmk@bell-labs.com</email>
36    </address>
37  </author>
38 
39  <author initials='L.' surname='Montulli' fullname='Lou Montulli'>
40    <organization>Epinions.com, Inc.</organization>
41    <address>
42      <postal>
43        <street>2037 Landings Dr.</street>
44        <city>Mountain View</city>
45        <region>CA</region>
46        <code>94301</code>
47      </postal>
48      <email>lou@montulli.org</email>
49    </address>
50  </author>
51 
52  <date month='October' year='2000'></date>
53
54  <abstract>
55    <t>
56     This document specifies a way to create a stateful session with
57     Hypertext Transfer Protocol (HTTP) requests and responses.  It
58     describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
59     carry state information between participating origin servers and user
60     agents.  The method described here differs from Netscape's Cookie
61     proposal <xref target="Netscape"/>, but it can interoperate with HTTP/1.0 user
62     agents that use Netscape's method.  (See the HISTORICAL section.)
63    </t><t>
64     This document reflects implementation experience with RFC 2109 and
65     obsoletes it.
66     </t>
67  </abstract>
68</front>
69<middle>
70<section title="TERMINOLOGY">
71<t>
72   The terms user agent, client, server, proxy, origin server, and
73   http_URL have the same meaning as in the HTTP/1.1 specification
74   <xref target="RFC2616"/>.  The terms abs_path and absoluteURI have the same meaning
75   as in the URI Syntax specification <xref target="RFC2396"/>.
76</t>
77<t>
78   Host name (HN) means either the host domain name (HDN) or the numeric
79   Internet Protocol (IP) address of a host.  The fully qualified domain
80   name is preferred; use of numeric IP addresses is strongly
81   discouraged.
82</t>
83<t>
84   The terms request-host and request-URI refer to the values the client
85   would send to the server as, respectively, the host (but not port)
86   and abs_path portions of the absoluteURI (http_URL) of the HTTP
87   request line.  Note that request-host is a HN.
88</t>
89<t>
90   The term effective host name is related to host name.  If a host name
91   contains no dots, the effective host name is that name with the
92   string .local appended to it.  Otherwise the effective host name is
93   the same as the host name.  Note that all effective host names
94   contain at least one dot.
95</t>
96<t>
97   The term request-port refers to the port portion of the absoluteURI
98   (http_URL) of the HTTP request line.  If the absoluteURI has no
99   explicit port, the request-port is the HTTP default, 80.  The
100   request-port of a cookie is the request-port of the request in which
101   a Set-Cookie2 response header was returned to the user agent.
102</t>
103<t>
104   Host names can be specified either as an IP address or a HDN string.
105   Sometimes we compare one host name with another.  (Such comparisons
106   &SHALL; be case-insensitive.)  Host A's name domain-matches host B's if
107  <list style="symbols">
108    <t>their host name strings string-compare equal; or</t>
109
110    <t>A is a HDN string and has the form NB, where N is a non-empty
111         name string, B has the form .B', and B' is a HDN string.  (So,
112         x.y.com domain-matches .Y.com but not Y.com.)</t>
113  </list>
114</t>
115<t>
116   Note that domain-match is not a commutative operation: a.b.c.com
117   domain-matches .c.com, but not the reverse.
118</t>
119<t>
120   The reach R of a host name H is defined as follows:
121  <list style="symbols">
122    <t>If
123      <list style="symbols">     
124        <t>H is the host domain name of a host; and,</t>
125        <t>H has the form A.B; and</t>
126        <t>A has no embedded (that is, interior) dots; and</t>
127        <t>B has at least one embedded dot, or B is the string "local".
128            then the reach of H is .B.</t>
129      </list>
130      </t>
131      <t>Otherwise, the reach of H is H.</t>
132  </list>
133</t>
134<t>
135   For two strings that represent paths, P1 and P2, P1 path-matches P2
136   if P2 is a prefix of P1 (including the case where P1 and P2 string-
137   compare equal).  Thus, the string /tec/waldo path-matches /tec.
138</t>
139<t>
140   Because it was used in Netscape's original implementation of state
141   management, we will use the term cookie to refer to the state
142   information that passes between an origin server and user agent, and
143   that gets stored by the user agent.
144</t>
145
146<section title="Requirements">
147<t>
148   The key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED",
149   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT" in this
150   document are to be interpreted as described in RFC 2119 <xref target="RFC2119"/>.
151</t>
152</section>
153</section>
154
155<section title="STATE AND SESSIONS">
156<t>
157   This document describes a way to create stateful sessions with HTTP
158   requests and responses.  Currently, HTTP servers respond to each
159   client request without relating that request to previous or
160   subsequent requests; the state management mechanism allows clients
161   and servers that wish to exchange state information to place HTTP
162   requests and responses within a larger context, which we term a
163   "session".  This context might be used to create, for example, a
164   "shopping cart", in which user selections can be aggregated before
165   purchase, or a magazine browsing system, in which a user's previous
166   reading affects which offerings are presented.
167</t>
168<t>
169   Neither clients nor servers are required to support cookies.  A
170   server &MAY; refuse to provide content to a client that does not return
171   the cookies it sends.
172</t>
173</section>
174
175<section title="DESCRIPTION">
176<t>
177   We describe here a way for an origin server to send state information
178   to the user agent, and for the user agent to return the state
179   information to the origin server.  The goal is to have a minimal
180   impact on HTTP and user agents.
181</t>
182
183<section title="Syntax: General">
184<t>
185   The two state management headers, Set-Cookie2 and Cookie, have common
186   syntactic properties involving attribute-value pairs.  The following
187   grammar uses the notation, and tokens DIGIT (decimal digits), token
188   (informally, a sequence of non-special, non-white space characters),
189   and http_URL from the HTTP/1.1 specification <xref target="RFC2616"/> to describe
190   their syntax.
191</t>
192<figure><artwork type="abnf2616">
193   av-pairs    =     av-pair *(";" av-pair)
194   av-pair     =     attr ["=" value]              ; optional value
195   attr        =     token
196   value       =     token | quoted-string
197</artwork></figure>
198<t>
199   Attributes (names) (attr) are case-insensitive.  White space is
200   permitted between tokens.  Note that while the above syntax
201   description shows value as optional, most attrs require them.
202</t>
203<t>
204   NOTE: The syntax above allows whitespace between the attribute and
205   the = sign.
206</t>
207</section>
208
209<section title="Origin Server Role">
210<section title="General">
211<t>
212   The origin server initiates a session, if it so
213   desires.  To do so, it returns an extra response header to the
214   client, Set-Cookie2.  (The details follow later.)
215</t>
216<t>
217   A user agent returns a Cookie request header (see below) to the
218   origin server if it chooses to continue a session.  The origin server
219   &MAY; ignore it or use it to determine the current state of the
220   session.  It &MAY; send back to the client a Set-Cookie2 response
221   header with the same or different information, or it &MAY; send no
222   Set-Cookie2 header at all.  The origin server effectively ends a
223   session by sending the client a Set-Cookie2 header with Max-Age=0.
224</t>
225<t>
226   Servers &MAY; return Set-Cookie2 response headers with any response.
227   User agents &SHOULD; send Cookie request headers, subject to other
228   rules detailed below, with every request.
229</t>
230<t>
231   An origin server &MAY; include multiple Set-Cookie2 headers in a
232   response.  Note that an intervening gateway could fold multiple such
233   headers into a single header.
234</t>
235</section>
236
237<section title="Set-Cookie2 Syntax">
238<iref item="Set-Cookie2 header" primary="true"/>
239<iref item="Headers" subitem="Set-Cookie2" primary="true"/>
240<t>
241   The syntax for the Set-Cookie2 response
242   header is
243</t>
244<figure><artwork type="abnf2616">
245   set-cookie      =       "Set-Cookie2:" cookies
246   cookies         =       1#cookie
247   cookie          =       NAME "=" VALUE *(";" set-cookie-av)
248   NAME            =       attr
249   VALUE           =       value
250   set-cookie-av   =       "Comment" "=" value
251                   |       "CommentURL" "=" &lt;"> http_URL &lt;">
252                   |       "Discard"
253                   |       "Domain" "=" value
254                   |       "Max-Age" "=" value
255                   |       "Path" "=" value
256                   |       "Port" [ "=" &lt;"> portlist &lt;"> ]
257                   |       "Secure"
258                   |       "Version" "=" 1*DIGIT
259   portlist        =       1#portnum
260   portnum         =       1*DIGIT
261</artwork></figure>
262<t>
263   Informally, the Set-Cookie2 response header comprises the token Set-Cookie2:,
264   followed by a comma-separated list of one or more cookies.
265   Each cookie begins with a NAME=VALUE pair, followed by zero or more
266   semi-colon-separated attribute-value pairs.  The syntax for
267   attribute-value pairs was shown earlier.  The specific attributes and
268   the semantics of their values follows.  The NAME=VALUE attribute-value
269   pair &MUST; come first in each cookie.  The others, if present,
270   can occur in any order.  If an attribute appears more than once in a
271   cookie, the client &SHALL; use only the value associated with the first
272   appearance of the attribute; a client &MUST; ignore values after the
273   first.
274</t>
275<t>
276   The NAME of a cookie &MAY; be the same as one of the attributes in this
277   specification.  However, because the cookie's NAME must come first in
278   a Set-Cookie2 response header, the NAME and its VALUE cannot be
279   confused with an attribute-value pair.
280</t>
281<t>
282  <list style="hanging">
283    <x:lt hangText="NAME=VALUE">
284      <t>
285        &REQUIRED;.  The name of the state information ("cookie") is NAME,
286        and its value is VALUE.  NAMEs that begin with $ are reserved and
287        &MUST-NOT; be used by applications.
288      </t>
289      <t>
290        The VALUE is opaque to the user agent and may be anything the
291        origin server chooses to send, possibly in a server-selected
292        printable ASCII encoding.  "Opaque" implies that the content is of
293        interest and relevance only to the origin server.  The content
294        may, in fact, be readable by anyone that examines the Set-Cookie2
295        header.
296      </t>
297    </x:lt>
298    <x:lt hangText="Comment=value">
299      <t>
300        &OPTIONAL;.  Because cookies can be used to derive or store private
301        information about a user, the value of the Comment attribute
302        allows an origin server to document how it intends to use the
303        cookie.  The user can inspect the information to decide whether to
304        initiate or continue a session with this cookie.  Characters in
305        value &MUST; be in UTF-8 encoding. <xref target="RFC2279"/>
306      </t>
307    </x:lt>
308    <x:lt hangText='CommentURL="http_URL"'>
309      <t>
310        &OPTIONAL;.  Because cookies can be used to derive or store private
311        information about a user, the CommentURL attribute allows an
312        origin server to document how it intends to use the cookie.  The
313        user can inspect the information identified by the URL to decide
314        whether to initiate or continue a session with this cookie.
315      </t>
316    </x:lt>
317    <x:lt hangText="Discard">
318      <t>
319        &OPTIONAL;.  The Discard attribute instructs the user agent to
320        discard the cookie unconditionally when the user agent terminates.
321      </t>
322    </x:lt>
323    <x:lt hangText="Domain=value">
324      <t>
325        &OPTIONAL;.  The value of the Domain attribute specifies the domain
326        for which the cookie is valid.  If an explicitly specified value
327        does not start with a dot, the user agent supplies a leading dot.
328      </t>
329    </x:lt>
330    <x:lt hangText="Max-Age=value">
331      <t>
332        &OPTIONAL;.  The value of the Max-Age attribute is delta-seconds,
333        the lifetime of the cookie in seconds, a decimal non-negative
334        integer.  To handle cached cookies correctly, a client &SHOULD;
335        calculate the age of the cookie according to the age calculation
336        rules in the HTTP/1.1 specification <xref target="RFC2616"/>.  When the age is
337        greater than delta-seconds seconds, the client &SHOULD; discard the
338        cookie.  A value of zero means the cookie &SHOULD; be discarded
339        immediately.
340      </t>
341    </x:lt>
342    <x:lt hangText="Path=value">
343      <t>
344        &OPTIONAL;.  The value of the Path attribute specifies the subset of
345        URLs on the origin server to which this cookie applies.
346      </t>
347    </x:lt>
348    <x:lt hangText='Port[="portlist"]'>
349      <t>
350        &OPTIONAL;.  The Port attribute restricts the port to which a cookie
351        may be returned in a Cookie request header.  Note that the syntax
352        REQUIREs quotes around the &OPTIONAL; portlist even if there is only
353        one portnum in portlist.
354      </t>
355    </x:lt>
356    <x:lt hangText="Secure">
357      <t>
358        &OPTIONAL;.  The Secure attribute (with no value) directs the user
359        agent to use only (unspecified) secure means to contact the origin
360        server whenever it sends back this cookie, to protect the
361        confidentially and authenticity of the information in the cookie.
362      </t>
363      <t>
364        The user agent (possibly with user interaction) &MAY; determine what
365        level of security it considers appropriate for "secure" cookies.
366        The Secure attribute should be considered security advice from the
367        server to the user agent, indicating that it is in the session's
368        interest to protect the cookie contents.  When it sends a "secure"
369        cookie back to a server, the user agent &SHOULD; use no less than
370        the same level of security as was used when it received the cookie
371        from the server.
372      </t>
373    </x:lt>
374    <x:lt hangText="Version=value">
375      <t>
376        &REQUIRED;.  The value of the Version attribute, a decimal integer,
377        identifies the version of the state management specification to
378        which the cookie conforms.  For this specification, Version=1
379        applies.
380      </t>
381    </x:lt>
382  </list>
383</t>
384</section>
385
386<section title="Controlling Caching">
387<t>
388   An origin server must be cognizant of the
389   effect of possible caching of both the returned resource and the
390   Set-Cookie2 header.  Caching "public" documents is desirable.  For
391   example, if the origin server wants to use a public document such as
392   a "front door" page as a sentinel to indicate the beginning of a
393   session for which a Set-Cookie2 response header must be generated,
394   the page &SHOULD; be stored in caches "pre-expired" so that the origin
395   server will see further requests.  "Private documents", for example
396   those that contain information strictly private to a session, &SHOULD;
397   NOT be cached in shared caches.
398</t>
399<t>
400   If the cookie is intended for use by a single user, the Set-Cookie2
401   header &SHOULD-NOT; be cached.  A Set-Cookie2 header that is intended
402   to be shared by multiple users &MAY; be cached.
403</t>
404<t>
405   The origin server &SHOULD; send the following additional HTTP/1.1
406   response headers, depending on circumstances:
407  <list style="symbols">
408    <t>To suppress caching of the Set-Cookie2 header:
409<figure><artwork type="example">
410    Cache-control: no-cache="set-cookie2"
411</artwork></figure>
412    </t>
413  </list>
414</t>
415<t>
416   and one of the following:
417  <list style="symbols">
418      <t>To suppress caching of a private document in shared caches:
419<figure><artwork type="example">
420    Cache-control: private
421</artwork></figure>
422      </t>
423      <t>To allow caching of a document and require that it be validated
424         before returning it to the client:
425<figure><artwork type="example">
426    Cache-Control: must-revalidate, max-age=0
427</artwork></figure>
428      </t>
429      <t>To allow caching of a document, but to require that proxy
430         caches (not user agent caches) validate it before returning it
431         to the client:
432<figure><artwork type="example">
433    Cache-Control: proxy-revalidate, max-age=0
434</artwork></figure>
435      </t>
436      <t>To allow caching of a document and request that it be validated
437         before returning it to the client (by "pre-expiring" it):
438<figure><artwork type="example">
439    Cache-control: max-age=0
440</artwork></figure>
441         Not all caches will revalidate the document in every case.
442      </t>
443  </list>
444</t>
445<t>
446   HTTP/1.1 servers &MUST; send Expires: old-date (where old-date is a
447   date long in the past) on responses containing Set-Cookie2 response
448   headers unless they know for certain (by out of band means) that
449   there are no HTTP/1.0 proxies in the response chain.  HTTP/1.1
450   servers &MAY; send other Cache-Control directives that permit caching
451   by HTTP/1.1 proxies in addition to the Expires: old-date directive;
452   the Cache-Control directive will override the Expires: old-date for
453   HTTP/1.1 proxies.
454</t>
455</section>
456</section>
457
458<section title="User Agent Role">
459<section title="Interpreting Set-Cookie2">
460<t>
461   The user agent keeps separate track
462   of state information that arrives via Set-Cookie2 response headers
463   from each origin server (as distinguished by name or IP address and
464   port).  The user agent &MUST; ignore attribute-value pairs whose
465   attribute it does not recognize.  The user agent applies these
466   defaults for optional attributes that are missing:
467</t>
468<t>
469  <list style="hanging">
470    <t hangText="Discard">The default behavior is dictated by the presence or absence
471           of a Max-Age attribute.</t>
472    <t hangText="Domain">Defaults to the effective request-host.  (Note that because
473           there is no dot at the beginning of effective request-host,
474           the default Domain can only domain-match itself.)</t>
475    <t hangText="Max-Age">The default behavior is to discard the cookie when the user
476           agent exits.</t>
477    <t hangText="Path">Defaults to the path of the request URL that generated the
478           Set-Cookie2 response, up to and including the right-most /.</t>
479    <t hangText="Port">The default behavior is that a cookie &MAY; be returned to any
480           request-port.</t>
481    <t hangText="Secure">If absent, the user agent &MAY; send the cookie over an
482           insecure channel.</t>
483  </list>
484</t>
485</section>
486
487<section title="Rejecting Cookies">
488<t>
489   To prevent possible security or privacy
490   violations, a user agent rejects a cookie according to rules below.
491   The goal of the rules is to try to limit the set of servers for which
492   a cookie is valid, based on the values of the Path, Domain, and Port
493   attributes and the request-URI, request-host and request-port.
494</t>
495<t>
496   A user agent rejects (&SHALL-NOT; store its information) if the Version
497   attribute is missing.  Moreover, a user agent rejects (&SHALL-NOT;
498   store its information) if any of the following is true of the
499   attributes explicitly present in the Set-Cookie2 response header:
500  <list style="symbols">
501    <t>The value for the Path attribute is not a prefix of the
502         request-URI.</t>
503    <t>The value for the Domain attribute contains no embedded dots,
504         and the value is not .local.</t>
505    <t>The effective host name that derives from the request-host does
506         not domain-match the Domain attribute.</t>
507    <t>The request-host is a HDN (not IP address) and has the form HD,
508         where D is the value of the Domain attribute, and H is a string
509         that contains one or more dots.</t>
510    <t>The Port attribute has a "port-list", and the request-port was
511         not in the list.</t>
512  </list>
513</t>
514<t>
515   Examples:
516  <list style="symbols"> 
517    <t>A Set-Cookie2 from request-host y.x.foo.com for Domain=.foo.com
518         would be rejected, because H is y.x and contains a dot.</t>
519    <t>A Set-Cookie2 from request-host x.foo.com for Domain=.foo.com
520         would be accepted.</t>
521    <t>A Set-Cookie2 with Domain=.com or Domain=.com., will always be
522         rejected, because there is no embedded dot.</t>
523    <t>A Set-Cookie2 with Domain=ajax.com will be accepted, and the
524         value for Domain will be taken to be .ajax.com, because a dot
525         gets prepended to the value.</t>
526    <t>A Set-Cookie2 with Port="80,8000" will be accepted if the
527         request was made to port 80 or 8000 and will be rejected
528         otherwise.</t>
529    <t>A Set-Cookie2 from request-host example for Domain=.local will
530         be accepted, because the effective host name for the request-
531         host is example.local, and example.local domain-matches .local.</t>
532  </list>
533</t>
534</section>
535
536<section title="Cookie Management">
537<t>
538   If a user agent receives a Set-Cookie2
539   response header whose NAME is the same as that of a cookie it has
540   previously stored, the new cookie supersedes the old when: the old
541   and new Domain attribute values compare equal, using a case-insensitive string-compare;
542   and, the old and new Path attribute
543   values string-compare equal (case-sensitive).  However, if the Set-Cookie2
544   has a value for Max-Age of zero, the (old and new) cookie is
545   discarded.  Otherwise a cookie persists (resources permitting) until
546   whichever happens first, then gets discarded: its Max-Age lifetime is
547   exceeded; or, if the Discard attribute is set, the user agent
548   terminates the session.
549</t>
550<t>
551   Because user agents have finite space in which to store cookies, they
552   &MAY; also discard older cookies to make space for newer ones, using,
553   for example, a least-recently-used algorithm, along with constraints
554   on the maximum number of cookies that each origin server may set.
555</t>
556<t>
557   If a Set-Cookie2 response header includes a Comment attribute, the
558   user agent &SHOULD; store that information in a human-readable form
559   with the cookie and &SHOULD; display the comment text as part of a
560   cookie inspection user interface.
561</t>
562<t>
563   If a Set-Cookie2 response header includes a CommentURL attribute, the
564   user agent &SHOULD; store that information in a human-readable form
565   with the cookie, or, preferably, &SHOULD; allow the user to follow the
566   http_URL link as part of a cookie inspection user interface.
567</t>
568<t>
569   The cookie inspection user interface may include a facility whereby a
570   user can decide, at the time the user agent receives the Set-Cookie2
571   response header, whether or not to accept the cookie.  A potentially
572   confusing situation could arise if the following sequence occurs:
573  <list style="symbols">
574    <t>the user agent receives a cookie that contains a CommentURL
575         attribute;</t>
576    <t>the user agent's cookie inspection interface is configured so
577         that it presents a dialog to the user before the user agent
578         accepts the cookie;</t>
579    <t>the dialog allows the user to follow the CommentURL link when
580         the user agent receives the cookie; and,</t>
581    <t>when the user follows the CommentURL link, the origin server
582         (or another server, via other links in the returned content)
583         returns another cookie.</t>
584  </list>
585</t>
586<t>
587   The user agent &SHOULD-NOT; send any cookies in this context.  The user
588   agent &MAY; discard any cookie it receives in this context that the
589   user has not, through some user agent mechanism, deemed acceptable.
590</t>
591<t>
592   User agents &SHOULD; allow the user to control cookie destruction, but
593   they &MUST-NOT; extend the cookie's lifetime beyond that controlled by
594   the Discard and Max-Age attributes.  An infrequently-used cookie may
595   function as a "preferences file" for network applications, and a user
596   may wish to keep it even if it is the least-recently-used cookie. One
597   possible implementation would be an interface that allows the
598   permanent storage of a cookie through a checkbox (or, conversely, its
599   immediate destruction).
600</t>
601<t>
602   Privacy considerations dictate that the user have considerable
603   control over cookie management.  The PRIVACY section contains more
604   information.
605</t>
606</section>
607
608<section title="Sending Cookies to the Origin Server">
609<iref item="Cookie header" primary="true"/>
610<iref item="Headers" subitem="Cookie" primary="true"/>
611<t>
612   When it sends a request
613   to an origin server, the user agent includes a Cookie request header
614   if it has stored cookies that are applicable to the request, based on
615  <list style="symbols">
616    <t>the request-host and request-port;</t>
617    <t>the request-URI;</t>
618    <t>the cookie's age.</t>
619  </list>
620</t>
621<figure><preamble>
622   The syntax for the header is:
623</preamble><artwork type="abnf2616">
624cookie          =  "Cookie:" cookie-version 1*((";" | ",") cookie-value)
625cookie-value    =  NAME "=" VALUE [";" path] [";" domain] [";" port]
626cookie-version  =  "$Version" "=" value
627NAME            =  attr
628VALUE           =  value
629path            =  "$Path" "=" value
630domain          =  "$Domain" "=" value
631port            =  "$Port" [ "=" &lt;"> value &lt;"> ]
632</artwork></figure>
633<t>
634   The value of the cookie-version attribute &MUST; be the value from the
635   Version attribute of the corresponding Set-Cookie2 response header.
636   Otherwise the value for cookie-version is 0.  The value for the path
637   attribute &MUST; be the value from the Path attribute, if one was
638   present, of the corresponding Set-Cookie2 response header.  Otherwise
639   the attribute &SHOULD; be omitted from the Cookie request header.  The
640   value for the domain attribute &MUST; be the value from the Domain
641   attribute, if one was present, of the corresponding Set-Cookie2
642   response header.  Otherwise the attribute &SHOULD; be omitted from the
643   Cookie request header.
644</t>
645<t>
646   The port attribute of the Cookie request header &MUST; mirror the Port
647   attribute, if one was present, in the corresponding Set-Cookie2
648   response header.  That is, the port attribute &MUST; be present if the
649   Port attribute was present in the Set-Cookie2 header, and it &MUST;
650   have the same value, if any.  Otherwise, if the Port attribute was
651   absent from the Set-Cookie2 header, the attribute likewise &MUST; be
652   omitted from the Cookie request header.
653</t>
654<t>
655   Note that there is neither a Comment nor a CommentURL attribute in
656   the Cookie request header corresponding to the ones in the Set-Cookie2
657   response header.  The user agent does not return the comment
658   information to the origin server.
659</t>
660<t>
661   The user agent applies the following rules to choose applicable
662   cookie-values to send in Cookie request headers from among all the
663   cookies it has received.
664  <list style="hanging">
665    <t hangText="Domain Selection">
666      The origin server's effective host name &MUST; domain-match the
667      Domain attribute of the cookie.
668    </t>
669   <t hangText="Port Selection">
670      There are three possible behaviors, depending on the Port
671      attribute in the Set-Cookie2 response header:
672    <list style="numbers">
673      <t>By default (no Port attribute), the cookie &MAY; be sent to any
674         port.</t>
675      <t>If the attribute is present but has no value (e.g., Port), the
676         cookie &MUST; only be sent to the request-port it was received
677         from.</t>
678      <t>If the attribute has a port-list, the cookie &MUST; only be
679         returned if the new request-port is one of those listed in
680         port-list.</t>
681      </list>
682    </t>
683    <t hangText="Path Selection">
684      The request-URI &MUST; path-match the Path attribute of the cookie.
685    </t>
686    <t hangText="Max-Age Selection">
687      Cookies that have expired should have been discarded and thus are
688      not forwarded to an origin server.
689    </t>
690  </list>
691</t>
692<t>
693   If multiple cookies satisfy the criteria above, they are ordered in
694   the Cookie header such that those with more specific Path attributes
695   precede those with less specific.  Ordering with respect to other
696   attributes (e.g., Domain) is unspecified.
697</t>
698<t>
699   Note: For backward compatibility, the separator in the Cookie header
700   is semi-colon (;) everywhere.  A server &SHOULD; also accept comma (,)
701   as the separator between cookie-values for future compatibility.
702</t>
703</section>
704
705<section title="Identifying What Version is Understood:  Cookie2">
706<iref item="Cookie2 header" primary="true"/>
707<iref item="Headers" subitem="Cookie2" primary="true"/>
708<t>
709   The Cookie2
710   request header facilitates interoperation between clients and servers
711   that understand different versions of the cookie specification.  When
712   the client sends one or more cookies to an origin server, if at least
713   one of those cookies contains a $Version attribute whose value is
714   different from the version that the client understands, then the
715   client &MUST; also send a Cookie2 request header, the syntax for which
716   is
717</t>
718<figure><artwork type="abnf2616">
719   cookie2 =       "Cookie2:" cookie-version
720</artwork></figure>
721<t>
722   Here the value for cookie-version is the highest version of cookie
723   specification (currently 1) that the client understands.  The client
724   needs to send at most one such request header per request.
725</t>
726</section>
727
728<section title="Sending Cookies in Unverifiable Transactions">
729<t>
730   Users &MUST; have
731   control over sessions in order to ensure privacy.  (See PRIVACY
732   section below.)  To simplify implementation and to prevent an
733   additional layer of complexity where adequate safeguards exist,
734   however, this document distinguishes between transactions that are
735   verifiable and those that are unverifiable.  A transaction is
736   verifiable if the user, or a user-designated agent, has the option to
737   review the request-URI prior to its use in the transaction.  A
738   transaction is unverifiable if the user does not have that option.
739   Unverifiable transactions typically arise when a user agent
740   automatically requests inlined or embedded entities or when it
741   resolves redirection (3xx) responses from an origin server.
742   Typically the origin transaction, the transaction that the user
743   initiates, is verifiable, and that transaction may directly or
744   indirectly induce the user agent to make unverifiable transactions.
745</t>
746<t>
747   An unverifiable transaction is to a third-party host if its request-host
748   U does not domain-match the reach R of the request-host O in the
749   origin transaction.
750</t>
751<t>
752   When it makes an unverifiable transaction, a user agent &MUST; disable
753   all cookie processing (i.e., &MUST-NOT; send cookies, and &MUST-NOT;
754   accept any received cookies) if the transaction is to a third-party
755   host.
756</t>
757<t>
758   This restriction prevents a malicious service author from using
759   unverifiable transactions to induce a user agent to start or continue
760   a session with a server in a different domain.  The starting or
761   continuation of such sessions could be contrary to the privacy
762   expectations of the user, and could also be a security problem.
763</t>
764<t>
765   User agents &MAY; offer configurable options that allow the user agent,
766   or any autonomous programs that the user agent executes, to ignore
767   the above rule, so long as these override options default to "off".
768</t>
769<t>
770   (N.B.  Mechanisms may be proposed that will automate overriding the
771   third-party restrictions under controlled conditions.)
772</t>
773<t>
774   Many current user agents already provide a review option that would
775   render many links verifiable.  For instance, some user agents display
776   the URL that would be referenced for a particular link when the mouse
777   pointer is placed over that link.  The user can therefore determine
778   whether to visit that site before causing the browser to do so.
779   (Though not implemented on current user agents, a similar technique
780   could be used for a button used to submit a form -- the user agent
781   could display the action to be taken if the user were to select that
782   button.)  However, even this would not make all links verifiable; for
783   example, links to automatically loaded images would not normally be
784   subject to "mouse pointer" verification.
785</t>
786<t>
787   Many user agents also provide the option for a user to view the HTML
788   source of a document, or to save the source to an external file where
789   it can be viewed by another application.  While such an option does
790   provide a crude review mechanism, some users might not consider it
791   acceptable for this purpose.
792</t>
793</section>
794</section>
795
796<section title="How an Origin Server Interprets the Cookie Header">
797<t>
798   A user agent returns much of the information in the Set-Cookie2
799   header to the origin server when the request-URI path-matches the
800   Path attribute of the cookie.  When it receives a Cookie header, the
801   origin server &SHOULD; treat cookies with NAMEs whose prefix is $
802   specially, as an attribute for the cookie.
803</t>
804</section>
805
806<section title="Caching Proxy Role">
807<t>
808   One reason for separating state information from both a URL and
809   document content is to facilitate the scaling that caching permits.
810   To support cookies, a caching proxy &MUST; obey these rules already in
811   the HTTP specification:
812  <list style="symbols">
813    <t>Honor requests from the cache, if possible, based on cache
814         validity rules.</t>
815    <t>Pass along a Cookie request header in any request that the
816         proxy must make of another server.</t>
817    <t>Return the response to the client.  Include any Set-Cookie2
818         response header.</t>
819    <t>Cache the received response subject to the control of the usual
820         headers, such as Expires,
821<figure><artwork type="example">
822   Cache-control: no-cache
823</artwork></figure>
824         and
825<figure><artwork type="example">
826   Cache-control: private
827</artwork></figure>
828         </t>
829    <t>Cache the Set-Cookie2 subject to the control of the usual
830         header,
831<figure><artwork type="example">
832   Cache-control: no-cache="set-cookie2"
833</artwork></figure>
834         (The Set-Cookie2 header should usually not be cached.)</t>
835  </list>
836</t>
837<t>
838   Proxies &MUST-NOT; introduce Set-Cookie2 (Cookie) headers of their own
839   in proxy responses (requests).
840</t>
841</section>
842</section>
843
844<section title="EXAMPLES">
845
846<section title="Example 1">
847<t>
848   Most detail of request and response headers has been omitted.  Assume
849   the user agent has no stored cookies.
850</t>
851<t>
852      1. User Agent -> Server
853</t>
854<figure><artwork type='message/http; msgtype="request"'>
855    POST /acme/login HTTP/1.1
856    [form data]
857</artwork></figure>   
858<t>
859        User identifies self via a form.
860</t>
861<t>
862      2. Server -> User Agent
863</t>
864<figure><artwork type='message/http; msgtype="response"'>
865    HTTP/1.1 200 OK
866    Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
867</artwork></figure>   
868<t>
869        Cookie reflects user's identity.
870</t>
871<t>
872      3. User Agent -> Server
873</t>
874<figure><artwork type='message/http; msgtype="request"'>
875    POST /acme/pickitem HTTP/1.1
876    Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
877    [form data]
878</artwork></figure>   
879<t>
880        User selects an item for "shopping basket".
881</t>
882<t>
883      4. Server -> User Agent
884</t>
885<figure><artwork type='message/http; msgtype="response"'>
886    HTTP/1.1 200 OK
887    Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
888            Path="/acme"
889</artwork></figure>   
890<t>
891        Shopping basket contains an item.
892</t>
893<t>
894      5. User Agent -> Server
895</t>
896<figure><artwork type='message/http; msgtype="request"'>
897    POST /acme/shipping HTTP/1.1
898    Cookie: $Version="1";
899            Customer="WILE_E_COYOTE"; $Path="/acme";
900            Part_Number="Rocket_Launcher_0001"; $Path="/acme"
901    [form data]
902</artwork></figure>   
903<t>
904        User selects shipping method from form.
905</t>
906<t>
907      6. Server -> User Agent
908</t>
909<figure><artwork type='message/http; msgtype="response"'>
910    HTTP/1.1 200 OK
911    Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme"
912</artwork></figure>   
913<t>
914        New cookie reflects shipping method.
915</t>
916<t>
917      7. User Agent -> Server
918</t>
919<figure><artwork type='message/http; msgtype="request"'>
920    POST /acme/process HTTP/1.1
921    Cookie: $Version="1";
922            Customer="WILE_E_COYOTE"; $Path="/acme";
923            Part_Number="Rocket_Launcher_0001"; $Path="/acme";
924            Shipping="FedEx"; $Path="/acme"
925    [form data]
926</artwork></figure>   
927<t>
928        User chooses to process order.
929</t>
930<t>
931      8. Server -> User Agent
932</t>
933<figure><artwork type='message/http; msgtype="response"'>
934    HTTP/1.1 200 OK
935</artwork></figure>   
936<t>
937        Transaction is complete.
938</t>
939<t>
940   The user agent makes a series of requests on the origin server, after
941   each of which it receives a new cookie.  All the cookies have the
942   same Path attribute and (default) domain.  Because the request-URIs
943   all path-match /acme, the Path attribute of each cookie, each request
944   contains all the cookies received so far.
945</t>
946</section>
947
948<section title="Example 2">
949<t>
950   This example illustrates the effect of the Path attribute.  All
951   detail of request and response headers has been omitted.  Assume the
952   user agent has no stored cookies.
953</t>
954<t>
955   Imagine the user agent has received, in response to earlier requests,
956   the response headers
957</t>
958<figure><artwork type="example">
959   Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
960           Path="/acme"
961</artwork></figure>   
962<t>
963   and
964</t>
965<figure><artwork type="example">
966   Set-Cookie2: Part_Number="Riding_Rocket_0023"; Version="1";
967           Path="/acme/ammo"
968</artwork></figure>   
969<t>
970   A subsequent request by the user agent to the (same) server for URLs
971   of the form /acme/ammo/...  would include the following request
972   header:
973</t>
974<figure><artwork type="example">
975   Cookie: $Version="1";
976           Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
977           Part_Number="Rocket_Launcher_0001"; $Path="/acme"
978</artwork></figure>   
979<t>
980   Note that the NAME=VALUE pair for the cookie with the more specific
981   Path attribute, /acme/ammo, comes before the one with the less
982   specific Path attribute, /acme.  Further note that the same cookie
983   name appears more than once.
984</t>
985<t>
986   A subsequent request by the user agent to the (same) server for a URL
987   of the form /acme/parts/ would include the following request header:
988</t>
989<figure><artwork type="example">
990   Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001";
991   $Path="/acme"
992</artwork></figure>   
993<t>
994   Here, the second cookie's Path attribute /acme/ammo is not a prefix
995   of the request URL, /acme/parts/, so the cookie does not get
996   forwarded to the server.
997</t>
998</section>
999</section>
1000
1001<section title="IMPLEMENTATION CONSIDERATIONS">
1002<t>
1003   Here we provide guidance on likely or desirable details for an origin
1004   server that implements state management.
1005</t>
1006
1007<section title="Set-Cookie2 Content">
1008<t>
1009   An origin server's content should probably be divided into disjoint
1010   application areas, some of which require the use of state
1011   information.  The application areas can be distinguished by their
1012   request URLs.  The Set-Cookie2 header can incorporate information
1013   about the application areas by setting the Path attribute for each
1014   one.
1015</t>
1016<t>
1017   The session information can obviously be clear or encoded text that
1018   describes state.  However, if it grows too large, it can become
1019   unwieldy.  Therefore, an implementor might choose for the session
1020   information to be a key to a server-side resource.  Of course, using
1021   a database creates some problems that this state management
1022   specification was meant to avoid, namely:
1023  <list style="numbers">
1024    <t>keeping real state on the server side;</t>
1025    <t>how and when to garbage-collect the database entry, in case the
1026         user agent terminates the session by, for example, exiting.</t>
1027  </list>
1028</t>
1029</section>
1030
1031<section title="Stateless Pages">
1032<t>
1033   Caching benefits the scalability of WWW.  Therefore it is important
1034   to reduce the number of documents that have state embedded in them
1035   inherently.  For example, if a shopping-basket-style application
1036   always displays a user's current basket contents on each page, those
1037   pages cannot be cached, because each user's basket's contents would
1038   be different.  On the other hand, if each page contains just a link
1039   that allows the user to "Look at My Shopping Basket", the page can be
1040   cached.
1041</t>
1042</section>
1043
1044<section title="Implementation Limits">
1045<t>
1046   Practical user agent implementations have limits on the number and
1047   size of cookies that they can store.  In general, user agents' cookie
1048   support should have no fixed limits.  They should strive to store as
1049   many frequently-used cookies as possible.  Furthermore, general-use
1050   user agents &SHOULD; provide each of the following minimum capabilities
1051   individually, although not necessarily simultaneously:
1052  <list style="symbols">
1053    <t>at least 300 cookies</t>
1054    <t>at least 4096 bytes per cookie (as measured by the characters
1055         that comprise the cookie non-terminal in the syntax description
1056         of the Set-Cookie2 header, and as received in the Set-Cookie2
1057         header)</t>
1058    <t>at least 20 cookies per unique host or domain name</t>
1059  </list>
1060</t>
1061<t>
1062   User agents created for specific purposes or for limited-capacity
1063   devices &SHOULD; provide at least 20 cookies of 4096 bytes, to ensure
1064   that the user can interact with a session-based origin server.
1065</t>
1066<t>
1067   The information in a Set-Cookie2 response header &MUST; be retained in
1068   its entirety.  If for some reason there is inadequate space to store
1069   the cookie, it &MUST; be discarded, not truncated.
1070</t>
1071<t>
1072   Applications should use as few and as small cookies as possible, and
1073   they should cope gracefully with the loss of a cookie.
1074</t>
1075
1076<section title="Denial of Service Attacks">
1077<t>
1078   User agents &MAY; choose to set an
1079   upper bound on the number of cookies to be stored from a given host
1080   or domain name or on the size of the cookie information.  Otherwise a
1081   malicious server could attempt to flood a user agent with many
1082   cookies, or large cookies, on successive responses, which would force
1083   out cookies the user agent had received from other servers.  However,
1084   the minima specified above &SHOULD; still be supported.
1085</t>
1086</section>
1087</section>
1088</section>
1089
1090<section title="PRIVACY">
1091<t>
1092   Informed consent should guide the design of systems that use cookies.
1093   A user should be able to find out how a web site plans to use
1094   information in a cookie and should be able to choose whether or not
1095   those policies are acceptable.  Both the user agent and the origin
1096   server must assist informed consent.
1097</t>
1098
1099<section title="User Agent Control">
1100<t>
1101   An origin server could create a Set-Cookie2 header to track the path
1102   of a user through the server.  Users may object to this behavior as
1103   an intrusive accumulation of information, even if their identity is
1104   not evident.  (Identity might become evident, for example, if a user
1105   subsequently fills out a form that contains identifying information.)
1106   This state management specification therefore requires that a user
1107   agent give the user control over such a possible intrusion, although
1108   the interface through which the user is given this control is left
1109   unspecified.  However, the control mechanisms provided &SHALL; at least
1110   allow the user
1111  <list style="symbols">
1112    <t>to completely disable the sending and saving of cookies.</t>
1113    <t>to determine whether a stateful session is in progress.</t>
1114    <t>to control the saving of a cookie on the basis of the cookie's
1115         Domain attribute.</t>
1116  </list>
1117</t>
1118<t>
1119   Such control could be provided, for example, by mechanisms
1120  <list style="symbols">
1121    <t>to notify the user when the user agent is about to send a
1122         cookie to the origin server, to offer the option not to begin a
1123         session.</t>
1124    <t>to display a visual indication that a stateful session is in
1125         progress.</t>
1126    <t>to let the user decide which cookies, if any, should be saved
1127         when the user concludes a window or user agent session.</t>
1128    <t>to let the user examine and delete the contents of a cookie at
1129         any time.</t>
1130  </list>
1131</t>
1132<t>
1133   A user agent usually begins execution with no remembered state
1134   information.  It &SHOULD; be possible to configure a user agent never
1135   to send Cookie headers, in which case it can never sustain state with
1136   an origin server.  (The user agent would then behave like one that is
1137   unaware of how to handle Set-Cookie2 response headers.)
1138</t>
1139<t>
1140   When the user agent terminates execution, it &SHOULD; let the user
1141   discard all state information.  Alternatively, the user agent &MAY; ask
1142   the user whether state information should be retained; the default
1143   should be "no".  If the user chooses to retain state information, it
1144   would be restored the next time the user agent runs.
1145</t>
1146<t>
1147   NOTE: User agents should probably be cautious about using files to
1148   store cookies long-term.  If a user runs more than one instance of
1149   the user agent, the cookies could be commingled or otherwise
1150   corrupted.
1151</t>
1152</section>
1153
1154<section title="Origin Server Role">
1155<t>
1156   An origin server &SHOULD; promote informed consent by adding CommentURL
1157   or Comment information to the cookies it sends.  CommentURL is
1158   preferred because of the opportunity to provide richer information in
1159   a multiplicity of languages.
1160</t>
1161</section>
1162
1163<section title="Clear Text">
1164<t>
1165   The information in the Set-Cookie2 and Cookie headers is unprotected.
1166   As a consequence:
1167  <list style="numbers">
1168    <t>Any sensitive information that is conveyed in them is exposed
1169         to intruders.</t>
1170    <t>A malicious intermediary could alter the headers as they travel
1171         in either direction, with unpredictable results.</t>
1172  </list>
1173</t>
1174<t>
1175   These facts imply that information of a personal and/or financial
1176   nature should only be sent over a secure channel.  For less sensitive
1177   information, or when the content of the header is a database key, an
1178   origin server should be vigilant to prevent a bad Cookie value from
1179   causing failures.
1180</t>
1181<t>
1182   A user agent in a shared user environment poses a further risk.
1183   Using a cookie inspection interface, User B could examine the
1184   contents of cookies that were saved when User A used the machine.
1185</t>
1186</section>
1187</section>
1188
1189<section title="SECURITY CONSIDERATIONS">
1190
1191<section title="Protocol Design">
1192<t>
1193   The restrictions on the value of the Domain attribute, and the rules
1194   concerning unverifiable transactions, are meant to reduce the ways
1195   that cookies can "leak" to the "wrong" site.  The intent is to
1196   restrict cookies to one host, or a closely related set of hosts.
1197   Therefore a request-host is limited as to what values it can set for
1198   Domain.  We consider it acceptable for hosts host1.foo.com and
1199   host2.foo.com to share cookies, but not a.com and b.com.
1200</t>
1201<t>
1202   Similarly, a server can set a Path only for cookies that are related
1203   to the request-URI.
1204</t>
1205</section>
1206
1207<section title="Cookie Spoofing">
1208<t>
1209   Proper application design can avoid spoofing attacks from related
1210   domains.  Consider:
1211  <list style="numbers">
1212     <t>User agent makes request to victim.cracker.edu, gets back
1213         cookie session_id="1234" and sets the default domain
1214         victim.cracker.edu.</t>
1215
1216     <t>User agent makes request to spoof.cracker.edu, gets back cookie
1217         session-id="1111", with Domain=".cracker.edu".</t>
1218
1219     <t>User agent makes request to victim.cracker.edu again, and
1220         passes
1221<figure><artwork type="example">
1222     Cookie: $Version="1"; session_id="1234",
1223             $Version="1"; session_id="1111"; $Domain=".cracker.edu"
1224</artwork></figure>
1225         The server at victim.cracker.edu should detect that the second
1226         cookie was not one it originated by noticing that the Domain
1227         attribute is not for itself and ignore it.</t>
1228  </list>
1229</t>
1230</section>
1231
1232<section title="Unexpected Cookie Sharing">
1233<t>
1234   A user agent &SHOULD; make every attempt to prevent the sharing of
1235   session information between hosts that are in different domains.
1236   Embedded or inlined objects may cause particularly severe privacy
1237   problems if they can be used to share cookies between disparate
1238   hosts.  For example, a malicious server could embed cookie
1239   information for host a.com in a URI for a CGI on host b.com.  User
1240   agent implementors are strongly encouraged to prevent this sort of
1241   exchange whenever possible.
1242</t>
1243</section>
1244
1245<section title="Cookies For Account Information">
1246<t>
1247   While it is common practice to use them this way, cookies are not
1248   designed or intended to be used to hold authentication information,
1249   such as account names and passwords.  Unless such cookies are
1250   exchanged over an encrypted path, the account information they
1251   contain is highly vulnerable to perusal and theft.
1252</t>
1253</section>   
1254</section>
1255
1256<section title="OTHER, SIMILAR, PROPOSALS">
1257<t>
1258   Apart from RFC 2109, three other proposals have been made to
1259   accomplish similar goals.  This specification began as an amalgam of
1260   Kristol's State-Info proposal <xref target="DMK95"/> and Netscape's Cookie proposal
1261   <xref target="Netscape"/>.
1262</t>
1263<t>
1264   Brian Behlendorf proposed a Session-ID header that would be user-agent-initiated
1265   and could be used by an origin server to track
1266   "clicktrails".  It would not carry any origin-server-defined state,
1267   however.  Phillip Hallam-Baker has proposed another client-defined
1268   session ID mechanism for similar purposes.
1269</t>
1270<t>
1271   While both session IDs and cookies can provide a way to sustain
1272   stateful sessions, their intended purpose is different, and,
1273   consequently, the privacy requirements for them are different.  A
1274   user initiates session IDs to allow servers to track progress through
1275   them, or to distinguish multiple users on a shared machine.  Cookies
1276   are server-initiated, so the cookie mechanism described here gives
1277   users control over something that would otherwise take place without
1278   the users' awareness.  Furthermore, cookies convey rich, server-selected
1279   information, whereas session IDs comprise user-selected,
1280   simple information.
1281</t>
1282</section>
1283
1284<section title="HISTORICAL">
1285
1286<section title="Compatibility with Existing Implementations">
1287<t>
1288   Existing cookie implementations, based on the Netscape specification,
1289   use the Set-Cookie (not Set-Cookie2) header.  User agents that
1290   receive in the same response both a Set-Cookie and Set-Cookie2
1291   response header for the same cookie &MUST; discard the Set-Cookie
1292   information and use only the Set-Cookie2 information.  Furthermore, a
1293   user agent &MUST; assume, if it received a Set-Cookie2 response header,
1294   that the sending server complies with this document and will
1295   understand Cookie request headers that also follow this
1296   specification.
1297</t>
1298<t>
1299   New cookies &MUST; replace both equivalent old- and new-style cookies.
1300   That is, if a user agent that follows both this specification and
1301   Netscape's original specification receives a Set-Cookie2 response
1302   header, and the NAME and the Domain and Path attributes match (per
1303   the Cookie Management section) a Netscape-style cookie, the
1304   Netscape-style cookie &MUST; be discarded, and the user agent &MUST;
1305   retain only the cookie adhering to this specification.
1306</t>
1307<t>
1308   Older user agents that do not understand this specification, but that
1309   do understand Netscape's original specification, will not recognize
1310   the Set-Cookie2 response header and will receive and send cookies
1311   according to the older specification.
1312</t>
1313<t>
1314   A user agent that supports both this specification and Netscape-style
1315   cookies &SHOULD; send a Cookie request header that follows the older
1316   Netscape specification if it received the cookie in a Set-Cookie
1317   response header and not in a Set-Cookie2 response header.  However,
1318   it &SHOULD; send the following request header as well:
1319</t>
1320<figure><artwork type="example">
1321   Cookie2: $Version="1"
1322</artwork></figure>
1323<t>
1324   The Cookie2 header advises the server that the user agent understands
1325   new-style cookies.  If the server understands new-style cookies, as
1326   well, it &SHOULD; continue the stateful session by sending a Set-Cookie2
1327   response header, rather than Set-Cookie.  A server that does
1328   not understand new-style cookies will simply ignore the Cookie2
1329   request header.
1330</t>
1331</section>
1332
1333<section title="Caching and HTTP/1.0">
1334<t>
1335   Some caches, such as those conforming to HTTP/1.0, will inevitably
1336   cache the Set-Cookie2 and Set-Cookie headers, because there was no
1337   mechanism to suppress caching of headers prior to HTTP/1.1.  This
1338   caching can lead to security problems.  Documents transmitted by an
1339   origin server along with Set-Cookie2 and Set-Cookie headers usually
1340   either will be uncachable, or will be "pre-expired".  As long as
1341   caches obey instructions not to cache documents (following Expires:
1342   &lt;a date in the past> or Pragma: no-cache (HTTP/1.0), or Cache-control:  no-cache
1343   (HTTP/1.1)) uncachable documents present no
1344   problem.  However, pre-expired documents may be stored in caches.
1345   They require validation (a conditional GET) on each new request, but
1346   some cache operators loosen the rules for their caches, and sometimes
1347   serve expired documents without first validating them.  This
1348   combination of factors can lead to cookies meant for one user later
1349   being sent to another user.  The Set-Cookie2 and Set-Cookie headers
1350   are stored in the cache, and, although the document is stale
1351   (expired), the cache returns the document in response to later
1352   requests, including cached headers.
1353</t>
1354</section>
1355</section>
1356
1357<section title="ACKNOWLEDGEMENTS">
1358<t>
1359   This document really represents the collective efforts of the HTTP
1360   Working Group of the IETF and, particularly, the following people, in
1361   addition to the authors: Roy Fielding, Yaron Goland, Marc Hedlund,
1362   Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare, Foteos Macrides,
1363   David W. Morris.
1364</t>
1365</section>
1366
1367</middle>
1368<back>
1369
1370<references>
1371
1372  <reference anchor="DMK95" target="http://portal.research.bell-labs.com/~dmk/state-info.html">
1373    <front>
1374      <title>Proposed HTTP State-Info Mechanism</title>
1375      <author initials='D. M.' surname='Kristol' fullname='David M. Kristol'>
1376        <organization/>
1377      </author>
1378      <date year="1995" month="September"/>
1379    </front>
1380    <annotation>available at &lt;http://portal.research.bell-labs.com/~dmk/state-info.html></annotation>
1381  </reference>
1382 
1383  <reference anchor="Netscape" target="http://www.netscape.com/newsref/std/cookie_spec.html">
1384    <front>
1385      <title>Persistent Client State -- HTTP Cookies</title>
1386      <author>
1387        <organization/>
1388      </author>
1389      <date/>
1390    </front>
1391    <annotation>available at &lt;http://www.netscape.com/newsref/std/cookie_spec.html></annotation>
1392  </reference>
1393
1394    <reference anchor='RFC2109'>
1395      <front>
1396        <title>HTTP State Management Mechanism</title>
1397        <author initials='D.M.' surname='Kristol' fullname='David M. Kristol'>
1398        <organization>Bell Laboratories, Lucent Technologies</organization>
1399        <address>
1400        <postal>
1401        <street>600 Mountain Ave.  Room 2A-227</street>
1402        <street>Murray Hill</street>
1403        <street>NJ  07974</street></postal>
1404       
1405        <phone>(908) 582-2250</phone>
1406        <facsimile>(908) 582-5809</facsimile>
1407        <email>dmk@bell-labs.com</email></address></author>
1408        <author initials='L.' surname='Montulli' fullname='Lou Montulli'>
1409        <organization>Netscape Communications Corp.</organization>
1410        <address>
1411        <postal>
1412        <street>501 E. Middlefield Rd.</street>
1413        <street>Mountain View</street>
1414        <street>CA  94043</street></postal>
1415       
1416        <phone>(415) 528-2600</phone>
1417        <email>montulli@netscape.com</email></address>
1418        </author>
1419        <date year='1997' month='February' />
1420      </front>     
1421      <seriesInfo name='RFC' value='2109' />
1422    </reference>
1423
1424    <reference anchor="RFC2119">
1425      <front>
1426        <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
1427        <author initials="S." surname="Bradner" fullname="Scott Bradner">
1428        <organization>Harvard University</organization>
1429        <address>
1430          <email>sob@harvard.edu</email>
1431        </address></author>
1432        <date month="March" year="1997"/>
1433      </front>
1434      <seriesInfo name="BCP" value="14"/>
1435      <seriesInfo name="RFC" value="2119"/>
1436    </reference>
1437 
1438    <reference anchor="RFC2279">
1439      <front>
1440        <title>UTF-8, a transformation format of ISO 10646</title>
1441        <author initials="F." surname="Yergeau" fullname="F. Yergeau">
1442          <organization>Alis Technologies</organization>
1443          <address><email>fyergeau@alis.com</email></address>
1444        </author>
1445        <date month="January" year="1998"/>
1446      </front>
1447      <seriesInfo name="RFC" value="2279"/>
1448    </reference>
1449
1450    <reference anchor="RFC2396">
1451      <front>
1452        <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
1453        <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1454          <organization>World Wide Web Consortium</organization>
1455          <address>
1456            <email>timbl@w3.org</email>
1457          </address>
1458        </author>
1459        <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
1460          <organization>Department of Information and Computer Science</organization>
1461          <address>
1462            <email>fielding@ics.uci.edu</email>
1463          </address>
1464        </author>
1465        <author initials="L." surname="Masinter" fullname="Larry Masinter">
1466          <organization>Xerox PARC</organization>
1467          <address>
1468            <email>masinter@parc.xerox.com</email>
1469          </address>
1470        </author>
1471        <date month="August" year="1998"/>
1472      </front> 
1473      <seriesInfo name="RFC" value="2396"/>
1474    </reference>
1475
1476    <reference anchor="RFC2616">
1477      <front>
1478        <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1479        <author initials="R." surname="Fielding" fullname="R. Fielding">
1480          <organization>University of California, Irvine</organization>
1481          <address><email>fielding@ics.uci.edu</email></address>
1482        </author>
1483        <author initials="J." surname="Gettys" fullname="J. Gettys">
1484          <organization>W3C</organization>
1485          <address><email>jg@w3.org</email></address>
1486        </author>
1487        <author initials="J." surname="Mogul" fullname="J. Mogul">
1488          <organization>Compaq Computer Corporation</organization>
1489          <address><email>mogul@wrl.dec.com</email></address>
1490        </author>
1491        <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1492          <organization>MIT Laboratory for Computer Science</organization>
1493          <address><email>frystyk@w3.org</email></address>
1494        </author>
1495        <author initials="L." surname="Masinter" fullname="L. Masinter">
1496          <organization>Xerox Corporation</organization>
1497          <address><email>masinter@parc.xerox.com</email></address>
1498        </author>
1499        <author initials="P." surname="Leach" fullname="P. Leach">
1500          <organization>Microsoft Corporation</organization>
1501          <address><email>paulle@microsoft.com</email></address>
1502        </author>
1503        <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1504          <organization>W3C</organization>
1505          <address><email>timbl@w3.org</email></address>
1506        </author>
1507        <date month="June" year="1999"/>
1508      </front>
1509      <seriesInfo name="RFC" value="2616"/>
1510    </reference>
1511  </references>
1512
1513</back>
1514</rfc>
Note: See TracBrowser for help on using the repository browser.