Attachment 'rfc2109.txt'
Download 1 Network Working Group D. Kristol
2 Request for Comments: 2109 Bell Laboratories, Lucent Technologies
3 Category: Standards Track L. Montulli
4 Netscape Communications
5 February 1997
6
7
8 HTTP State Management Mechanism
9
10 Status of this Memo
11
12 This document specifies an Internet standards track protocol for the
13 Internet community, and requests discussion and suggestions for
14 improvements. Please refer to the current edition of the "Internet
15 Official Protocol Standards" (STD 1) for the standardization state
16 and status of this protocol. Distribution of this memo is unlimited.
17
18 1. ABSTRACT
19
20 This document specifies a way to create a stateful session with HTTP
21 requests and responses. It describes two new headers, Cookie and
22 Set-Cookie, which carry state information between participating
23 origin servers and user agents. The method described here differs
24 from Netscape's Cookie proposal, but it can interoperate with
25 HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL
26 section.)
27
28 2. TERMINOLOGY
29
30 The terms user agent, client, server, proxy, and origin server have
31 the same meaning as in the HTTP/1.0 specification.
32
33 Fully-qualified host name (FQHN) means either the fully-qualified
34 domain name (FQDN) of a host (i.e., a completely specified domain
35 name ending in a top-level domain such as .com or .uk), or the
36 numeric Internet Protocol (IP) address of a host. The fully
37 qualified domain name is preferred; use of numeric IP addresses is
38 strongly discouraged.
39
40 The terms request-host and request-URI refer to the values the client
41 would send to the server as, respectively, the host (but not port)
42 and abs_path portions of the absoluteURI (http_URL) of the HTTP
43 request line. Note that request-host must be a FQHN.
44
45
46
47
48
49
50
51
52 Kristol & Montulli Standards Track [Page 1]
53
54 RFC 2109 HTTP State Management Mechanism February 1997
55
56
57 Hosts names can be specified either as an IP address or a FQHN
58 string. Sometimes we compare one host name with another. Host A's
59 name domain-matches host B's if
60
61 * both host names are IP addresses and their host name strings match
62 exactly; or
63
64 * both host names are FQDN strings and their host name strings match
65 exactly; or
66
67 * A is a FQDN string and has the form NB, where N is a non-empty name
68 string, B has the form .B', and B' is a FQDN string. (So, x.y.com
69 domain-matches .y.com but not y.com.)
70
71 Note that domain-match is not a commutative operation: a.b.c.com
72 domain-matches .c.com, but not the reverse.
73
74 Because it was used in Netscape's original implementation of state
75 management, we will use the term cookie to refer to the state
76 information that passes between an origin server and user agent, and
77 that gets stored by the user agent.
78
79 3. STATE AND SESSIONS
80
81 This document describes a way to create stateful sessions with HTTP
82 requests and responses. Currently, HTTP servers respond to each
83 client request without relating that request to previous or
84 subsequent requests; the technique allows clients and servers that
85 wish to exchange state information to place HTTP requests and
86 responses within a larger context, which we term a "session". This
87 context might be used to create, for example, a "shopping cart", in
88 which user selections can be aggregated before purchase, or a
89 magazine browsing system, in which a user's previous reading affects
90 which offerings are presented.
91
92 There are, of course, many different potential contexts and thus many
93 different potential types of session. The designers' paradigm for
94 sessions created by the exchange of cookies has these key attributes:
95
96 1. Each session has a beginning and an end.
97
98 2. Each session is relatively short-lived.
99
100 3. Either the user agent or the origin server may terminate a
101 session.
102
103 4. The session is implicit in the exchange of state information.
104
105
106
107
108 Kristol & Montulli Standards Track [Page 2]
109
110 RFC 2109 HTTP State Management Mechanism February 1997
111
112
113 4. OUTLINE
114
115 We outline here a way for an origin server to send state information
116 to the user agent, and for the user agent to return the state
117 information to the origin server. The goal is to have a minimal
118 impact on HTTP and user agents. Only origin servers that need to
119 maintain sessions would suffer any significant impact, and that
120 impact can largely be confined to Common Gateway Interface (CGI)
121 programs, unless the server provides more sophisticated state
122 management support. (See Implementation Considerations, below.)
123
124 4.1 Syntax: General
125
126 The two state management headers, Set-Cookie and Cookie, have common
127 syntactic properties involving attribute-value pairs. The following
128 grammar uses the notation, and tokens DIGIT (decimal digits) and
129 token (informally, a sequence of non-special, non-white space
130 characters) from the HTTP/1.1 specification [RFC 2068] to describe
131 their syntax.
132
133 av-pairs = av-pair *(";" av-pair)
134 av-pair = attr ["=" value] ; optional value
135 attr = token
136 value = word
137 word = token | quoted-string
138
139 Attributes (names) (attr) are case-insensitive. White space is
140 permitted between tokens. Note that while the above syntax
141 description shows value as optional, most attrs require them.
142
143 NOTE: The syntax above allows whitespace between the attribute and
144 the = sign.
145
146 4.2 Origin Server Role
147
148 4.2.1 General
149
150 The origin server initiates a session, if it so desires. (Note that
151 "session" here does not refer to a persistent network connection but
152 to a logical session created from HTTP requests and responses. The
153 presence or absence of a persistent connection should have no effect
154 on the use of cookie-derived sessions). To initiate a session, the
155 origin server returns an extra response header to the client, Set-
156 Cookie. (The details follow later.)
157
158 A user agent returns a Cookie request header (see below) to the
159 origin server if it chooses to continue a session. The origin server
160 may ignore it or use it to determine the current state of the
161
162
163
164 Kristol & Montulli Standards Track [Page 3]
165
166 RFC 2109 HTTP State Management Mechanism February 1997
167
168
169 session. It may send back to the client a Set-Cookie response header
170 with the same or different information, or it may send no Set-Cookie
171 header at all. The origin server effectively ends a session by
172 sending the client a Set-Cookie header with Max-Age=0.
173
174 Servers may return a Set-Cookie response headers with any response.
175 User agents should send Cookie request headers, subject to other
176 rules detailed below, with every request.
177
178 An origin server may include multiple Set-Cookie headers in a
179 response. Note that an intervening gateway could fold multiple such
180 headers into a single header.
181
182 4.2.2 Set-Cookie Syntax
183
184 The syntax for the Set-Cookie response header is
185
186 set-cookie = "Set-Cookie:" cookies
187 cookies = 1#cookie
188 cookie = NAME "=" VALUE *(";" cookie-av)
189 NAME = attr
190 VALUE = value
191 cookie-av = "Comment" "=" value
192 | "Domain" "=" value
193 | "Max-Age" "=" value
194 | "Path" "=" value
195 | "Secure"
196 | "Version" "=" 1*DIGIT
197
198 Informally, the Set-Cookie response header comprises the token Set-
199 Cookie:, followed by a comma-separated list of one or more cookies.
200 Each cookie begins with a NAME=VALUE pair, followed by zero or more
201 semi-colon-separated attribute-value pairs. The syntax for
202 attribute-value pairs was shown earlier. The specific attributes and
203 the semantics of their values follows. The NAME=VALUE attribute-
204 value pair must come first in each cookie. The others, if present,
205 can occur in any order. If an attribute appears more than once in a
206 cookie, the behavior is undefined.
207
208 NAME=VALUE
209 Required. The name of the state information ("cookie") is NAME,
210 and its value is VALUE. NAMEs that begin with $ are reserved for
211 other uses and must not be used by applications.
212
213
214
215
216
217
218
219
220 Kristol & Montulli Standards Track [Page 4]
221
222 RFC 2109 HTTP State Management Mechanism February 1997
223
224
225 The VALUE is opaque to the user agent and may be anything the
226 origin server chooses to send, possibly in a server-selected
227 printable ASCII encoding. "Opaque" implies that the content is of
228 interest and relevance only to the origin server. The content
229 may, in fact, be readable by anyone that examines the Set-Cookie
230 header.
231
232 Comment=comment
233 Optional. Because cookies can contain private information about a
234 user, the Cookie attribute allows an origin server to document its
235 intended use of a cookie. The user can inspect the information to
236 decide whether to initiate or continue a session with this cookie.
237
238 Domain=domain
239 Optional. The Domain attribute specifies the domain for which the
240 cookie is valid. An explicitly specified domain must always start
241 with a dot.
242
243 Max-Age=delta-seconds
244 Optional. The Max-Age attribute defines the lifetime of the
245 cookie, in seconds. The delta-seconds value is a decimal non-
246 negative integer. After delta-seconds seconds elapse, the client
247 should discard the cookie. A value of zero means the cookie
248 should be discarded immediately.
249
250 Path=path
251 Optional. The Path attribute specifies the subset of URLs to
252 which this cookie applies.
253
254 Secure
255 Optional. The Secure attribute (with no value) directs the user
256 agent to use only (unspecified) secure means to contact the origin
257 server whenever it sends back this cookie.
258
259 The user agent (possibly under the user's control) may determine
260 what level of security it considers appropriate for "secure"
261 cookies. The Secure attribute should be considered security
262 advice from the server to the user agent, indicating that it is in
263 the session's interest to protect the cookie contents.
264
265 Version=version
266 Required. The Version attribute, a decimal integer, identifies to
267 which version of the state management specification the cookie
268 conforms. For this specification, Version=1 applies.
269
270
271
272
273
274
275
276 Kristol & Montulli Standards Track [Page 5]
277
278 RFC 2109 HTTP State Management Mechanism February 1997
279
280
281 4.2.3 Controlling Caching
282
283 An origin server must be cognizant of the effect of possible caching
284 of both the returned resource and the Set-Cookie header. Caching
285 "public" documents is desirable. For example, if the origin server
286 wants to use a public document such as a "front door" page as a
287 sentinel to indicate the beginning of a session for which a Set-
288 Cookie response header must be generated, the page should be stored
289 in caches "pre-expired" so that the origin server will see further
290 requests. "Private documents", for example those that contain
291 information strictly private to a session, should not be cached in
292 shared caches.
293
294 If the cookie is intended for use by a single user, the Set-cookie
295 header should not be cached. A Set-cookie header that is intended to
296 be shared by multiple users may be cached.
297
298 The origin server should send the following additional HTTP/1.1
299 response headers, depending on circumstances:
300
301 * To suppress caching of the Set-Cookie header: Cache-control: no-
302 cache="set-cookie".
303
304 and one of the following:
305
306 * To suppress caching of a private document in shared caches: Cache-
307 control: private.
308
309 * To allow caching of a document and require that it be validated
310 before returning it to the client: Cache-control: must-revalidate.
311
312 * To allow caching of a document, but to require that proxy caches
313 (not user agent caches) validate it before returning it to the
314 client: Cache-control: proxy-revalidate.
315
316 * To allow caching of a document and request that it be validated
317 before returning it to the client (by "pre-expiring" it):
318 Cache-control: max-age=0. Not all caches will revalidate the
319 document in every case.
320
321 HTTP/1.1 servers must send Expires: old-date (where old-date is a
322 date long in the past) on responses containing Set-Cookie response
323 headers unless they know for certain (by out of band means) that
324 there are no downsteam HTTP/1.0 proxies. HTTP/1.1 servers may send
325 other Cache-Control directives that permit caching by HTTP/1.1
326 proxies in addition to the Expires: old-date directive; the Cache-
327 Control directive will override the Expires: old-date for HTTP/1.1
328 proxies.
329
330
331
332 Kristol & Montulli Standards Track [Page 6]
333
334 RFC 2109 HTTP State Management Mechanism February 1997
335
336
337 4.3 User Agent Role
338
339 4.3.1 Interpreting Set-Cookie
340
341 The user agent keeps separate track of state information that arrives
342 via Set-Cookie response headers from each origin server (as
343 distinguished by name or IP address and port). The user agent
344 applies these defaults for optional attributes that are missing:
345
346 VersionDefaults to "old cookie" behavior as originally specified by
347 Netscape. See the HISTORICAL section.
348
349 Domain Defaults to the request-host. (Note that there is no dot at
350 the beginning of request-host.)
351
352 Max-AgeThe default behavior is to discard the cookie when the user
353 agent exits.
354
355 Path Defaults to the path of the request URL that generated the
356 Set-Cookie response, up to, but not including, the
357 right-most /.
358
359 Secure If absent, the user agent may send the cookie over an
360 insecure channel.
361
362 4.3.2 Rejecting Cookies
363
364 To prevent possible security or privacy violations, a user agent
365 rejects a cookie (shall not store its information) if any of the
366 following is true:
367
368 * The value for the Path attribute is not a prefix of the request-
369 URI.
370
371 * The value for the Domain attribute contains no embedded dots or
372 does not start with a dot.
373
374 * The value for the request-host does not domain-match the Domain
375 attribute.
376
377 * The request-host is a FQDN (not IP address) and has the form HD,
378 where D is the value of the Domain attribute, and H is a string
379 that contains one or more dots.
380
381 Examples:
382
383 * A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
384 would be rejected, because H is y.x and contains a dot.
385
386
387
388 Kristol & Montulli Standards Track [Page 7]
389
390 RFC 2109 HTTP State Management Mechanism February 1997
391
392
393 * A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
394 be accepted.
395
396 * A Set-Cookie with Domain=.com or Domain=.com., will always be
397 rejected, because there is no embedded dot.
398
399 * A Set-Cookie with Domain=ajax.com will be rejected because the
400 value for Domain does not begin with a dot.
401
402 4.3.3 Cookie Management
403
404 If a user agent receives a Set-Cookie response header whose NAME is
405 the same as a pre-existing cookie, and whose Domain and Path
406 attribute values exactly (string) match those of a pre-existing
407 cookie, the new cookie supersedes the old. However, if the Set-
408 Cookie has a value for Max-Age of zero, the (old and new) cookie is
409 discarded. Otherwise cookies accumulate until they expire (resources
410 permitting), at which time they are discarded.
411
412 Because user agents have finite space in which to store cookies, they
413 may also discard older cookies to make space for newer ones, using,
414 for example, a least-recently-used algorithm, along with constraints
415 on the maximum number of cookies that each origin server may set.
416
417 If a Set-Cookie response header includes a Comment attribute, the
418 user agent should store that information in a human-readable form
419 with the cookie and should display the comment text as part of a
420 cookie inspection user interface.
421
422 User agents should allow the user to control cookie destruction. An
423 infrequently-used cookie may function as a "preferences file" for
424 network applications, and a user may wish to keep it even if it is
425 the least-recently-used cookie. One possible implementation would be
426 an interface that allows the permanent storage of a cookie through a
427 checkbox (or, conversely, its immediate destruction).
428
429 Privacy considerations dictate that the user have considerable
430 control over cookie management. The PRIVACY section contains more
431 information.
432
433 4.3.4 Sending Cookies to the Origin Server
434
435 When it sends a request to an origin server, the user agent sends a
436 Cookie request header to the origin server if it has cookies that are
437 applicable to the request, based on
438
439 * the request-host;
440
441
442
443
444 Kristol & Montulli Standards Track [Page 8]
445
446 RFC 2109 HTTP State Management Mechanism February 1997
447
448
449 * the request-URI;
450
451 * the cookie's age.
452
453 The syntax for the header is:
454
455 cookie = "Cookie:" cookie-version
456 1*((";" | ",") cookie-value)
457 cookie-value = NAME "=" VALUE [";" path] [";" domain]
458 cookie-version = "$Version" "=" value
459 NAME = attr
460 VALUE = value
461 path = "$Path" "=" value
462 domain = "$Domain" "=" value
463
464 The value of the cookie-version attribute must be the value from the
465 Version attribute, if any, of the corresponding Set-Cookie response
466 header. Otherwise the value for cookie-version is 0. The value for
467 the path attribute must be the value from the Path attribute, if any,
468 of the corresponding Set-Cookie response header. Otherwise the
469 attribute should be omitted from the Cookie request header. The
470 value for the domain attribute must be the value from the Domain
471 attribute, if any, of the corresponding Set-Cookie response header.
472 Otherwise the attribute should be omitted from the Cookie request
473 header.
474
475 Note that there is no Comment attribute in the Cookie request header
476 corresponding to the one in the Set-Cookie response header. The user
477 agent does not return the comment information to the origin server.
478
479 The following rules apply to choosing applicable cookie-values from
480 among all the cookies the user agent has.
481
482 Domain Selection
483 The origin server's fully-qualified host name must domain-match
484 the Domain attribute of the cookie.
485
486 Path Selection
487 The Path attribute of the cookie must match a prefix of the
488 request-URI.
489
490 Max-Age Selection
491 Cookies that have expired should have been discarded and thus
492 are not forwarded to an origin server.
493
494
495
496
497
498
499
500 Kristol & Montulli Standards Track [Page 9]
501
502 RFC 2109 HTTP State Management Mechanism February 1997
503
504
505 If multiple cookies satisfy the criteria above, they are ordered in
506 the Cookie header such that those with more specific Path attributes
507 precede those with less specific. Ordering with respect to other
508 attributes (e.g., Domain) is unspecified.
509
510 Note: For backward compatibility, the separator in the Cookie header
511 is semi-colon (;) everywhere. A server should also accept comma (,)
512 as the separator between cookie-values for future compatibility.
513
514 4.3.5 Sending Cookies in Unverifiable Transactions
515
516 Users must have control over sessions in order to ensure privacy.
517 (See PRIVACY section below.) To simplify implementation and to
518 prevent an additional layer of complexity where adequate safeguards
519 exist, however, this document distinguishes between transactions that
520 are verifiable and those that are unverifiable. A transaction is
521 verifiable if the user has the option to review the request-URI prior
522 to its use in the transaction. A transaction is unverifiable if the
523 user does not have that option. Unverifiable transactions typically
524 arise when a user agent automatically requests inlined or embedded
525 entities or when it resolves redirection (3xx) responses from an
526 origin server. Typically the origin transaction, the transaction
527 that the user initiates, is verifiable, and that transaction may
528 directly or indirectly induce the user agent to make unverifiable
529 transactions.
530
531 When it makes an unverifiable transaction, a user agent must enable a
532 session only if a cookie with a domain attribute D was sent or
533 received in its origin transaction, such that the host name in the
534 Request-URI of the unverifiable transaction domain-matches D.
535
536 This restriction prevents a malicious service author from using
537 unverifiable transactions to induce a user agent to start or continue
538 a session with a server in a different domain. The starting or
539 continuation of such sessions could be contrary to the privacy
540 expectations of the user, and could also be a security problem.
541
542 User agents may offer configurable options that allow the user agent,
543 or any autonomous programs that the user agent executes, to ignore
544 the above rule, so long as these override options default to "off".
545
546 Many current user agents already provide a review option that would
547 render many links verifiable. For instance, some user agents display
548 the URL that would be referenced for a particular link when the mouse
549 pointer is placed over that link. The user can therefore determine
550 whether to visit that site before causing the browser to do so.
551 (Though not implemented on current user agents, a similar technique
552 could be used for a button used to submit a form -- the user agent
553
554
555
556 Kristol & Montulli Standards Track [Page 10]
557
558 RFC 2109 HTTP State Management Mechanism February 1997
559
560
561 could display the action to be taken if the user were to select that
562 button.) However, even this would not make all links verifiable; for
563 example, links to automatically loaded images would not normally be
564 subject to "mouse pointer" verification.
565
566 Many user agents also provide the option for a user to view the HTML
567 source of a document, or to save the source to an external file where
568 it can be viewed by another application. While such an option does
569 provide a crude review mechanism, some users might not consider it
570 acceptable for this purpose.
571
572 4.4 How an Origin Server Interprets the Cookie Header
573
574 A user agent returns much of the information in the Set-Cookie header
575 to the origin server when the Path attribute matches that of a new
576 request. When it receives a Cookie header, the origin server should
577 treat cookies with NAMEs whose prefix is $ specially, as an attribute
578 for the adjacent cookie. The value for such a NAME is to be
579 interpreted as applying to the lexically (left-to-right) most recent
580 cookie whose name does not have the $ prefix. If there is no
581 previous cookie, the value applies to the cookie mechanism as a
582 whole. For example, consider the cookie
583
584 Cookie: $Version="1"; Customer="WILE_E_COYOTE";
585 $Path="/acme"
586
587 $Version applies to the cookie mechanism as a whole (and gives the
588 version number for the cookie mechanism). $Path is an attribute
589 whose value (/acme) defines the Path attribute that was used when the
590 Customer cookie was defined in a Set-Cookie response header.
591
592 4.5 Caching Proxy Role
593
594 One reason for separating state information from both a URL and
595 document content is to facilitate the scaling that caching permits.
596 To support cookies, a caching proxy must obey these rules already in
597 the HTTP specification:
598
599 * Honor requests from the cache, if possible, based on cache validity
600 rules.
601
602 * Pass along a Cookie request header in any request that the proxy
603 must make of another server.
604
605 * Return the response to the client. Include any Set-Cookie response
606 header.
607
608
609
610
611
612 Kristol & Montulli Standards Track [Page 11]
613
614 RFC 2109 HTTP State Management Mechanism February 1997
615
616
617 * Cache the received response subject to the control of the usual
618 headers, such as Expires, Cache-control: no-cache, and Cache-
619 control: private,
620
621 * Cache the Set-Cookie subject to the control of the usual header,
622 Cache-control: no-cache="set-cookie". (The Set-Cookie header
623 should usually not be cached.)
624
625 Proxies must not introduce Set-Cookie (Cookie) headers of their own
626 in proxy responses (requests).
627
628 5. EXAMPLES
629
630 5.1 Example 1
631
632 Most detail of request and response headers has been omitted. Assume
633 the user agent has no stored cookies.
634
635 1. User Agent -> Server
636
637 POST /acme/login HTTP/1.1
638 [form data]
639
640 User identifies self via a form.
641
642 2. Server -> User Agent
643
644 HTTP/1.1 200 OK
645 Set-Cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
646
647 Cookie reflects user's identity.
648
649 3. User Agent -> Server
650
651 POST /acme/pickitem HTTP/1.1
652 Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
653 [form data]
654
655 User selects an item for "shopping basket."
656
657 4. Server -> User Agent
658
659 HTTP/1.1 200 OK
660 Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
661 Path="/acme"
662
663 Shopping basket contains an item.
664
665
666
667
668 Kristol & Montulli Standards Track [Page 12]
669
670 RFC 2109 HTTP State Management Mechanism February 1997
671
672
673 5. User Agent -> Server
674
675 POST /acme/shipping HTTP/1.1
676 Cookie: $Version="1";
677 Customer="WILE_E_COYOTE"; $Path="/acme";
678 Part_Number="Rocket_Launcher_0001"; $Path="/acme"
679 [form data]
680
681 User selects shipping method from form.
682
683 6. Server -> User Agent
684
685 HTTP/1.1 200 OK
686 Set-Cookie: Shipping="FedEx"; Version="1"; Path="/acme"
687
688 New cookie reflects shipping method.
689
690 7. User Agent -> Server
691
692 POST /acme/process HTTP/1.1
693 Cookie: $Version="1";
694 Customer="WILE_E_COYOTE"; $Path="/acme";
695 Part_Number="Rocket_Launcher_0001"; $Path="/acme";
696 Shipping="FedEx"; $Path="/acme"
697 [form data]
698
699 User chooses to process order.
700
701 8. Server -> User Agent
702
703 HTTP/1.1 200 OK
704
705 Transaction is complete.
706
707 The user agent makes a series of requests on the origin server, after
708 each of which it receives a new cookie. All the cookies have the
709 same Path attribute and (default) domain. Because the request URLs
710 all have /acme as a prefix, and that matches the Path attribute, each
711 request contains all the cookies received so far.
712
713 5.2 Example 2
714
715 This example illustrates the effect of the Path attribute. All
716 detail of request and response headers has been omitted. Assume the
717 user agent has no stored cookies.
718
719 Imagine the user agent has received, in response to earlier requests,
720 the response headers
721
722
723
724 Kristol & Montulli Standards Track [Page 13]
725
726 RFC 2109 HTTP State Management Mechanism February 1997
727
728
729 Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
730 Path="/acme"
731
732 and
733
734 Set-Cookie: Part_Number="Riding_Rocket_0023"; Version="1";
735 Path="/acme/ammo"
736
737 A subsequent request by the user agent to the (same) server for URLs
738 of the form /acme/ammo/... would include the following request
739 header:
740
741 Cookie: $Version="1";
742 Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
743 Part_Number="Rocket_Launcher_0001"; $Path="/acme"
744
745 Note that the NAME=VALUE pair for the cookie with the more specific
746 Path attribute, /acme/ammo, comes before the one with the less
747 specific Path attribute, /acme. Further note that the same cookie
748 name appears more than once.
749
750 A subsequent request by the user agent to the (same) server for a URL
751 of the form /acme/parts/ would include the following request header:
752
753 Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"
754
755 Here, the second cookie's Path attribute /acme/ammo is not a prefix
756 of the request URL, /acme/parts/, so the cookie does not get
757 forwarded to the server.
758
759 6. IMPLEMENTATION CONSIDERATIONS
760
761 Here we speculate on likely or desirable details for an origin server
762 that implements state management.
763
764 6.1 Set-Cookie Content
765
766 An origin server's content should probably be divided into disjoint
767 application areas, some of which require the use of state
768 information. The application areas can be distinguished by their
769 request URLs. The Set-Cookie header can incorporate information
770 about the application areas by setting the Path attribute for each
771 one.
772
773 The session information can obviously be clear or encoded text that
774 describes state. However, if it grows too large, it can become
775 unwieldy. Therefore, an implementor might choose for the session
776 information to be a key to a server-side resource. Of course, using
777
778
779
780 Kristol & Montulli Standards Track [Page 14]
781
782 RFC 2109 HTTP State Management Mechanism February 1997
783
784
785 a database creates some problems that this state management
786 specification was meant to avoid, namely:
787
788 1. keeping real state on the server side;
789
790 2. how and when to garbage-collect the database entry, in case the
791 user agent terminates the session by, for example, exiting.
792
793 6.2 Stateless Pages
794
795 Caching benefits the scalability of WWW. Therefore it is important
796 to reduce the number of documents that have state embedded in them
797 inherently. For example, if a shopping-basket-style application
798 always displays a user's current basket contents on each page, those
799 pages cannot be cached, because each user's basket's contents would
800 be different. On the other hand, if each page contains just a link
801 that allows the user to "Look at My Shopping Basket", the page can be
802 cached.
803
804 6.3 Implementation Limits
805
806 Practical user agent implementations have limits on the number and
807 size of cookies that they can store. In general, user agents' cookie
808 support should have no fixed limits. They should strive to store as
809 many frequently-used cookies as possible. Furthermore, general-use
810 user agents should provide each of the following minimum capabilities
811 individually, although not necessarily simultaneously:
812
813 * at least 300 cookies
814
815 * at least 4096 bytes per cookie (as measured by the size of the
816 characters that comprise the cookie non-terminal in the syntax
817 description of the Set-Cookie header)
818
819 * at least 20 cookies per unique host or domain name
820
821 User agents created for specific purposes or for limited-capacity
822 devices should provide at least 20 cookies of 4096 bytes, to ensure
823 that the user can interact with a session-based origin server.
824
825 The information in a Set-Cookie response header must be retained in
826 its entirety. If for some reason there is inadequate space to store
827 the cookie, it must be discarded, not truncated.
828
829 Applications should use as few and as small cookies as possible, and
830 they should cope gracefully with the loss of a cookie.
831
832
833
834
835
836 Kristol & Montulli Standards Track [Page 15]
837
838 RFC 2109 HTTP State Management Mechanism February 1997
839
840
841 6.3.1 Denial of Service Attacks
842
843 User agents may choose to set an upper bound on the number of cookies
844 to be stored from a given host or domain name or on the size of the
845 cookie information. Otherwise a malicious server could attempt to
846 flood a user agent with many cookies, or large cookies, on successive
847 responses, which would force out cookies the user agent had received
848 from other servers. However, the minima specified above should still
849 be supported.
850
851 7. PRIVACY
852
853 7.1 User Agent Control
854
855 An origin server could create a Set-Cookie header to track the path
856 of a user through the server. Users may object to this behavior as
857 an intrusive accumulation of information, even if their identity is
858 not evident. (Identity might become evident if a user subsequently
859 fills out a form that contains identifying information.) This state
860 management specification therefore requires that a user agent give
861 the user control over such a possible intrusion, although the
862 interface through which the user is given this control is left
863 unspecified. However, the control mechanisms provided shall at least
864 allow the user
865
866 * to completely disable the sending and saving of cookies.
867
868 * to determine whether a stateful session is in progress.
869
870 * to control the saving of a cookie on the basis of the cookie's
871 Domain attribute.
872
873 Such control could be provided by, for example, mechanisms
874
875 * to notify the user when the user agent is about to send a cookie
876 to the origin server, offering the option not to begin a session.
877
878 * to display a visual indication that a stateful session is in
879 progress.
880
881 * to let the user decide which cookies, if any, should be saved
882 when the user concludes a window or user agent session.
883
884 * to let the user examine the contents of a cookie at any time.
885
886 A user agent usually begins execution with no remembered state
887 information. It should be possible to configure a user agent never
888 to send Cookie headers, in which case it can never sustain state with
889
890
891
892 Kristol & Montulli Standards Track [Page 16]
893
894 RFC 2109 HTTP State Management Mechanism February 1997
895
896
897 an origin server. (The user agent would then behave like one that is
898 unaware of how to handle Set-Cookie response headers.)
899
900 When the user agent terminates execution, it should let the user
901 discard all state information. Alternatively, the user agent may ask
902 the user whether state information should be retained; the default
903 should be "no". If the user chooses to retain state information, it
904 would be restored the next time the user agent runs.
905
906 NOTE: User agents should probably be cautious about using files to
907 store cookies long-term. If a user runs more than one instance of
908 the user agent, the cookies could be commingled or otherwise messed
909 up.
910
911 7.2 Protocol Design
912
913 The restrictions on the value of the Domain attribute, and the rules
914 concerning unverifiable transactions, are meant to reduce the ways
915 that cookies can "leak" to the "wrong" site. The intent is to
916 restrict cookies to one, or a closely related set of hosts.
917 Therefore a request-host is limited as to what values it can set for
918 Domain. We consider it acceptable for hosts host1.foo.com and
919 host2.foo.com to share cookies, but not a.com and b.com.
920
921 Similarly, a server can only set a Path for cookies that are related
922 to the request-URI.
923
924 8. SECURITY CONSIDERATIONS
925
926 8.1 Clear Text
927
928 The information in the Set-Cookie and Cookie headers is unprotected.
929 Two consequences are:
930
931 1. Any sensitive information that is conveyed in them is exposed
932 to intruders.
933
934 2. A malicious intermediary could alter the headers as they travel
935 in either direction, with unpredictable results.
936
937 These facts imply that information of a personal and/or financial
938 nature should only be sent over a secure channel. For less sensitive
939 information, or when the content of the header is a database key, an
940 origin server should be vigilant to prevent a bad Cookie value from
941 causing failures.
942
943
944
945
946
947
948 Kristol & Montulli Standards Track [Page 17]
949
950 RFC 2109 HTTP State Management Mechanism February 1997
951
952
953 8.2 Cookie Spoofing
954
955 Proper application design can avoid spoofing attacks from related
956 domains. Consider:
957
958 1. User agent makes request to victim.cracker.edu, gets back
959 cookie session_id="1234" and sets the default domain
960 victim.cracker.edu.
961
962 2. User agent makes request to spoof.cracker.edu, gets back
963 cookie session-id="1111", with Domain=".cracker.edu".
964
965 3. User agent makes request to victim.cracker.edu again, and
966 passes
967
968 Cookie: $Version="1";
969 session_id="1234";
970 session_id="1111"; $Domain=".cracker.edu"
971
972 The server at victim.cracker.edu should detect that the second
973 cookie was not one it originated by noticing that the Domain
974 attribute is not for itself and ignore it.
975
976 8.3 Unexpected Cookie Sharing
977
978 A user agent should make every attempt to prevent the sharing of
979 session information between hosts that are in different domains.
980 Embedded or inlined objects may cause particularly severe privacy
981 problems if they can be used to share cookies between disparate
982 hosts. For example, a malicious server could embed cookie
983 information for host a.com in a URI for a CGI on host b.com. User
984 agent implementors are strongly encouraged to prevent this sort of
985 exchange whenever possible.
986
987 9. OTHER, SIMILAR, PROPOSALS
988
989 Three other proposals have been made to accomplish similar goals.
990 This specification is an amalgam of Kristol's State-Info proposal and
991 Netscape's Cookie proposal.
992
993 Brian Behlendorf proposed a Session-ID header that would be user-
994 agent-initiated and could be used by an origin server to track
995 "clicktrails". It would not carry any origin-server-defined state,
996 however. Phillip Hallam-Baker has proposed another client-defined
997 session ID mechanism for similar purposes.
998
999
1000
1001
1002
1003
1004 Kristol & Montulli Standards Track [Page 18]
1005
1006 RFC 2109 HTTP State Management Mechanism February 1997
1007
1008
1009 While both session IDs and cookies can provide a way to sustain
1010 stateful sessions, their intended purpose is different, and,
1011 consequently, the privacy requirements for them are different. A
1012 user initiates session IDs to allow servers to track progress through
1013 them, or to distinguish multiple users on a shared machine. Cookies
1014 are server-initiated, so the cookie mechanism described here gives
1015 users control over something that would otherwise take place without
1016 the users' awareness. Furthermore, cookies convey rich, server-
1017 selected information, whereas session IDs comprise user-selected,
1018 simple information.
1019
1020 10. HISTORICAL
1021
1022 10.1 Compatibility With Netscape's Implementation
1023
1024 HTTP/1.0 clients and servers may use Set-Cookie and Cookie headers
1025 that reflect Netscape's original cookie proposal. These notes cover
1026 inter-operation between "old" and "new" cookies.
1027
1028 10.1.1 Extended Cookie Header
1029
1030 This proposal adds attribute-value pairs to the Cookie request header
1031 in a compatible way. An "old" client that receives a "new" cookie
1032 will ignore attributes it does not understand; it returns what it
1033 does understand to the origin server. A "new" client always sends
1034 cookies in the new form.
1035
1036 An "old" server that receives a "new" cookie will see what it thinks
1037 are many cookies with names that begin with a $, and it will ignore
1038 them. (The "old" server expects these cookies to be separated by
1039 semi-colon, not comma.) A "new" server can detect cookies that have
1040 passed through an "old" client, because they lack a $Version
1041 attribute.
1042
1043 10.1.2 Expires and Max-Age
1044
1045 Netscape's original proposal defined an Expires header that took a
1046 date value in a fixed-length variant format in place of Max-Age:
1047
1048 Wdy, DD-Mon-YY HH:MM:SS GMT
1049
1050 Note that the Expires date format contains embedded spaces, and that
1051 "old" cookies did not have quotes around values. Clients that
1052 implement to this specification should be aware of "old" cookies and
1053 Expires.
1054
1055
1056
1057
1058
1059
1060 Kristol & Montulli Standards Track [Page 19]
1061
1062 RFC 2109 HTTP State Management Mechanism February 1997
1063
1064
1065 10.1.3 Punctuation
1066
1067 In Netscape's original proposal, the values in attribute-value pairs
1068 did not accept "-quoted strings. Origin servers should be cautious
1069 about sending values that require quotes unless they know the
1070 receiving user agent understands them (i.e., "new" cookies). A
1071 ("new") user agent should only use quotes around values in Cookie
1072 headers when the cookie's version(s) is (are) all compliant with this
1073 specification or later.
1074
1075 In Netscape's original proposal, no whitespace was permitted around
1076 the = that separates attribute-value pairs. Therefore such
1077 whitespace should be used with caution in new implementations.
1078
1079 10.2 Caching and HTTP/1.0
1080
1081 Some caches, such as those conforming to HTTP/1.0, will inevitably
1082 cache the Set-Cookie header, because there was no mechanism to
1083 suppress caching of headers prior to HTTP/1.1. This caching can lead
1084 to security problems. Documents transmitted by an origin server
1085 along with Set-Cookie headers will usually either be uncachable, or
1086 will be "pre-expired". As long as caches obey instructions not to
1087 cache documents (following Expires: <a date in the past> or Pragma:
1088 no-cache (HTTP/1.0), or Cache-control: no-cache (HTTP/1.1))
1089 uncachable documents present no problem. However, pre-expired
1090 documents may be stored in caches. They require validation (a
1091 conditional GET) on each new request, but some cache operators loosen
1092 the rules for their caches, and sometimes serve expired documents
1093 without first validating them. This combination of factors can lead
1094 to cookies meant for one user later being sent to another user. The
1095 Set-Cookie header is stored in the cache, and, although the document
1096 is stale (expired), the cache returns the document in response to
1097 later requests, including cached headers.
1098
1099 11. ACKNOWLEDGEMENTS
1100
1101 This document really represents the collective efforts of the
1102 following people, in addition to the authors: Roy Fielding, Marc
1103 Hedlund, Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare.
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116 Kristol & Montulli Standards Track [Page 20]
1117
1118 RFC 2109 HTTP State Management Mechanism February 1997
1119
1120
1121 12. AUTHORS' ADDRESSES
1122
1123 David M. Kristol
1124 Bell Laboratories, Lucent Technologies
1125 600 Mountain Ave. Room 2A-227
1126 Murray Hill, NJ 07974
1127
1128 Phone: (908) 582-2250
1129 Fax: (908) 582-5809
1130 EMail: dmk@bell-labs.com
1131
1132
1133 Lou Montulli
1134 Netscape Communications Corp.
1135 501 E. Middlefield Rd.
1136 Mountain View, CA 94043
1137
1138 Phone: (415) 528-2600
1139 EMail: montulli@netscape.com
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172 Kristol & Montulli Standards Track [Page 21]
1173
Attached Files
To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.You are not allowed to attach a file to this page.