diff options
Diffstat (limited to 'doc/rfc/rfc9292.txt')
| -rw-r--r-- | doc/rfc/rfc9292.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc9292.txt b/doc/rfc/rfc9292.txt new file mode 100644 index 0000000..5d7d7c1 --- /dev/null +++ b/doc/rfc/rfc9292.txt @@ -0,0 +1,787 @@ + + + + +Internet Engineering Task Force (IETF) M. Thomson +Request for Comments: 9292 Mozilla +Category: Standards Track C. A. Wood +ISSN: 2070-1721 Cloudflare + August 2022 + + + Binary Representation of HTTP Messages + +Abstract + + This document defines a binary format for representing HTTP messages. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9292. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions and Definitions + 3. Format + 3.1. Known-Length Messages + 3.2. Indeterminate-Length Messages + 3.3. Framing Indicator + 3.4. Request Control Data + 3.5. Response Control Data + 3.5.1. Informational Status Codes + 3.6. Header and Trailer Field Lines + 3.7. Content + 3.8. Padding and Truncation + 4. Invalid Messages + 5. Examples + 5.1. Request Example + 5.2. Response Example + 6. Notable Differences with HTTP Protocol Messages + 7. "message/bhttp" Media Type + 8. Security Considerations + 9. IANA Considerations + 10. References + 10.1. Normative References + 10.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + This document defines a simple format for representing an HTTP + message [HTTP], either request or response. This allows for the + encoding of HTTP messages that can be conveyed outside an HTTP + protocol. This enables the transformation of entire messages, + including the application of authenticated encryption. + + The design of this format is informed by the framing structure of + HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3]. Rules for constructing messages + rely on the rules defined in HTTP/2, but the format itself is + distinct; see Section 6. + + This format defines "message/bhttp", a binary alternative to the + "message/http" content type defined in [HTTP/1.1]. A binary format + permits more efficient encoding and processing of messages. A binary + format also reduces exposure to security problems related to + processing of HTTP messages. + + Two modes for encoding are described: + + * a known-length encoding includes length prefixes for all major + message components, and + + * an indeterminate-length encoding enables efficient generation of + messages where lengths are not known when encoding starts. + + This format is designed to convey the semantics of valid HTTP + messages as simply and efficiently as possible. It is not designed + to capture all of the details of the encoding of messages from + specific HTTP versions [HTTP/1.1] [HTTP/2] [HTTP/3]. As such, this + format is unlikely to be suitable for applications that depend on an + exact recording of the encoding of messages. + +2. Conventions and Definitions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This document uses terminology from HTTP [HTTP] and notation from + QUIC (Section 1.3 of [QUIC]). + +3. Format + + Section 6 of [HTTP] defines the general structure of HTTP messages + and composes those messages into distinct parts. This format + describes how those parts are composed into a sequence of bytes. At + a high level, binary messages are comprised of: + + 1. Framing indicator. This format uses a single integer to describe + framing, which describes whether the message is a request or + response and how subsequent sections are formatted; see + Section 3.3. + + 2. For a response, zero or more informational responses. Each + informational response consists of an informational status code + and header section. + + 3. Control data. For a request, this contains the request method + and target. For a response, this contains the status code. + + 4. Header section. This contains zero or more header fields. + + 5. Content. This is a sequence of zero or more bytes. + + 6. Trailer section. This contains zero or more trailer fields. + + 7. Optional padding. Any amount of zero-valued bytes. + + All lengths and numeric values are encoded using the variable-length + integer encoding from Section 16 of [QUIC]. Integer values do not + need to be encoded on the minimum number of bytes necessary. + +3.1. Known-Length Messages + + A request or response that has a known length at the time of + construction uses the format shown in Figure 1. + + Known-Length Request { + Framing Indicator (i) = 0, + Request Control Data (..), + Known-Length Field Section (..), + Known-Length Content (..), + Known-Length Field Section (..), + Padding (..), + } + + Known-Length Response { + Framing Indicator (i) = 1, + Known-Length Informational Response (..) ..., + Final Response Control Data (..), + Known-Length Field Section (..), + Known-Length Content (..), + Known-Length Field Section (..), + Padding (..), + } + + Known-Length Field Section { + Length (i), + Field Line (..) ..., + } + + Known-Length Content { + Content Length (i), + Content (..), + } + + Known-Length Informational Response { + Informational Response Control Data (..), + Known-Length Field Section (..), + } + + Figure 1: Known-Length Message + + A known-length request consists of a framing indicator (Section 3.3), + request control data (Section 3.4), a header section with a length + prefix, binary content with a length prefix, a trailer section with a + length prefix, and padding. + + A known-length response contains the same fields, with the exception + that request control data is replaced by zero or more informational + responses (Section 3.5.1) followed by response control data + (Section 3.5). + + For a known-length encoding, the length prefix on field sections and + content is a variable-length encoding of an integer. This integer is + the number of bytes in the field section or content, not including + the length field itself. + + Fields in the header and trailer sections consist of a length- + prefixed name and length-prefixed value; see Section 3.6. + + The format allows for the message to be truncated before any of the + length prefixes that precede the field sections or content; see + Section 3.8. + + The variable-length integer encoding means that there is a limit of + 2^62-1 bytes for each field section and the message content. + +3.2. Indeterminate-Length Messages + + A request or response that is constructed without encoding a known + length for each section uses the format shown in Figure 2: + + Indeterminate-Length Request { + Framing Indicator (i) = 2, + Request Control Data (..), + Indeterminate-Length Field Section (..), + Indeterminate-Length Content (..), + Indeterminate-Length Field Section (..), + Padding (..), + } + + Indeterminate-Length Response { + Framing Indicator (i) = 3, + Indeterminate-Length Informational Response (..) ..., + Final Response Control Data (..), + Indeterminate-Length Field Section (..), + Indeterminate-Length Content (..), + Indeterminate-Length Field Section (..), + Padding (..), + } + + Indeterminate-Length Content { + Indeterminate-Length Content Chunk (..) ..., + Content Terminator (i) = 0, + } + + Indeterminate-Length Content Chunk { + Chunk Length (i) = 1.., + Chunk (..), + } + + Indeterminate-Length Field Section { + Field Line (..) ..., + Content Terminator (i) = 0, + } + + Indeterminate-Length Informational Response { + Informational Response Control Data (..), + Indeterminate-Length Field Section (..), + } + + Figure 2: Indeterminate-Length Message + + An indeterminate-length request consists of a framing indicator + (Section 3.3), request control data (Section 3.4), a header section + that is terminated by a zero value, any number of non-zero-length + chunks of binary content, a zero value, a trailer section that is + terminated by a zero value, and padding. + + An indeterminate-length response contains the same fields, with the + exception that request control data is replaced by zero or more + informational responses (Section 3.5.1) and response control data + (Section 3.5). + + The indeterminate-length encoding only uses length prefixes for + content blocks. Multiple length-prefixed portions of content can be + included, each prefixed by a non-zero Chunk Length integer describing + the number of bytes in the block. The Chunk Length is encoded as a + variable-length integer. + + Each Field Line in an Indeterminate-Length Field Section starts with + a Name Length field. An Indeterminate-Length Field Section ends with + a Content Terminator field. The zero value of the Content Terminator + distinguishes it from the Name Length field, which cannot contain a + value of 0. + + Indeterminate-length messages can be truncated in a way similar to + that for known-length messages; see Section 3.8. + + Indeterminate-length messages use the same encoding for Field Line as + known-length messages; see Section 3.6. + +3.3. Framing Indicator + + The start of each binary message is a framing indicator that is a + single integer that describes the structure of the subsequent + sections. The framing indicator can take just four values: + + * A value of 0 describes a request of known length. + + * A value of 1 describes a response of known length. + + * A value of 2 describes a request of indeterminate length. + + * A value of 3 describes a response of indeterminate length. + + Other values cause the message to be invalid; see Section 4. + +3.4. Request Control Data + + The control data for a request message contains the method and + request target. That information is encoded as an ordered sequence + of fields: Method, Scheme, Authority, Path. Each of these fields is + prefixed with a length. + + The values of these fields follow the rules in HTTP/2 (Section 8.3.1 + of [HTTP/2]) that apply to the ":method", ":scheme", ":authority", + and ":path" pseudo-header fields, respectively. However, where the + ":authority" pseudo-header field might be omitted in HTTP/2, a zero- + length value is encoded instead. + + The format of request control data is shown in Figure 3. + + Request Control Data { + Method Length (i), + Method (..), + Scheme Length (i), + Scheme (..), + Authority Length (i), + Authority (..), + Path Length (i), + Path (..), + } + + Figure 3: Format of Request Control Data + +3.5. Response Control Data + + The control data for a response message consists of the status code. + The status code (Section 15 of [HTTP]) is encoded as a variable- + length integer, not a length-prefixed decimal string. + + The format of final response control data is shown in Figure 4. + + Final Response Control Data { + Status Code (i) = 200..599, + } + + Figure 4: Format of Final Response Control Data + +3.5.1. Informational Status Codes + + Responses that include informational status codes (see Section 15.2 + of [HTTP]) are encoded by repeating the response control data and + associated header section until a final status code is encoded; that + is, a Status Code field with a value from 200 to 599 (inclusive). + The status code distinguishes between informational and final + responses. + + The format of the informational response control data is shown in + Figure 5. + + Informational Response Control Data { + Status Code (i) = 100..199, + } + + Figure 5: Format of Informational Response Control Data + + A response message can include any number of informational responses + that precede a final status code. These convey an informational + status code and a header block. + + If the response control data includes an informational status code + (that is, a value between 100 and 199 inclusive), the control data is + followed by a header section (encoded with known length or + indeterminate length according to the framing indicator) and another + block of control data. This pattern repeats until the control data + contains a final status code (200 to 599 inclusive). + +3.6. Header and Trailer Field Lines + + Header and trailer sections consist of zero or more field lines; see + Section 5 of [HTTP]. The format of a field section depends on + whether the message is of known length or indeterminate length. + + Each Field Line encoding includes a name and a value. Both the name + and value are length-prefixed sequences of bytes. The Name field is + a minimum of one byte. The format of a Field Line is shown in + Figure 6. + + Field Line { + Name Length (i) = 1.., + Name (..), + Value Length (i), + Value (..), + } + + Figure 6: Format of a Field Line + + For field names, byte values that are not permitted in an HTTP field + name cause the message to be invalid; see Section 5.1 of [HTTP] for a + definition of what is valid and Section 4 regarding the handling of + invalid messages. A recipient MUST treat a message that contains + field values that would cause an HTTP/2 message to be malformed + according to Section 8.2.1 of [HTTP/2] as invalid; see Section 4. + + The same field name can be repeated over more than one field line; + see Section 5.2 of [HTTP] for the semantics of repeated field names + and rules for combining values. + + Messages are invalid (Section 4) if they contain fields named + ":method", ":scheme", ":authority", ":path", or ":status". Other + pseudo-fields that are defined by protocol extensions MAY be + included; pseudo-fields cannot be included in trailers (see + Section 8.1 of [HTTP/2]). A Field Line containing pseudo-fields MUST + precede other Field Line values. A message that contains a pseudo- + field after any other field is invalid; see Section 4. + + Fields that relate to connections (Section 7.6.1 of [HTTP]) cannot be + used to produce the effect on a connection in this context. These + fields SHOULD be removed when constructing a binary message. + However, they do not cause a message to be invalid (Section 4); + permitting these fields allows a binary message to capture messages + that are exchanged in a protocol context. + + Like HTTP/2 or HTTP/3, this format has an exception for the + combination of multiple instances of the Cookie field. Instances of + fields with the ASCII-encoded value of "cookie" are combined using a + semicolon octet (0x3b) rather than a comma; see Section 8.2.3 of + [HTTP/2]. + +3.7. Content + + The content of messages is a sequence of bytes of any length. Though + a known-length message has a limit, this limit is large enough that + it is unlikely to be a practical limitation. There is no limit to + the size of content in an indeterminate-length message. + +3.8. Padding and Truncation + + Messages can be padded with any number of zero-valued bytes. Non- + zero padding bytes cause a message to be invalid (see Section 4). + Unlike other parts of a message, a processor MAY decide not to + validate the value of padding bytes. + + Truncation can be used to reduce the size of messages that have no + data in trailing field sections or content. If the trailers of a + message are empty, they MAY be omitted by the encoder in place of + adding a length field equal to zero. An encoder MAY omit empty + content in the same way if the trailers are also empty. A message + that is truncated at any other point is invalid; see Section 4. + + Decoders MUST treat missing truncated fields as equivalent to having + been sent with the length field set to zero. + + Padding is compatible with truncation of empty parts of the messages. + Zero-valued bytes will be interpreted as a zero-length part, which is + semantically equivalent to the part being absent. + +4. Invalid Messages + + This document describes a number of ways that a message can be + invalid. Invalid messages MUST NOT be processed further except to + log an error and produce an error response. + + The format is designed to allow incremental processing. + Implementations need to be aware of the possibility that an error + might be detected after performing incremental processing. + +5. Examples + + This section includes example requests and responses encoded in both + known-length and indeterminate-length forms. + +5.1. Request Example + + The example HTTP/1.1 message in Figure 7 shows the content in the + "message/http" format. + + Valid HTTP/1.1 messages require lines terminated with CRLF (the two + bytes 0x0d and 0x0a). For simplicity and consistency, the content of + these examples is limited to text, which also uses CRLF for line + endings. + + GET /hello.txt HTTP/1.1 + User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 + Host: www.example.com + Accept-Language: en, mi + + Figure 7: Sample HTTP Request + + This can be expressed as a binary message (type "message/bhttp") + using a known-length encoding as shown in hexadecimal in Figure 8. + Figure 8 includes text alongside to show that most of the content is + not modified. + + 00034745 54056874 74707300 0a2f6865 ..GET.https../he + 6c6c6f2e 74787440 6c0a7573 65722d61 llo.txt@l.user-a + 67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3 + 206c6962 6375726c 2f372e31 362e3320 libcurl/7.16.3 + 4f70656e 53534c2f 302e392e 376c207a OpenSSL/0.9.7l z + 6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w + 77772e65 78616d70 6c652e63 6f6d0f61 ww.example.com.a + 63636570 742d6c61 6e677561 67650665 ccept-language.e + 6e2c206d 690000 n, mi.. + + Figure 8: Known-Length Binary Encoding of Request + + This example shows that the Host header field is not replicated in + the ":authority" field, as is required for ensuring that the request + is reproduced accurately; see Section 8.3.1 of [HTTP/2]. + + The same message can be truncated with no effect on interpretation. + In this case, the last two bytes -- corresponding to content and a + trailer section -- can each be removed without altering the semantics + of the message. + + The same message, encoded using an indeterminate-length encoding, is + shown in Figure 9. As the content of this message is empty, the + difference in formats is negligible. + + 02034745 54056874 74707300 0a2f6865 ..GET.https../he + 6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age + 6e743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 l + 69626375 726c2f37 2e31362e 33204f70 ibcurl/7.16.3 Op + 656e5353 4c2f302e 392e376c 207a6c69 enSSL/0.9.7l zli + 622f312e 322e3304 686f7374 0f777777 b/1.2.3.host.www + 2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc + 6570742d 6c616e67 75616765 06656e2c ept-language.en, + 206d6900 00000000 00000000 00000000 mi............. + + Figure 9: Indeterminate-Length Binary Encoding of Request + + This indeterminate-length encoding contains 10 bytes of padding. As + two additional bytes can be truncated in the same way as the known- + length example, anything up to 12 bytes can be removed from this + message without affecting its meaning. + +5.2. Response Example + + Response messages can contain interim (1xx) status codes, as the + message in Figure 10 shows. Figure 10 includes examples of + informational status codes 102 and 103, as defined in [RFC2518] (now + obsolete but defines status code 102) and [RFC8297], respectively. + + HTTP/1.1 102 Processing + Running: "sleep 15" + + HTTP/1.1 103 Early Hints + Link: </style.css>; rel=preload; as=style + Link: </script.js>; rel=preload; as=script + + HTTP/1.1 200 OK + Date: Mon, 27 Jul 2009 12:28:53 GMT + Server: Apache + Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT + ETag: "34aa387-d-1568eb00" + Accept-Ranges: bytes + Content-Length: 51 + Vary: Accept-Encoding + Content-Type: text/plain + + Hello World! My content includes a trailing CRLF. + + Figure 10: Sample HTTP Response + + As this is a longer example, only the indeterminate-length encoding + is shown in Figure 11. Note here that the specific text used in the + reason phrase is not retained by this encoding. + + 03406607 72756e6e 696e670a 22736c65 .@f.running."sle + 65702031 35220040 67046c69 6e6b233c ep 15".@g.link#< + 2f737479 6c652e63 73733e3b 2072656c /style.css>; rel + 3d707265 6c6f6164 3b206173 3d737479 =preload; as=sty + 6c65046c 696e6b24 3c2f7363 72697074 le.link$</script + 2e6a733e 3b207265 6c3d7072 656c6f61 .js>; rel=preloa + 643b2061 733d7363 72697074 0040c804 d; as=script.@.. + 64617465 1d4d6f6e 2c203237 204a756c date.Mon, 27 Jul + 20323030 39203132 3a32383a 35332047 2009 12:28:53 G + 4d540673 65727665 72064170 61636865 MT.server.Apache + 0d6c6173 742d6d6f 64696669 65641d57 .last-modified.W + 65642c20 3232204a 756c2032 30303920 ed, 22 Jul 2009 + 31393a31 353a3536 20474d54 04657461 19:15:56 GMT.eta + 67142233 34616133 38372d64 2d313536 g."34aa387-d-156 + 38656230 30220d61 63636570 742d7261 8eb00".accept-ra + 6e676573 05627974 65730e63 6f6e7465 nges.bytes.conte + 6e742d6c 656e6774 68023531 04766172 nt-length.51.var + 790f4163 63657074 2d456e63 6f64696e y.Accept-Encodin + 670c636f 6e74656e 742d7479 70650a74 g.content-type.t + 6578742f 706c6169 6e003348 656c6c6f ext/plain.3Hello + 20576f72 6c642120 4d792063 6f6e7465 World! My conte + 6e742069 6e636c75 64657320 61207472 nt includes a tr + 61696c69 6e672043 524c462e 0d0a0000 ailing CRLF..... + + Figure 11: Binary Response, including Informational Responses + + A response that uses the chunked encoding (see Section 7.1 of + [HTTP/1.1]) as shown in Figure 12 can be encoded using indeterminate- + length encoding, which minimizes buffering needed to translate into + the binary format. However, chunk boundaries do not need to be + retained, and any chunk extensions cannot be conveyed using the + binary format; see Section 6. + + HTTP/1.1 200 OK + Transfer-Encoding: chunked + + 4 + This + 6 + conte + 13;chunk-extension=foo + nt contains CRLF. + + 0 + Trailer: text + + Figure 12: Chunked Encoding Example + + Figure 13 shows this message using the known-length encoding. Note + that the Transfer-Encoding header field is removed. + + 0140c800 1d546869 7320636f 6e74656e .@...This conten + 7420636f 6e746169 6e732043 524c462e t contains CRLF. + 0d0a0d07 74726169 6c657204 74657874 ....trailer.text + + Figure 13: Known-Length Encoding of Response + +6. Notable Differences with HTTP Protocol Messages + + This format is designed to carry HTTP semantics just like HTTP/1.1 + [HTTP/1.1], HTTP/2 [HTTP/2], or HTTP/3 [HTTP/3]. However, there are + some notable differences between this format and the format used in + an interactive protocol version. + + In particular, as a standalone representation, this format lacks the + following features of the formats used in those protocols: + + * chunk extensions (Section 7.1.1 of [HTTP/1.1]) and transfer + encoding (Section 6.1 of [HTTP/1.1]) + + * generic framing and extensibility capabilities + + * field blocks other than a single header and trailer field block + + * carrying reason phrases in responses (Section 4 of [HTTP/1.1]) + + * header compression [HPACK] [QPACK] + + * response framing that depends on the corresponding request (such + as HEAD) or the value of the status code (such as 204 or 304); + these responses use the same framing as all other messages + + Some of these features are also absent in HTTP/2 and HTTP/3. + + Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control + data rather than using pseudo-fields. + + Note that while some messages -- CONNECT or upgrade requests in + particular -- can be represented using this format, doing so serves + no purpose, as these requests are used to affect protocol behavior, + which this format cannot do without additional mechanisms. + +7. "message/bhttp" Media Type + + The "message/bhttp" media type can be used to enclose a single HTTP + request or response message, provided that it obeys the MIME + restrictions for all "message" types regarding line length and + encodings. + + Type name: message + Subtype name: bhttp + Required parameters: N/A + Optional parameters: N/A + Encoding considerations: Only "8bit" or "binary" is permitted. + Security considerations: See Section 8. + Interoperability considerations: N/A + Published specification: RFC 9292 + Applications that use this media type: Applications seeking to + convey HTTP semantics that are independent of a specific protocol. + Fragment identifier considerations: N/A + Additional information: Deprecated alias names for this type: N/A + Magic number(s): N/A + File extension(s): N/A + Macintosh file type code(s): N/A + Person & email address to contact for further information: See the + Authors' Addresses section. + Intended usage: COMMON + Restrictions on usage: N/A + Author: See the Authors' Addresses section. + Change controller: IESG + +8. Security Considerations + + Many of the considerations that apply to HTTP message handling apply + to this format; see Section 17 of [HTTP] and Section 11 of [HTTP/1.1] + for common issues in handling HTTP messages. + + Strict parsing of the format with no tolerance for errors can help + avoid a number of attacks. However, implementations still need to be + aware of the possibility of resource exhaustion attacks that might + arise from receiving large messages, particularly those with large + numbers of fields. + + Implementations need to ensure that they aren't subject to resource + exhaustion attacks from maliciously crafted messages. Overall, the + format is designed to allow for minimal state when processing + messages. However, producing a combined field value (Section 5.2 of + [HTTP]) for fields might require the commitment of resources. In + particular, combining might be necessary for the Cookie field when + translating this format for use in other contexts, such as use in an + API or translation to HTTP/1.1 [HTTP/1.1], where the recipient of the + field might not expect multiple values. + +9. IANA Considerations + + IANA has added the media type "message/bhttp" to the "Media Types" + registry at <https://www.iana.org/assignments/media-types>. See + Section 7 for registration information. + +10. References + +10.1. Normative References + + [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + <https://www.rfc-editor.org/info/rfc9110>. + + [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, + DOI 10.17487/RFC9113, June 2022, + <https://www.rfc-editor.org/info/rfc9113>. + + [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + <https://www.rfc-editor.org/info/rfc9000>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +10.2. Informative References + + [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for + HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, + <https://www.rfc-editor.org/info/rfc7541>. + + [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, + June 2022, <https://www.rfc-editor.org/info/rfc9112>. + + [HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, + June 2022, <https://www.rfc-editor.org/info/rfc9114>. + + [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: + Field Compression for HTTP/3", RFC 9204, + DOI 10.17487/RFC9204, June 2022, + <https://www.rfc-editor.org/info/rfc9204>. + + [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. + Jensen, "HTTP Extensions for Distributed Authoring -- + WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, + <https://www.rfc-editor.org/info/rfc2518>. + + [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", + RFC 8297, DOI 10.17487/RFC8297, December 2017, + <https://www.rfc-editor.org/info/rfc8297>. + +Acknowledgments + + Julian Reschke, David Schinazi, Lucas Pardue, and Tommy Pauly + provided excellent feedback on both the design and its documentation. + +Authors' Addresses + + Martin Thomson + Mozilla + Email: mt@lowentropy.net + + + Christopher A. Wood + Cloudflare + Email: caw@heapingbits.net |