idnits 2.17.1 draft-thomson-http-binary-message-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 August 2021) is 962 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) == Outdated reference: A later version (-07) exists of draft-ietf-httpbis-http2bis-03 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-17 -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-17 -- Possible downref: Normative reference to a draft: ref. 'MESSAGING' -- Obsolete informational reference (is this intentional?): RFC 2518 (Obsoleted by RFC 4918) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPBIS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track C.A. Wood 5 Expires: 11 February 2022 Cloudflare 6 10 August 2021 8 Binary Representation of HTTP Messages 9 draft-thomson-http-binary-message-01 11 Abstract 13 This document defines a binary format for representing HTTP messages. 15 Discussion Venues 17 This note is to be removed before publishing as an RFC. 19 Discussion of this document takes place on the HTTP Working Group 20 mailing list (http@ietf.org), which is archived at 21 https://mailarchive.ietf.org/arch/browse/http/. 23 Source for this draft and an issue tracker can be found at 24 https://github.com/unicorn-wg/oblivious-http. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 11 February 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 61 3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Known Length Messages . . . . . . . . . . . . . . . . . . 4 63 3.2. Indeterminate Length Messages . . . . . . . . . . . . . . 5 64 3.3. Framing Indicator . . . . . . . . . . . . . . . . . . . . 6 65 3.4. Request Control Data . . . . . . . . . . . . . . . . . . 6 66 3.5. Response Control Data . . . . . . . . . . . . . . . . . . 7 67 3.5.1. Informational Status Codes . . . . . . . . . . . . . 7 68 3.6. Header and Trailer Field Lines . . . . . . . . . . . . . 8 69 3.7. Content . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Invalid Messages . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.1. Request Example . . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Response Example . . . . . . . . . . . . . . . . . . . . 11 74 6. "message/bhttp" Media Type . . . . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 9.2. Informative References . . . . . . . . . . . . . . . . . 15 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 This document defines a simple format for representing an HTTP 86 message ([HTTP]), either request or response. This allows for the 87 encoding of HTTP messages that can be conveyed outside of an HTTP 88 protocol. This enables the transformation of entire messages, 89 including the application of authenticated encryption. 91 This format is informed by the framing structure of HTTP/2 ([H2]) and 92 HTTP/3 ([H3]). In comparison, this format simpler by virtue of not 93 including either header compression ([HPACK], [QPACK]) or a generic 94 framing layer. 96 This format provides an alternative to the "message/http" content 97 type defined in [MESSAGING]. A binary format permits more efficient 98 encoding and processing of messages. A binary format also reduces 99 exposure to security problems related to processing of HTTP messages. 101 Two modes for encoding are described: 103 * a known-length encoding includes length prefixes for all major 104 message components; and 106 * an indefinite-length encoding enables efficient generation of 107 messages where lengths are not known when encoding starts. 109 2. Conventions and Definitions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 This document uses terminology from HTTP ([HTTP]) and notation from 118 QUIC (Section 1.3 of [QUIC]). 120 3. Format 122 Section 6 of [HTTP] defines five distinct parts to HTTP messages. A 123 framing indicator is added to signal how these parts are composed: 125 1. Framing indicator. This format uses a single integer to describe 126 framing, which describes whether the message is a request or 127 response and how subsequent sections are formatted; see 128 Section 3.3. 130 2. For a response, any number of interim responses, each consisting 131 of an informational status code and header section. 133 3. Control data. For a request, this contains the request method 134 and target. For a response, this contains the status code. 136 4. Header section. This contains zero or more header fields. 138 5. Content. This is a sequence of zero or more bytes. 140 6. Trailer section. This contains zero or more trailer fields. 142 All lengths and numeric values are encoded using the variable-length 143 integer encoding from Section 16 of [QUIC]. 145 3.1. Known Length Messages 147 A message that has a known length at the time of construction uses 148 the format shown in Figure 1. 150 Message with Known-Length { 151 Framing Indicator (i) = 0..1, 152 Known-Length Informational Response (..) ..., 153 Control Data (..), 154 Known-Length Field Section (..), 155 Known-Length Content (..), 156 Known-Length Field Section (..), 157 } 159 Known-Length Field Section { 160 Length (i) = 2.., 161 Field Line (..) ..., 162 } 164 Known-Length Content { 165 Content Length (i), 166 Content (..) 167 } 169 Known-Length Informational Response { 170 Informational Response Control Data (..), 171 Known-Length Field Section (..), 172 } 174 Figure 1: Known-Length Message 176 That is, a known-length message consists of a framing indicator, a 177 block of control data that is formatted according to the value of the 178 framing indicator, a header section with a length prefix, binary 179 content with a length prefix, and a trailer section with a length 180 prefix. 182 Response messages that contain informational status codes result in a 183 different structure; see Section 3.5.1. 185 Fields in the header and trailer sections consist of a length- 186 prefixed name and length-prefixed value. Both name and value are 187 sequences of bytes that cannot be zero length. 189 The format allows for the message to be truncated before any of the 190 length prefixes that precede the field sections or content. This 191 reduces the overall message size. A message that is truncated at any 192 other point is invalid; see Section 4. 194 The variable-length integer encoding means that there is a limit of 195 2^62-1 bytes for each field section and the message content. 197 3.2. Indeterminate Length Messages 199 A message that is constructed without encoding a known length for 200 each section uses the format shown in Figure 2: 202 Indeterminate-Length Message { 203 Framing Indicator (i) = 2..3, 204 Indeterminate-Length Informational Response (..) ..., 205 Control Data (..), 206 Indeterminate-Length Field Section (..), 207 Indeterminate-Length Content (..) ..., 208 Indeterminate-Length Field Section (..), 209 } 211 Indeterminate-Length Content { 212 Indeterminate-Length Content Chunk (..) ..., 213 Content Terminator (i) = 0, 214 } 216 Indeterminate-Length Content Chunk { 217 Chunk Length (i) = 1.., 218 Chunk (..) 219 } 221 Indeterminate-Length Field Section { 222 Field Line (..) ..., 223 Content Terminator (i) = 0, 224 } 226 Indeterminate-Length Informational Response { 227 Informational Response Control Data (..), 228 Indeterminate-Length Field Section (..), 229 } 231 Figure 2: Indeterminate-Length Message 233 That is, an indeterminate length consists of a framing indicator, a 234 block of control data that is formatted according to the value of the 235 framing indicator, a header section that is terminated by a zero 236 value, any number of non-zero-length chunks of binary content, a zero 237 value, and a trailer section that is terminated by a zero value. 239 Response messages that contain informational status codes result in a 240 different structure; see Section 3.5.1. 242 Indeterminate-length messages can be truncated in a similar way as 243 known-length messages. Truncation occurs after the control data, or 244 after the Content Terminator field that ends a field section or 245 sequence of content chunks. A message that is truncated at any other 246 point is invalid; see Section 4. 248 Indeterminate-length messages use the same encoding for field lines 249 as known-length messages; see Section 3.6. 251 3.3. Framing Indicator 253 The start of each is a framing indicator that is a single integer 254 that describes the structure of the subsequent sections. The framing 255 indicator can take just four values: 257 * A value of 0 describes a request of known length. 259 * A value of 1 describes a response of known length. 261 * A value of 2 describes a request of indeterminate length. 263 * A value of 3 describes a response of indeterminate length. 265 Other values cause the message to be invalid; see Section 4. 267 3.4. Request Control Data 269 The control data for a request message includes four values that 270 correspond to the values of the ":method", ":scheme", ":authority", 271 and ":path" pseudo-header fields described in HTTP/2 (Section 8.3.1 272 of [H2]). These fields are encoded, each with a length prefix, in 273 the order listed. 275 The rules in Section 8.3 of [H2] for constructing pseudo-header 276 fields apply to the construction of these values. However, where the 277 ":authority" pseudo-header field might be omitted in HTTP/2, a zero- 278 length value is encoded instead. 280 The format of request control data is shown in Figure 3. 282 Request Control Data { 283 Method Length (i), 284 Method (..), 285 Scheme Length (i), 286 Scheme (..), 287 Authority Length (i), 288 Authority (..), 289 Path Length (i), 290 Path (..), 291 } 293 Figure 3: Format of Request Control Data 295 3.5. Response Control Data 297 The control data for a request message includes a single field that 298 corresponds to the ":status" pseudo-header field in HTTP/2; see 299 Section 8.3.2 of [H2]. This field is encoded as a single variable 300 length integer, not a decimal string. 302 The format of final response control data is shown in Figure 4. 304 Final Response Control Data { 305 Status Code (i) = 200..599, 306 } 308 Figure 4: Format of Final Response Control Data 310 3.5.1. Informational Status Codes 312 Responses that include information status codes (see Section 15.2 of 313 [HTTP]) are encoded by repeating the response control data and 314 associated header section until the final status code is encoded. 316 The format of the informational response control data is shown in 317 Figure 5. 319 Informational Response Control Data { 320 Status Code (i) = 100..199, 321 } 323 Figure 5: Format of Informational Response Control Data 325 A response message can include any number of informational responses. 326 If the response control data includes an informational status code 327 (that is, a value between 100 and 199 inclusive), the control data is 328 followed by a header section (encoded with known- or indeterminate- 329 length according to the framing indicator). After the header 330 section, another response control data block follows. 332 3.6. Header and Trailer Field Lines 334 Header and trailer sections consist of zero or more field lines; see 335 Section 5 of [HTTP]. The format of a field section depends on 336 whether the message is known- or intermediate-length. 338 Each field line includes a name and a value. Both the name and value 339 are non-zero length sequences of bytes. The format of a field line 340 is shown in Figure 6. 342 Field Line { 343 Name Length (i) = 1.., 344 Name (..), 345 Value Length (i) = 1.., 346 Value (..), 347 } 349 Figure 6: Format of a Field Line 351 For field names, byte values that are not permitted in an HTTP field 352 name cause the message to be invalid; see Section 5.1 of [HTTP] for a 353 definition of what is valid and Section 4 for handling of invalid 354 messages. 356 Field names and values MUST be constructed and validated according to 357 the rules of Section 8.2.1 of [H2]. A recipient MUST treat a message 358 that HTTP/2 regards as malformed by these rules as invalid; see 359 Section 4. 361 The same field name can be repeated in multiple field lines; see 362 Section 5.2 of [HTTP] for the semantics of repeated field names and 363 rules for combining values. 365 Like HTTP/2, this format has an exception for the combination of 366 multiple instances of the "Cookie" field. Instances of fields with 367 the ASCII-encoded value of "cookie" are combined using a semicolon 368 octet (0x3b) rather than a comma; see Section 8.2.3 of [H2]. 370 This format provides fixed locations for content that would be 371 carried in HTTP/2 pseudo-fields. Therefore, there is no need to 372 include field lines containing a name of ":method", ":scheme", 373 ":authority", ":path", or ":status". Fields that contain one of 374 these names cause the message to be invalid; see Section 4. Pseudo- 375 fields that are defined by protocol extensions MAY be included. 376 Field lines containing pseudo-fields MUST precede other field lines; 377 a message that contains a pseudo-field after any other field is 378 invalid; see Section 4. 380 3.7. Content 382 The content of messages is a sequence of bytes of any length. Though 383 a known-length message has a limit, this limit is large enough that 384 it is unlikely to be a practical limitation. There is no limit to 385 the size of content in an indeterminate length message. 387 Omitting content by truncating a message is only possible if the 388 content is zero-length. 390 4. Invalid Messages 392 This document describes a number of ways that a message can be 393 invalid. Invalid messages MUST NOT be processed except to log an 394 error and produce an error response. 396 The format is designed to allow incremental processing. 397 Implementations need to be aware of the possibility that an error 398 might be detected after performing incremental processing. 400 5. Examples 402 This section includes example requests and responses encoded in both 403 known-length and indefinite-length forms. 405 5.1. Request Example 407 The example HTTP/1.1 message in Figure 7 shows the content of a 408 "message/http". 410 Valid HTTP/1.1 messages require lines terminated with CRLF (the two 411 bytes 0x0a and 0x0d). For simplicity and consistency, the content of 412 these examples is limited to text, which also uses CRLF for line 413 endings. 415 GET /hello.txt HTTP/1.1 416 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 417 Host: www.example.com 418 Accept-Language: en, mi 420 Figure 7: Sample HTTP Request 422 This can be expressed as a binary message (type "message/bhttp") 423 using a known-length encoding as shown in hexadecimal in Figure 8. 424 Figure 8 view includes some of the text alongside to show that most 425 of the content is not modified. 427 00034745 54056874 74707300 0a2f6865 ..GET.https../he 428 6c6c6f2e 74787440 6c0a7573 65722d61 llo.txt@l.user-a 429 67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3 430 206c6962 6375726c 2f372e31 362e3320 libcurl/7.16.3 431 4f70656e 53534c2f 302e392e 376c207a OpenSSL/0.9.7l z 432 6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w 433 77772e65 78616d70 6c652e63 6f6d0f61 ww.example.com.a 434 63636570 742d6c61 6e677561 67650665 ccept-language.e 435 6e2c206d 690000 n, mi.. 437 Figure 8: Known-Length Binary Encoding of Request 439 This example shows that the Host header field is not replicated in 440 the :authority field, as is required for ensuring that the request is 441 reproduced accurately; see Section 8.3.1 of [H2]. 443 The same message can be truncated with no effect on interpretation. 444 In this case, the last two bytes - corresponding to content and a 445 trailer section - can each be removed without altering the semantics 446 of the message. 448 The same message, encoded using an indefinite-length encoding is 449 shown in Figure 9. As the content of this message is empty, the 450 difference in formats is negligible. 452 02034745 54056874 74707300 0a2f6865 ..GET.https../he 453 6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age 454 6e743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 l 455 69626375 726c2f37 2e31362e 33204f70 ibcurl/7.16.3 Op 456 656e5353 4c2f302e 392e376c 207a6c69 enSSL/0.9.7l zli 457 622f312e 322e3304 686f7374 0f777777 b/1.2.3.host.www 458 2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc 459 6570742d 6c616e67 75616765 06656e2c ept-language.en, 460 206d6900 0000 mi... 462 Figure 9: Indefinite-Length Binary Encoding of Request 464 This indefinite-length encoding can be truncated by two bytes in the 465 same way. 467 5.2. Response Example 469 Response messages can contain interim (1xx) status codes as the 470 message in Figure 10 shows. Figure 10 includes examples of 471 informational status codes defined in [RFC2518] and [RFC8297]. 473 HTTP/1.1 102 Processing 474 Running: "sleep 15" 476 HTTP/1.1 103 Early Hints 477 Link: ; rel=preload; as=style 478 Link: ; rel=preload; as=script 480 HTTP/1.1 200 OK 481 Date: Mon, 27 Jul 2009 12:28:53 GMT 482 Server: Apache 483 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 484 ETag: "34aa387-d-1568eb00" 485 Accept-Ranges: bytes 486 Content-Length: 51 487 Vary: Accept-Encoding 488 Content-Type: text/plain 490 Hello World! My content includes a trailing CRLF. 492 Figure 10: Sample HTTP Response 494 As this is a longer example, only the indefinite-length encoding is 495 shown in Figure 11. Note here that the specific text used in the 496 reason phrase is not retained by this encoding. 498 03406607 72756e6e 696e670a 22736c65 .@f.running."sle 499 65702031 35220040 67046c69 6e6b233c ep 15".@g.link#< 500 2f737479 6c652e63 73733e3b 2072656c /style.css>; rel 501 3d707265 6c6f6164 3b206173 3d737479 =preload; as=sty 502 6c65046c 696e6b24 3c2f7363 72697074 le.link$; rel=preloa 504 643b2061 733d7363 72697074 0040c804 d; as=script.@.. 505 64617465 1d4d6f6e 2c203237 204a756c date.Mon, 27 Jul 506 20323030 39203132 3a32383a 35332047 2009 12:28:53 G 507 4d540673 65727665 72064170 61636865 MT.server.Apache 508 0d6c6173 742d6d6f 64696669 65641d57 .last-modified.W 509 65642c20 3232204a 756c2032 30303920 ed, 22 Jul 2009 510 31393a31 353a3536 20474d54 04657461 19:15:56 GMT.eta 511 67142233 34616133 38372d64 2d313536 g."34aa387-d-156 512 38656230 30220d61 63636570 742d7261 8eb00".accept-ra 513 6e676573 05627974 65730e63 6f6e7465 nges.bytes.conte 514 6e742d6c 656e6774 68023531 04766172 nt-length.51.var 515 790f4163 63657074 2d456e63 6f64696e y.Accept-Encodin 516 670c636f 6e74656e 742d7479 70650a74 g.content-type.t 517 6578742f 706c6169 6e003348 656c6c6f ext/plain.3Hello 518 20576f72 6c642120 4d792063 6f6e7465 World! My conte 519 6e742069 6e636c75 64657320 61207472 nt includes a tr 520 61696c69 6e672043 524c462e 0d0a0000 ailing CRLF..... 522 Figure 11: Binary Response including Interim Responses 524 A response that uses the chunked encoding (see Section 7.1 of 525 [MESSAGING]) as shown for Figure 12 can be encoded using indefinite- 526 length encoding, which minimizes buffering needed to translate into 527 the binary format. However, chunk boundaries do not need to be 528 retained and any chunk extensions cannot be conveyed using the binary 529 format. 531 HTTP/1.1 200 OK 532 Transfer-Encoding: chunked 534 4 535 This 536 6 537 conte 538 13;chunk-extension=foo 539 nt contains CRLF. 541 0 542 Trailer: text 544 Figure 12: Chunked Encoding Example 546 Figure 13 shows this message using the known-length coding. Note 547 that the transfer-encoding header field is removed. 549 0140c800 1d546869 7320636f 6e74656e .@...This conten 550 7420636f 6e746169 6e732043 524c462e t contains CRLF. 551 0d0a0d07 74726169 6c657204 74657874 ....trailer.text 553 Figure 13: Known-Length Encoding of Response 555 6. "message/bhttp" Media Type 557 The message/http media type can be used to enclose a single HTTP 558 request or response message, provided that it obeys the MIME 559 restrictions for all "message" types regarding line length and 560 encodings. 562 Type name: message 564 Subtype name: bhttp 566 Required parameters: N/A 568 Optional parameters: None 570 Encoding considerations: only "8bit" or "binary" is permitted 572 Security considerations: see Section 7 574 Interoperability considerations: N/A 576 Published specification: this specification 578 Applications that use this media type: N/A 580 Fragment identifier considerations: N/A 582 Additional information: Magic number(s): N/A 584 Deprecated alias names for this type: N/A 586 File extension(s): N/A 588 Macintosh file type code(s): N/A 590 Person and email address to contact for further information: see Aut 591 hors' Addresses section 593 Intended usage: COMMON 594 Restrictions on usage: N/A 596 Author: see Authors' Addresses section 598 Change controller: IESG 600 7. Security Considerations 602 Many of the considerations that apply to HTTP message handling apply 603 to this format; see Section 17 of [HTTP] and Section 11 of 604 [MESSAGING] for common issues in handling HTTP messages. 606 Strict parsing of the format with no tolerance for errors can help 607 avoid a number of attacks. However, implementations still need to be 608 aware of the possibility of resource exhaustion attacks that might 609 arise from receiving large messages, particularly those with large 610 numbers of fields. 612 The format is designed to allow for minimal state when translating 613 for use with HTTP proper. However, producing a combined value for 614 fields, which might be necessary for the "Cookie" field when 615 translating this format (like HTTP/1.1 [MESSAGING]), can require the 616 commitment of resources. Implementations need to ensure that they 617 aren't subject to resource exhaustion attack from a maliciously 618 crafted message. 620 8. IANA Considerations 622 Please add the "Media Types" registry at 623 https://www.iana.org/assignments/media-types 624 (https://www.iana.org/assignments/media-types) with the registration 625 information in Section 6 for the media type "message/bhttp". 627 9. References 629 9.1. Normative References 631 [H2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol 632 Version 2 (HTTP/2)", Work in Progress, Internet-Draft, 633 draft-ietf-httpbis-http2bis-03, 12 July 2021, 634 . 637 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 638 Semantics", Work in Progress, Internet-Draft, draft-ietf- 639 httpbis-semantics-17, 25 July 2021, 640 . 643 [MESSAGING] 644 Fielding, R. T., Nottingham, M., and J. Reschke, 645 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 646 httpbis-messaging-17, 25 July 2021, 647 . 650 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 651 Multiplexed and Secure Transport", RFC 9000, 652 DOI 10.17487/RFC9000, May 2021, 653 . 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, 657 DOI 10.17487/RFC2119, March 1997, 658 . 660 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 661 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 662 May 2017, . 664 9.2. Informative References 666 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 667 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 668 quic-http-34, 2 February 2021, 669 . 672 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 673 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 674 . 676 [QPACK] Krasic, C. '., Bishop, M., and A. Frindell, "QPACK: Header 677 Compression for HTTP/3", Work in Progress, Internet-Draft, 678 draft-ietf-quic-qpack-21, 2 February 2021, 679 . 682 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 683 Jensen, "HTTP Extensions for Distributed Authoring -- 684 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 685 . 687 [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", 688 RFC 8297, DOI 10.17487/RFC8297, December 2017, 689 . 691 Acknowledgments 693 TODO: credit where credit is due. 695 Authors' Addresses 697 Martin Thomson 698 Mozilla 700 Email: mt@lowentropy.net 702 Christopher A. Wood 703 Cloudflare 705 Email: caw@heapingbits.net