idnits 2.17.1 draft-ietf-httpbis-rfc6265bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6265, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document obsoletes RFC2965, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 25, 2017) is 2520 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group A. Barth 3 Internet-Draft M. West 4 Obsoletes: 6265 (if approved) Google, Inc 5 Intended status: Standards Track April 25, 2017 6 Expires: October 27, 2017 8 HTTP State Management Mechanism 9 draft-ietf-httpbis-rfc6265bis-01 11 Abstract 13 This document defines the HTTP Cookie and Set-Cookie header fields. 14 These header fields can be used by HTTP servers to store state 15 (called cookies) at HTTP user agents, letting the servers maintain a 16 stateful session over the mostly stateless HTTP protocol. Although 17 cookies have many historical infelicities that degrade their security 18 and privacy, the Cookie and Set-Cookie header fields are widely used 19 on the Internet. This document obsoletes RFC 2965. 21 Note to Readers 23 Discussion of this draft takes place on the HTTP working group 24 mailing list (ietf-http-wg@w3.org), which is archived at 25 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 27 Working Group information can be found at http://httpwg.github.io/ ; 28 source code and issues list for this draft can be found at 29 https://github.com/httpwg/http-extensions/labels/6265bis . 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 27, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 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 73 than English. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 80 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 81 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 82 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 84 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 8 85 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 87 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10 88 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 13 89 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 14 92 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 15 93 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 15 94 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15 95 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 17 96 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 18 97 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 18 98 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 19 99 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 21 100 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 21 101 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . 22 102 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . 22 103 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . 23 104 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 23 105 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23 106 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 27 107 6. Implementation Considerations . . . . . . . . . . . . . . . . 29 108 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 6.2. Application Programming Interfaces . . . . . . . . . . . 29 110 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 30 111 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 112 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 30 113 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 31 114 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 31 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 116 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 32 117 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 32 118 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 33 119 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 33 120 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 34 121 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 35 122 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 35 123 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 124 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 36 125 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 36 126 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 127 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 128 10.2. Informative References . . . . . . . . . . . . . . . . . 37 129 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 39 130 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 39 131 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 39 132 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 135 1. Introduction 137 This document defines the HTTP Cookie and Set-Cookie header fields. 138 Using the Set-Cookie header field, an HTTP server can pass name/value 139 pairs and associated metadata (called cookies) to a user agent. When 140 the user agent makes subsequent requests to the server, the user 141 agent uses the metadata and other information to determine whether to 142 return the name/value pairs in the Cookie header. 144 Although simple on their surface, cookies have a number of 145 complexities. For example, the server indicates a scope for each 146 cookie when sending it to the user agent. The scope indicates the 147 maximum amount of time in which the user agent should return the 148 cookie, the servers to which the user agent should return the cookie, 149 and the URI schemes for which the cookie is applicable. 151 For historical reasons, cookies contain a number of security and 152 privacy infelicities. For example, a server can indicate that a 153 given cookie is intended for "secure" connections, but the Secure 154 attribute does not provide integrity in the presence of an active 155 network attacker. Similarly, cookies for a given host are shared 156 across all the ports on that host, even though the usual "same-origin 157 policy" used by web browsers isolates content retrieved via different 158 ports. 160 There are two audiences for this specification: developers of cookie- 161 generating servers and developers of cookie-consuming user agents. 163 To maximize interoperability with user agents, servers SHOULD limit 164 themselves to the well-behaved profile defined in Section 4 when 165 generating cookies. 167 User agents MUST implement the more liberal processing rules defined 168 in Section 5, in order to maximize interoperability with existing 169 servers that do not conform to the well-behaved profile defined in 170 Section 4. 172 This document specifies the syntax and semantics of these headers as 173 they are actually used on the Internet. In particular, this document 174 does not create new syntax or semantics beyond those in use today. 175 The recommendations for cookie generation provided in Section 4 176 represent a preferred subset of current server behavior, and even the 177 more liberal cookie processing algorithm provided in Section 5 does 178 not recommend all of the syntactic and semantic variations in use 179 today. Where some existing software differs from the recommended 180 protocol in significant ways, the document contains a note explaining 181 the difference. 183 Prior to this document, there were at least three descriptions of 184 cookies: the so-called "Netscape cookie specification" [Netscape], 185 RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these 186 documents describe how the Cookie and Set-Cookie headers are actually 187 used on the Internet (see [Kri2001] for historical context). In 188 relation to previous IETF specifications of HTTP state management 189 mechanisms, this document requests the following actions: 191 1. Change the status of [RFC2109] to Historic (it has already been 192 obsoleted by [RFC2965]). 194 2. Change the status of [RFC2965] to Historic. 196 3. Indicate that [RFC2965] has been obsoleted by this document. 198 In particular, in moving RFC 2965 to Historic and obsoleting it, this 199 document deprecates the use of the Cookie2 and Set-Cookie2 header 200 fields. 202 2. Conventions 204 2.1. Conformance Criteria 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 Requirements phrased in the imperative as part of algorithms (such as 211 "strip any leading space characters" or "return false and abort these 212 steps") are to be interpreted with the meaning of the key word 213 ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm. 215 Conformance requirements phrased as algorithms or specific steps can 216 be implemented in any manner, so long as the end result is 217 equivalent. In particular, the algorithms defined in this 218 specification are intended to be easy to understand and are not 219 intended to be performant. 221 2.2. Syntax Notation 223 This specification uses the Augmented Backus-Naur Form (ABNF) 224 notation of [RFC5234]. 226 The following core rules are included by reference, as defined in 227 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 228 (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 229 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), 230 OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB 231 (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible 232 [USASCII] character), and WSP (whitespace). 234 The OWS (optional whitespace) rule is used where zero or more linear 235 whitespace characters MAY appear: 237 OWS = *( [ obs-fold ] WSP ) 238 ; "optional" whitespace 239 obs-fold = CRLF 241 OWS SHOULD either not be produced or be produced as a single SP 242 character. 244 2.3. Terminology 246 The terms "user agent", "client", "server", "proxy", and "origin 247 server" have the same meaning as in the HTTP/1.1 specification 248 ([RFC2616], Section 1.3). 250 The request-host is the name of the host, as known by the user agent, 251 to which the user agent is sending an HTTP request or from which it 252 is receiving an HTTP response (i.e., the name of the host to which it 253 sent the corresponding HTTP request). 255 The term request-uri is defined in Section 5.1.2 of [RFC2616]. 257 Two sequences of octets are said to case-insensitively match each 258 other if and only if they are equivalent under the i;ascii-casemap 259 collation defined in [RFC4790]. 261 The term string means a sequence of non-NUL octets. 263 3. Overview 265 This section outlines a way for an origin server to send state 266 information to a user agent and for the user agent to return the 267 state information to the origin server. 269 To store state, the origin server includes a Set-Cookie header in an 270 HTTP response. In subsequent requests, the user agent returns a 271 Cookie request header to the origin server. The Cookie header 272 contains cookies the user agent received in previous Set-Cookie 273 headers. The origin server is free to ignore the Cookie header or 274 use its contents for an application-defined purpose. 276 Origin servers MAY send a Set-Cookie response header with any 277 response. User agents MAY ignore Set-Cookie headers contained in 278 responses with 100-level status codes but MUST process Set-Cookie 279 headers contained in other responses (including responses with 400- 280 and 500-level status codes). An origin server can include multiple 281 Set-Cookie header fields in a single response. The presence of a 282 Cookie or a Set-Cookie header field does not preclude HTTP caches 283 from storing and reusing a response. 285 Origin servers SHOULD NOT fold multiple Set-Cookie header fields into 286 a single header field. The usual mechanism for folding HTTP headers 287 fields (i.e., as defined in [RFC2616]) might change the semantics of 288 the Set-Cookie header field because the %x2C (",") character is used 289 by Set-Cookie in a way that conflicts with such folding. 291 3.1. Examples 293 Using the Set-Cookie header, a server can send the user agent a short 294 string in an HTTP response that the user agent will return in future 295 HTTP requests that are within the scope of the cookie. For example, 296 the server can send the user agent a "session identifier" named SID 297 with the value 31d4d96e407aad42. The user agent then returns the 298 session identifier in subsequent requests. 300 == Server -> User Agent == 302 Set-Cookie: SID=31d4d96e407aad42 304 == User Agent -> Server == 306 Cookie: SID=31d4d96e407aad42 308 The server can alter the default scope of the cookie using the Path 309 and Domain attributes. For example, the server can instruct the user 310 agent to return the cookie to every path and every subdomain of 311 example.com. 313 == Server -> User Agent == 315 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com 317 == User Agent -> Server == 319 Cookie: SID=31d4d96e407aad42 321 As shown in the next example, the server can store multiple cookies 322 at the user agent. For example, the server can store a session 323 identifier as well as the user's preferred language by returning two 324 Set-Cookie header fields. Notice that the server uses the Secure and 325 HttpOnly attributes to provide additional security protections for 326 the more sensitive session identifier (see Section 4.1.2). 328 == Server -> User Agent == 330 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly 331 Set-Cookie: lang=en-US; Path=/; Domain=example.com 333 == User Agent -> Server == 335 Cookie: SID=31d4d96e407aad42; lang=en-US 337 Notice that the Cookie header above contains two cookies, one named 338 SID and one named lang. If the server wishes the user agent to 339 persist the cookie over multiple "sessions" (e.g., user agent 340 restarts), the server can specify an expiration date in the Expires 341 attribute. Note that the user agent might delete the cookie before 342 the expiration date if the user agent's cookie store exceeds its 343 quota or if the user manually deletes the server's cookie. 345 == Server -> User Agent == 347 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 349 == User Agent -> Server == 351 Cookie: SID=31d4d96e407aad42; lang=en-US 353 Finally, to remove a cookie, the server returns a Set-Cookie header 354 with an expiration date in the past. The server will be successful 355 in removing the cookie only if the Path and the Domain attribute in 356 the Set-Cookie header match the values used when the cookie was 357 created. 359 == Server -> User Agent == 361 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 363 == User Agent -> Server == 365 Cookie: SID=31d4d96e407aad42 367 4. Server Requirements 369 This section describes the syntax and semantics of a well-behaved 370 profile of the Cookie and Set-Cookie headers. 372 4.1. Set-Cookie 374 The Set-Cookie HTTP response header is used to send cookies from the 375 server to the user agent. 377 4.1.1. Syntax 379 Informally, the Set-Cookie response header contains the header name 380 "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with 381 a name-value-pair, followed by zero or more attribute-value pairs. 382 Servers SHOULD NOT send Set-Cookie headers that fail to conform to 383 the following grammar: 385 set-cookie-header = "Set-Cookie:" SP set-cookie-string 386 set-cookie-string = cookie-pair *( ";" SP cookie-av ) 387 cookie-pair = cookie-name "=" cookie-value 388 cookie-name = token 389 cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) 390 cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E 391 ; US-ASCII characters excluding CTLs, 392 ; whitespace DQUOTE, comma, semicolon, 393 ; and backslash 394 token = 396 cookie-av = expires-av / max-age-av / domain-av / 397 path-av / secure-av / httponly-av / 398 extension-av 399 expires-av = "Expires=" sane-cookie-date 400 sane-cookie-date = 401 402 max-age-av = "Max-Age=" non-zero-digit *DIGIT 403 ; In practice, both expires-av and max-age-av 404 ; are limited to dates representable by the 405 ; user agent. 406 non-zero-digit = %x31-39 407 ; digits 1 through 9 408 domain-av = "Domain=" domain-value 409 domain-value = 410 ; defined in [RFC1034], Section 3.5, as 411 ; enhanced by [RFC1123], Section 2.1 412 path-av = "Path=" path-value 413 path-value = *av-octet 414 secure-av = "Secure" 415 httponly-av = "HttpOnly" 416 extension-av = *av-octet 417 av-octet = %x20-3A / %x3C-7E 418 ; any CHAR except CTLs or ";" 420 Note that some of the grammatical terms above reference documents 421 that use different grammatical notations than this document (which 422 uses ABNF from [RFC5234]). 424 The semantics of the cookie-value are not defined by this document. 426 To maximize compatibility with user agents, servers that wish to 427 store arbitrary data in a cookie-value SHOULD encode that data, for 428 example, using Base64 [RFC4648]. 430 The portions of the set-cookie-string produced by the cookie-av term 431 are known as attributes. To maximize compatibility with user agents, 432 servers SHOULD NOT produce two attributes with the same name in the 433 same set-cookie-string. (See Section 5.3 for how user agents handle 434 this case.) 436 Servers SHOULD NOT include more than one Set-Cookie header field in 437 the same response with the same cookie-name. (See Section 5.2 for 438 how user agents handle this case.) 440 If a server sends multiple responses containing Set-Cookie headers 441 concurrently to the user agent (e.g., when communicating with the 442 user agent over multiple sockets), these responses create a "race 443 condition" that can lead to unpredictable behavior. 445 NOTE: Some existing user agents differ in their interpretation of 446 two-digit years. To avoid compatibility issues, servers SHOULD use 447 the rfc1123-date format, which requires a four-digit year. 449 NOTE: Some user agents store and process dates in cookies as 32-bit 450 UNIX time_t values. Implementation bugs in the libraries supporting 451 time_t processing on some systems might cause such user agents to 452 process dates after the year 2038 incorrectly. 454 4.1.2. Semantics (Non-Normative) 456 This section describes simplified semantics of the Set-Cookie header. 457 These semantics are detailed enough to be useful for understanding 458 the most common uses of cookies by servers. The full semantics are 459 described in Section 5. 461 When the user agent receives a Set-Cookie header, the user agent 462 stores the cookie together with its attributes. Subsequently, when 463 the user agent makes an HTTP request, the user agent includes the 464 applicable, non-expired cookies in the Cookie header. 466 If the user agent receives a new cookie with the same cookie-name, 467 domain-value, and path-value as a cookie that it has already stored, 468 the existing cookie is evicted and replaced with the new cookie. 469 Notice that servers can delete cookies by sending the user agent a 470 new cookie with an Expires attribute with a value in the past. 472 Unless the cookie's attributes indicate otherwise, the cookie is 473 returned only to the origin server (and not, for example, to any 474 subdomains), and it expires at the end of the current session (as 475 defined by the user agent). User agents ignore unrecognized cookie 476 attributes (but not the entire cookie). 478 4.1.2.1. The Expires Attribute 480 The Expires attribute indicates the maximum lifetime of the cookie, 481 represented as the date and time at which the cookie expires. The 482 user agent is not required to retain the cookie until the specified 483 date has passed. In fact, user agents often evict cookies due to 484 memory pressure or privacy concerns. 486 4.1.2.2. The Max-Age Attribute 488 The Max-Age attribute indicates the maximum lifetime of the cookie, 489 represented as the number of seconds until the cookie expires. The 490 user agent is not required to retain the cookie for the specified 491 duration. In fact, user agents often evict cookies due to memory 492 pressure or privacy concerns. 494 NOTE: Some existing user agents do not support the Max-Age attribute. 495 User agents that do not support the Max-Age attribute ignore the 496 attribute. 498 If a cookie has both the Max-Age and the Expires attribute, the Max- 499 Age attribute has precedence and controls the expiration date of the 500 cookie. If a cookie has neither the Max-Age nor the Expires 501 attribute, the user agent will retain the cookie until "the current 502 session is over" (as defined by the user agent). 504 4.1.2.3. The Domain Attribute 506 The Domain attribute specifies those hosts to which the cookie will 507 be sent. For example, if the value of the Domain attribute is 508 "example.com", the user agent will include the cookie in the Cookie 509 header when making HTTP requests to example.com, www.example.com, and 510 www.corp.example.com. (Note that a leading %x2E ("."), if present, 511 is ignored even though that character is not permitted, but a 512 trailing %x2E ("."), if present, will cause the user agent to ignore 513 the attribute.) If the server omits the Domain attribute, the user 514 agent will return the cookie only to the origin server. 516 WARNING: Some existing user agents treat an absent Domain attribute 517 as if the Domain attribute were present and contained the current 518 host name. For example, if example.com returns a Set-Cookie header 519 without a Domain attribute, these user agents will erroneously send 520 the cookie to www.example.com as well. 522 The user agent will reject cookies unless the Domain attribute 523 specifies a scope for the cookie that would include the origin 524 server. For example, the user agent will accept a cookie with a 525 Domain attribute of "example.com" or of "foo.example.com" from 526 foo.example.com, but the user agent will not accept a cookie with a 527 Domain attribute of "bar.example.com" or of "baz.foo.example.com". 529 NOTE: For security reasons, many user agents are configured to reject 530 Domain attributes that correspond to "public suffixes". For example, 531 some user agents will reject Domain attributes of "com" or "co.uk". 532 (See Section 5.3 for more information.) 534 4.1.2.4. The Path Attribute 536 The scope of each cookie is limited to a set of paths, controlled by 537 the Path attribute. If the server omits the Path attribute, the user 538 agent will use the "directory" of the request-uri's path component as 539 the default value. (See Section 5.1.4 for more details.) 541 The user agent will include the cookie in an HTTP request only if the 542 path portion of the request-uri matches (or is a subdirectory of) the 543 cookie's Path attribute, where the %x2F ("/") character is 544 interpreted as a directory separator. 546 Although seemingly useful for isolating cookies between different 547 paths within a given host, the Path attribute cannot be relied upon 548 for security (see Section 8). 550 4.1.2.5. The Secure Attribute 552 The Secure attribute limits the scope of the cookie to "secure" 553 channels (where "secure" is defined by the user agent). When a 554 cookie has the Secure attribute, the user agent will include the 555 cookie in an HTTP request only if the request is transmitted over a 556 secure channel (typically HTTP over Transport Layer Security (TLS) 557 [RFC2818]). 559 Although seemingly useful for protecting cookies from active network 560 attackers, the Secure attribute protects only the cookie's 561 confidentiality. An active network attacker can overwrite Secure 562 cookies from an insecure channel, disrupting their integrity (see 563 Section 8.6 for more details). 565 4.1.2.6. The HttpOnly Attribute 567 The HttpOnly attribute limits the scope of the cookie to HTTP 568 requests. In particular, the attribute instructs the user agent to 569 omit the cookie when providing access to cookies via "non-HTTP" APIs 570 (such as a web browser API that exposes cookies to scripts). 572 Note that the HttpOnly attribute is independent of the Secure 573 attribute: a cookie can have both the HttpOnly and the Secure 574 attribute. 576 4.1.3. Cookie Name Prefixes 578 Section 8.5 and 8.6 of this document spell out some of the drawbacks 579 of cookies' historical implementation. In particular, it is 580 impossible for a server to have confidence that a given cookie was 581 set with a particular set of attributes. In order to provide such 582 confidence in a backwards-compatible way, two common sets of 583 requirements can be inferred from the first few characters of the 584 cookie's name. 586 The normative requirements for the prefixes described below are 587 detailed in the storage model algorithm defined in Section 5.3. 589 4.1.3.1. The "__Secure-" Prefix 591 If a cookie's name begins with a case-sensitive match for the string 592 "__Secure-", then the cookie will have been set with a "Secure" 593 attribute. 595 For example, the following "Set-Cookie" header would be rejected by a 596 conformant user agent, as it does not have a "Secure" attribute. 598 Set-Cookie: __Secure-SID=12345; Domain=example.com 600 Whereas the following "Set-Cookie" header would be accepted: 602 Set-Cookie: __Secure-SID=12345; Domain=example.com; Secure 604 4.1.3.2. The "__Host-" Prefix 606 If a cookie's name begins with a case-sensitive match for the string 607 "__Host-", then the cookie will have been set with a "Secure" 608 attribute, a "Path" attribute with a value of "/", and no "Domain" 609 attribute. 611 This combination yields a cookie that hews as closely as a cookie can 612 to treating the origin as a security boundary. The lack of a 613 "Domain" attribute ensures that the cookie's "host-only-flag" is 614 true, locking the cookie to a particular host, rather than allowing 615 it to span subdomains. Setting the "Path" to "/" means that the 616 cookie is effective for the entire host, and won't be overridden for 617 specific paths. The "Secure" attribute ensures that the cookie is 618 unaltered by non-secure origins, and won't span protocols. 620 Ports are the only piece of the origin model that "__Host-" cookies 621 continue to ignore. 623 For example, the following cookies would always be rejected: 625 Set-Cookie: __Host-SID=12345 626 Set-Cookie: __Host-SID=12345; Secure 627 Set-Cookie: __Host-SID=12345; Domain=example.com 628 Set-Cookie: __Host-SID=12345; Domain=example.com; Path=/ 629 Set-Cookie: __Host-SID=12345; Secure; Domain=example.com; Path=/ 631 While the would be accepted if set from a secure origin (e.g. 632 "https://example.com/"), and rejected otherwise: 634 Set-Cookie: __Host-SID=12345; Secure; Path=/ 636 4.2. Cookie 638 4.2.1. Syntax 640 The user agent sends stored cookies to the origin server in the 641 Cookie header. If the server conforms to the requirements in 642 Section 4.1 (and the user agent conforms to the requirements in 643 Section 5), the user agent will send a Cookie header that conforms to 644 the following grammar: 646 cookie-header = "Cookie:" OWS cookie-string OWS 647 cookie-string = cookie-pair *( ";" SP cookie-pair ) 649 4.2.2. Semantics 651 Each cookie-pair represents a cookie stored by the user agent. The 652 cookie-pair contains the cookie-name and cookie-value the user agent 653 received in the Set-Cookie header. 655 Notice that the cookie attributes are not returned. In particular, 656 the server cannot determine from the Cookie header alone when a 657 cookie will expire, for which hosts the cookie is valid, for which 658 paths the cookie is valid, or whether the cookie was set with the 659 Secure or HttpOnly attributes. 661 The semantics of individual cookies in the Cookie header are not 662 defined by this document. Servers are expected to imbue these 663 cookies with application-specific semantics. 665 Although cookies are serialized linearly in the Cookie header, 666 servers SHOULD NOT rely upon the serialization order. In particular, 667 if the Cookie header contains two cookies with the same name (e.g., 668 that were set with different Path or Domain attributes), servers 669 SHOULD NOT rely upon the order in which these cookies appear in the 670 header. 672 5. User Agent Requirements 674 This section specifies the Cookie and Set-Cookie headers in 675 sufficient detail that a user agent implementing these requirements 676 precisely can interoperate with existing servers (even those that do 677 not conform to the well-behaved profile described in Section 4). 679 A user agent could enforce more restrictions than those specified 680 herein (e.g., for the sake of improved security); however, 681 experiments have shown that such strictness reduces the likelihood 682 that a user agent will be able to interoperate with existing servers. 684 5.1. Subcomponent Algorithms 686 This section defines some algorithms used by user agents to process 687 specific subcomponents of the Cookie and Set-Cookie headers. 689 5.1.1. Dates 691 The user agent MUST use an algorithm equivalent to the following 692 algorithm to parse a cookie-date. Note that the various boolean 693 flags defined as a part of the algorithm (i.e., found-time, found- 694 day-of-month, found-month, found-year) are initially "not set". 696 1. Using the grammar below, divide the cookie-date into date-tokens. 698 cookie-date = *delimiter date-token-list *delimiter 699 date-token-list = date-token *( 1*delimiter date-token ) 700 date-token = 1*non-delimiter 702 delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E 703 non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF 704 non-digit = %x00-2F / %x3A-FF 706 day-of-month = 1*2DIGIT [ non-digit *OCTET ] 707 month = ( "jan" / "feb" / "mar" / "apr" / 708 "may" / "jun" / "jul" / "aug" / 709 "sep" / "oct" / "nov" / "dec" ) *OCTET 710 year = 2*4DIGIT [ non-digit *OCTET ] 711 time = hms-time [ non-digit *OCTET ] 712 hms-time = time-field ":" time-field ":" time-field 713 time-field = 1*2DIGIT 715 2. Process each date-token sequentially in the order the date-tokens 716 appear in the cookie-date: 718 1. If the found-time flag is not set and the token matches the 719 time production, set the found-time flag and set the hour- 720 value, minute-value, and second-value to the numbers denoted 721 by the digits in the date-token, respectively. Skip the 722 remaining sub-steps and continue to the next date-token. 724 2. If the found-day-of-month flag is not set and the date-token 725 matches the day-of-month production, set the found-day-of- 726 month flag and set the day-of-month-value to the number 727 denoted by the date-token. Skip the remaining sub-steps and 728 continue to the next date-token. 730 3. If the found-month flag is not set and the date-token matches 731 the month production, set the found-month flag and set the 732 month-value to the month denoted by the date-token. Skip the 733 remaining sub-steps and continue to the next date-token. 735 4. If the found-year flag is not set and the date-token matches 736 the year production, set the found-year flag and set the 737 year-value to the number denoted by the date-token. Skip the 738 remaining sub-steps and continue to the next date-token. 740 3. If the year-value is greater than or equal to 70 and less than or 741 equal to 99, increment the year-value by 1900. 743 4. If the year-value is greater than or equal to 0 and less than or 744 equal to 69, increment the year-value by 2000. 746 1. NOTE: Some existing user agents interpret two-digit years 747 differently. 749 5. Abort these steps and fail to parse the cookie-date if: 751 * at least one of the found-day-of-month, found-month, found- 752 year, or found-time flags is not set, 754 * the day-of-month-value is less than 1 or greater than 31, 756 * the year-value is less than 1601, 758 * the hour-value is greater than 23, 760 * the minute-value is greater than 59, or 762 * the second-value is greater than 59. 764 (Note that leap seconds cannot be represented in this syntax.) 766 6. Let the parsed-cookie-date be the date whose day-of-month, month, 767 year, hour, minute, and second (in UTC) are the day-of-month- 768 value, the month-value, the year-value, the hour-value, the 769 minute-value, and the second-value, respectively. If no such 770 date exists, abort these steps and fail to parse the cookie-date. 772 7. Return the parsed-cookie-date as the result of this algorithm. 774 5.1.2. Canonicalized Host Names 776 A canonicalized host name is the string generated by the following 777 algorithm: 779 1. Convert the host name to a sequence of individual domain name 780 labels. 782 2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label, 783 to an A-label (see Section 2.3.2.1 of [RFC5890] for the former 784 and latter), or to a "punycode label" (a label resulting from the 785 "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate 786 (see Section 6.3 of this specification). 788 3. Concatenate the resulting labels, separated by a %x2E (".") 789 character. 791 5.1.3. Domain Matching 793 A string domain-matches a given domain string if at least one of the 794 following conditions hold: 796 o The domain string and the string are identical. (Note that both 797 the domain string and the string will have been canonicalized to 798 lower case at this point.) 800 o All of the following conditions hold: 802 * The domain string is a suffix of the string. 804 * The last character of the string that is not included in the 805 domain string is a %x2E (".") character. 807 * The string is a host name (i.e., not an IP address). 809 5.1.4. Paths and Path-Match 811 The user agent MUST use an algorithm equivalent to the following 812 algorithm to compute the default-path of a cookie: 814 1. Let uri-path be the path portion of the request-uri if such a 815 portion exists (and empty otherwise). For example, if the 816 request-uri contains just a path (and optional query string), 817 then the uri-path is that path (without the %x3F ("?") character 818 or query string), and if the request-uri contains a full 819 absoluteURI, the uri-path is the path component of that URI. 821 2. If the uri-path is empty or if the first character of the uri- 822 path is not a %x2F ("/") character, output %x2F ("/") and skip 823 the remaining steps. 825 3. If the uri-path contains no more than one %x2F ("/") character, 826 output %x2F ("/") and skip the remaining step. 828 4. Output the characters of the uri-path from the first character up 829 to, but not including, the right-most %x2F ("/"). 831 A request-path path-matches a given cookie-path if at least one of 832 the following conditions holds: 834 o The cookie-path and the request-path are identical. 836 Note that this differs from the rules in [RFC3986] for equivalence 837 of the path component, and hence two equivalent paths can have 838 different cookies. 840 o The cookie-path is a prefix of the request-path, and the last 841 character of the cookie-path is %x2F ("/"). 843 o The cookie-path is a prefix of the request-path, and the first 844 character of the request-path that is not included in the cookie- 845 path is a %x2F ("/") character. 847 5.2. The Set-Cookie Header 849 When a user agent receives a Set-Cookie header field in an HTTP 850 response, the user agent MAY ignore the Set-Cookie header field in 851 its entirety. For example, the user agent might wish to block 852 responses to "third-party" requests from setting cookies (see 853 Section 7.1). 855 If the user agent does not ignore the Set-Cookie header field in its 856 entirety, the user agent MUST parse the field-value of the Set-Cookie 857 header field as a set-cookie-string (defined below). 859 NOTE: The algorithm below is more permissive than the grammar in 860 Section 4.1. For example, the algorithm strips leading and trailing 861 whitespace from the cookie name and value (but maintains internal 862 whitespace), whereas the grammar in Section 4.1 forbids whitespace in 863 these positions. User agents use this algorithm so as to 864 interoperate with servers that do not follow the recommendations in 865 Section 4. 867 A user agent MUST use an algorithm equivalent to the following 868 algorithm to parse a set-cookie-string: 870 1. If the set-cookie-string contains a %x3B (";") character: 872 1. The name-value-pair string consists of the characters up to, 873 but not including, the first %x3B (";"), and the unparsed- 874 attributes consist of the remainder of the set-cookie-string 875 (including the %x3B (";") in question). 877 Otherwise: 879 1. The name-value-pair string consists of all the characters 880 contained in the set-cookie-string, and the unparsed- 881 attributes is the empty string. 883 2. If the name-value-pair string lacks a %x3D ("=") character, 884 ignore the set-cookie-string entirely. 886 3. The (possibly empty) name string consists of the characters up 887 to, but not including, the first %x3D ("=") character, and the 888 (possibly empty) value string consists of the characters after 889 the first %x3D ("=") character. 891 4. Remove any leading or trailing WSP characters from the name 892 string and the value string. 894 5. If the name string is empty, ignore the set-cookie-string 895 entirely. 897 6. The cookie-name is the name string, and the cookie-value is the 898 value string. 900 The user agent MUST use an algorithm equivalent to the following 901 algorithm to parse the unparsed-attributes: 903 1. If the unparsed-attributes string is empty, skip the rest of 904 these steps. 906 2. Discard the first character of the unparsed-attributes (which 907 will be a %x3B (";") character). 909 3. If the remaining unparsed-attributes contains a %x3B (";") 910 character: 912 1. Consume the characters of the unparsed-attributes up to, but 913 not including, the first %x3B (";") character. 915 Otherwise: 917 1. Consume the remainder of the unparsed-attributes. 919 Let the cookie-av string be the characters consumed in this step. 921 4. If the cookie-av string contains a %x3D ("=") character: 923 1. The (possibly empty) attribute-name string consists of the 924 characters up to, but not including, the first %x3D ("=") 925 character, and the (possibly empty) attribute-value string 926 consists of the characters after the first %x3D ("=") 927 character. 929 Otherwise: 931 1. The attribute-name string consists of the entire cookie-av 932 string, and the attribute-value string is empty. 934 5. Remove any leading or trailing WSP characters from the attribute- 935 name string and the attribute-value string. 937 6. Process the attribute-name and attribute-value according to the 938 requirements in the following subsections. (Notice that 939 attributes with unrecognized attribute-names are ignored.) 941 7. Return to Step 1 of this algorithm. 943 When the user agent finishes parsing the set-cookie-string, the user 944 agent is said to "receive a cookie" from the request-uri with name 945 cookie-name, value cookie-value, and attributes cookie-attribute- 946 list. (See Section 5.3 for additional requirements triggered by 947 receiving a cookie.) 949 5.2.1. The Expires Attribute 951 If the attribute-name case-insensitively matches the string 952 "Expires", the user agent MUST process the cookie-av as follows. 954 1. Let the expiry-time be the result of parsing the attribute-value 955 as cookie-date (see Section 5.1.1). 957 2. If the attribute-value failed to parse as a cookie date, ignore 958 the cookie-av. 960 3. If the expiry-time is later than the last date the user agent can 961 represent, the user agent MAY replace the expiry-time with the 962 last representable date. 964 4. If the expiry-time is earlier than the earliest date the user 965 agent can represent, the user agent MAY replace the expiry-time 966 with the earliest representable date. 968 5. Append an attribute to the cookie-attribute-list with an 969 attribute-name of Expires and an attribute-value of expiry-time. 971 5.2.2. The Max-Age Attribute 973 If the attribute-name case-insensitively matches the string "Max- 974 Age", the user agent MUST process the cookie-av as follows. 976 1. If the first character of the attribute-value is not a DIGIT or a 977 "-" character, ignore the cookie-av. 979 2. If the remainder of attribute-value contains a non-DIGIT 980 character, ignore the cookie-av. 982 3. Let delta-seconds be the attribute-value converted to an integer. 984 4. If delta-seconds is less than or equal to zero (0), let expiry- 985 time be the earliest representable date and time. Otherwise, let 986 the expiry-time be the current date and time plus delta-seconds 987 seconds. 989 5. Append an attribute to the cookie-attribute-list with an 990 attribute-name of Max-Age and an attribute-value of expiry-time. 992 5.2.3. The Domain Attribute 994 If the attribute-name case-insensitively matches the string "Domain", 995 the user agent MUST process the cookie-av as follows. 997 1. If the attribute-value is empty, the behavior is undefined. 998 However, the user agent SHOULD ignore the cookie-av entirely. 1000 2. If the first character of the attribute-value string is %x2E 1001 ("."): 1003 1. Let cookie-domain be the attribute-value without the leading 1004 %x2E (".") character. 1006 Otherwise: 1008 1. Let cookie-domain be the entire attribute-value. 1010 3. Convert the cookie-domain to lower case. 1012 4. Append an attribute to the cookie-attribute-list with an 1013 attribute-name of Domain and an attribute-value of cookie-domain. 1015 5.2.4. The Path Attribute 1017 If the attribute-name case-insensitively matches the string "Path", 1018 the user agent MUST process the cookie-av as follows. 1020 1. If the attribute-value is empty or if the first character of the 1021 attribute-value is not %x2F ("/"): 1023 1. Let cookie-path be the default-path. 1025 Otherwise: 1027 1. Let cookie-path be the attribute-value. 1029 2. Append an attribute to the cookie-attribute-list with an 1030 attribute-name of Path and an attribute-value of cookie-path. 1032 5.2.5. The Secure Attribute 1034 If the attribute-name case-insensitively matches the string "Secure", 1035 the user agent MUST append an attribute to the cookie-attribute-list 1036 with an attribute-name of Secure and an empty attribute-value. 1038 5.2.6. The HttpOnly Attribute 1040 If the attribute-name case-insensitively matches the string 1041 "HttpOnly", the user agent MUST append an attribute to the cookie- 1042 attribute-list with an attribute-name of HttpOnly and an empty 1043 attribute-value. 1045 5.3. Storage Model 1047 The user agent stores the following fields about each cookie: name, 1048 value, expiry-time, domain, path, creation-time, last-access-time, 1049 persistent-flag, host-only-flag, secure-only-flag, and http-only- 1050 flag. 1052 When the user agent "receives a cookie" from a request-uri with name 1053 cookie-name, value cookie-value, and attributes cookie-attribute- 1054 list, the user agent MUST process the cookie as follows: 1056 1. A user agent MAY ignore a received cookie in its entirety. For 1057 example, the user agent might wish to block receiving cookies 1058 from "third-party" responses or the user agent might not wish to 1059 store cookies that exceed some size. 1061 2. Create a new cookie with name cookie-name, value cookie-value. 1062 Set the creation-time and the last-access-time to the current 1063 date and time. 1065 3. If the cookie-attribute-list contains an attribute with an 1066 attribute-name of "Max-Age": 1068 1. Set the cookie's persistent-flag to true. 1070 2. Set the cookie's expiry-time to attribute-value of the last 1071 attribute in the cookie-attribute-list with an attribute- 1072 name of "Max-Age". 1074 Otherwise, if the cookie-attribute-list contains an attribute 1075 with an attribute-name of "Expires" (and does not contain an 1076 attribute with an attribute-name of "Max-Age"): 1078 1. Set the cookie's persistent-flag to true. 1080 2. Set the cookie's expiry-time to attribute-value of the last 1081 attribute in the cookie-attribute-list with an attribute- 1082 name of "Expires". 1084 Otherwise: 1086 1. Set the cookie's persistent-flag to false. 1088 2. Set the cookie's expiry-time to the latest representable 1089 date. 1091 4. If the cookie-attribute-list contains an attribute with an 1092 attribute-name iof "Domain": 1094 1. Let the domain-attribute be the attribute-value of the last 1095 attribute in the cookie-attribute-list with an attribute- 1096 name of "Domain". 1098 Otherwise: 1100 1. Let the domain-attribute be the empty string. 1102 5. If the user agent is configured to reject "public suffixes" and 1103 the domain-attribute is a public suffix: 1105 1. If the domain-attribute is identical to the canonicalized 1106 request-host: 1108 1. Let the domain-attribute be the empty string. 1110 Otherwise: 1112 1. Ignore the cookie entirely and abort these steps. 1114 NOTE: A "public suffix" is a domain that is controlled by a 1115 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". 1116 This step is essential for preventing attacker.com from 1117 disrupting the integrity of example.com by setting a cookie with 1118 a Domain attribute of "com". Unfortunately, the set of public 1119 suffixes (also known as "registry controlled domains") changes 1120 over time. If feasible, user agents SHOULD use an up-to-date 1121 public suffix list, such as the one maintained by the Mozilla 1122 project at http://publicsuffix.org/ . 1124 6. If the domain-attribute is non-empty: 1126 1. If the canonicalized request-host does not domain-match the 1127 domain-attribute: 1129 1. Ignore the cookie entirely and abort these steps. 1131 Otherwise: 1133 1. Set the cookie's host-only-flag to false. 1135 2. Set the cookie's domain to the domain-attribute. 1137 Otherwise: 1139 1. Set the cookie's host-only-flag to true. 1141 2. Set the cookie's domain to the canonicalized request-host. 1143 7. If the cookie-attribute-list contains an attribute with an 1144 attribute-name of "Path", set the cookie's path to attribute- 1145 value of the last attribute in the cookie-attribute-list with an 1146 attribute-name of "Path". Otherwise, set the cookie's path to 1147 the default-path of the request-uri. 1149 8. If the cookie-attribute-list contains an attribute with an 1150 attribute-name of "Secure", set the cookie's secure-only-flag to 1151 true. Otherwise, set the cookie's secure-only-flag to false. 1153 9. If the scheme component of the request-uri does not denote a 1154 "secure" protocol (as defined by the user agent), and the 1155 cookie's secure-only-flag is true, then abort these steps and 1156 ignore the cookie entirely. 1158 10. If the cookie-attribute-list contains an attribute with an 1159 attribute-name of "HttpOnly", set the cookie's http-only-flag to 1160 true. Otherwise, set the cookie's http-only-flag to false. 1162 11. If the cookie was received from a "non-HTTP" API and the 1163 cookie's http-only-flag is true, abort these steps and ignore 1164 the cookie entirely. 1166 12. If the cookie's secure-only-flag is not set, and the scheme 1167 component of request-uri does not denote a "secure" protocol, 1168 then abort these steps and ignore the cookie entirely if the 1169 cookie store contains one or more cookies that meet all of the 1170 following criteria: 1172 1. Their name matches the name of the newly-created cookie. 1174 2. Their secure-only-flag is true. 1176 3. Their domain domain-matches the domain of the newly-created 1177 cookie, or vice-versa. 1179 4. The path of the newly-created cookie path-matches the path 1180 of the existing cookie. 1182 Note: The path comparison is not symmetric, ensuring only that a 1183 newly-created, non-secure cookie does not overlay an existing 1184 secure cookie, providing some mitigation against cookie-fixing 1185 attacks. That is, given an existing secure cookie named 'a' 1186 with a path of '/login', a non-secure cookie named 'a' could be 1187 set for a path of '/' or '/foo', but not for a path of '/login' 1188 or '/login/en'. 1190 13. If the cookie-name begins with a case-sensitive match for the 1191 string "__Secure-", abort these steps and ignore the cookie 1192 entirely unless the cookie's secure-only-flag is true. 1194 14. If the cookie-name begins with a case-sensitive match for the 1195 string "__Host-", abort these steps and ignore the cookie 1196 entirely unless the cookie meets all the following criteria: 1198 1. The cookie's secure-only-flag is true. 1200 2. The cookie's host-only-flag is true. 1202 3. The cookie's path is "/". 1204 15. If the cookie store contains a cookie with the same name, 1205 domain, and path as the newly-created cookie: 1207 1. Let old-cookie be the existing cookie with the same name, 1208 domain, and path as the newly-created cookie. (Notice that 1209 this algorithm maintains the invariant that there is at most 1210 one such cookie.) 1212 2. If the newly-created cookie was received from a "non-HTTP" 1213 API and the old-cookie's http-only-flag is true, abort these 1214 steps and ignore the newly created cookie entirely. 1216 3. Update the creation-time of the newly-created cookie to 1217 match the creation-time of the old-cookie. 1219 4. Remove the old-cookie from the cookie store. 1221 16. Insert the newly-created cookie into the cookie store. 1223 A cookie is "expired" if the cookie has an expiry date in the past. 1225 The user agent MUST evict all expired cookies from the cookie store 1226 if, at any time, an expired cookie exists in the cookie store. 1228 At any time, the user agent MAY "remove excess cookies" from the 1229 cookie store if the number of cookies sharing a domain field exceeds 1230 some implementation-defined upper bound (such as 50 cookies). 1232 At any time, the user agent MAY "remove excess cookies" from the 1233 cookie store if the cookie store exceeds some predetermined upper 1234 bound (such as 3000 cookies). 1236 When the user agent removes excess cookies from the cookie store, the 1237 user agent MUST evict cookies in the following priority order: 1239 1. Expired cookies. 1241 2. Cookies whose secure-only-flag is not set, and which share a 1242 domain field with more than a predetermined number of other 1243 cookies. 1245 3. Cookies that share a domain field with more than a predetermined 1246 number of other cookies. 1248 4. All cookies. 1250 If two cookies have the same removal priority, the user agent MUST 1251 evict the cookie with the earliest last-access date first. 1253 When "the current session is over" (as defined by the user agent), 1254 the user agent MUST remove from the cookie store all cookies with the 1255 persistent-flag set to false. 1257 5.4. The Cookie Header 1259 The user agent includes stored cookies in the Cookie HTTP request 1260 header. 1262 When the user agent generates an HTTP request, the user agent MUST 1263 NOT attach more than one Cookie header field. 1265 A user agent MAY omit the Cookie header in its entirety. For 1266 example, the user agent might wish to block sending cookies during 1267 "third-party" requests from setting cookies (see Section 7.1). 1269 If the user agent does attach a Cookie header field to an HTTP 1270 request, the user agent MUST send the cookie-string (defined below) 1271 as the value of the header field. 1273 The user agent MUST use an algorithm equivalent to the following 1274 algorithm to compute the cookie-string from a cookie store and a 1275 request-uri: 1277 1. Let cookie-list be the set of cookies from the cookie store that 1278 meets all of the following requirements: 1280 * Either: 1282 + The cookie's host-only-flag is true and the canonicalized 1283 request-host is identical to the cookie's domain. 1285 Or: 1287 + The cookie's host-only-flag is false and the canonicalized 1288 request-host domain-matches the cookie's domain. 1290 * The request-uri's path path-matches the cookie's path. 1292 * If the cookie's secure-only-flag is true, then the request- 1293 uri's scheme must denote a "secure" protocol (as defined by 1294 the user agent). 1296 NOTE: The notion of a "secure" protocol is not defined by this 1297 document. Typically, user agents consider a protocol secure 1298 if the protocol makes use of transport-layer security, such as 1299 SSL or TLS. For example, most user agents consider "https" to 1300 be a scheme that denotes a secure protocol. 1302 * If the cookie's http-only-flag is true, then exclude the 1303 cookie if the cookie-string is being generated for a "non- 1304 HTTP" API (as defined by the user agent). 1306 2. The user agent SHOULD sort the cookie-list in the following 1307 order: 1309 * Cookies with longer paths are listed before cookies with 1310 shorter paths. 1312 * Among cookies that have equal-length path fields, cookies with 1313 earlier creation-times are listed before cookies with later 1314 creation-times. 1316 NOTE: Not all user agents sort the cookie-list in this order, but 1317 this order reflects common practice when this document was 1318 written, and, historically, there have been servers that 1319 (erroneously) depended on this order. 1321 3. Update the last-access-time of each cookie in the cookie-list to 1322 the current date and time. 1324 4. Serialize the cookie-list into a cookie-string by processing each 1325 cookie in the cookie-list in order: 1327 1. Output the cookie's name, the %x3D ("=") character, and the 1328 cookie's value. 1330 2. If there is an unprocessed cookie in the cookie-list, output 1331 the characters %x3B and %x20 ("; "). 1333 NOTE: Despite its name, the cookie-string is actually a sequence of 1334 octets, not a sequence of characters. To convert the cookie-string 1335 (or components thereof) into a sequence of characters (e.g., for 1336 presentation to the user), the user agent might wish to try using the 1337 UTF-8 character encoding [RFC3629] to decode the octet sequence. 1338 This decoding might fail, however, because not every sequence of 1339 octets is valid UTF-8. 1341 6. Implementation Considerations 1343 6.1. Limits 1345 Practical user agent implementations have limits on the number and 1346 size of cookies that they can store. General-use user agents SHOULD 1347 provide each of the following minimum capabilities: 1349 o At least 4096 bytes per cookie (as measured by the sum of the 1350 length of the cookie's name, value, and attributes). 1352 o At least 50 cookies per domain. 1354 o At least 3000 cookies total. 1356 Servers SHOULD use as few and as small cookies as possible to avoid 1357 reaching these implementation limits and to minimize network 1358 bandwidth due to the Cookie header being included in every request. 1360 Servers SHOULD gracefully degrade if the user agent fails to return 1361 one or more cookies in the Cookie header because the user agent might 1362 evict any cookie at any time on orders from the user. 1364 6.2. Application Programming Interfaces 1366 One reason the Cookie and Set-Cookie headers use such esoteric syntax 1367 is that many platforms (both in servers and user agents) provide a 1368 string-based application programming interface (API) to cookies, 1369 requiring application-layer programmers to generate and parse the 1370 syntax used by the Cookie and Set-Cookie headers, which many 1371 programmers have done incorrectly, resulting in interoperability 1372 problems. 1374 Instead of providing string-based APIs to cookies, platforms would be 1375 well-served by providing more semantic APIs. It is beyond the scope 1376 of this document to recommend specific API designs, but there are 1377 clear benefits to accepting an abstract "Date" object instead of a 1378 serialized date string. 1380 6.3. IDNA Dependency and Migration 1382 IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are 1383 differences between the two specifications, and thus there can be 1384 differences in processing (e.g., converting) domain name labels that 1385 have been registered under one from those registered under the other. 1386 There will be a transition period of some time during which 1387 IDNA2003-based domain name labels will exist in the wild. User 1388 agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [UTS46] 1389 or [RFC5895] in order to facilitate their IDNA transition. If a user 1390 agent does not implement IDNA2008, the user agent MUST implement 1391 IDNA2003 [RFC3490]. 1393 7. Privacy Considerations 1395 Cookies are often criticized for letting servers track users. For 1396 example, a number of "web analytics" companies use cookies to 1397 recognize when a user returns to a web site or visits another web 1398 site. Although cookies are not the only mechanism servers can use to 1399 track users across HTTP requests, cookies facilitate tracking because 1400 they are persistent across user agent sessions and can be shared 1401 between hosts. 1403 7.1. Third-Party Cookies 1405 Particularly worrisome are so-called "third-party" cookies. In 1406 rendering an HTML document, a user agent often requests resources 1407 from other servers (such as advertising networks). These third-party 1408 servers can use cookies to track the user even if the user never 1409 visits the server directly. For example, if a user visits a site 1410 that contains content from a third party and then later visits 1411 another site that contains content from the same third party, the 1412 third party can track the user between the two sites. 1414 Some user agents restrict how third-party cookies behave. For 1415 example, some of these user agents refuse to send the Cookie header 1416 in third-party requests. Others refuse to process the Set-Cookie 1417 header in responses to third-party requests. User agents vary widely 1418 in their third-party cookie policies. This document grants user 1419 agents wide latitude to experiment with third-party cookie policies 1420 that balance the privacy and compatibility needs of their users. 1421 However, this document does not endorse any particular third-party 1422 cookie policy. 1424 Third-party cookie blocking policies are often ineffective at 1425 achieving their privacy goals if servers attempt to work around their 1426 restrictions to track users. In particular, two collaborating 1427 servers can often track users without using cookies at all by 1428 injecting identifying information into dynamic URLs. 1430 7.2. User Controls 1432 User agents SHOULD provide users with a mechanism for managing the 1433 cookies stored in the cookie store. For example, a user agent might 1434 let users delete all cookies received during a specified time period 1435 or all the cookies related to a particular domain. In addition, many 1436 user agents include a user interface element that lets users examine 1437 the cookies stored in their cookie store. 1439 User agents SHOULD provide users with a mechanism for disabling 1440 cookies. When cookies are disabled, the user agent MUST NOT include 1441 a Cookie header in outbound HTTP requests and the user agent MUST NOT 1442 process Set-Cookie headers in inbound HTTP responses. 1444 Some user agents provide users the option of preventing persistent 1445 storage of cookies across sessions. When configured thusly, user 1446 agents MUST treat all received cookies as if the persistent-flag were 1447 set to false. Some popular user agents expose this functionality via 1448 "private browsing" mode [Aggarwal2010]. 1450 Some user agents provide users with the ability to approve individual 1451 writes to the cookie store. In many common usage scenarios, these 1452 controls generate a large number of prompts. However, some privacy- 1453 conscious users find these controls useful nonetheless. 1455 7.3. Expiration Dates 1457 Although servers can set the expiration date for cookies to the 1458 distant future, most user agents do not actually retain cookies for 1459 multiple decades. Rather than choosing gratuitously long expiration 1460 periods, servers SHOULD promote user privacy by selecting reasonable 1461 cookie expiration periods based on the purpose of the cookie. For 1462 example, a typical session identifier might reasonably be set to 1463 expire in two weeks. 1465 8. Security Considerations 1467 8.1. Overview 1469 Cookies have a number of security pitfalls. This section overviews a 1470 few of the more salient issues. 1472 In particular, cookies encourage developers to rely on ambient 1473 authority for authentication, often becoming vulnerable to attacks 1474 such as cross-site request forgery [CSRF]. Also, when storing 1475 session identifiers in cookies, developers often create session 1476 fixation vulnerabilities. 1478 Transport-layer encryption, such as that employed in HTTPS, is 1479 insufficient to prevent a network attacker from obtaining or altering 1480 a victim's cookies because the cookie protocol itself has various 1481 vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", 1482 below). In addition, by default, cookies do not provide 1483 confidentiality or integrity from network attackers, even when used 1484 in conjunction with HTTPS. 1486 8.2. Ambient Authority 1488 A server that uses cookies to authenticate users can suffer security 1489 vulnerabilities because some user agents let remote parties issue 1490 HTTP requests from the user agent (e.g., via HTTP redirects or HTML 1491 forms). When issuing those requests, user agents attach cookies even 1492 if the remote party does not know the contents of the cookies, 1493 potentially letting the remote party exercise authority at an unwary 1494 server. 1496 Although this security concern goes by a number of names (e.g., 1497 cross-site request forgery, confused deputy), the issue stems from 1498 cookies being a form of ambient authority. Cookies encourage server 1499 operators to separate designation (in the form of URLs) from 1500 authorization (in the form of cookies). Consequently, the user agent 1501 might supply the authorization for a resource designated by the 1502 attacker, possibly causing the server or its clients to undertake 1503 actions designated by the attacker as though they were authorized by 1504 the user. 1506 Instead of using cookies for authorization, server operators might 1507 wish to consider entangling designation and authorization by treating 1508 URLs as capabilities. Instead of storing secrets in cookies, this 1509 approach stores secrets in URLs, requiring the remote entity to 1510 supply the secret itself. Although this approach is not a panacea, 1511 judicious application of these principles can lead to more robust 1512 security. 1514 8.3. Clear Text 1516 Unless sent over a secure channel (such as TLS), the information in 1517 the Cookie and Set-Cookie headers is transmitted in the clear. 1519 1. All sensitive information conveyed in these headers is exposed to 1520 an eavesdropper. 1522 2. A malicious intermediary could alter the headers as they travel 1523 in either direction, with unpredictable results. 1525 3. A malicious client could alter the Cookie header before 1526 transmission, with unpredictable results. 1528 Servers SHOULD encrypt and sign the contents of cookies (using 1529 whatever format the server desires) when transmitting them to the 1530 user agent (even when sending the cookies over a secure channel). 1531 However, encrypting and signing cookie contents does not prevent an 1532 attacker from transplanting a cookie from one user agent to another 1533 or from replaying the cookie at a later time. 1535 In addition to encrypting and signing the contents of every cookie, 1536 servers that require a higher level of security SHOULD use the Cookie 1537 and Set-Cookie headers only over a secure channel. When using 1538 cookies over a secure channel, servers SHOULD set the Secure 1539 attribute (see Section 4.1.2.5) for every cookie. If a server does 1540 not set the Secure attribute, the protection provided by the secure 1541 channel will be largely moot. 1543 For example, consider a webmail server that stores a session 1544 identifier in a cookie and is typically accessed over HTTPS. If the 1545 server does not set the Secure attribute on its cookies, an active 1546 network attacker can intercept any outbound HTTP request from the 1547 user agent and redirect that request to the webmail server over HTTP. 1548 Even if the webmail server is not listening for HTTP connections, the 1549 user agent will still include cookies in the request. The active 1550 network attacker can intercept these cookies, replay them against the 1551 server, and learn the contents of the user's email. If, instead, the 1552 server had set the Secure attribute on its cookies, the user agent 1553 would not have included the cookies in the clear-text request. 1555 8.4. Session Identifiers 1557 Instead of storing session information directly in a cookie (where it 1558 might be exposed to or replayed by an attacker), servers commonly 1559 store a nonce (or "session identifier") in a cookie. When the server 1560 receives an HTTP request with a nonce, the server can look up state 1561 information associated with the cookie using the nonce as a key. 1563 Using session identifier cookies limits the damage an attacker can 1564 cause if the attacker learns the contents of a cookie because the 1565 nonce is useful only for interacting with the server (unlike non- 1566 nonce cookie content, which might itself be sensitive). Furthermore, 1567 using a single nonce prevents an attacker from "splicing" together 1568 cookie content from two interactions with the server, which could 1569 cause the server to behave unexpectedly. 1571 Using session identifiers is not without risk. For example, the 1572 server SHOULD take care to avoid "session fixation" vulnerabilities. 1573 A session fixation attack proceeds in three steps. First, the 1574 attacker transplants a session identifier from his or her user agent 1575 to the victim's user agent. Second, the victim uses that session 1576 identifier to interact with the server, possibly imbuing the session 1577 identifier with the user's credentials or confidential information. 1578 Third, the attacker uses the session identifier to interact with 1579 server directly, possibly obtaining the user's authority or 1580 confidential information. 1582 8.5. Weak Confidentiality 1584 Cookies do not provide isolation by port. If a cookie is readable by 1585 a service running on one port, the cookie is also readable by a 1586 service running on another port of the same server. If a cookie is 1587 writable by a service on one port, the cookie is also writable by a 1588 service running on another port of the same server. For this reason, 1589 servers SHOULD NOT both run mutually distrusting services on 1590 different ports of the same host and use cookies to store security- 1591 sensitive information. 1593 Cookies do not provide isolation by scheme. Although most commonly 1594 used with the http and https schemes, the cookies for a given host 1595 might also be available to other schemes, such as ftp and gopher. 1596 Although this lack of isolation by scheme is most apparent in non- 1597 HTTP APIs that permit access to cookies (e.g., HTML's document.cookie 1598 API), the lack of isolation by scheme is actually present in 1599 requirements for processing cookies themselves (e.g., consider 1600 retrieving a URI with the gopher scheme via HTTP). 1602 Cookies do not always provide isolation by path. Although the 1603 network-level protocol does not send cookies stored for one path to 1604 another, some user agents expose cookies via non-HTTP APIs, such as 1605 HTML's document.cookie API. Because some of these user agents (e.g., 1606 web browsers) do not isolate resources received from different paths, 1607 a resource retrieved from one path might be able to access cookies 1608 stored for another path. 1610 8.6. Weak Integrity 1612 Cookies do not provide integrity guarantees for sibling domains (and 1613 their subdomains). For example, consider foo.example.com and 1614 bar.example.com. The foo.example.com server can set a cookie with a 1615 Domain attribute of "example.com" (possibly overwriting an existing 1616 "example.com" cookie set by bar.example.com), and the user agent will 1617 include that cookie in HTTP requests to bar.example.com. In the 1618 worst case, bar.example.com will be unable to distinguish this cookie 1619 from a cookie it set itself. The foo.example.com server might be 1620 able to leverage this ability to mount an attack against 1621 bar.example.com. 1623 Even though the Set-Cookie header supports the Path attribute, the 1624 Path attribute does not provide any integrity protection because the 1625 user agent will accept an arbitrary Path attribute in a Set-Cookie 1626 header. For example, an HTTP response to a request for 1627 http://example.com/foo/bar can set a cookie with a Path attribute of 1628 "/qux". Consequently, servers SHOULD NOT both run mutually 1629 distrusting services on different paths of the same host and use 1630 cookies to store security-sensitive information. 1632 An active network attacker can also inject cookies into the Cookie 1633 header sent to https://example.com/ by impersonating a response from 1634 http://example.com/ and injecting a Set-Cookie header. The HTTPS 1635 server at example.com will be unable to distinguish these cookies 1636 from cookies that it set itself in an HTTPS response. An active 1637 network attacker might be able to leverage this ability to mount an 1638 attack against example.com even if example.com uses HTTPS 1639 exclusively. 1641 Servers can partially mitigate these attacks by encrypting and 1642 signing the contents of their cookies. However, using cryptography 1643 does not mitigate the issue completely because an attacker can replay 1644 a cookie he or she received from the authentic example.com server in 1645 the user's session, with unpredictable results. 1647 Finally, an attacker might be able to force the user agent to delete 1648 cookies by storing a large number of cookies. Once the user agent 1649 reaches its storage limit, the user agent will be forced to evict 1650 some cookies. Servers SHOULD NOT rely upon user agents retaining 1651 cookies. 1653 8.7. Reliance on DNS 1655 Cookies rely upon the Domain Name System (DNS) for security. If the 1656 DNS is partially or fully compromised, the cookie protocol might fail 1657 to provide the security properties required by applications. 1659 9. IANA Considerations 1661 The permanent message header field registry (see [RFC3864]) needs to 1662 be updated with the following registrations. 1664 9.1. Cookie 1666 Header field name: Cookie 1668 Applicable protocol: http 1670 Status: standard 1672 Author/Change controller: IETF 1674 Specification document: this specification (Section 5.4) 1676 9.2. Set-Cookie 1678 Header field name: Set-Cookie 1680 Applicable protocol: http 1682 Status: standard 1684 Author/Change controller: IETF 1686 Specification document: this specification (Section 5.2) 1688 10. References 1690 10.1. Normative References 1692 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1693 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1694 . 1696 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1697 Application and Support", STD 3, RFC 1123, 1698 DOI 10.17487/RFC1123, October 1989, 1699 . 1701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1702 Requirement Levels", BCP 14, RFC 2119, 1703 DOI 10.17487/RFC2119, March 1997, 1704 . 1706 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1707 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1708 Transfer Protocol -- HTTP/1.1", RFC 2616, 1709 DOI 10.17487/RFC2616, June 1999, 1710 . 1712 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1713 "Internationalizing Domain Names in Applications (IDNA)", 1714 RFC 3490, DOI 10.17487/RFC3490, March 2003, 1715 . 1717 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 1718 Application Protocol Collation Registry", RFC 4790, 1719 DOI 10.17487/RFC4790, March 2007, 1720 . 1722 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1723 Specifications: ABNF", STD 68, RFC 5234, 1724 DOI 10.17487/RFC5234, January 2008, 1725 . 1727 [RFC5890] Klensin, J., "Internationalized Domain Names for 1728 Applications (IDNA): Definitions and Document Framework", 1729 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1730 . 1732 [USASCII] Institute, A., "Coded Character Set -- 7-bit American 1733 Standard Code for Information Interchange", 1986, . 1736 10.2. Informative References 1738 [Aggarwal2010] 1739 Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, 1740 "An Analysis of Private Browsing Modes in Modern 1741 Browsers", 2010, 1742 . 1745 [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses 1746 for Cross-Site Request Forgery", 2008, 1747 . 1749 [draft-ietf-httpbis-cookie-alone] 1750 West, M., "Deprecate modification of 'secure' cookies from 1751 non-secure origins", September 2016, 1752 . 1755 [draft-ietf-httpbis-cookie-prefixes] 1756 West, M., "Cookie Prefixes", February 2016, 1757 . 1760 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 1761 Politics", ACM ACM Transactions on Internet Technology 1762 Vol. 1, #2, November 2001, 1763 . 1765 [Netscape] 1766 Corp., N., "Persistent Client State -- HTTP Cookies", 1767 1999, . 1770 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1771 Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, 1772 . 1774 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1775 DOI 10.17487/RFC2818, May 2000, 1776 . 1778 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1779 Mechanism", RFC 2965, DOI 10.17487/RFC2965, October 2000, 1780 . 1782 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1783 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1784 2003, . 1786 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1787 Procedures for Message Header Fields", BCP 90, RFC 3864, 1788 DOI 10.17487/RFC3864, September 2004, 1789 . 1791 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1792 Resource Identifier (URI): Generic Syntax", STD 66, 1793 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1794 . 1796 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1797 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1798 . 1800 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1801 Internationalized Domain Names in Applications (IDNA) 1802 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 1803 . 1805 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1806 DOI 10.17487/RFC6265, April 2011, 1807 . 1809 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1810 Processing", UNICODE Unicode Technical Standards # 46, 1811 2010, . 1813 Appendix A. Changes 1815 A.1. draft-ietf-httpbis-rfc6265bis-00 1817 o Port [RFC6265] to Markdown. No (intentional) normative changes. 1819 A.2. draft-ietf-httpbis-rfc6265bis-01 1821 o Fixes to formatting caused by mistakes in the initial port to 1822 Markdown: 1824 * https://github.com/httpwg/http-extensions/issues/243 1826 * https://github.com/httpwg/http-extensions/issues/246 1828 o Addresses errata 3444 by updating the "path-value" and "extension- 1829 av" grammar, errata 4148 by updating the "day-of-month", "year", 1830 and "time" grammar, and errata 3663 by adding the requested note. 1831 https://www.rfc-editor.org/errata_search.php?rfc=6265 1833 o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations 1834 section: https://github.com/httpwg/http-extensions/issues/247 1836 o Merged the recommendations from [draft-ietf-httpbis-cookie-alone], 1837 removing the ability for a non-secure origin to set cookies with a 1838 'secure' flag, and to overwrite cookies whose 'secure' flag is 1839 true. 1841 o Merged the recommendations from 1842 [draft-ietf-httpbis-cookie-prefixes], adding "__Secure-" and 1843 "__Host-" cookie name prefix processing instructions. 1845 Appendix B. Acknowledgements 1847 This document is a minor update of RFC 6265, adding small features, 1848 and aligning the specification with the reality of today's 1849 deployments. Here, we're standing upon the shoulders of giants. 1851 Authors' Addresses 1853 Adam Barth 1854 Google, Inc 1856 URI: https://www.adambarth.com/ 1858 Mike West 1859 Google, Inc 1861 Email: mkwst@google.com 1862 URI: https://mikewest.org/