idnits 2.17.1 draft-fielding-http-key-03.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 (September 24, 2015) is 3130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 685, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding 3 Internet-Draft Adobe Systems Incorporated 4 Intended status: Informational M. Nottingham 5 Expires: March 27, 2016 September 24, 2015 7 The Key HTTP Response Header Field 8 draft-fielding-http-key-03 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/mnot/I-D/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 March 27, 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 . . . . . . . . . . . . 9 74 2.3. Key Parameters . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 15 81 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 5.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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, 232 Vary: Accept-Encoding, User-Agent 233 Key: Accept-Encoding, User-Agent;substr="mozilla" 235 Here, Accept-Encoding is included in Key without parameters; caches 236 MAY treat these as they do values in the Vary header, relying upon 237 knowledge of their generic semantics to select an appropriate 238 response. 240 2.2. Calculating a Secondary Cache Key 242 When used by a cache to determine whether a stored response can be 243 used to satisfy a presented request, each field-name in Key 244 identifies a potential request header, just as with the Vary response 245 header field. 247 However, each of these can have zero to many key parameters that 248 change how the response selection process (as defined in [RFC7234], 249 Section 4.3)) works. 251 In particular, when a cache fully implements this specification, it 252 creates a secondary cache key for every request by following the 253 instructions in the Key header field, ignoring the Vary header for 254 this purpose. 256 Then, when a new request is presented, the secondary cache key 257 generated for that request can be compared to the stored one to find 258 the appropriate response, to determine if it can be selected. 260 To generate a secondary cache key for a given request (including that 261 which is stored with a response) using Key, the following steps are 262 taken: 264 1. If the Key header field is not present on the most recent 265 cacheable (as per [RFC7234], Section 3)) response seen for the 266 resource, abort this algorithm (i.e., fall back to using Vary to 267 determine the secondary cache key). 269 2. Let "key_value" be the most recently seen Key header field value 270 for the resource, as the result of Creating a Header Field Value 271 (Section 2.2.1). 273 3. Let "secondary_key" be an empty string. 275 4. Create "key_list" by splitting "key_value" on "," characters. 277 5. For "key_item" in "key_list": 279 1. Remove any leading and trailing WSP from "key_item". 281 2. If "key_item" does not contain a ";" character, fail 282 parameter processing (Section 2.2.2) and skip to the next 283 "key_item". 285 3. Let "field_name" be the string before the first ";" character 286 in "key_item". 288 4. Let "field_value" be the result of Creating a Header Field 289 Value (Section 2.2.1) with "field_name" as the 290 "target_field_name" and the request header list as 291 "header_list". 293 5. Let "parameters" be the string after the first ";" character 294 in "key_item". 296 6. Create "param_list" by splitting "parameters" on ";" 297 characters, excepting ";" characters within quoted strings, 298 as per [RFC7230] Section 3.2.6. 300 7. For "parameter" in "param_list": 302 1. If "parameter" does not contain a "=", fail parameter 303 processing (Section 2.2.2) and skip to the next 304 "key_item". 306 2. Let "param_name" be the string before the first "=" 307 character in "parameter", case-normalized to lowercase. 309 3. If "param_name" does not identify a Key parameter 310 processing algorithm that is implemented, fail parameter 311 processing (Section 2.2.2) and skip to the next 312 "key_item". 314 4. Let "param_value" be the string after the first "=" 315 character in "parameter". 317 5. If the first and last characters of "param_value" are 318 both DQUOTE: 320 1. Remove the first and last characters of 321 "param_value". 323 2. Replace quoted-pairs within "param_value" with the 324 octet following the backslash, as per [RFC7230] 325 Section 3.2.6. 327 6. If "param_value" does not conform to the syntax defined 328 for it by the parameter definition, fail parameter 329 processing Section 2.2.2 and skip to the next "key_item". 331 7. Run the identified processing algorithm on "field_value" 332 with the "param_value", and append the result to 333 "secondary_key". If parameter processing fails 334 Section 2.2.2, skip to the next "key_item". 336 8. Append a separator character (e.g., NULL) to 337 "secondary_key". 339 6. Return "secondary_key". 341 Note that this specification does not require that exact algorithm to 342 be implemented. However, implementations' observable behavior MUST 343 be identical to running it. This includes parameter processing 344 algorithms; implementations MAY use different internal artefacts for 345 secondary cache keys, as long as the results are the same. 347 Likewise, while the secondary cache key associated with both stored 348 and presented requests is required to use the most recently seen Key 349 header field for the resource in question, this can be achieved using 350 a variety of implementation strategies, including (but not limited 351 to): 353 o Generating a new secondary cache key for every stored response 354 associated with the resource upon each request. 356 o Caching the secondary cache key with the stored request/response 357 pair and re-generating it when the Key header field is observed to 358 change. 360 o Caching the secondary cache key with the stored response and 361 invalidating the stored response(s) when the Key header field is 362 observed to change. 364 2.2.1. Creating a Header Field Value 366 Given a header field name "target_field_name" and "header_list", a 367 list of ("field_name", "field_value") tuples: 369 1. Let "target_field_values" be an empty list. 371 2. For each ("field_name", "field_value") tuple in "header_list": 373 1. If "field_name" does not match "target_field_name", skip to 374 the next tuple. 376 2. Strip leading and trailing WSP from "field_value" and append 377 it to "target_field_values". 379 3. If "target_field_values" is empty, return an empty string. 381 4. Return the concatenation of "target_field_values", separating 382 each with "," characters. 384 2.2.2. Failing Parameter Processing 386 In some cases, a key parameter cannot determine a secondary cache key 387 corresponding to its nominated header field value. When this 388 happens, Key processing needs to fail safely, so that the correct 389 behavior is observed. 391 When this happens, implementations MUST either behave as if the Key 392 header was not present, or assure that the nominated header fields 393 being compared match, as per [RFC7234], Section 4.1. 395 2.3. Key Parameters 397 A Key parameter associates a name with a specific processing 398 algorithm that takes two inputs; a HTTP header value "header_value" 399 (as described in Section 2.2.1), and "parameter_value", a string that 400 indicates how the identified header should be processed. 402 The set of key parameters (and their associated processing 403 algorithms) is extensible; see Section 3. This document defines the 404 following key parameters: 406 2.3.1. div 408 The "div" parameter normalizes positive integer header values into 409 groups by dividing them by a configured value. 411 Its value's syntax is: 413 div = 1*DIGIT 415 To process a set of header fields against a div parameter, follow 416 these steps (or their equivalent): 418 1. If "parameter_value" is "0", fail parameter processing 419 Section 2.2.2. 421 2. If "header_value" is the empty string, return "none". 423 3. If "header_value" contains a ",", remove it and all subsequent 424 characters. 426 4. Remove all WSP characters from "header_value". 428 5. If "header_value" does not match the div ABNF rule, fail 429 parameter processing (Section 2.2.2). 431 6. Return the quotient of "header_value" / "parameter_value" 432 (omitting the modulus). 434 For example, the Key: 436 Key: Bar;div=5 438 indicates that the "Bar" header's field value should be partitioned 439 into groups of 5. Thus, the following field values would be 440 considered the same (because, divided by 5, they all result in 1): 442 Bar: 1 443 Bar: 3 , 42 444 Bar: 4, 1 446 whereas these would be considered to be in a different group 447 (because, divided by 5, they all result in 2); 449 Bar: 12 450 Bar: 10 451 Bar: 14, 1 453 2.3.2. partition 455 The "partition" parameter normalizes positive numeric header values 456 into pre-defined segments. 458 Its value's syntax is: 460 partition = [ segment ] *( ":" [ segment ] ) 461 segment = [ 0*DIGIT "." ] 1*DIGIT 463 To process a set of header fields against a partition parameter, 464 follow these steps (or their equivalent): 466 1. If "header_value" is the empty string, return "none". 468 2. If "header_value" contains a ",", remove it and all subsequent 469 characters. 471 3. Remove all WSP characters from "header_value". 473 4. If "header_value" does not match the segment ABNF rule, fail 474 parameter processing (Section 2.2.2). 476 5. Let "segment_id" be 0. 478 6. Create a list "segment_list" by splitting "parameter_value" on 479 ":" characters. 481 7. For each "segment_value" in "segment_list": 483 1. If "header_value" is less than "segment_value" when they are 484 numerically compared, skip to step 7. 486 2. Increment "segment_id" by 1. 488 8. Return "segment_id". 490 For example, the Key: 492 Key: Foo;partition=20:30:40 494 indicates that the "Foo" header's field value should be divided into 495 four segments: 497 o less than 20 499 o 20 to less than 30 501 o 30 to less than 40 503 o forty or greater 505 Thus, the following headers would all be normalized to the first 506 segment: 508 Foo: 1 509 Foo: 0 510 Foo: 4, 54 511 Foo: 19.9 513 whereas the following would fall into the second segment: 515 Foo: 20 516 Foo: 29.999 517 Foo: 24 , 10 519 2.3.3. match 521 The "match" parameter is used to determine if an exact value occurs 522 in a list of header values. It is case-sensitive. 524 Its value's syntax is: 526 match = ( token / quoted-string ) 528 To process a set of header fields against a match parameter, follow 529 these steps (or their equivalent): 531 1. If "header_value" is the empty string, return "none". 533 2. Create "header_list" by splitting "header_value" on "," 534 characters. 536 3. For each "header_item" in "header_list": 538 1. Remove leading and trailing WSP characters in "header_item". 540 2. If the value of "header_item" is character-for-character 541 identical to "parameter_value", return "1". 543 4. Return "0". 545 For example, the Key: 547 Key: Baz;match="charlie" 549 Would return "1" for the following header field values: 551 Baz: charlie 552 Baz: foo, charlie 553 Baz: bar, charlie , abc 555 and "0" for these: 557 Baz: theodore 558 Baz: joe, sam 559 Baz: "charlie" 560 Baz: Charlie 561 Baz: cha rlie 562 Baz: charlie2 564 2.3.4. substr 566 The "substr" parameter is used to determine if a value occurs as a 567 substring of an item in a list of header values. It is case- 568 sensitive. 570 Its value's syntax is: 572 substr = ( token / quoted-string ) 573 To process a set of header fields against a substr parameter, follow 574 these steps (or their equivalent): 576 1. If "header_value" is the empty string, return "none". 578 2. Create "header_list" by splitting "header_value" on "," 579 characters. 581 3. For each "header_item" in "header_list": 583 1. Remove leading and trailing WSP characters in "header_item". 585 2. If the value of "parameter_value" is character-for-character 586 present as a substring of "header_value", return "1". 588 4. Return "0". 590 For example, the Key: 592 Key: Abc;substr=bennet 594 Would return "1" for the following header field values: 596 Abc: bennet 597 Abc: foo, bennet 598 Abc: abennet00 599 Abc: bar, 99bennet , abc 600 Abc: "bennet" 602 and "0" for these: 604 Abc: theodore 605 Abc: joe, sam 606 Abc: Bennet 607 Abc: Ben net 609 2.3.5. param 611 The "param" parameter considers the request header field as a list of 612 key=value parameters, and uses the nominated key's value as the 613 secondary cache key. 615 Its value's syntax is: 617 param = ( token / quoted-string ) 619 To process a list of header fields against a param parameter, follow 620 these steps (or their equivalent): 622 1. Let "header_list" be an empty list. 624 2. Create "header_list_tmp1" by splitting header_value on "," 625 characters. 627 3. For each "header_item_tmp1" in "header_list_tmp1": 629 1. Create "header_list_tmp2" by splitting "header_item_tmp1" on 630 ";" characters. 632 2. For each "header_item_tmp2" in "header_list_tmp2": 634 1. Remove leading and trailing WSP from "header_item_tmp2". 636 2. Append "header_item_tmp2" to header_list. 638 4. For each "header_item" in "header_list": 640 1. If the "=" character does not occur within "header_item", 641 skip to the next "header_item". 643 2. Let "item_name" be the string occurring before the first "=" 644 character in "header_item". 646 3. If "item_name" does not case-insensitively match 647 "parameter_value", skip to the next "header_item". 649 4. Return the string occurring after the first "=" character in 650 "header_item". 652 5. Return the empty string. 654 Note that steps 2 and 3 accommodate semicolon-separated values, so 655 that it can be used with the Cookie request header field. 657 For example, the Key: 659 Key: Def;param=liam 661 The following headers would return the string (surrounded in single 662 quotes) indicated: 664 Def: liam=123 // '123' 665 Def: mno=456 // '' 666 Def: // '' 667 Def: abc=123; liam=890 // '890' 668 Def: liam="678" // '"678"' 670 3. IANA Considerations 672 This specification defines the HTTP Key Parameter Registry, 673 maintained at http://www.iana.org/assignments/http-parameters/http- 674 parameters.xhtml#key . 676 3.1. Procedure 678 Key Parameter registrations MUST include the following fields: 680 o Parameter Name: [name] 682 o Reference: [Pointer to specification text] 684 Values to be added to this namespace require IETF Review (see 685 Section 4.1 of [RFC5226]) and MUST conform to the purpose of content 686 coding defined in this section. 688 3.2. Registrations 690 This specification makes the following entries in the HTTP Key 691 Parameter Registry: 693 +----------------+---------------+ 694 | Parameter Name | Reference | 695 +----------------+---------------+ 696 | div | Section 2.3.1 | 697 | partition | Section 2.3.2 | 698 | match | Section 2.3.3 | 699 | substr | Section 2.3.4 | 700 | param | Section 2.3.5 | 701 +----------------+---------------+ 703 4. Security Considerations 705 Because Key is an alternative to Vary, it is possible for caches to 706 behave differently based upon whether they implement Key. Likewise, 707 because support for any one Key parameter is not required, it is 708 possible for different implementations of Key to behave differently. 709 In both cases, an attacker might be able to exploit these 710 differences. 712 This risk is mitigated by the requirement to fall back to Vary when 713 unsupported parameters are encountered, coupled with the requirement 714 that servers that use Key also include a relevant Vary header. 716 An attacker with the ability to inject response headers might be able 717 to perform a cache poisoning attack that tailors a response to a 718 specific user (e.g., by Keying to a Cookie that's specific to them). 719 While the attack is still possible without Key, the ability to tailor 720 is new. 722 When implemented, Key might result in a larger number of stored 723 responses for a given resource in caches; this, in turn, might be 724 used to create an attack upon the cache itself. Good cache 725 replacement algorithms and denial of service monitoring in cache 726 implementations are reasonable mitigations against this risk. 728 5. References 730 5.1. Normative References 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 734 RFC2119, March 1997, 735 . 737 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 738 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 739 RFC5234, January 2008, 740 . 742 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 743 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 744 7230, DOI 10.17487/RFC7230, June 2014, 745 . 747 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 748 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 749 10.17487/RFC7231, June 2014, 750 . 752 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 753 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 754 RFC 7234, DOI 10.17487/RFC7234, June 2014, 755 . 757 5.2. Informative References 759 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 760 DOI 10.17487/RFC6265, April 2011, 761 . 763 Appendix A. Acknowledgements 765 Thanks to Ilya Grigorik, Amos Jeffries and Yoav Weiss for their 766 feedback. 768 Authors' Addresses 770 Roy T. Fielding 771 Adobe Systems Incorporated 773 Email: fielding@gbiv.com 774 URI: http://roy.gbiv.com/ 776 Mark Nottingham 778 Email: mnot@mnot.net 779 URI: http://www.mnot.net/