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