source: draft-ietf-httpbis/latest/p8-cookies.xml @ 302

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

Partition RFC 2616 into seven (mostly) independent documents.
No semantic changes. Some meaningless crossreferences to prior
editorial decisions have been removed from appendices.

Structural changes minimized to simplify diff versus rfc2616.
This was a lot harder than it looks.

Part 8 (Cookies) is for future specification based on RFC 2965.

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