···
7
+
Internet Engineering Task Force (IETF) A. Barth
8
+
Request for Comments: 6265 U.C. Berkeley
9
+
Obsoletes: 2965 April 2011
10
+
Category: Standards Track
14
+
HTTP State Management Mechanism
18
+
This document defines the HTTP Cookie and Set-Cookie header fields.
19
+
These header fields can be used by HTTP servers to store state
20
+
(called cookies) at HTTP user agents, letting the servers maintain a
21
+
stateful session over the mostly stateless HTTP protocol. Although
22
+
cookies have many historical infelicities that degrade their security
23
+
and privacy, the Cookie and Set-Cookie header fields are widely used
24
+
on the Internet. This document obsoletes RFC 2965.
28
+
This is an Internet Standards Track document.
30
+
This document is a product of the Internet Engineering Task Force
31
+
(IETF). It represents the consensus of the IETF community. It has
32
+
received public review and has been approved for publication by the
33
+
Internet Engineering Steering Group (IESG). Further information on
34
+
Internet Standards is available in Section 2 of RFC 5741.
36
+
Information about the current status of this document, any errata,
37
+
and how to provide feedback on it may be obtained at
38
+
http://www.rfc-editor.org/info/rfc6265.
42
+
Copyright (c) 2011 IETF Trust and the persons identified as the
43
+
document authors. All rights reserved.
45
+
This document is subject to BCP 78 and the IETF Trust's Legal
46
+
Provisions Relating to IETF Documents
47
+
(http://trustee.ietf.org/license-info) in effect on the date of
48
+
publication of this document. Please review these documents
49
+
carefully, as they describe your rights and restrictions with respect
50
+
to this document. Code Components extracted from this document must
51
+
include Simplified BSD License text as described in Section 4.e of
52
+
the Trust Legal Provisions and are provided without warranty as
53
+
described in the Simplified BSD License.
58
+
Barth Standards Track [Page 1]
60
+
RFC 6265 HTTP State Management Mechanism April 2011
63
+
This document may contain material from IETF Documents or IETF
64
+
Contributions published or made publicly available before November
65
+
10, 2008. The person(s) controlling the copyright in some of this
66
+
material may not have granted the IETF Trust the right to allow
67
+
modifications of such material outside the IETF Standards Process.
68
+
Without obtaining an adequate license from the person(s) controlling
69
+
the copyright in such materials, this document may not be modified
70
+
outside the IETF Standards Process, and derivative works of it may
71
+
not be created outside the IETF Standards Process, except to format
72
+
it for publication as an RFC or to translate it into languages other
77
+
1. Introduction ....................................................3
78
+
2. Conventions .....................................................4
79
+
2.1. Conformance Criteria .......................................4
80
+
2.2. Syntax Notation ............................................5
81
+
2.3. Terminology ................................................5
82
+
3. Overview ........................................................6
83
+
3.1. Examples ...................................................6
84
+
4. Server Requirements .............................................8
85
+
4.1. Set-Cookie .................................................8
86
+
4.1.1. Syntax ..............................................8
87
+
4.1.2. Semantics (Non-Normative) ..........................10
88
+
4.2. Cookie ....................................................13
89
+
4.2.1. Syntax .............................................13
90
+
4.2.2. Semantics ..........................................13
91
+
5. User Agent Requirements ........................................14
92
+
5.1. Subcomponent Algorithms ...................................14
93
+
5.1.1. Dates ..............................................14
94
+
5.1.2. Canonicalized Host Names ...........................16
95
+
5.1.3. Domain Matching ....................................16
96
+
5.1.4. Paths and Path-Match ...............................16
97
+
5.2. The Set-Cookie Header .....................................17
98
+
5.2.1. The Expires Attribute ..............................19
99
+
5.2.2. The Max-Age Attribute ..............................20
100
+
5.2.3. The Domain Attribute ...............................20
101
+
5.2.4. The Path Attribute .................................21
102
+
5.2.5. The Secure Attribute ...............................21
103
+
5.2.6. The HttpOnly Attribute .............................21
104
+
5.3. Storage Model .............................................21
105
+
5.4. The Cookie Header .........................................25
106
+
6. Implementation Considerations ..................................27
107
+
6.1. Limits ....................................................27
108
+
6.2. Application Programming Interfaces ........................27
109
+
6.3. IDNA Dependency and Migration .............................27
110
+
7. Privacy Considerations .........................................28
114
+
Barth Standards Track [Page 2]
116
+
RFC 6265 HTTP State Management Mechanism April 2011
119
+
7.1. Third-Party Cookies .......................................28
120
+
7.2. User Controls .............................................28
121
+
7.3. Expiration Dates ..........................................29
122
+
8. Security Considerations ........................................29
123
+
8.1. Overview ..................................................29
124
+
8.2. Ambient Authority .........................................30
125
+
8.3. Clear Text ................................................30
126
+
8.4. Session Identifiers .......................................31
127
+
8.5. Weak Confidentiality ......................................32
128
+
8.6. Weak Integrity ............................................32
129
+
8.7. Reliance on DNS ...........................................33
130
+
9. IANA Considerations ............................................33
131
+
9.1. Cookie ....................................................34
132
+
9.2. Set-Cookie ................................................34
133
+
9.3. Cookie2 ...................................................34
134
+
9.4. Set-Cookie2 ...............................................34
135
+
10. References ....................................................35
136
+
10.1. Normative References .....................................35
137
+
10.2. Informative References ...................................35
138
+
Appendix A. Acknowledgements ......................................37
142
+
This document defines the HTTP Cookie and Set-Cookie header fields.
143
+
Using the Set-Cookie header field, an HTTP server can pass name/value
144
+
pairs and associated metadata (called cookies) to a user agent. When
145
+
the user agent makes subsequent requests to the server, the user
146
+
agent uses the metadata and other information to determine whether to
147
+
return the name/value pairs in the Cookie header.
149
+
Although simple on their surface, cookies have a number of
150
+
complexities. For example, the server indicates a scope for each
151
+
cookie when sending it to the user agent. The scope indicates the
152
+
maximum amount of time in which the user agent should return the
153
+
cookie, the servers to which the user agent should return the cookie,
154
+
and the URI schemes for which the cookie is applicable.
156
+
For historical reasons, cookies contain a number of security and
157
+
privacy infelicities. For example, a server can indicate that a
158
+
given cookie is intended for "secure" connections, but the Secure
159
+
attribute does not provide integrity in the presence of an active
160
+
network attacker. Similarly, cookies for a given host are shared
161
+
across all the ports on that host, even though the usual "same-origin
162
+
policy" used by web browsers isolates content retrieved via different
165
+
There are two audiences for this specification: developers of cookie-
166
+
generating servers and developers of cookie-consuming user agents.
170
+
Barth Standards Track [Page 3]
172
+
RFC 6265 HTTP State Management Mechanism April 2011
175
+
To maximize interoperability with user agents, servers SHOULD limit
176
+
themselves to the well-behaved profile defined in Section 4 when
177
+
generating cookies.
179
+
User agents MUST implement the more liberal processing rules defined
180
+
in Section 5, in order to maximize interoperability with existing
181
+
servers that do not conform to the well-behaved profile defined in
184
+
This document specifies the syntax and semantics of these headers as
185
+
they are actually used on the Internet. In particular, this document
186
+
does not create new syntax or semantics beyond those in use today.
187
+
The recommendations for cookie generation provided in Section 4
188
+
represent a preferred subset of current server behavior, and even the
189
+
more liberal cookie processing algorithm provided in Section 5 does
190
+
not recommend all of the syntactic and semantic variations in use
191
+
today. Where some existing software differs from the recommended
192
+
protocol in significant ways, the document contains a note explaining
195
+
Prior to this document, there were at least three descriptions of
196
+
cookies: the so-called "Netscape cookie specification" [Netscape],
197
+
RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
198
+
documents describe how the Cookie and Set-Cookie headers are actually
199
+
used on the Internet (see [Kri2001] for historical context). In
200
+
relation to previous IETF specifications of HTTP state management
201
+
mechanisms, this document requests the following actions:
203
+
1. Change the status of [RFC2109] to Historic (it has already been
204
+
obsoleted by [RFC2965]).
206
+
2. Change the status of [RFC2965] to Historic.
208
+
3. Indicate that [RFC2965] has been obsoleted by this document.
210
+
In particular, in moving RFC 2965 to Historic and obsoleting it, this
211
+
document deprecates the use of the Cookie2 and Set-Cookie2 header
216
+
2.1. Conformance Criteria
218
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
219
+
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
220
+
document are to be interpreted as described in [RFC2119].
226
+
Barth Standards Track [Page 4]
228
+
RFC 6265 HTTP State Management Mechanism April 2011
231
+
Requirements phrased in the imperative as part of algorithms (such as
232
+
"strip any leading space characters" or "return false and abort these
233
+
steps") are to be interpreted with the meaning of the key word
234
+
("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
236
+
Conformance requirements phrased as algorithms or specific steps can
237
+
be implemented in any manner, so long as the end result is
238
+
equivalent. In particular, the algorithms defined in this
239
+
specification are intended to be easy to understand and are not
240
+
intended to be performant.
242
+
2.2. Syntax Notation
244
+
This specification uses the Augmented Backus-Naur Form (ABNF)
245
+
notation of [RFC5234].
247
+
The following core rules are included by reference, as defined in
248
+
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
249
+
(CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
250
+
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
251
+
OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
252
+
(horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible
253
+
[USASCII] character), and WSP (whitespace).
255
+
The OWS (optional whitespace) rule is used where zero or more linear
256
+
whitespace characters MAY appear:
258
+
OWS = *( [ obs-fold ] WSP )
259
+
; "optional" whitespace
262
+
OWS SHOULD either not be produced or be produced as a single SP
267
+
The terms user agent, client, server, proxy, and origin server have
268
+
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
271
+
The request-host is the name of the host, as known by the user agent,
272
+
to which the user agent is sending an HTTP request or from which it
273
+
is receiving an HTTP response (i.e., the name of the host to which it
274
+
sent the corresponding HTTP request).
276
+
The term request-uri is defined in Section 5.1.2 of [RFC2616].
282
+
Barth Standards Track [Page 5]
284
+
RFC 6265 HTTP State Management Mechanism April 2011
287
+
Two sequences of octets are said to case-insensitively match each
288
+
other if and only if they are equivalent under the i;ascii-casemap
289
+
collation defined in [RFC4790].
291
+
The term string means a sequence of non-NUL octets.
295
+
This section outlines a way for an origin server to send state
296
+
information to a user agent and for the user agent to return the
297
+
state information to the origin server.
299
+
To store state, the origin server includes a Set-Cookie header in an
300
+
HTTP response. In subsequent requests, the user agent returns a
301
+
Cookie request header to the origin server. The Cookie header
302
+
contains cookies the user agent received in previous Set-Cookie
303
+
headers. The origin server is free to ignore the Cookie header or
304
+
use its contents for an application-defined purpose.
306
+
Origin servers MAY send a Set-Cookie response header with any
307
+
response. User agents MAY ignore Set-Cookie headers contained in
308
+
responses with 100-level status codes but MUST process Set-Cookie
309
+
headers contained in other responses (including responses with 400-
310
+
and 500-level status codes). An origin server can include multiple
311
+
Set-Cookie header fields in a single response. The presence of a
312
+
Cookie or a Set-Cookie header field does not preclude HTTP caches
313
+
from storing and reusing a response.
315
+
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
316
+
a single header field. The usual mechanism for folding HTTP headers
317
+
fields (i.e., as defined in [RFC2616]) might change the semantics of
318
+
the Set-Cookie header field because the %x2C (",") character is used
319
+
by Set-Cookie in a way that conflicts with such folding.
323
+
Using the Set-Cookie header, a server can send the user agent a short
324
+
string in an HTTP response that the user agent will return in future
325
+
HTTP requests that are within the scope of the cookie. For example,
326
+
the server can send the user agent a "session identifier" named SID
327
+
with the value 31d4d96e407aad42. The user agent then returns the
328
+
session identifier in subsequent requests.
338
+
Barth Standards Track [Page 6]
340
+
RFC 6265 HTTP State Management Mechanism April 2011
343
+
== Server -> User Agent ==
345
+
Set-Cookie: SID=31d4d96e407aad42
347
+
== User Agent -> Server ==
349
+
Cookie: SID=31d4d96e407aad42
351
+
The server can alter the default scope of the cookie using the Path
352
+
and Domain attributes. For example, the server can instruct the user
353
+
agent to return the cookie to every path and every subdomain of
356
+
== Server -> User Agent ==
358
+
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com
360
+
== User Agent -> Server ==
362
+
Cookie: SID=31d4d96e407aad42
364
+
As shown in the next example, the server can store multiple cookies
365
+
at the user agent. For example, the server can store a session
366
+
identifier as well as the user's preferred language by returning two
367
+
Set-Cookie header fields. Notice that the server uses the Secure and
368
+
HttpOnly attributes to provide additional security protections for
369
+
the more sensitive session identifier (see Section 4.1.2.)
371
+
== Server -> User Agent ==
373
+
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
374
+
Set-Cookie: lang=en-US; Path=/; Domain=example.com
376
+
== User Agent -> Server ==
378
+
Cookie: SID=31d4d96e407aad42; lang=en-US
380
+
Notice that the Cookie header above contains two cookies, one named
381
+
SID and one named lang. If the server wishes the user agent to
382
+
persist the cookie over multiple "sessions" (e.g., user agent
383
+
restarts), the server can specify an expiration date in the Expires
384
+
attribute. Note that the user agent might delete the cookie before
385
+
the expiration date if the user agent's cookie store exceeds its
386
+
quota or if the user manually deletes the server's cookie.
394
+
Barth Standards Track [Page 7]
396
+
RFC 6265 HTTP State Management Mechanism April 2011
399
+
== Server -> User Agent ==
401
+
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
403
+
== User Agent -> Server ==
405
+
Cookie: SID=31d4d96e407aad42; lang=en-US
407
+
Finally, to remove a cookie, the server returns a Set-Cookie header
408
+
with an expiration date in the past. The server will be successful
409
+
in removing the cookie only if the Path and the Domain attribute in
410
+
the Set-Cookie header match the values used when the cookie was
413
+
== Server -> User Agent ==
415
+
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
417
+
== User Agent -> Server ==
419
+
Cookie: SID=31d4d96e407aad42
421
+
4. Server Requirements
423
+
This section describes the syntax and semantics of a well-behaved
424
+
profile of the Cookie and Set-Cookie headers.
428
+
The Set-Cookie HTTP response header is used to send cookies from the
429
+
server to the user agent.
433
+
Informally, the Set-Cookie response header contains the header name
434
+
"Set-Cookie" followed by a ":" and a cookie. Each cookie begins with
435
+
a name-value-pair, followed by zero or more attribute-value pairs.
436
+
Servers SHOULD NOT send Set-Cookie headers that fail to conform to
437
+
the following grammar:
450
+
Barth Standards Track [Page 8]
452
+
RFC 6265 HTTP State Management Mechanism April 2011
455
+
set-cookie-header = "Set-Cookie:" SP set-cookie-string
456
+
set-cookie-string = cookie-pair *( ";" SP cookie-av )
457
+
cookie-pair = cookie-name "=" cookie-value
458
+
cookie-name = token
459
+
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
460
+
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
461
+
; US-ASCII characters excluding CTLs,
462
+
; whitespace DQUOTE, comma, semicolon,
464
+
token = <token, defined in [RFC2616], Section 2.2>
466
+
cookie-av = expires-av / max-age-av / domain-av /
467
+
path-av / secure-av / httponly-av /
469
+
expires-av = "Expires=" sane-cookie-date
470
+
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
471
+
max-age-av = "Max-Age=" non-zero-digit *DIGIT
472
+
; In practice, both expires-av and max-age-av
473
+
; are limited to dates representable by the
475
+
non-zero-digit = %x31-39
476
+
; digits 1 through 9
477
+
domain-av = "Domain=" domain-value
478
+
domain-value = <subdomain>
479
+
; defined in [RFC1034], Section 3.5, as
480
+
; enhanced by [RFC1123], Section 2.1
481
+
path-av = "Path=" path-value
482
+
path-value = <any CHAR except CTLs or ";">
483
+
secure-av = "Secure"
484
+
httponly-av = "HttpOnly"
485
+
extension-av = <any CHAR except CTLs or ";">
487
+
Note that some of the grammatical terms above reference documents
488
+
that use different grammatical notations than this document (which
489
+
uses ABNF from [RFC5234]).
491
+
The semantics of the cookie-value are not defined by this document.
493
+
To maximize compatibility with user agents, servers that wish to
494
+
store arbitrary data in a cookie-value SHOULD encode that data, for
495
+
example, using Base64 [RFC4648].
497
+
The portions of the set-cookie-string produced by the cookie-av term
498
+
are known as attributes. To maximize compatibility with user agents,
499
+
servers SHOULD NOT produce two attributes with the same name in the
500
+
same set-cookie-string. (See Section 5.3 for how user agents handle
506
+
Barth Standards Track [Page 9]
508
+
RFC 6265 HTTP State Management Mechanism April 2011
511
+
Servers SHOULD NOT include more than one Set-Cookie header field in
512
+
the same response with the same cookie-name. (See Section 5.2 for
513
+
how user agents handle this case.)
515
+
If a server sends multiple responses containing Set-Cookie headers
516
+
concurrently to the user agent (e.g., when communicating with the
517
+
user agent over multiple sockets), these responses create a "race
518
+
condition" that can lead to unpredictable behavior.
520
+
NOTE: Some existing user agents differ in their interpretation of
521
+
two-digit years. To avoid compatibility issues, servers SHOULD use
522
+
the rfc1123-date format, which requires a four-digit year.
524
+
NOTE: Some user agents store and process dates in cookies as 32-bit
525
+
UNIX time_t values. Implementation bugs in the libraries supporting
526
+
time_t processing on some systems might cause such user agents to
527
+
process dates after the year 2038 incorrectly.
529
+
4.1.2. Semantics (Non-Normative)
531
+
This section describes simplified semantics of the Set-Cookie header.
532
+
These semantics are detailed enough to be useful for understanding
533
+
the most common uses of cookies by servers. The full semantics are
534
+
described in Section 5.
536
+
When the user agent receives a Set-Cookie header, the user agent
537
+
stores the cookie together with its attributes. Subsequently, when
538
+
the user agent makes an HTTP request, the user agent includes the
539
+
applicable, non-expired cookies in the Cookie header.
541
+
If the user agent receives a new cookie with the same cookie-name,
542
+
domain-value, and path-value as a cookie that it has already stored,
543
+
the existing cookie is evicted and replaced with the new cookie.
544
+
Notice that servers can delete cookies by sending the user agent a
545
+
new cookie with an Expires attribute with a value in the past.
547
+
Unless the cookie's attributes indicate otherwise, the cookie is
548
+
returned only to the origin server (and not, for example, to any
549
+
subdomains), and it expires at the end of the current session (as
550
+
defined by the user agent). User agents ignore unrecognized cookie
551
+
attributes (but not the entire cookie).
562
+
Barth Standards Track [Page 10]
564
+
RFC 6265 HTTP State Management Mechanism April 2011
567
+
4.1.2.1. The Expires Attribute
569
+
The Expires attribute indicates the maximum lifetime of the cookie,
570
+
represented as the date and time at which the cookie expires. The
571
+
user agent is not required to retain the cookie until the specified
572
+
date has passed. In fact, user agents often evict cookies due to
573
+
memory pressure or privacy concerns.
575
+
4.1.2.2. The Max-Age Attribute
577
+
The Max-Age attribute indicates the maximum lifetime of the cookie,
578
+
represented as the number of seconds until the cookie expires. The
579
+
user agent is not required to retain the cookie for the specified
580
+
duration. In fact, user agents often evict cookies due to memory
581
+
pressure or privacy concerns.
583
+
NOTE: Some existing user agents do not support the Max-Age
584
+
attribute. User agents that do not support the Max-Age attribute
585
+
ignore the attribute.
587
+
If a cookie has both the Max-Age and the Expires attribute, the Max-
588
+
Age attribute has precedence and controls the expiration date of the
589
+
cookie. If a cookie has neither the Max-Age nor the Expires
590
+
attribute, the user agent will retain the cookie until "the current
591
+
session is over" (as defined by the user agent).
593
+
4.1.2.3. The Domain Attribute
595
+
The Domain attribute specifies those hosts to which the cookie will
596
+
be sent. For example, if the value of the Domain attribute is
597
+
"example.com", the user agent will include the cookie in the Cookie
598
+
header when making HTTP requests to example.com, www.example.com, and
599
+
www.corp.example.com. (Note that a leading %x2E ("."), if present,
600
+
is ignored even though that character is not permitted, but a
601
+
trailing %x2E ("."), if present, will cause the user agent to ignore
602
+
the attribute.) If the server omits the Domain attribute, the user
603
+
agent will return the cookie only to the origin server.
605
+
WARNING: Some existing user agents treat an absent Domain
606
+
attribute as if the Domain attribute were present and contained
607
+
the current host name. For example, if example.com returns a Set-
608
+
Cookie header without a Domain attribute, these user agents will
609
+
erroneously send the cookie to www.example.com as well.
618
+
Barth Standards Track [Page 11]
620
+
RFC 6265 HTTP State Management Mechanism April 2011
623
+
The user agent will reject cookies unless the Domain attribute
624
+
specifies a scope for the cookie that would include the origin
625
+
server. For example, the user agent will accept a cookie with a
626
+
Domain attribute of "example.com" or of "foo.example.com" from
627
+
foo.example.com, but the user agent will not accept a cookie with a
628
+
Domain attribute of "bar.example.com" or of "baz.foo.example.com".
630
+
NOTE: For security reasons, many user agents are configured to reject
631
+
Domain attributes that correspond to "public suffixes". For example,
632
+
some user agents will reject Domain attributes of "com" or "co.uk".
633
+
(See Section 5.3 for more information.)
635
+
4.1.2.4. The Path Attribute
637
+
The scope of each cookie is limited to a set of paths, controlled by
638
+
the Path attribute. If the server omits the Path attribute, the user
639
+
agent will use the "directory" of the request-uri's path component as
640
+
the default value. (See Section 5.1.4 for more details.)
642
+
The user agent will include the cookie in an HTTP request only if the
643
+
path portion of the request-uri matches (or is a subdirectory of) the
644
+
cookie's Path attribute, where the %x2F ("/") character is
645
+
interpreted as a directory separator.
647
+
Although seemingly useful for isolating cookies between different
648
+
paths within a given host, the Path attribute cannot be relied upon
649
+
for security (see Section 8).
651
+
4.1.2.5. The Secure Attribute
653
+
The Secure attribute limits the scope of the cookie to "secure"
654
+
channels (where "secure" is defined by the user agent). When a
655
+
cookie has the Secure attribute, the user agent will include the
656
+
cookie in an HTTP request only if the request is transmitted over a
657
+
secure channel (typically HTTP over Transport Layer Security (TLS)
660
+
Although seemingly useful for protecting cookies from active network
661
+
attackers, the Secure attribute protects only the cookie's
662
+
confidentiality. An active network attacker can overwrite Secure
663
+
cookies from an insecure channel, disrupting their integrity (see
664
+
Section 8.6 for more details).
674
+
Barth Standards Track [Page 12]
676
+
RFC 6265 HTTP State Management Mechanism April 2011
679
+
4.1.2.6. The HttpOnly Attribute
681
+
The HttpOnly attribute limits the scope of the cookie to HTTP
682
+
requests. In particular, the attribute instructs the user agent to
683
+
omit the cookie when providing access to cookies via "non-HTTP" APIs
684
+
(such as a web browser API that exposes cookies to scripts).
686
+
Note that the HttpOnly attribute is independent of the Secure
687
+
attribute: a cookie can have both the HttpOnly and the Secure
694
+
The user agent sends stored cookies to the origin server in the
695
+
Cookie header. If the server conforms to the requirements in
696
+
Section 4.1 (and the user agent conforms to the requirements in
697
+
Section 5), the user agent will send a Cookie header that conforms to
698
+
the following grammar:
700
+
cookie-header = "Cookie:" OWS cookie-string OWS
701
+
cookie-string = cookie-pair *( ";" SP cookie-pair )
705
+
Each cookie-pair represents a cookie stored by the user agent. The
706
+
cookie-pair contains the cookie-name and cookie-value the user agent
707
+
received in the Set-Cookie header.
709
+
Notice that the cookie attributes are not returned. In particular,
710
+
the server cannot determine from the Cookie header alone when a
711
+
cookie will expire, for which hosts the cookie is valid, for which
712
+
paths the cookie is valid, or whether the cookie was set with the
713
+
Secure or HttpOnly attributes.
715
+
The semantics of individual cookies in the Cookie header are not
716
+
defined by this document. Servers are expected to imbue these
717
+
cookies with application-specific semantics.
719
+
Although cookies are serialized linearly in the Cookie header,
720
+
servers SHOULD NOT rely upon the serialization order. In particular,
721
+
if the Cookie header contains two cookies with the same name (e.g.,
722
+
that were set with different Path or Domain attributes), servers
723
+
SHOULD NOT rely upon the order in which these cookies appear in the
730
+
Barth Standards Track [Page 13]
732
+
RFC 6265 HTTP State Management Mechanism April 2011
735
+
5. User Agent Requirements
737
+
This section specifies the Cookie and Set-Cookie headers in
738
+
sufficient detail that a user agent implementing these requirements
739
+
precisely can interoperate with existing servers (even those that do
740
+
not conform to the well-behaved profile described in Section 4).
742
+
A user agent could enforce more restrictions than those specified
743
+
herein (e.g., for the sake of improved security); however,
744
+
experiments have shown that such strictness reduces the likelihood
745
+
that a user agent will be able to interoperate with existing servers.
747
+
5.1. Subcomponent Algorithms
749
+
This section defines some algorithms used by user agents to process
750
+
specific subcomponents of the Cookie and Set-Cookie headers.
754
+
The user agent MUST use an algorithm equivalent to the following
755
+
algorithm to parse a cookie-date. Note that the various boolean
756
+
flags defined as a part of the algorithm (i.e., found-time, found-
757
+
day-of-month, found-month, found-year) are initially "not set".
759
+
1. Using the grammar below, divide the cookie-date into date-tokens.
761
+
cookie-date = *delimiter date-token-list *delimiter
762
+
date-token-list = date-token *( 1*delimiter date-token )
763
+
date-token = 1*non-delimiter
765
+
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
766
+
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
767
+
non-digit = %x00-2F / %x3A-FF
769
+
day-of-month = 1*2DIGIT ( non-digit *OCTET )
770
+
month = ( "jan" / "feb" / "mar" / "apr" /
771
+
"may" / "jun" / "jul" / "aug" /
772
+
"sep" / "oct" / "nov" / "dec" ) *OCTET
773
+
year = 2*4DIGIT ( non-digit *OCTET )
774
+
time = hms-time ( non-digit *OCTET )
775
+
hms-time = time-field ":" time-field ":" time-field
776
+
time-field = 1*2DIGIT
778
+
2. Process each date-token sequentially in the order the date-tokens
779
+
appear in the cookie-date:
786
+
Barth Standards Track [Page 14]
788
+
RFC 6265 HTTP State Management Mechanism April 2011
791
+
1. If the found-time flag is not set and the token matches the
792
+
time production, set the found-time flag and set the hour-
793
+
value, minute-value, and second-value to the numbers denoted
794
+
by the digits in the date-token, respectively. Skip the
795
+
remaining sub-steps and continue to the next date-token.
797
+
2. If the found-day-of-month flag is not set and the date-token
798
+
matches the day-of-month production, set the found-day-of-
799
+
month flag and set the day-of-month-value to the number
800
+
denoted by the date-token. Skip the remaining sub-steps and
801
+
continue to the next date-token.
803
+
3. If the found-month flag is not set and the date-token matches
804
+
the month production, set the found-month flag and set the
805
+
month-value to the month denoted by the date-token. Skip the
806
+
remaining sub-steps and continue to the next date-token.
808
+
4. If the found-year flag is not set and the date-token matches
809
+
the year production, set the found-year flag and set the
810
+
year-value to the number denoted by the date-token. Skip the
811
+
remaining sub-steps and continue to the next date-token.
813
+
3. If the year-value is greater than or equal to 70 and less than or
814
+
equal to 99, increment the year-value by 1900.
816
+
4. If the year-value is greater than or equal to 0 and less than or
817
+
equal to 69, increment the year-value by 2000.
819
+
1. NOTE: Some existing user agents interpret two-digit years
822
+
5. Abort these steps and fail to parse the cookie-date if:
824
+
* at least one of the found-day-of-month, found-month, found-
825
+
year, or found-time flags is not set,
827
+
* the day-of-month-value is less than 1 or greater than 31,
829
+
* the year-value is less than 1601,
831
+
* the hour-value is greater than 23,
833
+
* the minute-value is greater than 59, or
835
+
* the second-value is greater than 59.
837
+
(Note that leap seconds cannot be represented in this syntax.)
842
+
Barth Standards Track [Page 15]
844
+
RFC 6265 HTTP State Management Mechanism April 2011
847
+
6. Let the parsed-cookie-date be the date whose day-of-month, month,
848
+
year, hour, minute, and second (in UTC) are the day-of-month-
849
+
value, the month-value, the year-value, the hour-value, the
850
+
minute-value, and the second-value, respectively. If no such
851
+
date exists, abort these steps and fail to parse the cookie-date.
853
+
7. Return the parsed-cookie-date as the result of this algorithm.
855
+
5.1.2. Canonicalized Host Names
857
+
A canonicalized host name is the string generated by the following
860
+
1. Convert the host name to a sequence of individual domain name
863
+
2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label,
864
+
to an A-label (see Section 2.3.2.1 of [RFC5890] for the former
865
+
and latter), or to a "punycode label" (a label resulting from the
866
+
"ToASCII" conversion in Section 4 of [RFC3490]), as appropriate
867
+
(see Section 6.3 of this specification).
869
+
3. Concatenate the resulting labels, separated by a %x2E (".")
872
+
5.1.3. Domain Matching
874
+
A string domain-matches a given domain string if at least one of the
875
+
following conditions hold:
877
+
o The domain string and the string are identical. (Note that both
878
+
the domain string and the string will have been canonicalized to
879
+
lower case at this point.)
881
+
o All of the following conditions hold:
883
+
* The domain string is a suffix of the string.
885
+
* The last character of the string that is not included in the
886
+
domain string is a %x2E (".") character.
888
+
* The string is a host name (i.e., not an IP address).
890
+
5.1.4. Paths and Path-Match
892
+
The user agent MUST use an algorithm equivalent to the following
893
+
algorithm to compute the default-path of a cookie:
898
+
Barth Standards Track [Page 16]
900
+
RFC 6265 HTTP State Management Mechanism April 2011
903
+
1. Let uri-path be the path portion of the request-uri if such a
904
+
portion exists (and empty otherwise). For example, if the
905
+
request-uri contains just a path (and optional query string),
906
+
then the uri-path is that path (without the %x3F ("?") character
907
+
or query string), and if the request-uri contains a full
908
+
absoluteURI, the uri-path is the path component of that URI.
910
+
2. If the uri-path is empty or if the first character of the uri-
911
+
path is not a %x2F ("/") character, output %x2F ("/") and skip
912
+
the remaining steps.
914
+
3. If the uri-path contains no more than one %x2F ("/") character,
915
+
output %x2F ("/") and skip the remaining step.
917
+
4. Output the characters of the uri-path from the first character up
918
+
to, but not including, the right-most %x2F ("/").
920
+
A request-path path-matches a given cookie-path if at least one of
921
+
the following conditions holds:
923
+
o The cookie-path and the request-path are identical.
925
+
o The cookie-path is a prefix of the request-path, and the last
926
+
character of the cookie-path is %x2F ("/").
928
+
o The cookie-path is a prefix of the request-path, and the first
929
+
character of the request-path that is not included in the cookie-
930
+
path is a %x2F ("/") character.
932
+
5.2. The Set-Cookie Header
934
+
When a user agent receives a Set-Cookie header field in an HTTP
935
+
response, the user agent MAY ignore the Set-Cookie header field in
936
+
its entirety. For example, the user agent might wish to block
937
+
responses to "third-party" requests from setting cookies (see
940
+
If the user agent does not ignore the Set-Cookie header field in its
941
+
entirety, the user agent MUST parse the field-value of the Set-Cookie
942
+
header field as a set-cookie-string (defined below).
944
+
NOTE: The algorithm below is more permissive than the grammar in
945
+
Section 4.1. For example, the algorithm strips leading and trailing
946
+
whitespace from the cookie name and value (but maintains internal
947
+
whitespace), whereas the grammar in Section 4.1 forbids whitespace in
948
+
these positions. User agents use this algorithm so as to
949
+
interoperate with servers that do not follow the recommendations in
954
+
Barth Standards Track [Page 17]
956
+
RFC 6265 HTTP State Management Mechanism April 2011
959
+
A user agent MUST use an algorithm equivalent to the following
960
+
algorithm to parse a "set-cookie-string":
962
+
1. If the set-cookie-string contains a %x3B (";") character:
964
+
The name-value-pair string consists of the characters up to,
965
+
but not including, the first %x3B (";"), and the unparsed-
966
+
attributes consist of the remainder of the set-cookie-string
967
+
(including the %x3B (";") in question).
971
+
The name-value-pair string consists of all the characters
972
+
contained in the set-cookie-string, and the unparsed-
973
+
attributes is the empty string.
975
+
2. If the name-value-pair string lacks a %x3D ("=") character,
976
+
ignore the set-cookie-string entirely.
978
+
3. The (possibly empty) name string consists of the characters up
979
+
to, but not including, the first %x3D ("=") character, and the
980
+
(possibly empty) value string consists of the characters after
981
+
the first %x3D ("=") character.
983
+
4. Remove any leading or trailing WSP characters from the name
984
+
string and the value string.
986
+
5. If the name string is empty, ignore the set-cookie-string
989
+
6. The cookie-name is the name string, and the cookie-value is the
992
+
The user agent MUST use an algorithm equivalent to the following
993
+
algorithm to parse the unparsed-attributes:
995
+
1. If the unparsed-attributes string is empty, skip the rest of
998
+
2. Discard the first character of the unparsed-attributes (which
999
+
will be a %x3B (";") character).
1001
+
3. If the remaining unparsed-attributes contains a %x3B (";")
1004
+
Consume the characters of the unparsed-attributes up to, but
1005
+
not including, the first %x3B (";") character.
1010
+
Barth Standards Track [Page 18]
1012
+
RFC 6265 HTTP State Management Mechanism April 2011
1017
+
Consume the remainder of the unparsed-attributes.
1019
+
Let the cookie-av string be the characters consumed in this step.
1021
+
4. If the cookie-av string contains a %x3D ("=") character:
1023
+
The (possibly empty) attribute-name string consists of the
1024
+
characters up to, but not including, the first %x3D ("=")
1025
+
character, and the (possibly empty) attribute-value string
1026
+
consists of the characters after the first %x3D ("=")
1031
+
The attribute-name string consists of the entire cookie-av
1032
+
string, and the attribute-value string is empty.
1034
+
5. Remove any leading or trailing WSP characters from the attribute-
1035
+
name string and the attribute-value string.
1037
+
6. Process the attribute-name and attribute-value according to the
1038
+
requirements in the following subsections. (Notice that
1039
+
attributes with unrecognized attribute-names are ignored.)
1041
+
7. Return to Step 1 of this algorithm.
1043
+
When the user agent finishes parsing the set-cookie-string, the user
1044
+
agent is said to "receive a cookie" from the request-uri with name
1045
+
cookie-name, value cookie-value, and attributes cookie-attribute-
1046
+
list. (See Section 5.3 for additional requirements triggered by
1047
+
receiving a cookie.)
1049
+
5.2.1. The Expires Attribute
1051
+
If the attribute-name case-insensitively matches the string
1052
+
"Expires", the user agent MUST process the cookie-av as follows.
1054
+
Let the expiry-time be the result of parsing the attribute-value as
1055
+
cookie-date (see Section 5.1.1).
1057
+
If the attribute-value failed to parse as a cookie date, ignore the
1060
+
If the expiry-time is later than the last date the user agent can
1061
+
represent, the user agent MAY replace the expiry-time with the last
1062
+
representable date.
1066
+
Barth Standards Track [Page 19]
1068
+
RFC 6265 HTTP State Management Mechanism April 2011
1071
+
If the expiry-time is earlier than the earliest date the user agent
1072
+
can represent, the user agent MAY replace the expiry-time with the
1073
+
earliest representable date.
1075
+
Append an attribute to the cookie-attribute-list with an attribute-
1076
+
name of Expires and an attribute-value of expiry-time.
1078
+
5.2.2. The Max-Age Attribute
1080
+
If the attribute-name case-insensitively matches the string "Max-
1081
+
Age", the user agent MUST process the cookie-av as follows.
1083
+
If the first character of the attribute-value is not a DIGIT or a "-"
1084
+
character, ignore the cookie-av.
1086
+
If the remainder of attribute-value contains a non-DIGIT character,
1087
+
ignore the cookie-av.
1089
+
Let delta-seconds be the attribute-value converted to an integer.
1091
+
If delta-seconds is less than or equal to zero (0), let expiry-time
1092
+
be the earliest representable date and time. Otherwise, let the
1093
+
expiry-time be the current date and time plus delta-seconds seconds.
1095
+
Append an attribute to the cookie-attribute-list with an attribute-
1096
+
name of Max-Age and an attribute-value of expiry-time.
1098
+
5.2.3. The Domain Attribute
1100
+
If the attribute-name case-insensitively matches the string "Domain",
1101
+
the user agent MUST process the cookie-av as follows.
1103
+
If the attribute-value is empty, the behavior is undefined. However,
1104
+
the user agent SHOULD ignore the cookie-av entirely.
1106
+
If the first character of the attribute-value string is %x2E ("."):
1108
+
Let cookie-domain be the attribute-value without the leading %x2E
1113
+
Let cookie-domain be the entire attribute-value.
1115
+
Convert the cookie-domain to lower case.
1117
+
Append an attribute to the cookie-attribute-list with an attribute-
1118
+
name of Domain and an attribute-value of cookie-domain.
1122
+
Barth Standards Track [Page 20]
1124
+
RFC 6265 HTTP State Management Mechanism April 2011
1127
+
5.2.4. The Path Attribute
1129
+
If the attribute-name case-insensitively matches the string "Path",
1130
+
the user agent MUST process the cookie-av as follows.
1132
+
If the attribute-value is empty or if the first character of the
1133
+
attribute-value is not %x2F ("/"):
1135
+
Let cookie-path be the default-path.
1139
+
Let cookie-path be the attribute-value.
1141
+
Append an attribute to the cookie-attribute-list with an attribute-
1142
+
name of Path and an attribute-value of cookie-path.
1144
+
5.2.5. The Secure Attribute
1146
+
If the attribute-name case-insensitively matches the string "Secure",
1147
+
the user agent MUST append an attribute to the cookie-attribute-list
1148
+
with an attribute-name of Secure and an empty attribute-value.
1150
+
5.2.6. The HttpOnly Attribute
1152
+
If the attribute-name case-insensitively matches the string
1153
+
"HttpOnly", the user agent MUST append an attribute to the cookie-
1154
+
attribute-list with an attribute-name of HttpOnly and an empty
1157
+
5.3. Storage Model
1159
+
The user agent stores the following fields about each cookie: name,
1160
+
value, expiry-time, domain, path, creation-time, last-access-time,
1161
+
persistent-flag, host-only-flag, secure-only-flag, and http-only-
1164
+
When the user agent "receives a cookie" from a request-uri with name
1165
+
cookie-name, value cookie-value, and attributes cookie-attribute-
1166
+
list, the user agent MUST process the cookie as follows:
1168
+
1. A user agent MAY ignore a received cookie in its entirety. For
1169
+
example, the user agent might wish to block receiving cookies
1170
+
from "third-party" responses or the user agent might not wish to
1171
+
store cookies that exceed some size.
1178
+
Barth Standards Track [Page 21]
1180
+
RFC 6265 HTTP State Management Mechanism April 2011
1183
+
2. Create a new cookie with name cookie-name, value cookie-value.
1184
+
Set the creation-time and the last-access-time to the current
1187
+
3. If the cookie-attribute-list contains an attribute with an
1188
+
attribute-name of "Max-Age":
1190
+
Set the cookie's persistent-flag to true.
1192
+
Set the cookie's expiry-time to attribute-value of the last
1193
+
attribute in the cookie-attribute-list with an attribute-name
1196
+
Otherwise, if the cookie-attribute-list contains an attribute
1197
+
with an attribute-name of "Expires" (and does not contain an
1198
+
attribute with an attribute-name of "Max-Age"):
1200
+
Set the cookie's persistent-flag to true.
1202
+
Set the cookie's expiry-time to attribute-value of the last
1203
+
attribute in the cookie-attribute-list with an attribute-name
1208
+
Set the cookie's persistent-flag to false.
1210
+
Set the cookie's expiry-time to the latest representable
1213
+
4. If the cookie-attribute-list contains an attribute with an
1214
+
attribute-name of "Domain":
1216
+
Let the domain-attribute be the attribute-value of the last
1217
+
attribute in the cookie-attribute-list with an attribute-name
1222
+
Let the domain-attribute be the empty string.
1224
+
5. If the user agent is configured to reject "public suffixes" and
1225
+
the domain-attribute is a public suffix:
1227
+
If the domain-attribute is identical to the canonicalized
1230
+
Let the domain-attribute be the empty string.
1234
+
Barth Standards Track [Page 22]
1236
+
RFC 6265 HTTP State Management Mechanism April 2011
1241
+
Ignore the cookie entirely and abort these steps.
1243
+
NOTE: A "public suffix" is a domain that is controlled by a
1244
+
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
1245
+
This step is essential for preventing attacker.com from
1246
+
disrupting the integrity of example.com by setting a cookie
1247
+
with a Domain attribute of "com". Unfortunately, the set of
1248
+
public suffixes (also known as "registry controlled domains")
1249
+
changes over time. If feasible, user agents SHOULD use an
1250
+
up-to-date public suffix list, such as the one maintained by
1251
+
the Mozilla project at <http://publicsuffix.org/>.
1253
+
6. If the domain-attribute is non-empty:
1255
+
If the canonicalized request-host does not domain-match the
1258
+
Ignore the cookie entirely and abort these steps.
1262
+
Set the cookie's host-only-flag to false.
1264
+
Set the cookie's domain to the domain-attribute.
1268
+
Set the cookie's host-only-flag to true.
1270
+
Set the cookie's domain to the canonicalized request-host.
1272
+
7. If the cookie-attribute-list contains an attribute with an
1273
+
attribute-name of "Path", set the cookie's path to attribute-
1274
+
value of the last attribute in the cookie-attribute-list with an
1275
+
attribute-name of "Path". Otherwise, set the cookie's path to
1276
+
the default-path of the request-uri.
1278
+
8. If the cookie-attribute-list contains an attribute with an
1279
+
attribute-name of "Secure", set the cookie's secure-only-flag to
1280
+
true. Otherwise, set the cookie's secure-only-flag to false.
1282
+
9. If the cookie-attribute-list contains an attribute with an
1283
+
attribute-name of "HttpOnly", set the cookie's http-only-flag to
1284
+
true. Otherwise, set the cookie's http-only-flag to false.
1290
+
Barth Standards Track [Page 23]
1292
+
RFC 6265 HTTP State Management Mechanism April 2011
1295
+
10. If the cookie was received from a "non-HTTP" API and the
1296
+
cookie's http-only-flag is set, abort these steps and ignore the
1299
+
11. If the cookie store contains a cookie with the same name,
1300
+
domain, and path as the newly created cookie:
1302
+
1. Let old-cookie be the existing cookie with the same name,
1303
+
domain, and path as the newly created cookie. (Notice that
1304
+
this algorithm maintains the invariant that there is at most
1307
+
2. If the newly created cookie was received from a "non-HTTP"
1308
+
API and the old-cookie's http-only-flag is set, abort these
1309
+
steps and ignore the newly created cookie entirely.
1311
+
3. Update the creation-time of the newly created cookie to
1312
+
match the creation-time of the old-cookie.
1314
+
4. Remove the old-cookie from the cookie store.
1316
+
12. Insert the newly created cookie into the cookie store.
1318
+
A cookie is "expired" if the cookie has an expiry date in the past.
1320
+
The user agent MUST evict all expired cookies from the cookie store
1321
+
if, at any time, an expired cookie exists in the cookie store.
1323
+
At any time, the user agent MAY "remove excess cookies" from the
1324
+
cookie store if the number of cookies sharing a domain field exceeds
1325
+
some implementation-defined upper bound (such as 50 cookies).
1327
+
At any time, the user agent MAY "remove excess cookies" from the
1328
+
cookie store if the cookie store exceeds some predetermined upper
1329
+
bound (such as 3000 cookies).
1331
+
When the user agent removes excess cookies from the cookie store, the
1332
+
user agent MUST evict cookies in the following priority order:
1334
+
1. Expired cookies.
1336
+
2. Cookies that share a domain field with more than a predetermined
1337
+
number of other cookies.
1341
+
If two cookies have the same removal priority, the user agent MUST
1342
+
evict the cookie with the earliest last-access date first.
1346
+
Barth Standards Track [Page 24]
1348
+
RFC 6265 HTTP State Management Mechanism April 2011
1351
+
When "the current session is over" (as defined by the user agent),
1352
+
the user agent MUST remove from the cookie store all cookies with the
1353
+
persistent-flag set to false.
1355
+
5.4. The Cookie Header
1357
+
The user agent includes stored cookies in the Cookie HTTP request
1360
+
When the user agent generates an HTTP request, the user agent MUST
1361
+
NOT attach more than one Cookie header field.
1363
+
A user agent MAY omit the Cookie header in its entirety. For
1364
+
example, the user agent might wish to block sending cookies during
1365
+
"third-party" requests from setting cookies (see Section 7.1).
1367
+
If the user agent does attach a Cookie header field to an HTTP
1368
+
request, the user agent MUST send the cookie-string (defined below)
1369
+
as the value of the header field.
1371
+
The user agent MUST use an algorithm equivalent to the following
1372
+
algorithm to compute the "cookie-string" from a cookie store and a
1375
+
1. Let cookie-list be the set of cookies from the cookie store that
1376
+
meets all of the following requirements:
1380
+
The cookie's host-only-flag is true and the canonicalized
1381
+
request-host is identical to the cookie's domain.
1385
+
The cookie's host-only-flag is false and the canonicalized
1386
+
request-host domain-matches the cookie's domain.
1388
+
* The request-uri's path path-matches the cookie's path.
1390
+
* If the cookie's secure-only-flag is true, then the request-
1391
+
uri's scheme must denote a "secure" protocol (as defined by
1394
+
NOTE: The notion of a "secure" protocol is not defined by
1395
+
this document. Typically, user agents consider a protocol
1396
+
secure if the protocol makes use of transport-layer
1402
+
Barth Standards Track [Page 25]
1404
+
RFC 6265 HTTP State Management Mechanism April 2011
1407
+
security, such as SSL or TLS. For example, most user
1408
+
agents consider "https" to be a scheme that denotes a
1411
+
* If the cookie's http-only-flag is true, then exclude the
1412
+
cookie if the cookie-string is being generated for a "non-
1413
+
HTTP" API (as defined by the user agent).
1415
+
2. The user agent SHOULD sort the cookie-list in the following
1418
+
* Cookies with longer paths are listed before cookies with
1421
+
* Among cookies that have equal-length path fields, cookies with
1422
+
earlier creation-times are listed before cookies with later
1425
+
NOTE: Not all user agents sort the cookie-list in this order, but
1426
+
this order reflects common practice when this document was
1427
+
written, and, historically, there have been servers that
1428
+
(erroneously) depended on this order.
1430
+
3. Update the last-access-time of each cookie in the cookie-list to
1431
+
the current date and time.
1433
+
4. Serialize the cookie-list into a cookie-string by processing each
1434
+
cookie in the cookie-list in order:
1436
+
1. Output the cookie's name, the %x3D ("=") character, and the
1439
+
2. If there is an unprocessed cookie in the cookie-list, output
1440
+
the characters %x3B and %x20 ("; ").
1442
+
NOTE: Despite its name, the cookie-string is actually a sequence of
1443
+
octets, not a sequence of characters. To convert the cookie-string
1444
+
(or components thereof) into a sequence of characters (e.g., for
1445
+
presentation to the user), the user agent might wish to try using the
1446
+
UTF-8 character encoding [RFC3629] to decode the octet sequence.
1447
+
This decoding might fail, however, because not every sequence of
1448
+
octets is valid UTF-8.
1458
+
Barth Standards Track [Page 26]
1460
+
RFC 6265 HTTP State Management Mechanism April 2011
1463
+
6. Implementation Considerations
1467
+
Practical user agent implementations have limits on the number and
1468
+
size of cookies that they can store. General-use user agents SHOULD
1469
+
provide each of the following minimum capabilities:
1471
+
o At least 4096 bytes per cookie (as measured by the sum of the
1472
+
length of the cookie's name, value, and attributes).
1474
+
o At least 50 cookies per domain.
1476
+
o At least 3000 cookies total.
1478
+
Servers SHOULD use as few and as small cookies as possible to avoid
1479
+
reaching these implementation limits and to minimize network
1480
+
bandwidth due to the Cookie header being included in every request.
1482
+
Servers SHOULD gracefully degrade if the user agent fails to return
1483
+
one or more cookies in the Cookie header because the user agent might
1484
+
evict any cookie at any time on orders from the user.
1486
+
6.2. Application Programming Interfaces
1488
+
One reason the Cookie and Set-Cookie headers use such esoteric syntax
1489
+
is that many platforms (both in servers and user agents) provide a
1490
+
string-based application programming interface (API) to cookies,
1491
+
requiring application-layer programmers to generate and parse the
1492
+
syntax used by the Cookie and Set-Cookie headers, which many
1493
+
programmers have done incorrectly, resulting in interoperability
1496
+
Instead of providing string-based APIs to cookies, platforms would be
1497
+
well-served by providing more semantic APIs. It is beyond the scope
1498
+
of this document to recommend specific API designs, but there are
1499
+
clear benefits to accepting an abstract "Date" object instead of a
1500
+
serialized date string.
1502
+
6.3. IDNA Dependency and Migration
1504
+
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are
1505
+
differences between the two specifications, and thus there can be
1506
+
differences in processing (e.g., converting) domain name labels that
1507
+
have been registered under one from those registered under the other.
1508
+
There will be a transition period of some time during which IDNA2003-
1509
+
based domain name labels will exist in the wild. User agents SHOULD
1510
+
implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895]
1514
+
Barth Standards Track [Page 27]
1516
+
RFC 6265 HTTP State Management Mechanism April 2011
1519
+
in order to facilitate their IDNA transition. If a user agent does
1520
+
not implement IDNA2008, the user agent MUST implement IDNA2003
1523
+
7. Privacy Considerations
1525
+
Cookies are often criticized for letting servers track users. For
1526
+
example, a number of "web analytics" companies use cookies to
1527
+
recognize when a user returns to a web site or visits another web
1528
+
site. Although cookies are not the only mechanism servers can use to
1529
+
track users across HTTP requests, cookies facilitate tracking because
1530
+
they are persistent across user agent sessions and can be shared
1533
+
7.1. Third-Party Cookies
1535
+
Particularly worrisome are so-called "third-party" cookies. In
1536
+
rendering an HTML document, a user agent often requests resources
1537
+
from other servers (such as advertising networks). These third-party
1538
+
servers can use cookies to track the user even if the user never
1539
+
visits the server directly. For example, if a user visits a site
1540
+
that contains content from a third party and then later visits
1541
+
another site that contains content from the same third party, the
1542
+
third party can track the user between the two sites.
1544
+
Some user agents restrict how third-party cookies behave. For
1545
+
example, some of these user agents refuse to send the Cookie header
1546
+
in third-party requests. Others refuse to process the Set-Cookie
1547
+
header in responses to third-party requests. User agents vary widely
1548
+
in their third-party cookie policies. This document grants user
1549
+
agents wide latitude to experiment with third-party cookie policies
1550
+
that balance the privacy and compatibility needs of their users.
1551
+
However, this document does not endorse any particular third-party
1554
+
Third-party cookie blocking policies are often ineffective at
1555
+
achieving their privacy goals if servers attempt to work around their
1556
+
restrictions to track users. In particular, two collaborating
1557
+
servers can often track users without using cookies at all by
1558
+
injecting identifying information into dynamic URLs.
1560
+
7.2. User Controls
1562
+
User agents SHOULD provide users with a mechanism for managing the
1563
+
cookies stored in the cookie store. For example, a user agent might
1564
+
let users delete all cookies received during a specified time period
1570
+
Barth Standards Track [Page 28]
1572
+
RFC 6265 HTTP State Management Mechanism April 2011
1575
+
or all the cookies related to a particular domain. In addition, many
1576
+
user agents include a user interface element that lets users examine
1577
+
the cookies stored in their cookie store.
1579
+
User agents SHOULD provide users with a mechanism for disabling
1580
+
cookies. When cookies are disabled, the user agent MUST NOT include
1581
+
a Cookie header in outbound HTTP requests and the user agent MUST NOT
1582
+
process Set-Cookie headers in inbound HTTP responses.
1584
+
Some user agents provide users the option of preventing persistent
1585
+
storage of cookies across sessions. When configured thusly, user
1586
+
agents MUST treat all received cookies as if the persistent-flag were
1587
+
set to false. Some popular user agents expose this functionality via
1588
+
"private browsing" mode [Aggarwal2010].
1590
+
Some user agents provide users with the ability to approve individual
1591
+
writes to the cookie store. In many common usage scenarios, these
1592
+
controls generate a large number of prompts. However, some privacy-
1593
+
conscious users find these controls useful nonetheless.
1595
+
7.3. Expiration Dates
1597
+
Although servers can set the expiration date for cookies to the
1598
+
distant future, most user agents do not actually retain cookies for
1599
+
multiple decades. Rather than choosing gratuitously long expiration
1600
+
periods, servers SHOULD promote user privacy by selecting reasonable
1601
+
cookie expiration periods based on the purpose of the cookie. For
1602
+
example, a typical session identifier might reasonably be set to
1603
+
expire in two weeks.
1605
+
8. Security Considerations
1609
+
Cookies have a number of security pitfalls. This section overviews a
1610
+
few of the more salient issues.
1612
+
In particular, cookies encourage developers to rely on ambient
1613
+
authority for authentication, often becoming vulnerable to attacks
1614
+
such as cross-site request forgery [CSRF]. Also, when storing
1615
+
session identifiers in cookies, developers often create session
1616
+
fixation vulnerabilities.
1618
+
Transport-layer encryption, such as that employed in HTTPS, is
1619
+
insufficient to prevent a network attacker from obtaining or altering
1620
+
a victim's cookies because the cookie protocol itself has various
1621
+
vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
1626
+
Barth Standards Track [Page 29]
1628
+
RFC 6265 HTTP State Management Mechanism April 2011
1631
+
below). In addition, by default, cookies do not provide
1632
+
confidentiality or integrity from network attackers, even when used
1633
+
in conjunction with HTTPS.
1635
+
8.2. Ambient Authority
1637
+
A server that uses cookies to authenticate users can suffer security
1638
+
vulnerabilities because some user agents let remote parties issue
1639
+
HTTP requests from the user agent (e.g., via HTTP redirects or HTML
1640
+
forms). When issuing those requests, user agents attach cookies even
1641
+
if the remote party does not know the contents of the cookies,
1642
+
potentially letting the remote party exercise authority at an unwary
1645
+
Although this security concern goes by a number of names (e.g.,
1646
+
cross-site request forgery, confused deputy), the issue stems from
1647
+
cookies being a form of ambient authority. Cookies encourage server
1648
+
operators to separate designation (in the form of URLs) from
1649
+
authorization (in the form of cookies). Consequently, the user agent
1650
+
might supply the authorization for a resource designated by the
1651
+
attacker, possibly causing the server or its clients to undertake
1652
+
actions designated by the attacker as though they were authorized by
1655
+
Instead of using cookies for authorization, server operators might
1656
+
wish to consider entangling designation and authorization by treating
1657
+
URLs as capabilities. Instead of storing secrets in cookies, this
1658
+
approach stores secrets in URLs, requiring the remote entity to
1659
+
supply the secret itself. Although this approach is not a panacea,
1660
+
judicious application of these principles can lead to more robust
1665
+
Unless sent over a secure channel (such as TLS), the information in
1666
+
the Cookie and Set-Cookie headers is transmitted in the clear.
1668
+
1. All sensitive information conveyed in these headers is exposed to
1671
+
2. A malicious intermediary could alter the headers as they travel
1672
+
in either direction, with unpredictable results.
1674
+
3. A malicious client could alter the Cookie header before
1675
+
transmission, with unpredictable results.
1682
+
Barth Standards Track [Page 30]
1684
+
RFC 6265 HTTP State Management Mechanism April 2011
1687
+
Servers SHOULD encrypt and sign the contents of cookies (using
1688
+
whatever format the server desires) when transmitting them to the
1689
+
user agent (even when sending the cookies over a secure channel).
1690
+
However, encrypting and signing cookie contents does not prevent an
1691
+
attacker from transplanting a cookie from one user agent to another
1692
+
or from replaying the cookie at a later time.
1694
+
In addition to encrypting and signing the contents of every cookie,
1695
+
servers that require a higher level of security SHOULD use the Cookie
1696
+
and Set-Cookie headers only over a secure channel. When using
1697
+
cookies over a secure channel, servers SHOULD set the Secure
1698
+
attribute (see Section 4.1.2.5) for every cookie. If a server does
1699
+
not set the Secure attribute, the protection provided by the secure
1700
+
channel will be largely moot.
1702
+
For example, consider a webmail server that stores a session
1703
+
identifier in a cookie and is typically accessed over HTTPS. If the
1704
+
server does not set the Secure attribute on its cookies, an active
1705
+
network attacker can intercept any outbound HTTP request from the
1706
+
user agent and redirect that request to the webmail server over HTTP.
1707
+
Even if the webmail server is not listening for HTTP connections, the
1708
+
user agent will still include cookies in the request. The active
1709
+
network attacker can intercept these cookies, replay them against the
1710
+
server, and learn the contents of the user's email. If, instead, the
1711
+
server had set the Secure attribute on its cookies, the user agent
1712
+
would not have included the cookies in the clear-text request.
1714
+
8.4. Session Identifiers
1716
+
Instead of storing session information directly in a cookie (where it
1717
+
might be exposed to or replayed by an attacker), servers commonly
1718
+
store a nonce (or "session identifier") in a cookie. When the server
1719
+
receives an HTTP request with a nonce, the server can look up state
1720
+
information associated with the cookie using the nonce as a key.
1722
+
Using session identifier cookies limits the damage an attacker can
1723
+
cause if the attacker learns the contents of a cookie because the
1724
+
nonce is useful only for interacting with the server (unlike non-
1725
+
nonce cookie content, which might itself be sensitive). Furthermore,
1726
+
using a single nonce prevents an attacker from "splicing" together
1727
+
cookie content from two interactions with the server, which could
1728
+
cause the server to behave unexpectedly.
1730
+
Using session identifiers is not without risk. For example, the
1731
+
server SHOULD take care to avoid "session fixation" vulnerabilities.
1732
+
A session fixation attack proceeds in three steps. First, the
1733
+
attacker transplants a session identifier from his or her user agent
1734
+
to the victim's user agent. Second, the victim uses that session
1738
+
Barth Standards Track [Page 31]
1740
+
RFC 6265 HTTP State Management Mechanism April 2011
1743
+
identifier to interact with the server, possibly imbuing the session
1744
+
identifier with the user's credentials or confidential information.
1745
+
Third, the attacker uses the session identifier to interact with
1746
+
server directly, possibly obtaining the user's authority or
1747
+
confidential information.
1749
+
8.5. Weak Confidentiality
1751
+
Cookies do not provide isolation by port. If a cookie is readable by
1752
+
a service running on one port, the cookie is also readable by a
1753
+
service running on another port of the same server. If a cookie is
1754
+
writable by a service on one port, the cookie is also writable by a
1755
+
service running on another port of the same server. For this reason,
1756
+
servers SHOULD NOT both run mutually distrusting services on
1757
+
different ports of the same host and use cookies to store security-
1758
+
sensitive information.
1760
+
Cookies do not provide isolation by scheme. Although most commonly
1761
+
used with the http and https schemes, the cookies for a given host
1762
+
might also be available to other schemes, such as ftp and gopher.
1763
+
Although this lack of isolation by scheme is most apparent in non-
1764
+
HTTP APIs that permit access to cookies (e.g., HTML's document.cookie
1765
+
API), the lack of isolation by scheme is actually present in
1766
+
requirements for processing cookies themselves (e.g., consider
1767
+
retrieving a URI with the gopher scheme via HTTP).
1769
+
Cookies do not always provide isolation by path. Although the
1770
+
network-level protocol does not send cookies stored for one path to
1771
+
another, some user agents expose cookies via non-HTTP APIs, such as
1772
+
HTML's document.cookie API. Because some of these user agents (e.g.,
1773
+
web browsers) do not isolate resources received from different paths,
1774
+
a resource retrieved from one path might be able to access cookies
1775
+
stored for another path.
1777
+
8.6. Weak Integrity
1779
+
Cookies do not provide integrity guarantees for sibling domains (and
1780
+
their subdomains). For example, consider foo.example.com and
1781
+
bar.example.com. The foo.example.com server can set a cookie with a
1782
+
Domain attribute of "example.com" (possibly overwriting an existing
1783
+
"example.com" cookie set by bar.example.com), and the user agent will
1784
+
include that cookie in HTTP requests to bar.example.com. In the
1785
+
worst case, bar.example.com will be unable to distinguish this cookie
1786
+
from a cookie it set itself. The foo.example.com server might be
1787
+
able to leverage this ability to mount an attack against
1794
+
Barth Standards Track [Page 32]
1796
+
RFC 6265 HTTP State Management Mechanism April 2011
1799
+
Even though the Set-Cookie header supports the Path attribute, the
1800
+
Path attribute does not provide any integrity protection because the
1801
+
user agent will accept an arbitrary Path attribute in a Set-Cookie
1802
+
header. For example, an HTTP response to a request for
1803
+
http://example.com/foo/bar can set a cookie with a Path attribute of
1804
+
"/qux". Consequently, servers SHOULD NOT both run mutually
1805
+
distrusting services on different paths of the same host and use
1806
+
cookies to store security-sensitive information.
1808
+
An active network attacker can also inject cookies into the Cookie
1809
+
header sent to https://example.com/ by impersonating a response from
1810
+
http://example.com/ and injecting a Set-Cookie header. The HTTPS
1811
+
server at example.com will be unable to distinguish these cookies
1812
+
from cookies that it set itself in an HTTPS response. An active
1813
+
network attacker might be able to leverage this ability to mount an
1814
+
attack against example.com even if example.com uses HTTPS
1817
+
Servers can partially mitigate these attacks by encrypting and
1818
+
signing the contents of their cookies. However, using cryptography
1819
+
does not mitigate the issue completely because an attacker can replay
1820
+
a cookie he or she received from the authentic example.com server in
1821
+
the user's session, with unpredictable results.
1823
+
Finally, an attacker might be able to force the user agent to delete
1824
+
cookies by storing a large number of cookies. Once the user agent
1825
+
reaches its storage limit, the user agent will be forced to evict
1826
+
some cookies. Servers SHOULD NOT rely upon user agents retaining
1829
+
8.7. Reliance on DNS
1831
+
Cookies rely upon the Domain Name System (DNS) for security. If the
1832
+
DNS is partially or fully compromised, the cookie protocol might fail
1833
+
to provide the security properties required by applications.
1835
+
9. IANA Considerations
1837
+
The permanent message header field registry (see [RFC3864]) has been
1838
+
updated with the following registrations.
1850
+
Barth Standards Track [Page 33]
1852
+
RFC 6265 HTTP State Management Mechanism April 2011
1857
+
Header field name: Cookie
1859
+
Applicable protocol: http
1863
+
Author/Change controller: IETF
1865
+
Specification document: this specification (Section 5.4)
1869
+
Header field name: Set-Cookie
1871
+
Applicable protocol: http
1875
+
Author/Change controller: IETF
1877
+
Specification document: this specification (Section 5.2)
1881
+
Header field name: Cookie2
1883
+
Applicable protocol: http
1887
+
Author/Change controller: IETF
1889
+
Specification document: [RFC2965]
1893
+
Header field name: Set-Cookie2
1895
+
Applicable protocol: http
1899
+
Author/Change controller: IETF
1901
+
Specification document: [RFC2965]
1906
+
Barth Standards Track [Page 34]
1908
+
RFC 6265 HTTP State Management Mechanism April 2011
1913
+
10.1. Normative References
1915
+
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1916
+
STD 13, RFC 1034, November 1987.
1918
+
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
1919
+
and Support", STD 3, RFC 1123, October 1989.
1921
+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1922
+
Requirement Levels", BCP 14, RFC 2119, March 1997.
1924
+
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1925
+
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1926
+
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1928
+
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
1929
+
"Internationalizing Domain Names in Applications (IDNA)",
1930
+
RFC 3490, March 2003.
1932
+
See Section 6.3 for an explanation why the normative
1933
+
reference to an obsoleted specification is needed.
1935
+
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
1936
+
Application Protocol Collation Registry", RFC 4790,
1939
+
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1940
+
Specifications: ABNF", STD 68, RFC 5234, January 2008.
1942
+
[RFC5890] Klensin, J., "Internationalized Domain Names for
1943
+
Applications (IDNA): Definitions and Document Framework",
1944
+
RFC 5890, August 2010.
1946
+
[USASCII] American National Standards Institute, "Coded Character
1947
+
Set -- 7-bit American Standard Code for Information
1948
+
Interchange", ANSI X3.4, 1986.
1950
+
10.2. Informative References
1952
+
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
1953
+
Mechanism", RFC 2109, February 1997.
1955
+
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
1956
+
Mechanism", RFC 2965, October 2000.
1962
+
Barth Standards Track [Page 35]
1964
+
RFC 6265 HTTP State Management Mechanism April 2011
1967
+
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1969
+
[Netscape] Netscape Communications Corp., "Persistent Client State --
1970
+
HTTP Cookies", 1999, <http://web.archive.org/web/
1971
+
20020803110822/http://wp.netscape.com/newsref/std/
1972
+
cookie_spec.html>.
1974
+
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
1975
+
Politics", ACM Transactions on Internet Technology Vol. 1,
1976
+
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
1978
+
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1979
+
10646", STD 63, RFC 3629, November 2003.
1981
+
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
1982
+
Encodings", RFC 4648, October 2006.
1984
+
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
1985
+
Procedures for Message Header Fields", BCP 90, RFC 3864,
1988
+
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
1989
+
Internationalized Domain Names in Applications (IDNA)
1990
+
2008", RFC 5895, September 2010.
1992
+
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
1993
+
Processing", Unicode Technical Standards # 46, 2010,
1994
+
<http://unicode.org/reports/tr46/>.
1996
+
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
1997
+
for Cross-Site Request Forgery", 2008,
1998
+
<http://portal.acm.org/citation.cfm?id=1455770.1455782>.
2001
+
Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
2002
+
"An Analysis of Private Browsing Modes in Modern
2003
+
Browsers", 2010, <http://www.usenix.org/events/sec10/tech/
2004
+
full_papers/Aggarwal.pdf>.
2018
+
Barth Standards Track [Page 36]
2020
+
RFC 6265 HTTP State Management Mechanism April 2011
2023
+
Appendix A. Acknowledgements
2025
+
This document borrows heavily from RFC 2109 [RFC2109]. We are
2026
+
indebted to David M. Kristol and Lou Montulli for their efforts to
2027
+
specify cookies. David M. Kristol, in particular, provided
2028
+
invaluable advice on navigating the IETF process. We would also like
2029
+
to thank Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry,
2030
+
corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van
2031
+
Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim
2032
+
Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller,
2033
+
Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre,
2034
+
Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro
2035
+
Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their
2036
+
valuable feedback on this document.
2041
+
University of California, Berkeley
2043
+
EMail: abarth@eecs.berkeley.edu
2044
+
URI: http://www.adambarth.com/
2074
+
Barth Standards Track [Page 37]
anil.recoil.org