idnits 2.17.1 draft-ietf-httpbis-rfc6265bis-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 20, 2020) is 1467 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) -- Looks like a reference, but probably isn't: '1' on line 2249 -- Looks like a reference, but probably isn't: '2' on line 2251 -- Looks like a reference, but probably isn't: '3' on line 2253 -- Looks like a reference, but probably isn't: '4' on line 2255 -- Looks like a reference, but probably isn't: '5' on line 2324 -- Looks like a reference, but probably isn't: '6' on line 2326 -- Looks like a reference, but probably isn't: '7' on line 2331 -- Looks like a reference, but probably isn't: '8' on line 2334 -- Looks like a reference, but probably isn't: '9' on line 2354 -- Looks like a reference, but probably isn't: '10' on line 2357 -- Looks like a reference, but probably isn't: '11' on line 2361 -- Looks like a reference, but probably isn't: '12' on line 2365 -- Looks like a reference, but probably isn't: '13' on line 2369 -- Looks like a reference, but probably isn't: '14' on line 2373 -- Looks like a reference, but probably isn't: '15' on line 2378 -- Looks like a reference, but probably isn't: '16' on line 2382 -- Looks like a reference, but probably isn't: '17' on line 2385 -- Looks like a reference, but probably isn't: '18' on line 2390 -- Looks like a reference, but probably isn't: '19' on line 2393 -- Looks like a reference, but probably isn't: '20' on line 2397 -- Looks like a reference, but probably isn't: '21' on line 2400 -- Looks like a reference, but probably isn't: '22' on line 2405 -- Looks like a reference, but probably isn't: '23' on line 2406 -- Looks like a reference, but probably isn't: '24' on line 2407 -- Looks like a reference, but probably isn't: '25' on line 2408 -- Looks like a reference, but probably isn't: '26' on line 2413 -- Looks like a reference, but probably isn't: '27' on line 2414 -- Looks like a reference, but probably isn't: '28' on line 2417 -- Looks like a reference, but probably isn't: '29' on line 2421 -- Looks like a reference, but probably isn't: '30' on line 2421 -- Looks like a reference, but probably isn't: '31' on line 2424 -- Looks like a reference, but probably isn't: '32' on line 2428 -- Possible downref: Non-RFC (?) normative reference: ref. 'FETCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML' ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'SERVICE-WORKERS' -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 38 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. West, Ed. 3 Internet-Draft Google, Inc 4 Obsoletes: 6265 (if approved) J. Wilander, Ed. 5 Intended status: Standards Track Apple, Inc 6 Expires: October 22, 2020 April 20, 2020 8 Cookies: HTTP State Management Mechanism 9 draft-ietf-httpbis-rfc6265bis-06 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 6265. 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/ [1]. 27 Working Group information can be found at http://httpwg.github.io/ 28 [2]; source code and issues list for this draft can be found at 29 https://github.com/httpwg/http-extensions/labels/6265bis [3]. 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 https://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 22, 2020. 48 Copyright Notice 50 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 80 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 81 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 82 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 84 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9 85 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 87 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 88 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14 89 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 92 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 93 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17 94 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17 95 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 19 96 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19 97 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19 98 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20 99 5.2.1. Document-based requests . . . . . . . . . . . . . . . 21 100 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22 101 5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23 102 5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25 103 5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26 104 5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26 105 5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 27 106 5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27 107 5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27 108 5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27 109 5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28 110 5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33 111 6. Implementation Considerations . . . . . . . . . . . . . . . . 35 112 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35 113 6.2. Application Programming Interfaces . . . . . . . . . . . 36 114 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 36 115 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 116 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 37 117 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37 118 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 38 119 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 120 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38 121 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38 122 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 39 123 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 40 124 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40 125 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 41 126 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 42 127 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 42 128 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 42 129 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42 130 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 43 131 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43 132 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 133 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 44 134 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 135 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 44 136 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 44 137 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 45 138 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 139 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 140 10.2. Informative References . . . . . . . . . . . . . . . . . 47 141 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 48 142 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 50 143 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 50 144 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 50 145 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 50 146 A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 51 147 A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 51 148 A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 52 149 A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 52 150 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 52 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 153 1. Introduction 155 This document defines the HTTP Cookie and Set-Cookie header fields. 156 Using the Set-Cookie header field, an HTTP server can pass name/value 157 pairs and associated metadata (called cookies) to a user agent. When 158 the user agent makes subsequent requests to the server, the user 159 agent uses the metadata and other information to determine whether to 160 return the name/value pairs in the Cookie header. 162 Although simple on their surface, cookies have a number of 163 complexities. For example, the server indicates a scope for each 164 cookie when sending it to the user agent. The scope indicates the 165 maximum amount of time in which the user agent should return the 166 cookie, the servers to which the user agent should return the cookie, 167 and the URI schemes for which the cookie is applicable. 169 For historical reasons, cookies contain a number of security and 170 privacy infelicities. For example, a server can indicate that a 171 given cookie is intended for "secure" connections, but the Secure 172 attribute does not provide integrity in the presence of an active 173 network attacker. Similarly, cookies for a given host are shared 174 across all the ports on that host, even though the usual "same-origin 175 policy" used by web browsers isolates content retrieved via different 176 ports. 178 There are two audiences for this specification: developers of cookie- 179 generating servers and developers of cookie-consuming user agents. 181 To maximize interoperability with user agents, servers SHOULD limit 182 themselves to the well-behaved profile defined in Section 4 when 183 generating cookies. 185 User agents MUST implement the more liberal processing rules defined 186 in Section 5, in order to maximize interoperability with existing 187 servers that do not conform to the well-behaved profile defined in 188 Section 4. 190 This document specifies the syntax and semantics of these headers as 191 they are actually used on the Internet. In particular, this document 192 does not create new syntax or semantics beyond those in use today. 193 The recommendations for cookie generation provided in Section 4 194 represent a preferred subset of current server behavior, and even the 195 more liberal cookie processing algorithm provided in Section 5 does 196 not recommend all of the syntactic and semantic variations in use 197 today. Where some existing software differs from the recommended 198 protocol in significant ways, the document contains a note explaining 199 the difference. 201 This document obsoletes [RFC6265]. 203 2. Conventions 205 2.1. Conformance Criteria 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 211 Requirements phrased in the imperative as part of algorithms (such as 212 "strip any leading space characters" or "return false and abort these 213 steps") are to be interpreted with the meaning of the key word 214 ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm. 216 Conformance requirements phrased as algorithms or specific steps can 217 be implemented in any manner, so long as the end result is 218 equivalent. In particular, the algorithms defined in this 219 specification are intended to be easy to understand and are not 220 intended to be performant. 222 2.2. Syntax Notation 224 This specification uses the Augmented Backus-Naur Form (ABNF) 225 notation of [RFC5234]. 227 The following core rules are included by reference, as defined in 228 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 229 (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 230 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), 231 OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB 232 (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible 233 [USASCII] character), and WSP (whitespace). 235 The OWS (optional whitespace) and BWS (bad whitespace) rules are 236 defined in Section 3.2.3 of [RFC7230]. 238 2.3. Terminology 240 The terms "user agent", "client", "server", "proxy", and "origin 241 server" have the same meaning as in the HTTP/1.1 specification 242 ([RFC7230], Section 2). 244 The request-host is the name of the host, as known by the user agent, 245 to which the user agent is sending an HTTP request or from which it 246 is receiving an HTTP response (i.e., the name of the host to which it 247 sent the corresponding HTTP request). 249 The term request-uri refers to "request-target" as defined in 250 Section 5.3 of [RFC7230]. 252 Two sequences of octets are said to case-insensitively match each 253 other if and only if they are equivalent under the i;ascii-casemap 254 collation defined in [RFC4790]. 256 The term string means a sequence of non-NUL octets. 258 The terms "active document", "ancestor browsing context", "browsing 259 context", "dedicated worker", "Document", "WorkerGlobalScope", 260 "sandboxed origin browsing context flag", "parent browsing context", 261 "shared worker", "the worker's Documents", "nested browsing context", 262 and "top-level browsing context" are defined in [HTML]. 264 "Service Workers" are defined in the Service Workers specification 265 [SERVICE-WORKERS]. 267 The term "origin", the mechanism of deriving an origin from a URI, 268 and the "the same" matching algorithm for origins are defined in 269 [RFC6454]. 271 "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as 272 defined in Section 4.2.1 of [RFC7231]. 274 A domain's "public suffix" is the portion of a domain that is 275 controlled by a public registry, such as "com", "co.uk", and 276 "pvt.k12.wy.us". A domain's "registrable domain" is the domain's 277 public suffix plus the label to its left. That is, for 278 "https://www.site.example", the public suffix is "example", and the 279 registrable domain is "site.example". Whenever possible, user agents 280 SHOULD use an up-to-date public suffix list, such as the one 281 maintained by the Mozilla project at [PSL]. 283 The term "request", as well as a request's "client", "current url", 284 "method", and "target browsing context", are defined in [FETCH]. 286 3. Overview 288 This section outlines a way for an origin server to send state 289 information to a user agent and for the user agent to return the 290 state information to the origin server. 292 To store state, the origin server includes a Set-Cookie header in an 293 HTTP response. In subsequent requests, the user agent returns a 294 Cookie request header to the origin server. The Cookie header 295 contains cookies the user agent received in previous Set-Cookie 296 headers. The origin server is free to ignore the Cookie header or 297 use its contents for an application-defined purpose. 299 Origin servers MAY send a Set-Cookie response header with any 300 response. User agents MAY ignore Set-Cookie headers contained in 301 responses with 100-level status codes but MUST process Set-Cookie 302 headers contained in other responses (including responses with 400- 303 and 500-level status codes). An origin server can include multiple 304 Set-Cookie header fields in a single response. The presence of a 305 Cookie or a Set-Cookie header field does not preclude HTTP caches 306 from storing and reusing a response. 308 Origin servers SHOULD NOT fold multiple Set-Cookie header fields into 309 a single header field. The usual mechanism for folding HTTP headers 310 fields (i.e., as defined in Section 3.2.2 of [RFC7230]) might change 311 the semantics of the Set-Cookie header field because the %x2C (",") 312 character is used by Set-Cookie in a way that conflicts with such 313 folding. 315 3.1. Examples 317 Using the Set-Cookie header, a server can send the user agent a short 318 string in an HTTP response that the user agent will return in future 319 HTTP requests that are within the scope of the cookie. For example, 320 the server can send the user agent a "session identifier" named SID 321 with the value 31d4d96e407aad42. The user agent then returns the 322 session identifier in subsequent requests. 324 == Server -> User Agent == 326 Set-Cookie: SID=31d4d96e407aad42 328 == User Agent -> Server == 330 Cookie: SID=31d4d96e407aad42 332 The server can alter the default scope of the cookie using the Path 333 and Domain attributes. For example, the server can instruct the user 334 agent to return the cookie to every path and every subdomain of 335 site.example. 337 == Server -> User Agent == 339 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=site.example 341 == User Agent -> Server == 343 Cookie: SID=31d4d96e407aad42 345 As shown in the next example, the server can store multiple cookies 346 at the user agent. For example, the server can store a session 347 identifier as well as the user's preferred language by returning two 348 Set-Cookie header fields. Notice that the server uses the Secure and 349 HttpOnly attributes to provide additional security protections for 350 the more sensitive session identifier (see Section 4.1.2). 352 == Server -> User Agent == 354 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly 355 Set-Cookie: lang=en-US; Path=/; Domain=site.example 357 == User Agent -> Server == 359 Cookie: SID=31d4d96e407aad42; lang=en-US 361 Notice that the Cookie header above contains two cookies, one named 362 SID and one named lang. If the server wishes the user agent to 363 persist the cookie over multiple "sessions" (e.g., user agent 364 restarts), the server can specify an expiration date in the Expires 365 attribute. Note that the user agent might delete the cookie before 366 the expiration date if the user agent's cookie store exceeds its 367 quota or if the user manually deletes the server's cookie. 369 == Server -> User Agent == 371 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 373 == User Agent -> Server == 375 Cookie: SID=31d4d96e407aad42; lang=en-US 377 Finally, to remove a cookie, the server returns a Set-Cookie header 378 with an expiration date in the past. The server will be successful 379 in removing the cookie only if the Path and the Domain attribute in 380 the Set-Cookie header match the values used when the cookie was 381 created. 383 == Server -> User Agent == 385 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 387 == User Agent -> Server == 389 Cookie: SID=31d4d96e407aad42 391 4. Server Requirements 393 This section describes the syntax and semantics of a well-behaved 394 profile of the Cookie and Set-Cookie headers. 396 4.1. Set-Cookie 398 The Set-Cookie HTTP response header is used to send cookies from the 399 server to the user agent. 401 4.1.1. Syntax 403 Informally, the Set-Cookie response header contains the header name 404 "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with 405 a name-value-pair, followed by zero or more attribute-value pairs. 406 Servers SHOULD NOT send Set-Cookie headers that fail to conform to 407 the following grammar: 409 set-cookie-header = "Set-Cookie:" SP BWS set-cookie-string 410 set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av ) 411 cookie-pair = cookie-name BWS "=" BWS cookie-value 412 cookie-name = 1*cookie-octet 413 cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) 414 cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E / %x80-FF 415 ; US-ASCII characters excluding CTLs, 416 ; whitespace DQUOTE, comma, semicolon, 417 ; and backslash 419 cookie-av = expires-av / max-age-av / domain-av / 420 path-av / secure-av / httponly-av / 421 samesite-av / extension-av 422 expires-av = "Expires" BWS "=" BWS sane-cookie-date 423 sane-cookie-date = 424 425 max-age-av = "Max-Age" BWS "=" BWS non-zero-digit *DIGIT 426 ; In practice, both expires-av and max-age-av 427 ; are limited to dates representable by the 428 ; user agent. 429 non-zero-digit = %x31-39 430 ; digits 1 through 9 431 domain-av = "Domain" BWS "=" BWS domain-value 432 domain-value = 433 ; defined in [RFC1034], Section 3.5, as 434 ; enhanced by [RFC1123], Section 2.1 435 path-av = "Path" BWS "=" BWS path-value 436 path-value = *av-octet 437 secure-av = "Secure" 438 httponly-av = "HttpOnly" 439 samesite-av = "SameSite" BWS "=" BWS samesite-value 440 samesite-value = "Strict" / "Lax" / "None" 441 extension-av = *av-octet 442 av-octet = %x20-3A / %x3C-7E 443 ; any CHAR except CTLs or ";" 445 Note that some of the grammatical terms above reference documents 446 that use different grammatical notations than this document (which 447 uses ABNF from [RFC5234]). 449 The semantics of the cookie-value are not defined by this document. 451 To maximize compatibility with user agents, servers that wish to 452 store arbitrary data in a cookie-value SHOULD encode that data, for 453 example, using Base64 [RFC4648]. 455 Per the grammar above, the cookie-value MAY be wrapped in DQUOTE 456 characters. Note that in this case, the initial and trailing DQUOTE 457 characters are not stripped. They are part of the cookie-value, and 458 will be included in Cookie headers sent to the server. 460 The portions of the set-cookie-string produced by the cookie-av term 461 are known as attributes. To maximize compatibility with user agents, 462 servers SHOULD NOT produce two attributes with the same name in the 463 same set-cookie-string. (See Section 5.4 for how user agents handle 464 this case.) 466 Servers SHOULD NOT include more than one Set-Cookie header field in 467 the same response with the same cookie-name. (See Section 5.3 for 468 how user agents handle this case.) 470 If a server sends multiple responses containing Set-Cookie headers 471 concurrently to the user agent (e.g., when communicating with the 472 user agent over multiple sockets), these responses create a "race 473 condition" that can lead to unpredictable behavior. 475 NOTE: Some existing user agents differ in their interpretation of 476 two-digit years. To avoid compatibility issues, servers SHOULD use 477 the rfc1123-date format, which requires a four-digit year. 479 NOTE: Some user agents store and process dates in cookies as 32-bit 480 UNIX time_t values. Implementation bugs in the libraries supporting 481 time_t processing on some systems might cause such user agents to 482 process dates after the year 2038 incorrectly. 484 4.1.2. Semantics (Non-Normative) 486 This section describes simplified semantics of the Set-Cookie header. 487 These semantics are detailed enough to be useful for understanding 488 the most common uses of cookies by servers. The full semantics are 489 described in Section 5. 491 When the user agent receives a Set-Cookie header, the user agent 492 stores the cookie together with its attributes. Subsequently, when 493 the user agent makes an HTTP request, the user agent includes the 494 applicable, non-expired cookies in the Cookie header. 496 If the user agent receives a new cookie with the same cookie-name, 497 domain-value, and path-value as a cookie that it has already stored, 498 the existing cookie is evicted and replaced with the new cookie. 499 Notice that servers can delete cookies by sending the user agent a 500 new cookie with an Expires attribute with a value in the past. 502 Unless the cookie's attributes indicate otherwise, the cookie is 503 returned only to the origin server (and not, for example, to any 504 subdomains), and it expires at the end of the current session (as 505 defined by the user agent). User agents ignore unrecognized cookie 506 attributes (but not the entire cookie). 508 4.1.2.1. The Expires Attribute 510 The Expires attribute indicates the maximum lifetime of the cookie, 511 represented as the date and time at which the cookie expires. The 512 user agent is not required to retain the cookie until the specified 513 date has passed. In fact, user agents often evict cookies due to 514 memory pressure or privacy concerns. 516 4.1.2.2. The Max-Age Attribute 518 The Max-Age attribute indicates the maximum lifetime of the cookie, 519 represented as the number of seconds until the cookie expires. The 520 user agent is not required to retain the cookie for the specified 521 duration. In fact, user agents often evict cookies due to memory 522 pressure or privacy concerns. 524 NOTE: Some existing user agents do not support the Max-Age attribute. 525 User agents that do not support the Max-Age attribute ignore the 526 attribute. 528 If a cookie has both the Max-Age and the Expires attribute, the Max- 529 Age attribute has precedence and controls the expiration date of the 530 cookie. If a cookie has neither the Max-Age nor the Expires 531 attribute, the user agent will retain the cookie until "the current 532 session is over" (as defined by the user agent). 534 4.1.2.3. The Domain Attribute 536 The Domain attribute specifies those hosts to which the cookie will 537 be sent. For example, if the value of the Domain attribute is 538 "site.example", the user agent will include the cookie in the Cookie 539 header when making HTTP requests to site.example, www.site.example, 540 and www.corp.site.example. (Note that a leading %x2E ("."), if 541 present, is ignored even though that character is not permitted, but 542 a trailing %x2E ("."), if present, will cause the user agent to 543 ignore the attribute.) If the server omits the Domain attribute, the 544 user agent will return the cookie only to the origin server. 546 WARNING: Some existing user agents treat an absent Domain attribute 547 as if the Domain attribute were present and contained the current 548 host name. For example, if site.example returns a Set-Cookie header 549 without a Domain attribute, these user agents will erroneously send 550 the cookie to www.site.example as well. 552 The user agent will reject cookies unless the Domain attribute 553 specifies a scope for the cookie that would include the origin 554 server. For example, the user agent will accept a cookie with a 555 Domain attribute of "site.example" or of "foo.site.example" from 556 foo.site.example, but the user agent will not accept a cookie with a 557 Domain attribute of "bar.site.example" or of "baz.foo.site.example". 559 NOTE: For security reasons, many user agents are configured to reject 560 Domain attributes that correspond to "public suffixes". For example, 561 some user agents will reject Domain attributes of "com" or "co.uk". 562 (See Section 5.4 for more information.) 564 4.1.2.4. The Path Attribute 566 The scope of each cookie is limited to a set of paths, controlled by 567 the Path attribute. If the server omits the Path attribute, the user 568 agent will use the "directory" of the request-uri's path component as 569 the default value. (See Section 5.1.4 for more details.) 571 The user agent will include the cookie in an HTTP request only if the 572 path portion of the request-uri matches (or is a subdirectory of) the 573 cookie's Path attribute, where the %x2F ("/") character is 574 interpreted as a directory separator. 576 Although seemingly useful for isolating cookies between different 577 paths within a given host, the Path attribute cannot be relied upon 578 for security (see Section 8). 580 4.1.2.5. The Secure Attribute 582 The Secure attribute limits the scope of the cookie to "secure" 583 channels (where "secure" is defined by the user agent). When a 584 cookie has the Secure attribute, the user agent will include the 585 cookie in an HTTP request only if the request is transmitted over a 586 secure channel (typically HTTP over Transport Layer Security (TLS) 587 [RFC2818]). 589 Although seemingly useful for protecting cookies from active network 590 attackers, the Secure attribute protects only the cookie's 591 confidentiality. An active network attacker can overwrite Secure 592 cookies from an insecure channel, disrupting their integrity (see 593 Section 8.6 for more details). 595 4.1.2.6. The HttpOnly Attribute 597 The HttpOnly attribute limits the scope of the cookie to HTTP 598 requests. In particular, the attribute instructs the user agent to 599 omit the cookie when providing access to cookies via "non-HTTP" APIs 600 (such as a web browser API that exposes cookies to scripts). 602 Note that the HttpOnly attribute is independent of the Secure 603 attribute: a cookie can have both the HttpOnly and the Secure 604 attribute. 606 4.1.2.7. The SameSite Attribute 608 The "SameSite" attribute limits the scope of the cookie such that it 609 will only be attached to requests if those requests are same-site, as 610 defined by the algorithm in Section 5.2. For example, requests for 611 "https://site.example/sekrit-image" will attach same-site cookies if 612 and only if initiated from a context whose "site for cookies" is 613 "site.example". 615 If the "SameSite" attribute's value is "Strict", the cookie will only 616 be sent along with "same-site" requests. If the value is "Lax", the 617 cookie will be sent with same-site requests, and with "cross-site" 618 top-level navigations, as described in Section 5.3.7.1. If the value 619 is "None", the cookie will be sent with same-site and cross-site 620 requests. If the "SameSite" attribute's value is something other 621 than these three known keywords, the attribute's value will be 622 treated as "None". 624 The "SameSite" attribute affects cookie creation as well as delivery. 625 Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be 626 set in responses to cross-site subresource requests, or cross-site 627 nested navigations. They can be set along with any top-level 628 navigation, cross-site or otherwise. 630 4.1.3. Cookie Name Prefixes 632 Section 8.5 and Section 8.6 of this document spell out some of the 633 drawbacks of cookies' historical implementation. In particular, it 634 is impossible for a server to have confidence that a given cookie was 635 set with a particular set of attributes. In order to provide such 636 confidence in a backwards-compatible way, two common sets of 637 requirements can be inferred from the first few characters of the 638 cookie's name. 640 The normative requirements for the prefixes described below are 641 detailed in the storage model algorithm defined in Section 5.4. 643 4.1.3.1. The "__Secure-" Prefix 645 If a cookie's name begins with a case-sensitive match for the string 646 "__Secure-", then the cookie will have been set with a "Secure" 647 attribute. 649 For example, the following "Set-Cookie" header would be rejected by a 650 conformant user agent, as it does not have a "Secure" attribute. 652 Set-Cookie: __Secure-SID=12345; Domain=site.example 654 Whereas the following "Set-Cookie" header would be accepted: 656 Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure 658 4.1.3.2. The "__Host-" Prefix 660 If a cookie's name begins with a case-sensitive match for the string 661 "__Host-", then the cookie will have been set with a "Secure" 662 attribute, a "Path" attribute with a value of "/", and no "Domain" 663 attribute. 665 This combination yields a cookie that hews as closely as a cookie can 666 to treating the origin as a security boundary. The lack of a 667 "Domain" attribute ensures that the cookie's "host-only-flag" is 668 true, locking the cookie to a particular host, rather than allowing 669 it to span subdomains. Setting the "Path" to "/" means that the 670 cookie is effective for the entire host, and won't be overridden for 671 specific paths. The "Secure" attribute ensures that the cookie is 672 unaltered by non-secure origins, and won't span protocols. 674 Ports are the only piece of the origin model that "__Host-" cookies 675 continue to ignore. 677 For example, the following cookies would always be rejected: 679 Set-Cookie: __Host-SID=12345 680 Set-Cookie: __Host-SID=12345; Secure 681 Set-Cookie: __Host-SID=12345; Domain=site.example 682 Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/ 683 Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/ 685 While the would be accepted if set from a secure origin (e.g. 686 "https://site.example/"), and rejected otherwise: 688 Set-Cookie: __Host-SID=12345; Secure; Path=/ 690 4.2. Cookie 692 4.2.1. Syntax 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:" SP cookie-string 701 cookie-string = cookie-pair *( ";" SP cookie-pair ) 703 4.2.2. Semantics 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 724 header. 726 5. User Agent Requirements 728 This section specifies the Cookie and Set-Cookie headers in 729 sufficient detail that a user agent implementing these requirements 730 precisely can interoperate with existing servers (even those that do 731 not conform to the well-behaved profile described in Section 4). 733 A user agent could enforce more restrictions than those specified 734 herein (e.g., for the sake of improved security); however, 735 experiments have shown that such strictness reduces the likelihood 736 that a user agent will be able to interoperate with existing servers. 738 5.1. Subcomponent Algorithms 740 This section defines some algorithms used by user agents to process 741 specific subcomponents of the Cookie and Set-Cookie headers. 743 5.1.1. Dates 745 The user agent MUST use an algorithm equivalent to the following 746 algorithm to parse a cookie-date. Note that the various boolean 747 flags defined as a part of the algorithm (i.e., found-time, found- 748 day-of-month, found-month, found-year) are initially "not set". 750 1. Using the grammar below, divide the cookie-date into date-tokens. 752 cookie-date = *delimiter date-token-list *delimiter 753 date-token-list = date-token *( 1*delimiter date-token ) 754 date-token = 1*non-delimiter 756 delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E 757 non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF 758 non-digit = %x00-2F / %x3A-FF 760 day-of-month = 1*2DIGIT [ non-digit *OCTET ] 761 month = ( "jan" / "feb" / "mar" / "apr" / 762 "may" / "jun" / "jul" / "aug" / 763 "sep" / "oct" / "nov" / "dec" ) *OCTET 764 year = 2*4DIGIT [ non-digit *OCTET ] 765 time = hms-time [ non-digit *OCTET ] 766 hms-time = time-field ":" time-field ":" time-field 767 time-field = 1*2DIGIT 769 2. Process each date-token sequentially in the order the date-tokens 770 appear in the cookie-date: 772 1. If the found-time flag is not set and the token matches the 773 time production, set the found-time flag and set the hour- 774 value, minute-value, and second-value to the numbers denoted 775 by the digits in the date-token, respectively. Skip the 776 remaining sub-steps and continue to the next date-token. 778 2. If the found-day-of-month flag is not set and the date-token 779 matches the day-of-month production, set the found-day-of- 780 month flag and set the day-of-month-value to the number 781 denoted by the date-token. Skip the remaining sub-steps and 782 continue to the next date-token. 784 3. If the found-month flag is not set and the date-token matches 785 the month production, set the found-month flag and set the 786 month-value to the month denoted by the date-token. Skip the 787 remaining sub-steps and continue to the next date-token. 789 4. If the found-year flag is not set and the date-token matches 790 the year production, set the found-year flag and set the 791 year-value to the number denoted by the date-token. Skip the 792 remaining sub-steps and continue to the next date-token. 794 3. If the year-value is greater than or equal to 70 and less than or 795 equal to 99, increment the year-value by 1900. 797 4. If the year-value is greater than or equal to 0 and less than or 798 equal to 69, increment the year-value by 2000. 800 1. NOTE: Some existing user agents interpret two-digit years 801 differently. 803 5. Abort these steps and fail to parse the cookie-date if: 805 * at least one of the found-day-of-month, found-month, found- 806 year, or found-time flags is not set, 808 * the day-of-month-value is less than 1 or greater than 31, 810 * the year-value is less than 1601, 812 * the hour-value is greater than 23, 814 * the minute-value is greater than 59, or 816 * the second-value is greater than 59. 818 (Note that leap seconds cannot be represented in this syntax.) 820 6. Let the parsed-cookie-date be the date whose day-of-month, month, 821 year, hour, minute, and second (in UTC) are the day-of-month- 822 value, the month-value, the year-value, the hour-value, the 823 minute-value, and the second-value, respectively. If no such 824 date exists, abort these steps and fail to parse the cookie-date. 826 7. Return the parsed-cookie-date as the result of this algorithm. 828 5.1.2. Canonicalized Host Names 830 A canonicalized host name is the string generated by the following 831 algorithm: 833 1. Convert the host name to a sequence of individual domain name 834 labels. 836 2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label, 837 to an A-label (see Section 2.3.2.1 of [RFC5890] for the former 838 and latter), or to a "punycode label" (a label resulting from the 839 "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate 840 (see Section 6.3 of this specification). 842 3. Concatenate the resulting labels, separated by a %x2E (".") 843 character. 845 5.1.3. Domain Matching 847 A string domain-matches a given domain string if at least one of the 848 following conditions hold: 850 o The domain string and the string are identical. (Note that both 851 the domain string and the string will have been canonicalized to 852 lower case at this point.) 854 o All of the following conditions hold: 856 * The domain string is a suffix of the string. 858 * The last character of the string that is not included in the 859 domain string is a %x2E (".") character. 861 * The string is a host name (i.e., not an IP address). 863 5.1.4. Paths and Path-Match 865 The user agent MUST use an algorithm equivalent to the following 866 algorithm to compute the default-path of a cookie: 868 1. Let uri-path be the path portion of the request-uri if such a 869 portion exists (and empty otherwise). For example, if the 870 request-uri contains just a path (and optional query string), 871 then the uri-path is that path (without the %x3F ("?") character 872 or query string), and if the request-uri contains a full 873 absoluteURI, the uri-path is the path component of that URI. 875 2. If the uri-path is empty or if the first character of the uri- 876 path is not a %x2F ("/") character, output %x2F ("/") and skip 877 the remaining steps. 879 3. If the uri-path contains no more than one %x2F ("/") character, 880 output %x2F ("/") and skip the remaining step. 882 4. Output the characters of the uri-path from the first character up 883 to, but not including, the right-most %x2F ("/"). 885 A request-path path-matches a given cookie-path if at least one of 886 the following conditions holds: 888 o The cookie-path and the request-path are identical. 890 Note that this differs from the rules in [RFC3986] for equivalence 891 of the path component, and hence two equivalent paths can have 892 different cookies. 894 o The cookie-path is a prefix of the request-path, and the last 895 character of the cookie-path is %x2F ("/"). 897 o The cookie-path is a prefix of the request-path, and the first 898 character of the request-path that is not included in the cookie- 899 path is a %x2F ("/") character. 901 5.2. "Same-site" and "cross-site" Requests 903 A request is "same-site" if its target's URI's origin's registrable 904 domain is an exact match for the request's client's "site for 905 cookies", or if the request has no client. The request is otherwise 906 "cross-site". 908 For a given request ("request"), the following algorithm returns 909 "same-site" or "cross-site": 911 1. If "request"'s client is "null", return "same-site". 913 Note that this is the case for navigation triggered by the user 914 directly (e.g. by typing directly into a user agent's address 915 bar). 917 2. Let "site" be "request"'s client's "site for cookies" (as defined 918 in the following sections). 920 3. Let "target" be the registrable domain of "request"'s current 921 url. 923 4. If "site" is an exact match for "target", return "same-site". 925 5. Return "cross-site". 927 The request's client's "site for cookies" is calculated depending 928 upon its client's type, as described in the following subsections: 930 5.2.1. Document-based requests 932 The URI displayed in a user agent's address bar is the only security 933 context directly exposed to users, and therefore the only signal 934 users can reasonably rely upon to determine whether or not they trust 935 a particular website. The registrable domain of that URI's origin 936 represents the context in which a user most likely believes 937 themselves to be interacting. We'll label this domain the "top-level 938 site". 940 For a document displayed in a top-level browsing context, we can stop 941 here: the document's "site for cookies" is the top-level site. 943 For documents which are displayed in nested browsing contexts, we 944 need to audit the origins of each of a document's ancestor browsing 945 contexts' active documents in order to account for the "multiple- 946 nested scenarios" described in Section 4 of [RFC7034]. A document's 947 "site for cookies" is the top-level site if and only if the document 948 and each of its ancestor documents' origins have the same registrable 949 domain as the top-level site. Otherwise its "site for cookies" is 950 the empty string. 952 Given a Document ("document"), the following algorithm returns its 953 "site for cookies" (either a registrable domain, or the empty 954 string): 956 1. Let "top-document" be the active document in "document"'s 957 browsing context's top-level browsing context. 959 2. Let "top-origin" be the origin of "top-document"'s URI if "top- 960 document"'s sandboxed origin browsing context flag is set, and 961 "top-document"'s origin otherwise. 963 3. Let "documents" be a list containing "document" and each of 964 "document"'s ancestor browsing contexts' active documents. 966 4. For each "item" in "documents": 968 1. Let "origin" be the origin of "item"'s URI if "item"'s 969 sandboxed origin browsing context flag is set, and "item"'s 970 origin otherwise. 972 2. If "origin"'s host's registrable domain is not an exact match 973 for "top-origin"'s host's registrable domain, return the 974 empty string. 976 5. Return "top-origin"'s host's registrable domain. 978 5.2.2. Worker-based requests 980 Worker-driven requests aren't as clear-cut as document-driven 981 requests, as there isn't a clear link between a top-level browsing 982 context and a worker. This is especially true for Service Workers 983 [SERVICE-WORKERS], which may execute code in the background, without 984 any document visible at all. 986 Note: The descriptions below assume that workers must be same-origin 987 with the documents that instantiate them. If this invariant changes, 988 we'll need to take the worker's script's URI into account when 989 determining their status. 991 5.2.2.1. Dedicated and Shared Workers 993 Dedicated workers are simple, as each dedicated worker is bound to 994 one and only one document. Requests generated from a dedicated 995 worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define 996 their "site for cookies" as that document's "site for cookies". 998 Shared workers may be bound to multiple documents at once. As it is 999 quite possible for those documents to have distinct "site for cookie" 1000 values, the worker's "site for cookies" will be the empty string in 1001 cases where the values diverge, and the shared value in cases where 1002 the values agree. 1004 Given a WorkerGlobalScope ("worker"), the following algorithm returns 1005 its "site for cookies" (either a registrable domain, or the empty 1006 string): 1008 1. Let "site" be "worker"'s origin's host's registrable domain. 1010 2. For each "document" in "worker"'s Documents: 1012 1. Let "document-site" be "document"'s "site for cookies" (as 1013 defined in Section 5.2.1). 1015 2. If "document-site" is not an exact match for "site", return 1016 the empty string. 1018 3. Return "site". 1020 5.2.2.2. Service Workers 1022 Service Workers are more complicated, as they act as a completely 1023 separate execution context with only tangential relationship to the 1024 Document which registered them. 1026 Requests which simply pass through a Service Worker will be handled 1027 as described above: the request's client will be the Document or 1028 Worker which initiated the request, and its "site for cookies" will 1029 be those defined in Section 5.2.1 and Section 5.2.2.1 1031 Requests which are initiated by the Service Worker itself (via a 1032 direct call to "fetch()", for instance), on the other hand, will have 1033 a client which is a ServiceWorkerGlobalScope. Its "site for cookies" 1034 will be the registrable domain of the Service Worker's URI. 1036 Given a ServiceWorkerGlobalScope ("worker"), the following algorithm 1037 returns its "site for cookies" (either a registrable domain, or the 1038 empty string): 1040 1. Return "worker"'s origin's host's registrable domain. 1042 5.3. The Set-Cookie Header 1044 When a user agent receives a Set-Cookie header field in an HTTP 1045 response, the user agent MAY ignore the Set-Cookie header field in 1046 its entirety. For example, the user agent might wish to block 1047 responses to "third-party" requests from setting cookies (see 1048 Section 7.1). 1050 If the user agent does not ignore the Set-Cookie header field in its 1051 entirety, the user agent MUST parse the field-value of the Set-Cookie 1052 header field as a set-cookie-string (defined below). 1054 NOTE: The algorithm below is more permissive than the grammar in 1055 Section 4.1. For example, the algorithm strips leading and trailing 1056 whitespace from the cookie name and value (but maintains internal 1057 whitespace), whereas the grammar in Section 4.1 forbids whitespace in 1058 these positions. User agents use this algorithm so as to 1059 interoperate with servers that do not follow the recommendations in 1060 Section 4. 1062 A user agent MUST use an algorithm equivalent to the following 1063 algorithm to parse a set-cookie-string: 1065 1. If the set-cookie-string contains a %x3B (";") character: 1067 1. The name-value-pair string consists of the characters up to, 1068 but not including, the first %x3B (";"), and the unparsed- 1069 attributes consist of the remainder of the set-cookie-string 1070 (including the %x3B (";") in question). 1072 Otherwise: 1074 1. The name-value-pair string consists of all the characters 1075 contained in the set-cookie-string, and the unparsed- 1076 attributes is the empty string. 1078 2. If the name-value-pair string lacks a %x3D ("=") character, then 1079 the name string is empty, and the value string is the value of 1080 name-value-pair. 1082 Otherwise, the name string consists of the characters up to, but 1083 not including, the first %x3D ("=") character, and the (possibly 1084 empty) value string consists of the characters after the first 1085 %x3D ("=") character. 1087 3. Remove any leading or trailing WSP characters from the name 1088 string and the value string. 1090 4. If both the name string and the value string are empty, ignore 1091 the set-cookie-string entirely. 1093 5. The cookie-name is the name string, and the cookie-value is the 1094 value string. 1096 The user agent MUST use an algorithm equivalent to the following 1097 algorithm to parse the unparsed-attributes: 1099 1. If the unparsed-attributes string is empty, skip the rest of 1100 these steps. 1102 2. Discard the first character of the unparsed-attributes (which 1103 will be a %x3B (";") character). 1105 3. If the remaining unparsed-attributes contains a %x3B (";") 1106 character: 1108 1. Consume the characters of the unparsed-attributes up to, but 1109 not including, the first %x3B (";") character. 1111 Otherwise: 1113 1. Consume the remainder of the unparsed-attributes. 1115 Let the cookie-av string be the characters consumed in this step. 1117 4. If the cookie-av string contains a %x3D ("=") character: 1119 1. The (possibly empty) attribute-name string consists of the 1120 characters up to, but not including, the first %x3D ("=") 1121 character, and the (possibly empty) attribute-value string 1122 consists of the characters after the first %x3D ("=") 1123 character. 1125 Otherwise: 1127 1. The attribute-name string consists of the entire cookie-av 1128 string, and the attribute-value string is empty. 1130 5. Remove any leading or trailing WSP characters from the attribute- 1131 name string and the attribute-value string. 1133 6. Process the attribute-name and attribute-value according to the 1134 requirements in the following subsections. (Notice that 1135 attributes with unrecognized attribute-names are ignored.) 1137 7. Return to Step 1 of this algorithm. 1139 When the user agent finishes parsing the set-cookie-string, the user 1140 agent is said to "receive a cookie" from the request-uri with name 1141 cookie-name, value cookie-value, and attributes cookie-attribute- 1142 list. (See Section 5.4 for additional requirements triggered by 1143 receiving a cookie.) 1145 5.3.1. The Expires Attribute 1147 If the attribute-name case-insensitively matches the string 1148 "Expires", the user agent MUST process the cookie-av as follows. 1150 1. Let the expiry-time be the result of parsing the attribute-value 1151 as cookie-date (see Section 5.1.1). 1153 2. If the attribute-value failed to parse as a cookie date, ignore 1154 the cookie-av. 1156 3. If the expiry-time is later than the last date the user agent can 1157 represent, the user agent MAY replace the expiry-time with the 1158 last representable date. 1160 4. If the expiry-time is earlier than the earliest date the user 1161 agent can represent, the user agent MAY replace the expiry-time 1162 with the earliest representable date. 1164 5. Append an attribute to the cookie-attribute-list with an 1165 attribute-name of Expires and an attribute-value of expiry-time. 1167 5.3.2. The Max-Age Attribute 1169 If the attribute-name case-insensitively matches the string "Max- 1170 Age", the user agent MUST process the cookie-av as follows. 1172 1. If the first character of the attribute-value is not a DIGIT or a 1173 "-" character, ignore the cookie-av. 1175 2. If the remainder of attribute-value contains a non-DIGIT 1176 character, ignore the cookie-av. 1178 3. Let delta-seconds be the attribute-value converted to an integer. 1180 4. If delta-seconds is less than or equal to zero (0), let expiry- 1181 time be the earliest representable date and time. Otherwise, let 1182 the expiry-time be the current date and time plus delta-seconds 1183 seconds. 1185 5. Append an attribute to the cookie-attribute-list with an 1186 attribute-name of Max-Age and an attribute-value of expiry-time. 1188 5.3.3. The Domain Attribute 1190 If the attribute-name case-insensitively matches the string "Domain", 1191 the user agent MUST process the cookie-av as follows. 1193 1. If the attribute-value is empty, the behavior is undefined. 1194 However, the user agent SHOULD ignore the cookie-av entirely. 1196 2. If the first character of the attribute-value string is %x2E 1197 ("."): 1199 1. Let cookie-domain be the attribute-value without the leading 1200 %x2E (".") character. 1202 Otherwise: 1204 1. Let cookie-domain be the entire attribute-value. 1206 3. Convert the cookie-domain to lower case. 1208 4. Append an attribute to the cookie-attribute-list with an 1209 attribute-name of Domain and an attribute-value of cookie-domain. 1211 5.3.4. The Path Attribute 1213 If the attribute-name case-insensitively matches the string "Path", 1214 the user agent MUST process the cookie-av as follows. 1216 1. If the attribute-value is empty or if the first character of the 1217 attribute-value is not %x2F ("/"): 1219 1. Let cookie-path be the default-path. 1221 Otherwise: 1223 1. Let cookie-path be the attribute-value. 1225 2. Append an attribute to the cookie-attribute-list with an 1226 attribute-name of Path and an attribute-value of cookie-path. 1228 5.3.5. The Secure Attribute 1230 If the attribute-name case-insensitively matches the string "Secure", 1231 the user agent MUST append an attribute to the cookie-attribute-list 1232 with an attribute-name of Secure and an empty attribute-value. 1234 5.3.6. The HttpOnly Attribute 1236 If the attribute-name case-insensitively matches the string 1237 "HttpOnly", the user agent MUST append an attribute to the cookie- 1238 attribute-list with an attribute-name of HttpOnly and an empty 1239 attribute-value. 1241 5.3.7. The SameSite Attribute 1243 If the attribute-name case-insensitively matches the string 1244 "SameSite", the user agent MUST process the cookie-av as follows: 1246 1. Let "enforcement" be "None". 1248 2. If cookie-av's attribute-value is a case-insensitive match for 1249 "Strict", set "enforcement" to "Strict". 1251 3. If cookie-av's attribute-value is a case-insensitive match for 1252 "Lax", set "enforcement" to "Lax". 1254 4. Append an attribute to the cookie-attribute-list with an 1255 attribute-name of "SameSite" and an attribute-value of 1256 "enforcement". 1258 Note: This algorithm maps the "None" value, as well as any unknown 1259 value, to the "None" behavior, which is helpful for backwards 1260 compatibility when introducing new variants. 1262 5.3.7.1. "Strict" and "Lax" enforcement 1264 Same-site cookies in "Strict" enforcement mode will not be sent along 1265 with top-level navigations which are triggered from a cross-site 1266 document context. As discussed in Section 8.8.2, this might or might 1267 not be compatible with existing session management systems. In the 1268 interests of providing a drop-in mechanism that mitigates the risk of 1269 CSRF attacks, developers may set the "SameSite" attribute in a "Lax" 1270 enforcement mode that carves out an exception which sends same-site 1271 cookies along with cross-site requests if and only if they are top- 1272 level navigations which use a "safe" (in the [RFC7231] sense) HTTP 1273 method. 1275 Lax enforcement provides reasonable defense in depth against CSRF 1276 attacks that rely on unsafe HTTP methods (like "POST"), but does not 1277 offer a robust defense against CSRF as a general category of attack: 1279 1. Attackers can still pop up new windows or trigger top-level 1280 navigations in order to create a "same-site" request (as 1281 described in Section 5.2.1), which is only a speedbump along the 1282 road to exploitation. 1284 2. Features like "" [prerendering] can be 1285 exploited to create "same-site" requests without the risk of user 1286 detection. 1288 When possible, developers should use a session management mechanism 1289 such as that described in Section 8.8.2 to mitigate the risk of CSRF 1290 more completely. 1292 5.4. Storage Model 1294 The user agent stores the following fields about each cookie: name, 1295 value, expiry-time, domain, path, creation-time, last-access-time, 1296 persistent-flag, host-only-flag, secure-only-flag, http-only-flag, 1297 and same-site-flag. 1299 When the user agent "receives a cookie" from a request-uri with name 1300 cookie-name, value cookie-value, and attributes cookie-attribute- 1301 list, the user agent MUST process the cookie as follows: 1303 1. A user agent MAY ignore a received cookie in its entirety. For 1304 example, the user agent might wish to block receiving cookies 1305 from "third-party" responses or the user agent might not wish to 1306 store cookies that exceed some size. 1308 2. Create a new cookie with name cookie-name, value cookie-value. 1309 Set the creation-time and the last-access-time to the current 1310 date and time. 1312 3. If the cookie-attribute-list contains an attribute with an 1313 attribute-name of "Max-Age": 1315 1. Set the cookie's persistent-flag to true. 1317 2. Set the cookie's expiry-time to attribute-value of the last 1318 attribute in the cookie-attribute-list with an attribute- 1319 name of "Max-Age". 1321 Otherwise, if the cookie-attribute-list contains an attribute 1322 with an attribute-name of "Expires" (and does not contain an 1323 attribute with an attribute-name of "Max-Age"): 1325 1. Set the cookie's persistent-flag to true. 1327 2. Set the cookie's expiry-time to attribute-value of the last 1328 attribute in the cookie-attribute-list with an attribute- 1329 name of "Expires". 1331 Otherwise: 1333 1. Set the cookie's persistent-flag to false. 1335 2. Set the cookie's expiry-time to the latest representable 1336 date. 1338 4. If the cookie-attribute-list contains an attribute with an 1339 attribute-name of "Domain": 1341 1. Let the domain-attribute be the attribute-value of the last 1342 attribute in the cookie-attribute-list with an attribute- 1343 name of "Domain". 1345 Otherwise: 1347 1. Let the domain-attribute be the empty string. 1349 5. If the user agent is configured to reject "public suffixes" and 1350 the domain-attribute is a public suffix: 1352 1. If the domain-attribute is identical to the canonicalized 1353 request-host: 1355 1. Let the domain-attribute be the empty string. 1357 Otherwise: 1359 1. Ignore the cookie entirely and abort these steps. 1361 NOTE: This step prevents "attacker.example" from disrupting the 1362 integrity of "site.example" by setting a cookie with a Domain 1363 attribute of "example". 1365 6. If the domain-attribute is non-empty: 1367 1. If the canonicalized request-host does not domain-match the 1368 domain-attribute: 1370 1. Ignore the cookie entirely and abort these steps. 1372 Otherwise: 1374 1. Set the cookie's host-only-flag to false. 1376 2. Set the cookie's domain to the domain-attribute. 1378 Otherwise: 1380 1. Set the cookie's host-only-flag to true. 1382 2. Set the cookie's domain to the canonicalized request-host. 1384 7. If the cookie-attribute-list contains an attribute with an 1385 attribute-name of "Path", set the cookie's path to attribute- 1386 value of the last attribute in the cookie-attribute-list with an 1387 attribute-name of "Path". Otherwise, set the cookie's path to 1388 the default-path of the request-uri. 1390 8. If the cookie-attribute-list contains an attribute with an 1391 attribute-name of "Secure", set the cookie's secure-only-flag to 1392 true. Otherwise, set the cookie's secure-only-flag to false. 1394 9. If the scheme component of the request-uri does not denote a 1395 "secure" protocol (as defined by the user agent), and the 1396 cookie's secure-only-flag is true, then abort these steps and 1397 ignore the cookie entirely. 1399 10. If the cookie-attribute-list contains an attribute with an 1400 attribute-name of "HttpOnly", set the cookie's http-only-flag to 1401 true. Otherwise, set the cookie's http-only-flag to false. 1403 11. If the cookie was received from a "non-HTTP" API and the 1404 cookie's http-only-flag is true, abort these steps and ignore 1405 the cookie entirely. 1407 12. If the cookie's secure-only-flag is false, and the scheme 1408 component of request-uri does not denote a "secure" protocol, 1409 then abort these steps and ignore the cookie entirely if the 1410 cookie store contains one or more cookies that meet all of the 1411 following criteria: 1413 1. Their name matches the name of the newly-created cookie. 1415 2. Their secure-only-flag is true. 1417 3. Their domain domain-matches the domain of the newly-created 1418 cookie, or vice-versa. 1420 4. The path of the newly-created cookie path-matches the path 1421 of the existing cookie. 1423 Note: The path comparison is not symmetric, ensuring only that a 1424 newly-created, non-secure cookie does not overlay an existing 1425 secure cookie, providing some mitigation against cookie-fixing 1426 attacks. That is, given an existing secure cookie named 'a' 1427 with a path of '/login', a non-secure cookie named 'a' could be 1428 set for a path of '/' or '/foo', but not for a path of '/login' 1429 or '/login/en'. 1431 13. If the cookie-attribute-list contains an attribute with an 1432 attribute-name of "SameSite", set the cookie's same-site-flag to 1433 the attribute-value of the last attribute in the cookie- 1434 attribute-list with an attribute-name of "SameSite" (i.e. either 1435 "Strict", "Lax", or "None"). Otherwise, set the cookie's same- 1436 site-flag to "None". 1438 14. If the cookie's "same-site-flag" is not "None": 1440 1. If the cookie was received from a "non-HTTP" API, and the 1441 API was called from a context whose "site for cookies" is 1442 not an exact match for request-uri's host's registrable 1443 domain, then abort these steps and ignore the newly created 1444 cookie entirely. 1446 2. If the cookie was received from a "same-site" request (as 1447 defined in Section 5.2), skip the remaining substeps and 1448 continue processing the cookie. 1450 3. If the cookie was received from a request which is 1451 navigating a top-level browsing context [HTML] (e.g. if the 1452 request's "reserved client" is either "null" or an 1453 environment whose "target browsing context" is a top-level 1454 browing context), skip the remaining substeps and continue 1455 processing the cookie. 1457 Note: Top-level navigations can create a cookie with any 1458 "SameSite" value, even if the new cookie wouldn't have been 1459 sent along with the request had it already existed prior to 1460 the navigation. 1462 4. Abort these steps and ignore the newly created cookie 1463 entirely. 1465 15. If the cookie-name begins with a case-sensitive match for the 1466 string "__Secure-", abort these steps and ignore the cookie 1467 entirely unless the cookie's secure-only-flag is true. 1469 16. If the cookie-name begins with a case-sensitive match for the 1470 string "__Host-", abort these steps and ignore the cookie 1471 entirely unless the cookie meets all the following criteria: 1473 1. The cookie's secure-only-flag is true. 1475 2. The cookie's host-only-flag is true. 1477 3. The cookie-attribute-list contains an attribute with an 1478 attribute-name of "Path", and the cookie's path is "/". 1480 17. If the cookie store contains a cookie with the same name, 1481 domain, host-only-flag, and path as the newly-created cookie: 1483 1. Let old-cookie be the existing cookie with the same name, 1484 domain, host-only-flag, and path as the newly-created 1485 cookie. (Notice that this algorithm maintains the invariant 1486 that there is at most one such cookie.) 1488 2. If the newly-created cookie was received from a "non-HTTP" 1489 API and the old-cookie's http-only-flag is true, abort these 1490 steps and ignore the newly created cookie entirely. 1492 3. Update the creation-time of the newly-created cookie to 1493 match the creation-time of the old-cookie. 1495 4. Remove the old-cookie from the cookie store. 1497 18. Insert the newly-created cookie into the cookie store. 1499 A cookie is "expired" if the cookie has an expiry date in the past. 1501 The user agent MUST evict all expired cookies from the cookie store 1502 if, at any time, an expired cookie exists in the cookie store. 1504 At any time, the user agent MAY "remove excess cookies" from the 1505 cookie store if the number of cookies sharing a domain field exceeds 1506 some implementation-defined upper bound (such as 50 cookies). 1508 At any time, the user agent MAY "remove excess cookies" from the 1509 cookie store if the cookie store exceeds some predetermined upper 1510 bound (such as 3000 cookies). 1512 When the user agent removes excess cookies from the cookie store, the 1513 user agent MUST evict cookies in the following priority order: 1515 1. Expired cookies. 1517 2. Cookies whose secure-only-flag is false, and which share a domain 1518 field with more than a predetermined number of other cookies. 1520 3. Cookies that share a domain field with more than a predetermined 1521 number of other cookies. 1523 4. All cookies. 1525 If two cookies have the same removal priority, the user agent MUST 1526 evict the cookie with the earliest last-access-time first. 1528 When "the current session is over" (as defined by the user agent), 1529 the user agent MUST remove from the cookie store all cookies with the 1530 persistent-flag set to false. 1532 5.5. The Cookie Header 1534 The user agent includes stored cookies in the Cookie HTTP request 1535 header. 1537 When the user agent generates an HTTP request, the user agent MUST 1538 NOT attach more than one Cookie header field. 1540 A user agent MAY omit the Cookie header in its entirety. For 1541 example, the user agent might wish to block sending cookies during 1542 "third-party" requests from setting cookies (see Section 7.1). 1544 If the user agent does attach a Cookie header field to an HTTP 1545 request, the user agent MUST send the cookie-string (defined below) 1546 as the value of the header field. 1548 The user agent MUST use an algorithm equivalent to the following 1549 algorithm to compute the cookie-string from a cookie store and a 1550 request-uri: 1552 1. Let cookie-list be the set of cookies from the cookie store that 1553 meets all of the following requirements: 1555 * Either: 1557 + The cookie's host-only-flag is true and the canonicalized 1558 request-host is identical to the cookie's domain. 1560 Or: 1562 + The cookie's host-only-flag is false and the canonicalized 1563 request-host domain-matches the cookie's domain. 1565 * The request-uri's path path-matches the cookie's path. 1567 * If the cookie's secure-only-flag is true, then the request- 1568 uri's scheme must denote a "secure" protocol (as defined by 1569 the user agent). 1571 NOTE: The notion of a "secure" protocol is not defined by this 1572 document. Typically, user agents consider a protocol secure 1573 if the protocol makes use of transport-layer security, such as 1574 SSL or TLS. For example, most user agents consider "https" to 1575 be a scheme that denotes a secure protocol. 1577 * If the cookie's http-only-flag is true, then exclude the 1578 cookie if the cookie-string is being generated for a "non- 1579 HTTP" API (as defined by the user agent). 1581 * If the cookie's same-site-flag is not "None", and the HTTP 1582 request is cross-site (as defined in Section 5.2) then exclude 1583 the cookie unless all of the following statements hold: 1585 1. The same-site-flag is "Lax" 1587 2. The HTTP request's method is "safe". 1589 3. The HTTP request's target browsing context is a top-level 1590 browsing context. 1592 2. The user agent SHOULD sort the cookie-list in the following 1593 order: 1595 * Cookies with longer paths are listed before cookies with 1596 shorter paths. 1598 * Among cookies that have equal-length path fields, cookies with 1599 earlier creation-times are listed before cookies with later 1600 creation-times. 1602 NOTE: Not all user agents sort the cookie-list in this order, but 1603 this order reflects common practice when this document was 1604 written, and, historically, there have been servers that 1605 (erroneously) depended on this order. 1607 3. Update the last-access-time of each cookie in the cookie-list to 1608 the current date and time. 1610 4. Serialize the cookie-list into a cookie-string by processing each 1611 cookie in the cookie-list in order: 1613 1. If the cookies' name is not empty, output the cookie's name 1614 followed by the %x3D ("=") character. 1616 2. If the cookies' value is not empty, output the cookie's 1617 value. 1619 3. If there is an unprocessed cookie in the cookie-list, output 1620 the characters %x3B and %x20 ("; "). 1622 NOTE: Despite its name, the cookie-string is actually a sequence of 1623 octets, not a sequence of characters. To convert the cookie-string 1624 (or components thereof) into a sequence of characters (e.g., for 1625 presentation to the user), the user agent might wish to try using the 1626 UTF-8 character encoding [RFC3629] to decode the octet sequence. 1627 This decoding might fail, however, because not every sequence of 1628 octets is valid UTF-8. 1630 6. Implementation Considerations 1632 6.1. Limits 1634 Practical user agent implementations have limits on the number and 1635 size of cookies that they can store. General-use user agents SHOULD 1636 provide each of the following minimum capabilities: 1638 o At least 4096 bytes per cookie (as measured by the sum of the 1639 length of the cookie's name, value, and attributes). 1641 o At least 50 cookies per domain. 1643 o At least 3000 cookies total. 1645 Servers SHOULD use as few and as small cookies as possible to avoid 1646 reaching these implementation limits and to minimize network 1647 bandwidth due to the Cookie header being included in every request. 1649 Servers SHOULD gracefully degrade if the user agent fails to return 1650 one or more cookies in the Cookie header because the user agent might 1651 evict any cookie at any time on orders from the user. 1653 6.2. Application Programming Interfaces 1655 One reason the Cookie and Set-Cookie headers use such esoteric syntax 1656 is that many platforms (both in servers and user agents) provide a 1657 string-based application programming interface (API) to cookies, 1658 requiring application-layer programmers to generate and parse the 1659 syntax used by the Cookie and Set-Cookie headers, which many 1660 programmers have done incorrectly, resulting in interoperability 1661 problems. 1663 Instead of providing string-based APIs to cookies, platforms would be 1664 well-served by providing more semantic APIs. It is beyond the scope 1665 of this document to recommend specific API designs, but there are 1666 clear benefits to accepting an abstract "Date" object instead of a 1667 serialized date string. 1669 6.3. IDNA Dependency and Migration 1671 IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are 1672 differences between the two specifications, and thus there can be 1673 differences in processing (e.g., converting) domain name labels that 1674 have been registered under one from those registered under the other. 1675 There will be a transition period of some time during which 1676 IDNA2003-based domain name labels will exist in the wild. User 1677 agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [UTS46] 1678 or [RFC5895] in order to facilitate their IDNA transition. If a user 1679 agent does not implement IDNA2008, the user agent MUST implement 1680 IDNA2003 [RFC3490]. 1682 7. Privacy Considerations 1684 Cookies are often criticized for letting servers track users. For 1685 example, a number of "web analytics" companies use cookies to 1686 recognize when a user returns to a web site or visits another web 1687 site. Although cookies are not the only mechanism servers can use to 1688 track users across HTTP requests, cookies facilitate tracking because 1689 they are persistent across user agent sessions and can be shared 1690 between hosts. 1692 7.1. Third-Party Cookies 1694 Particularly worrisome are so-called "third-party" cookies. In 1695 rendering an HTML document, a user agent often requests resources 1696 from other servers (such as advertising networks). These third-party 1697 servers can use cookies to track the user even if the user never 1698 visits the server directly. For example, if a user visits a site 1699 that contains content from a third party and then later visits 1700 another site that contains content from the same third party, the 1701 third party can track the user between the two sites. 1703 Given this risk to user privacy, some user agents restrict how third- 1704 party cookies behave, and those restrictions vary widly. For 1705 instance, user agents might block third-party cookies entirely by 1706 refusing to send Cookie headers or process Set-Cookie headers during 1707 third-party requests. They might take a less draconian approach by 1708 partitioning cookies based on the first-party context, sending one 1709 set of cookies to a given third party in one first-party context, and 1710 another to the same third party in another. 1712 This document grants user agents wide latitude to experiment with 1713 third-party cookie policies that balance the privacy and 1714 compatibility needs of their users. However, this document does not 1715 endorse any particular third-party cookie policy. 1717 Third-party cookie blocking policies are often ineffective at 1718 achieving their privacy goals if servers attempt to work around their 1719 restrictions to track users. In particular, two collaborating 1720 servers can often track users without using cookies at all by 1721 injecting identifying information into dynamic URLs. 1723 7.2. User Controls 1725 User agents SHOULD provide users with a mechanism for managing the 1726 cookies stored in the cookie store. For example, a user agent might 1727 let users delete all cookies received during a specified time period 1728 or all the cookies related to a particular domain. In addition, many 1729 user agents include a user interface element that lets users examine 1730 the cookies stored in their cookie store. 1732 User agents SHOULD provide users with a mechanism for disabling 1733 cookies. When cookies are disabled, the user agent MUST NOT include 1734 a Cookie header in outbound HTTP requests and the user agent MUST NOT 1735 process Set-Cookie headers in inbound HTTP responses. 1737 Some user agents provide users the option of preventing persistent 1738 storage of cookies across sessions. When configured thusly, user 1739 agents MUST treat all received cookies as if the persistent-flag were 1740 set to false. Some popular user agents expose this functionality via 1741 "private browsing" mode [Aggarwal2010]. 1743 Some user agents provide users with the ability to approve individual 1744 writes to the cookie store. In many common usage scenarios, these 1745 controls generate a large number of prompts. However, some privacy- 1746 conscious users find these controls useful nonetheless. 1748 7.3. Expiration Dates 1750 Although servers can set the expiration date for cookies to the 1751 distant future, most user agents do not actually retain cookies for 1752 multiple decades. Rather than choosing gratuitously long expiration 1753 periods, servers SHOULD promote user privacy by selecting reasonable 1754 cookie expiration periods based on the purpose of the cookie. For 1755 example, a typical session identifier might reasonably be set to 1756 expire in two weeks. 1758 8. Security Considerations 1760 8.1. Overview 1762 Cookies have a number of security pitfalls. This section overviews a 1763 few of the more salient issues. 1765 In particular, cookies encourage developers to rely on ambient 1766 authority for authentication, often becoming vulnerable to attacks 1767 such as cross-site request forgery [CSRF]. Also, when storing 1768 session identifiers in cookies, developers often create session 1769 fixation vulnerabilities. 1771 Transport-layer encryption, such as that employed in HTTPS, is 1772 insufficient to prevent a network attacker from obtaining or altering 1773 a victim's cookies because the cookie protocol itself has various 1774 vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", 1775 below). In addition, by default, cookies do not provide 1776 confidentiality or integrity from network attackers, even when used 1777 in conjunction with HTTPS. 1779 8.2. Ambient Authority 1781 A server that uses cookies to authenticate users can suffer security 1782 vulnerabilities because some user agents let remote parties issue 1783 HTTP requests from the user agent (e.g., via HTTP redirects or HTML 1784 forms). When issuing those requests, user agents attach cookies even 1785 if the remote party does not know the contents of the cookies, 1786 potentially letting the remote party exercise authority at an unwary 1787 server. 1789 Although this security concern goes by a number of names (e.g., 1790 cross-site request forgery, confused deputy), the issue stems from 1791 cookies being a form of ambient authority. Cookies encourage server 1792 operators to separate designation (in the form of URLs) from 1793 authorization (in the form of cookies). Consequently, the user agent 1794 might supply the authorization for a resource designated by the 1795 attacker, possibly causing the server or its clients to undertake 1796 actions designated by the attacker as though they were authorized by 1797 the user. 1799 Instead of using cookies for authorization, server operators might 1800 wish to consider entangling designation and authorization by treating 1801 URLs as capabilities. Instead of storing secrets in cookies, this 1802 approach stores secrets in URLs, requiring the remote entity to 1803 supply the secret itself. Although this approach is not a panacea, 1804 judicious application of these principles can lead to more robust 1805 security. 1807 8.3. Clear Text 1809 Unless sent over a secure channel (such as TLS), the information in 1810 the Cookie and Set-Cookie headers is transmitted in the clear. 1812 1. All sensitive information conveyed in these headers is exposed to 1813 an eavesdropper. 1815 2. A malicious intermediary could alter the headers as they travel 1816 in either direction, with unpredictable results. 1818 3. A malicious client could alter the Cookie header before 1819 transmission, with unpredictable results. 1821 Servers SHOULD encrypt and sign the contents of cookies (using 1822 whatever format the server desires) when transmitting them to the 1823 user agent (even when sending the cookies over a secure channel). 1824 However, encrypting and signing cookie contents does not prevent an 1825 attacker from transplanting a cookie from one user agent to another 1826 or from replaying the cookie at a later time. 1828 In addition to encrypting and signing the contents of every cookie, 1829 servers that require a higher level of security SHOULD use the Cookie 1830 and Set-Cookie headers only over a secure channel. When using 1831 cookies over a secure channel, servers SHOULD set the Secure 1832 attribute (see Section 4.1.2.5) for every cookie. If a server does 1833 not set the Secure attribute, the protection provided by the secure 1834 channel will be largely moot. 1836 For example, consider a webmail server that stores a session 1837 identifier in a cookie and is typically accessed over HTTPS. If the 1838 server does not set the Secure attribute on its cookies, an active 1839 network attacker can intercept any outbound HTTP request from the 1840 user agent and redirect that request to the webmail server over HTTP. 1841 Even if the webmail server is not listening for HTTP connections, the 1842 user agent will still include cookies in the request. The active 1843 network attacker can intercept these cookies, replay them against the 1844 server, and learn the contents of the user's email. If, instead, the 1845 server had set the Secure attribute on its cookies, the user agent 1846 would not have included the cookies in the clear-text request. 1848 8.4. Session Identifiers 1850 Instead of storing session information directly in a cookie (where it 1851 might be exposed to or replayed by an attacker), servers commonly 1852 store a nonce (or "session identifier") in a cookie. When the server 1853 receives an HTTP request with a nonce, the server can look up state 1854 information associated with the cookie using the nonce as a key. 1856 Using session identifier cookies limits the damage an attacker can 1857 cause if the attacker learns the contents of a cookie because the 1858 nonce is useful only for interacting with the server (unlike non- 1859 nonce cookie content, which might itself be sensitive). Furthermore, 1860 using a single nonce prevents an attacker from "splicing" together 1861 cookie content from two interactions with the server, which could 1862 cause the server to behave unexpectedly. 1864 Using session identifiers is not without risk. For example, the 1865 server SHOULD take care to avoid "session fixation" vulnerabilities. 1866 A session fixation attack proceeds in three steps. First, the 1867 attacker transplants a session identifier from his or her user agent 1868 to the victim's user agent. Second, the victim uses that session 1869 identifier to interact with the server, possibly imbuing the session 1870 identifier with the user's credentials or confidential information. 1871 Third, the attacker uses the session identifier to interact with 1872 server directly, possibly obtaining the user's authority or 1873 confidential information. 1875 8.5. Weak Confidentiality 1877 Cookies do not provide isolation by port. If a cookie is readable by 1878 a service running on one port, the cookie is also readable by a 1879 service running on another port of the same server. If a cookie is 1880 writable by a service on one port, the cookie is also writable by a 1881 service running on another port of the same server. For this reason, 1882 servers SHOULD NOT both run mutually distrusting services on 1883 different ports of the same host and use cookies to store security- 1884 sensitive information. 1886 Cookies do not provide isolation by scheme. Although most commonly 1887 used with the http and https schemes, the cookies for a given host 1888 might also be available to other schemes, such as ftp and gopher. 1889 Although this lack of isolation by scheme is most apparent in non- 1890 HTTP APIs that permit access to cookies (e.g., HTML's document.cookie 1891 API), the lack of isolation by scheme is actually present in 1892 requirements for processing cookies themselves (e.g., consider 1893 retrieving a URI with the gopher scheme via HTTP). 1895 Cookies do not always provide isolation by path. Although the 1896 network-level protocol does not send cookies stored for one path to 1897 another, some user agents expose cookies via non-HTTP APIs, such as 1898 HTML's document.cookie API. Because some of these user agents (e.g., 1899 web browsers) do not isolate resources received from different paths, 1900 a resource retrieved from one path might be able to access cookies 1901 stored for another path. 1903 8.6. Weak Integrity 1905 Cookies do not provide integrity guarantees for sibling domains (and 1906 their subdomains). For example, consider foo.site.example and 1907 bar.site.example. The foo.site.example server can set a cookie with 1908 a Domain attribute of "site.example" (possibly overwriting an 1909 existing "site.example" cookie set by bar.site.example), and the user 1910 agent will include that cookie in HTTP requests to bar.site.example. 1911 In the worst case, bar.site.example will be unable to distinguish 1912 this cookie from a cookie it set itself. The foo.site.example server 1913 might be able to leverage this ability to mount an attack against 1914 bar.site.example. 1916 Even though the Set-Cookie header supports the Path attribute, the 1917 Path attribute does not provide any integrity protection because the 1918 user agent will accept an arbitrary Path attribute in a Set-Cookie 1919 header. For example, an HTTP response to a request for 1920 http://site.example/foo/bar can set a cookie with a Path attribute of 1921 "/qux". Consequently, servers SHOULD NOT both run mutually 1922 distrusting services on different paths of the same host and use 1923 cookies to store security-sensitive information. 1925 An active network attacker can also inject cookies into the Cookie 1926 header sent to https://site.example/ by impersonating a response from 1927 http://site.example/ and injecting a Set-Cookie header. The HTTPS 1928 server at site.example will be unable to distinguish these cookies 1929 from cookies that it set itself in an HTTPS response. An active 1930 network attacker might be able to leverage this ability to mount an 1931 attack against site.example even if site.example uses HTTPS 1932 exclusively. 1934 Servers can partially mitigate these attacks by encrypting and 1935 signing the contents of their cookies. However, using cryptography 1936 does not mitigate the issue completely because an attacker can replay 1937 a cookie he or she received from the authentic site.example server in 1938 the user's session, with unpredictable results. 1940 Finally, an attacker might be able to force the user agent to delete 1941 cookies by storing a large number of cookies. Once the user agent 1942 reaches its storage limit, the user agent will be forced to evict 1943 some cookies. Servers SHOULD NOT rely upon user agents retaining 1944 cookies. 1946 8.7. Reliance on DNS 1948 Cookies rely upon the Domain Name System (DNS) for security. If the 1949 DNS is partially or fully compromised, the cookie protocol might fail 1950 to provide the security properties required by applications. 1952 8.8. SameSite Cookies 1954 8.8.1. Defense in depth 1956 "SameSite" cookies offer a robust defense against CSRF attack when 1957 deployed in strict mode, and when supported by the client. It is, 1958 however, prudent to ensure that this designation is not the extent of 1959 a site's defense against CSRF, as same-site navigations and 1960 submissions can certainly be executed in conjunction with other 1961 attack vectors such as cross-site scripting. 1963 Developers are strongly encouraged to deploy the usual server-side 1964 defenses (CSRF tokens, ensuring that "safe" HTTP methods are 1965 idempotent, etc) to mitigate the risk more fully. 1967 Additionally, client-side techniques such as those described in 1968 [app-isolation] may also prove effective against CSRF, and are 1969 certainly worth exploring in combination with "SameSite" cookies. 1971 8.8.2. Top-level Navigations 1973 Setting the "SameSite" attribute in "strict" mode provides robust 1974 defense in depth against CSRF attacks, but has the potential to 1975 confuse users unless sites' developers carefully ensure that their 1976 cookie-based session management systems deal reasonably well with 1977 top-level navigations. 1979 Consider the scenario in which a user reads their email at MegaCorp 1980 Inc's webmail provider "https://site.example/". They might expect 1981 that clicking on an emailed link to "https://projects.example/secret/ 1982 project" would show them the secret project that they're authorized 1983 to see, but if "projects.example" has marked their session cookies as 1984 "SameSite", then this cross-site navigation won't send them along 1985 with the request. "projects.example" will render a 404 error to avoid 1986 leaking secret information, and the user will be quite confused. 1988 Developers can avoid this confusion by adopting a session management 1989 system that relies on not one, but two cookies: one conceptually 1990 granting "read" access, another granting "write" access. The latter 1991 could be marked as "SameSite", and its absence would prompt a 1992 reauthentication step before executing any non-idempotent action. 1993 The former could drop the "SameSite" attribute entirely, or choose 1994 the "Lax" version of enforcement, in order to allow users access to 1995 data via top-level navigation. 1997 8.8.3. Mashups and Widgets 1999 The "SameSite" attribute is inappropriate for some important use- 2000 cases. In particular, note that content intended for embedding in a 2001 cross-site contexts (social networking widgets or commenting 2002 services, for instance) will not have access to same-site cookies. 2003 Cookies may be required for requests triggered in these cross-site 2004 contexts in order to provide seamless functionality that relies on a 2005 user's state. 2007 Likewise, some forms of Single-Sign-On might require cookie-based 2008 authentication in a cross-site context; these mechanisms will not 2009 function as intended with same-site cookies. 2011 8.8.4. Server-controlled 2013 SameSite cookies in and of themselves don't do anything to address 2014 the general privacy concerns outlined in Section 7.1 of [RFC6265]. 2015 The "SameSite" attribute is set by the server, and serves to mitigate 2016 the risk of certain kinds of attacks that the server is worried 2017 about. The user is not involved in this decision. Moreover, a 2018 number of side-channels exist which could allow a server to link 2019 distinct requests even in the absence of cookies (for example, 2020 connection and/or socket pooling between same-site and cross-site 2021 requests). 2023 9. IANA Considerations 2025 9.1. Cookie 2027 The permanent message header field registry (see [RFC3864]) needs to 2028 be updated with the following registration: 2030 Header field name: Cookie 2032 Applicable protocol: http 2034 Status: standard 2036 Author/Change controller: IETF 2038 Specification document: this specification (Section 5.5) 2040 9.2. Set-Cookie 2042 The permanent message header field registry (see [RFC3864]) needs to 2043 be updated with the following registration: 2045 Header field name: Set-Cookie 2047 Applicable protocol: http 2049 Status: standard 2051 Author/Change controller: IETF 2053 Specification document: this specification (Section 5.3) 2055 9.3. Cookie Attribute Registry 2057 The "Cookie Attribute Registry" defines the name space of attribute 2058 used to control cookies' behavior. The registry is maintained at 2059 https://www.iana.org/assignments/cookie-attribute-names [4]. 2061 9.3.1. Procedure 2063 Each registered attribute name is associated with a description, and 2064 a reference detailing how the attribute is to be processed and 2065 stored. 2067 New registrations happen on a "RFC Required" basis (see Section 4.7 2068 of [RFC8126]). The attribute to be registered MUST match the 2069 "extension-av" syntax defined in Section 4.1.1. Note that attribute 2070 names are generally defined in CamelCase, but technically accepted 2071 case-insensitively. 2073 9.3.2. Registration 2075 The "Cookie Attribute Registry" will be updated with the 2076 registrations below: 2078 +----------+----------------------------------------+ 2079 | Name | Reference | 2080 +----------+----------------------------------------+ 2081 | Domain | Section 4.1.2.3 of this document | 2082 | Expires | Section 4.1.2.1 of this document | 2083 | HttpOnly | {{attribute-httponly} of this document | 2084 | Max-Age | {{attribute-max-age} of this document | 2085 | Path | {{attribute-path} of this document | 2086 | SameSite | {{attribute-samesite} of this document | 2087 | Secure | {{attribute-secure} of this document | 2088 +----------+----------------------------------------+ 2090 10. References 2092 10.1. Normative References 2094 [FETCH] van Kesteren, A., "Fetch", n.d., 2095 . 2097 [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, 2098 P., and D. Denicola, "HTML", n.d., 2099 . 2101 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2102 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2103 . 2105 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 2106 Application and Support", STD 3, RFC 1123, 2107 DOI 10.17487/RFC1123, October 1989, 2108 . 2110 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2111 Requirement Levels", BCP 14, RFC 2119, 2112 DOI 10.17487/RFC2119, March 1997, 2113 . 2115 [RFC3490] Costello, A., "Internationalizing Domain Names in 2116 Applications (IDNA)", RFC 3490, March 2003. 2118 See Section 6.3 for an explanation why the normative 2119 reference to an obsoleted specification is needed. 2121 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 2122 Application Protocol Collation Registry", RFC 4790, 2123 DOI 10.17487/RFC4790, March 2007, 2124 . 2126 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2127 Specifications: ABNF", STD 68, RFC 5234, 2128 DOI 10.17487/RFC5234, January 2008, 2129 . 2131 [RFC5890] Klensin, J., "Internationalized Domain Names for 2132 Applications (IDNA): Definitions and Document Framework", 2133 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2134 . 2136 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2137 DOI 10.17487/RFC6454, December 2011, 2138 . 2140 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2141 Protocol (HTTP/1.1): Message Syntax and Routing", 2142 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2143 . 2145 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2146 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2147 DOI 10.17487/RFC7231, June 2014, 2148 . 2150 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2151 Writing an IANA Considerations Section in RFCs", BCP 26, 2152 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2153 . 2155 [SERVICE-WORKERS] 2156 Russell, A., Song, J., and J. Archibald, "Service 2157 Workers", n.d., . 2159 [USASCII] American National Standards Institute, "Coded Character 2160 Set -- 7-bit American Standard Code for Information 2161 Interchange", ANSI X3.4, 1986. 2163 10.2. Informative References 2165 [Aggarwal2010] 2166 Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, 2167 "An Analysis of Private Browsing Modes in Modern 2168 Browsers", 2010, 2169 . 2172 [app-isolation] 2173 Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson, 2174 "App Isolation - Get the Security of Multiple Browsers 2175 with Just One", 2011, 2176 . 2179 [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses 2180 for Cross-Site Request Forgery", 2181 DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, 2182 ACM CCS '08: Proceedings of the 15th ACM conference on 2183 Computer and communications security (pages 75-88), 2184 October 2008, 2185 . 2187 [I-D.ietf-httpbis-cookie-alone] 2188 West, M., "Deprecate modification of 'secure' cookies from 2189 non-secure origins", draft-ietf-httpbis-cookie-alone-01 2190 (work in progress), September 2016. 2192 [I-D.ietf-httpbis-cookie-prefixes] 2193 West, M., "Cookie Prefixes", draft-ietf-httpbis-cookie- 2194 prefixes-00 (work in progress), February 2016. 2196 [I-D.ietf-httpbis-cookie-same-site] 2197 West, M. and M. Goodwin, "Same-Site Cookies", draft-ietf- 2198 httpbis-cookie-same-site-00 (work in progress), June 2016. 2200 [prerendering] 2201 Bentzel, C., "Chrome Prerendering", n.d., 2202 . 2205 [PSL] "Public Suffix List", n.d., 2206 . 2208 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2209 DOI 10.17487/RFC2818, May 2000, 2210 . 2212 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2213 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2214 2003, . 2216 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2217 Procedures for Message Header Fields", BCP 90, RFC 3864, 2218 DOI 10.17487/RFC3864, September 2004, 2219 . 2221 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2222 Resource Identifier (URI): Generic Syntax", STD 66, 2223 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2224 . 2226 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2227 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2228 . 2230 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 2231 Internationalized Domain Names in Applications (IDNA) 2232 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 2233 . 2235 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2236 DOI 10.17487/RFC6265, April 2011, 2237 . 2239 [RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame- 2240 Options", RFC 7034, DOI 10.17487/RFC7034, October 2013, 2241 . 2243 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 2244 Processing", UNICODE Unicode Technical Standards # 46, 2245 June 2016, . 2247 10.3. URIs 2249 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 2251 [2] http://httpwg.github.io/ 2253 [3] https://github.com/httpwg/http-extensions/labels/6265bis 2255 [4] https://www.iana.org/assignments/cookie-attribute-names 2257 [5] https://github.com/httpwg/http-extensions/issues/243 2259 [6] https://github.com/httpwg/http-extensions/issues/246 2261 [7] https://www.rfc-editor.org/errata_search.php?rfc=6265 2263 [8] https://github.com/httpwg/http-extensions/issues/247 2265 [9] https://github.com/httpwg/http-extensions/issues/201 2267 [10] https://github.com/httpwg/http-extensions/issues/204 2269 [11] https://github.com/httpwg/http-extensions/issues/222 2271 [12] https://github.com/httpwg/http-extensions/issues/248 2273 [13] https://github.com/httpwg/http-extensions/issues/295 2275 [14] https://github.com/httpwg/http-extensions/issues/302 2277 [15] https://github.com/httpwg/http-extensions/issues/389 2279 [16] https://github.com/httpwg/http-extensions/issues/199 2281 [17] https://github.com/httpwg/http-extensions/issues/788 2283 [18] https://github.com/httpwg/http-extensions/issues/594 2285 [19] https://github.com/httpwg/http-extensions/issues/159 2287 [20] https://github.com/httpwg/http-extensions/issues/159 2289 [21] https://github.com/httpwg/http-extensions/issues/901 2291 [22] https://github.com/httpwg/http-extensions/pull/1035 2293 [23] https://github.com/httpwg/http-extensions/pull/1038 2295 [24] https://github.com/httpwg/http-extensions/pull/1040 2297 [25] https://github.com/httpwg/http-extensions/pull/1047 2299 [26] https://github.com/httpwg/http-extensions/issues/1059 2301 [27] https://github.com/httpwg/http-extensions/issues/1158 2303 [28] https://github.com/httpwg/http-extensions/pull/1060 2305 [29] https://github.com/httpwg/http-extensions/issues/1074 2307 [30] https://github.com/httpwg/http-extensions/issues/1119 2309 [31] https://github.com/httpwg/http-extensions/pull/1143 2311 [32] https://github.com/httpwg/http-extensions/issues/1159 2313 Appendix A. Changes 2315 A.1. draft-ietf-httpbis-rfc6265bis-00 2317 o Port [RFC6265] to Markdown. No (intentional) normative changes. 2319 A.2. draft-ietf-httpbis-rfc6265bis-01 2321 o Fixes to formatting caused by mistakes in the initial port to 2322 Markdown: 2324 * https://github.com/httpwg/http-extensions/issues/243 [5] 2326 * https://github.com/httpwg/http-extensions/issues/246 [6] 2328 o Addresses errata 3444 by updating the "path-value" and "extension- 2329 av" grammar, errata 4148 by updating the "day-of-month", "year", 2330 and "time" grammar, and errata 3663 by adding the requested note. 2331 https://www.rfc-editor.org/errata_search.php?rfc=6265 [7] 2333 o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations 2334 section: https://github.com/httpwg/http-extensions/issues/247 [8] 2336 o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone], 2337 removing the ability for a non-secure origin to set cookies with a 2338 'secure' flag, and to overwrite cookies whose 'secure' flag is 2339 true. 2341 o Merged the recommendations from 2342 [I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and 2343 "__Host-" cookie name prefix processing instructions. 2345 A.3. draft-ietf-httpbis-rfc6265bis-02 2347 o Merged the recommendations from 2348 [I-D.ietf-httpbis-cookie-same-site], adding support for the 2349 "SameSite" attribute. 2351 o Closed a number of editorial bugs: 2353 * Clarified address bar behavior for SameSite cookies: 2354 https://github.com/httpwg/http-extensions/issues/201 [9] 2356 * Added the word "Cookies" to the document's name: 2357 https://github.com/httpwg/http-extensions/issues/204 [10] 2359 * Clarified that the "__Host-" prefix requires an explicit "Path" 2360 attribute: https://github.com/httpwg/http-extensions/issues/222 2361 [11] 2363 * Expanded the options for dealing with third-party cookies to 2364 include a brief mention of partitioning based on first-party: 2365 https://github.com/httpwg/http-extensions/issues/248 [12] 2367 * Noted that double-quotes in cookie values are part of the 2368 value, and are not stripped: https://github.com/httpwg/http- 2369 extensions/issues/295 [13] 2371 * Fixed the "site for cookies" algorithm to return something that 2372 makes sense: https://github.com/httpwg/http-extensions/ 2373 issues/302 [14] 2375 A.4. draft-ietf-httpbis-rfc6265bis-03 2377 o Clarified handling of invalid SameSite values: 2378 https://github.com/httpwg/http-extensions/issues/389 [15] 2380 o Reflect widespread implementation practice of including a cookie's 2381 "host-only-flag" when calculating its uniqueness: 2382 https://github.com/httpwg/http-extensions/issues/199 [16] 2384 o Introduced an explicit "None" value for the SameSite attribute: 2385 https://github.com/httpwg/http-extensions/issues/788 [17] 2387 A.5. draft-ietf-httpbis-rfc6265bis-04 2389 o Allow "SameSite" cookies to be set for all top-level navigations. 2390 https://github.com/httpwg/http-extensions/issues/594 [18] 2392 o Treat "Set-Cookie: token" as creating the cookie "("", "token")": 2393 https://github.com/httpwg/http-extensions/issues/159 [19] 2395 o Reject cookies with neither name nor value (e.g. "Set-Cookie: =" 2396 and "Set-Cookie:": https://github.com/httpwg/http-extensions/ 2397 issues/159 [20] 2399 o Clarified behavior of multiple "SameSite" attributes in a cookie 2400 string: https://github.com/httpwg/http-extensions/issues/901 [21] 2402 A.6. draft-ietf-httpbis-rfc6265bis-05 2404 o Typos and editorial fixes: https://github.com/httpwg/http- 2405 extensions/pull/1035 [22], https://github.com/httpwg/http- 2406 extensions/pull/1038 [23], https://github.com/httpwg/http- 2407 extensions/pull/1040 [24], https://github.com/httpwg/http- 2408 extensions/pull/1047 [25]. 2410 A.7. draft-ietf-httpbis-rfc6265bis-06 2412 o Editorial fixes: https://github.com/httpwg/http-extensions/ 2413 issues/1059 [26], https://github.com/httpwg/http-extensions/ 2414 issues/1158 [27]. 2416 o Created a registry for cookie attribute names: 2417 https://github.com/httpwg/http-extensions/pull/1060 [28]. 2419 o Tweaks to ABNF for "cookie-pair" and the "Cookie" header 2420 production: https://github.com/httpwg/http-extensions/issues/1074 2421 [29], https://github.com/httpwg/http-extensions/issues/1119 [30]. 2423 o Fixed serialization for nameless/valueless cookies: 2424 https://github.com/httpwg/http-extensions/pull/1143 [31]. 2426 o Converted a normative reference to Mozilla's Public Suffix List 2427 [PSL] into an informative reference: https://github.com/httpwg/ 2428 http-extensions/issues/1159 [32]. 2430 Acknowledgements 2432 RFC 6265 was written by Adam Barth. This document is a minor update 2433 of RFC 6265, adding small features, and aligning the specification 2434 with the reality of today's deployments. Here, we're standing upon 2435 the shoulders of a giant since the majority of the text is still 2436 Adam's. 2438 Authors' Addresses 2440 Mike West (editor) 2441 Google, Inc 2443 Email: mkwst@google.com 2444 URI: https://mikewest.org/ 2445 John Wilander (editor) 2446 Apple, Inc 2448 Email: wilander@apple.com