idnits 2.17.00 (12 Aug 2021) /tmp/idnits8469/draft-ietf-httpbis-key-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7234]), 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 date (October 19, 2015) is 2405 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) == Missing Reference: 'RFC5226' is mentioned on line 626, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis Working Group R. Fielding 3 Internet-Draft Adobe Systems Incorporated 4 Intended status: Standards Track M. Nottingham 5 Expires: April 21, 2016 October 19, 2015 7 The Key HTTP Response Header Field 8 draft-ietf-httpbis-key-00 10 Abstract 12 The 'Key' header field for HTTP responses allows an origin server to 13 describe the secondary cache key ([RFC7234], section 4.1) for a 14 resource, by conveying what is effectively a short algorithm that can 15 be used upon later requests to determine if a stored response is 16 reusable for a given request. 18 Key has the advantage of avoiding an additional round trip for 19 validation whenever a new request differs slightly, but not 20 significantly, from prior requests. 22 Key also informs user agents of the request characteristics that 23 might result in different content, which can be useful if the user 24 agent is not sending request header fields in order to reduce the 25 risk of fingerprinting. 27 Note to Readers 29 The issues list for this draft can be found at 30 https://github.com/httpwg/http-extensions/labels/key . 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 21, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4 69 2. The "Key" Response Header Field . . . . . . . . . . . . . . . 4 70 2.1. Relationship with Vary . . . . . . . . . . . . . . . . . 5 71 2.2. Calculating a Secondary Cache Key . . . . . . . . . . . . 6 72 2.2.1. Creating a Header Field Value . . . . . . . . . . . . 8 73 2.2.2. Failing Parameter Processing . . . . . . . . . . . . 8 74 2.3. Key Parameters . . . . . . . . . . . . . . . . . . . . . 8 75 2.3.1. div . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 2.3.2. partition . . . . . . . . . . . . . . . . . . . . . . 10 77 2.3.3. match . . . . . . . . . . . . . . . . . . . . . . . . 11 78 2.3.4. substr . . . . . . . . . . . . . . . . . . . . . . . 12 79 2.3.5. param . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 14 82 3.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 5.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 In HTTP caching [RFC7234], the Vary response header field effectively 93 modifies the key used to store and access a response to include 94 information from the request's headers. This "secondary cache key" 95 allows proactive content negotiation [RFC7231] to work with caches. 97 Vary's operation is generic; it works well when caches understand the 98 semantics of the selecting headers. For example, the Accept-Language 99 request header field has a well-defined syntax for expressing the 100 client's preferences; a cache that understands this header field can 101 select the appropriate response (based upon its Content-Language 102 header field) and serve it to a client, without any knowledge of the 103 underlying resource. 105 Vary does not work as well when the criteria for selecting a response 106 are specific to the resource. For example, if the nature of the 107 response depends upon the presence or absence of a particular Cookie 108 ([RFC6265]) in a request, Vary doesn't have a mechanism to offer 109 enough fine-grained, resource-specific information to aid a cache's 110 selection of the appropriate response. 112 This document defines a new response header field, "Key", that allows 113 resources to describe the secondary cache key in a fine-grained, 114 resource-specific manner, leading to improved cache efficiency when 115 responses depend upon such headers. 117 1.1. Examples 119 For example, this response header field: 121 Key: cookie;param=_sess;param=ID 123 indicates that the selected response depends upon the "_sess" and 124 "ID" cookie values. 126 This Key: 128 Key: user-agent;substr=MSIE 130 indicates that there are two possible secondary cache keys for this 131 resource; one for requests whose User-Agent header field contains 132 "MSIE", and another for those that don't. 134 A more complex example: 136 Key: user-agent;substr=MSIE;Substr="mobile", Cookie;param="ID" 138 indicates that the selected response depends on the presence of two 139 strings in the User-Agent request header field, as well as the value 140 of the "ID" cookie request header field. 142 1.2. Notational Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 This document uses the Augmented Backus-Naur Form (ABNF) notation of 149 [RFC5234] (including the DQUOTE rule), and the list rule extension 150 defined in [RFC7230], Section 7. It includes by reference the field- 151 name, quoted-string and quoted-pair rules from that document, and the 152 parameter rule from [RFC7231]. 154 2. The "Key" Response Header Field 156 The "Key" response header field describes the portions of the request 157 that the resource currently uses to select representations. 159 As such, its semantics are similar to the "Vary" response header 160 field, but it allows more fine-grained description, using "key 161 parameters". 163 Caches can use this information as part of determining whether a 164 stored response can be used to satisfy a given request. When a cache 165 knows and fully understands the Key header field for a given 166 resource, it MAY ignore the Vary response header field in any stored 167 responses for it. 169 Additionally, user agents can use Key to discover if additional 170 request header fields might influence the resource's selection of 171 responses. 173 The Key field-value is a comma-delimited list of selecting header 174 fields (similar to Vary), with zero to many parameters each, 175 delimited by semicolons. Whitespace is not allowed in the field- 176 value between each field-name and its parameter set. 178 Key = 1#field-name *( ";" parameter ) 180 Note that, as per [RFC7231], parameter names are case-insensitive, 181 and parameter values can be double-quoted strings (potentially with 182 ""-escaped characters inside). 184 The following header fields have the same effect: 186 Vary: Accept-Encoding, Cookie 187 Key: Accept-Encoding, Cookie 189 However, Key's use of parameters allows: 191 Key: Accept-Encoding, Cookie;param=foo 193 to indicate that the secondary cache key depends upon the Accept- 194 Encoding header field and the "foo" Cookie. 196 One important difference between Vary and Key is how they are 197 applied. Vary is specified to be specific to the response it occurs 198 within, whereas Key is specific to the resource (as identified by the 199 request URL) it is associated with. The most recent key you receive 200 for a given resource is applicable to all responses from that 201 resource. 203 This difference allows more efficient implementation (and reflects 204 practices that many caches use in implementing Vary already). 206 This specification defines a selection of Key parameters to address 207 common use cases such as selection upon individual Cookie header 208 fields, User-Agent substrings and numerical ranges. Future 209 parameters may define further capabilities. 211 2.1. Relationship with Vary 213 Origin servers SHOULD still send Vary when using Key, to ensure 214 backwards compatibility. 216 For example, 218 Vary: User-Agent 219 Key: User-Agent;substr="mozilla" 221 Note that, in some cases, it may be better to explicitly use "Vary: 222 *" if clients and caches don't have any practical way to use the Vary 223 header field's value. For example, 225 Vary: * 226 Key: Cookie;param="ID" 228 Except when Vary: * is used, the set of headers used in Key SHOULD 229 reflect the same request header fields as Vary does, even if they 230 don't have parameters. For example, 231 Vary: Accept-Encoding, User-Agent 232 Key: Accept-Encoding, User-Agent;substr="mozilla" 234 Here, Accept-Encoding is included in Key without parameters; caches 235 MAY treat these as they do values in the Vary header, relying upon 236 knowledge of their generic semantics to select an appropriate 237 response. 239 2.2. Calculating a Secondary Cache Key 241 When used by a cache to determine whether a stored response can be 242 used to satisfy a presented request, each field-name in Key 243 identifies a potential request header, just as with the Vary response 244 header field. 246 However, each of these can have zero to many key parameters that 247 change how the response selection process (as defined in [RFC7234], 248 Section 4.3)) works. 250 In particular, when a cache fully implements this specification, it 251 creates a secondary cache key for every request by following the 252 instructions in the Key header field, ignoring the Vary header for 253 this purpose. 255 Then, when a new request is presented, the secondary cache key 256 generated for that request can be compared to the stored one to find 257 the appropriate response, to determine if it can be selected. 259 To generate a secondary cache key for a given request (including that 260 which is stored with a response) using Key, the following steps are 261 taken: 263 1) If the Key header field is not present on the most recent 264 cacheable (as per [RFC7234], Section 3)) response seen for the 265 resource, abort this algorithm (i.e., fall back to using Vary to 266 determine the secondary cache key). 267 2) Let "key_value" be the most recently seen Key header field value 268 for the resource, as the result of Creating a Header Field Value 269 (Section 2.2.1). 270 3) Let "secondary_key" be an empty string. 271 4) Create "key_list" by splitting "key_value" on "," characters. 272 5) For "key_item" in "key_list": 274 1) Remove any leading and trailing WSP from "key_item". 275 2) If "key_item" does not contain a ";" character, fail 276 parameter processing (Section 2.2.2) and skip to the next 277 "key_item". 279 3) Let "field_name" be the string before the first ";" character 280 in "key_item". 281 4) Let "field_value" be the result of Creating a Header Field 282 Value (Section 2.2.1) with "field_name" as the 283 "target_field_name" and the request header list as 284 "header_list". 285 5) Let "parameters" be the string after the first ";" character 286 in "key_item". 287 6) Create "param_list" by splitting "parameters" on ";" 288 characters, excepting ";" characters within quoted strings, 289 as per [RFC7230] Section 3.2.6. 290 7) For "parameter" in "param_list": 292 1) If "parameter" does not contain a "=", fail parameter 293 processing (Section 2.2.2) and skip to the next 294 "key_item". 295 2) Let "param_name" be the string before the first "=" 296 character in "parameter", case-normalized to lowercase. 297 3) If "param_name" does not identify a Key parameter 298 processing algorithm that is implemented, fail parameter 299 processing (Section 2.2.2) and skip to the next 300 "key_item". 301 4) Let "param_value" be the string after the first "=" 302 character in "parameter". 303 5) If the first and last characters of "param_value" are 304 both DQUOTE: 306 1) Remove the first and last characters of 307 "param_value". 308 2) Replace quoted-pairs within "param_value" with the 309 octet following the backslash, as per [RFC7230] 310 Section 3.2.6. 311 6) If "param_value" does not conform to the syntax defined 312 for it by the parameter definition, fail parameter 313 processing Section 2.2.2 and skip to the next "key_item". 314 7) Run the identified processing algorithm on "field_value" 315 with the "param_value", and append the result to 316 "secondary_key". If parameter processing fails 317 Section 2.2.2, skip to the next "key_item". 318 8) Append a separator character (e.g., NULL) to 319 "secondary_key". 320 6) Return "secondary_key". 322 Note that this specification does not require that exact algorithm to 323 be implemented. However, implementations' observable behavior MUST 324 be identical to running it. This includes parameter processing 325 algorithms; implementations MAY use different internal artefacts for 326 secondary cache keys, as long as the results are the same. 328 Likewise, while the secondary cache key associated with both stored 329 and presented requests is required to use the most recently seen Key 330 header field for the resource in question, this can be achieved using 331 a variety of implementation strategies, including (but not limited 332 to): 334 o Generating a new secondary cache key for every stored response 335 associated with the resource upon each request. 336 o Caching the secondary cache key with the stored request/response 337 pair and re-generating it when the Key header field is observed to 338 change. 339 o Caching the secondary cache key with the stored response and 340 invalidating the stored response(s) when the Key header field is 341 observed to change. 343 2.2.1. Creating a Header Field Value 345 Given a header field name "target_field_name" and "header_list", a 346 list of ("field_name", "field_value") tuples: 348 1) Let "target_field_values" be an empty list. 349 2) For each ("field_name", "field_value") tuple in "header_list": 351 1) If "field_name" does not match "target_field_name", skip to 352 the next tuple. 353 2) Strip leading and trailing WSP from "field_value" and append 354 it to "target_field_values". 355 3) If "target_field_values" is empty, return an empty string. 356 4) Return the concatenation of "target_field_values", separating 357 each with "," characters. 359 2.2.2. Failing Parameter Processing 361 In some cases, a key parameter cannot determine a secondary cache key 362 corresponding to its nominated header field value. When this 363 happens, Key processing needs to fail safely, so that the correct 364 behavior is observed. 366 When this happens, implementations MUST either behave as if the Key 367 header was not present, or assure that the nominated header fields 368 being compared match, as per [RFC7234], Section 4.1. 370 2.3. Key Parameters 372 A Key parameter associates a name with a specific processing 373 algorithm that takes two inputs; a HTTP header value "header_value" 374 (as described in Section 2.2.1), and "parameter_value", a string that 375 indicates how the identified header should be processed. 377 The set of key parameters (and their associated processing 378 algorithms) is extensible; see Section 3. This document defines the 379 following key parameters: 381 2.3.1. div 383 The "div" parameter normalizes positive integer header values into 384 groups by dividing them by a configured value. 386 Its value's syntax is: 388 div = 1*DIGIT 390 To process a set of header fields against a div parameter, follow 391 these steps (or their equivalent): 393 1) If "parameter_value" is "0", fail parameter processing 394 Section 2.2.2. 395 2) If "header_value" is the empty string, return "none". 396 3) If "header_value" contains a ",", remove it and all subsequent 397 characters. 398 4) Remove all WSP characters from "header_value". 399 5) If "header_value" does not match the div ABNF rule, fail 400 parameter processing (Section 2.2.2). 401 6) Return the quotient of "header_value" / "parameter_value" 402 (omitting the modulus). 404 For example, the Key: 406 Key: Bar;div=5 408 indicates that the "Bar" header's field value should be partitioned 409 into groups of 5. Thus, the following field values would be 410 considered the same (because, divided by 5, they all result in 1): 412 Bar: 1 413 Bar: 3 , 42 414 Bar: 4, 1 416 whereas these would be considered to be in a different group 417 (because, divided by 5, they all result in 2); 418 Bar: 12 419 Bar: 10 420 Bar: 14, 1 422 2.3.2. partition 424 The "partition" parameter normalizes positive numeric header values 425 into pre-defined segments. 427 Its value's syntax is: 429 partition = [ segment ] *( ":" [ segment ] ) 430 segment = [ 0*DIGIT "." ] 1*DIGIT 432 To process a set of header fields against a partition parameter, 433 follow these steps (or their equivalent): 435 1) If "header_value" is the empty string, return "none". 436 2) If "header_value" contains a ",", remove it and all subsequent 437 characters. 438 3) Remove all WSP characters from "header_value". 439 4) If "header_value" does not match the segment ABNF rule, fail 440 parameter processing (Section 2.2.2). 441 5) Let "segment_id" be 0. 442 6) Create a list "segment_list" by splitting "parameter_value" on 443 ":" characters. 444 7) For each "segment_value" in "segment_list": 446 1) If "header_value" is less than "segment_value" when they are 447 numerically compared, skip to step 7. 448 2) Increment "segment_id" by 1. 449 8) Return "segment_id". 451 For example, the Key: 453 Key: Foo;partition=20:30:40 455 indicates that the "Foo" header's field value should be divided into 456 four segments: 458 o less than 20 459 o 20 to less than 30 460 o 30 to less than 40 461 o forty or greater 462 Thus, the following headers would all be normalized to the first 463 segment: 465 Foo: 1 466 Foo: 0 467 Foo: 4, 54 468 Foo: 19.9 470 whereas the following would fall into the second segment: 472 Foo: 20 473 Foo: 29.999 474 Foo: 24 , 10 476 2.3.3. match 478 The "match" parameter is used to determine if an exact value occurs 479 in a list of header values. It is case-sensitive. 481 Its value's syntax is: 483 match = ( token / quoted-string ) 485 To process a set of header fields against a match parameter, follow 486 these steps (or their equivalent): 488 1) If "header_value" is the empty string, return "none". 489 2) Create "header_list" by splitting "header_value" on "," 490 characters. 491 3) For each "header_item" in "header_list": 493 1) Remove leading and trailing WSP characters in "header_item". 494 2) If the value of "header_item" is character-for-character 495 identical to "parameter_value", return "1". 496 4) Return "0". 498 For example, the Key: 500 Key: Baz;match="charlie" 502 Would return "1" for the following header field values: 504 Baz: charlie 505 Baz: foo, charlie 506 Baz: bar, charlie , abc 508 and "0" for these: 510 Baz: theodore 511 Baz: joe, sam 512 Baz: "charlie" 513 Baz: Charlie 514 Baz: cha rlie 515 Baz: charlie2 517 2.3.4. substr 519 The "substr" parameter is used to determine if a value occurs as a 520 substring of an item in a list of header values. It is case- 521 sensitive. 523 Its value's syntax is: 525 substr = ( token / quoted-string ) 527 To process a set of header fields against a substr parameter, follow 528 these steps (or their equivalent): 530 1) If "header_value" is the empty string, return "none". 531 2) Create "header_list" by splitting "header_value" on "," 532 characters. 533 3) For each "header_item" in "header_list": 535 1) Remove leading and trailing WSP characters in "header_item". 536 2) If the value of "parameter_value" is character-for-character 537 present as a substring of "header_value", return "1". 538 4) Return "0". 540 For example, the Key: 542 Key: Abc;substr=bennet 544 Would return "1" for the following header field values: 546 Abc: bennet 547 Abc: foo, bennet 548 Abc: abennet00 549 Abc: bar, 99bennet , abc 550 Abc: "bennet" 552 and "0" for these: 554 Abc: theodore 555 Abc: joe, sam 556 Abc: Bennet 557 Abc: Ben net 559 2.3.5. param 561 The "param" parameter considers the request header field as a list of 562 key=value parameters, and uses the nominated key's value as the 563 secondary cache key. 565 Its value's syntax is: 567 param = ( token / quoted-string ) 569 To process a list of header fields against a param parameter, follow 570 these steps (or their equivalent): 572 1) Let "header_list" be an empty list. 573 2) Create "header_list_tmp1" by splitting header_value on "," 574 characters. 575 3) For each "header_item_tmp1" in "header_list_tmp1": 577 1) Create "header_list_tmp2" by splitting "header_item_tmp1" on 578 ";" characters. 579 2) For each "header_item_tmp2" in "header_list_tmp2": 581 1) Remove leading and trailing WSP from "header_item_tmp2". 582 2) Append "header_item_tmp2" to header_list. 583 4) For each "header_item" in "header_list": 585 1) If the "=" character does not occur within "header_item", 586 skip to the next "header_item". 587 2) Let "item_name" be the string occurring before the first "=" 588 character in "header_item". 589 3) If "item_name" does not case-insensitively match 590 "parameter_value", skip to the next "header_item". 592 4) Return the string occurring after the first "=" character in 593 "header_item". 594 5) Return the empty string. 596 Note that steps 2 and 3 accommodate semicolon-separated values, so 597 that it can be used with the Cookie request header field. 599 For example, the Key: 601 Key: Def;param=liam 603 The following headers would return the string (surrounded in single 604 quotes) indicated: 606 Def: liam=123 // '123' 607 Def: mno=456 // '' 608 Def: // '' 609 Def: abc=123; liam=890 // '890' 610 Def: liam="678" // '"678"' 612 3. IANA Considerations 614 This specification defines the HTTP Key Parameter Registry, 615 maintained at http://www.iana.org/assignments/http-parameters/http- 616 parameters.xhtml#key . 618 3.1. Procedure 620 Key Parameter registrations MUST include the following fields: 622 o Parameter Name: [name] 623 o Reference: [Pointer to specification text] 625 Values to be added to this namespace require IETF Review (see 626 Section 4.1 of [RFC5226]) and MUST conform to the purpose of content 627 coding defined in this section. 629 3.2. Registrations 631 This specification makes the following entries in the HTTP Key 632 Parameter Registry: 634 +----------------+---------------+ 635 | Parameter Name | Reference | 636 +----------------+---------------+ 637 | div | Section 2.3.1 | 638 | partition | Section 2.3.2 | 639 | match | Section 2.3.3 | 640 | substr | Section 2.3.4 | 641 | param | Section 2.3.5 | 642 +----------------+---------------+ 644 4. Security Considerations 646 Because Key is an alternative to Vary, it is possible for caches to 647 behave differently based upon whether they implement Key. Likewise, 648 because support for any one Key parameter is not required, it is 649 possible for different implementations of Key to behave differently. 650 In both cases, an attacker might be able to exploit these 651 differences. 653 This risk is mitigated by the requirement to fall back to Vary when 654 unsupported parameters are encountered, coupled with the requirement 655 that servers that use Key also include a relevant Vary header. 657 An attacker with the ability to inject response headers might be able 658 to perform a cache poisoning attack that tailors a response to a 659 specific user (e.g., by Keying to a Cookie that's specific to them). 660 While the attack is still possible without Key, the ability to tailor 661 is new. 663 When implemented, Key might result in a larger number of stored 664 responses for a given resource in caches; this, in turn, might be 665 used to create an attack upon the cache itself. Good cache 666 replacement algorithms and denial of service monitoring in cache 667 implementations are reasonable mitigations against this risk. 669 5. References 671 5.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 675 RFC2119, March 1997, 676 . 678 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 679 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 680 RFC5234, January 2008, 681 . 683 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 684 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 685 7230, DOI 10.17487/RFC7230, June 2014, 686 . 688 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 689 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 690 10.17487/RFC7231, June 2014, 691 . 693 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 694 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 695 RFC 7234, DOI 10.17487/RFC7234, June 2014, 696 . 698 5.2. Informative References 700 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 701 DOI 10.17487/RFC6265, April 2011, 702 . 704 Appendix A. Acknowledgements 706 Thanks to Ilya Grigorik, Amos Jeffries and Yoav Weiss for their 707 feedback. 709 Authors' Addresses 711 Roy T. Fielding 712 Adobe Systems Incorporated 714 Email: fielding@gbiv.com 715 URI: http://roy.gbiv.com/ 717 Mark Nottingham 719 Email: mnot@mnot.net 720 URI: http://www.mnot.net/