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

Last change on this file since 11 was 10, checked in by fielding@…, 12 years ago

RFC 2965: HTTP State Management Mechanism

Translated from text to XML by Julian Reschke.

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