idnits 2.17.1 draft-ietf-quic-http-33.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 December 2020) is 1228 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-19) exists of draft-ietf-httpbis-cache-13 -- Possible downref: Normative reference to a draft: ref. 'CACHING' == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-20 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-13 -- Possible downref: Normative reference to a draft: ref. 'SEMANTICS' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-13 -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Akamai 4 Intended status: Standards Track 15 December 2020 5 Expires: 18 June 2021 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-33 10 Abstract 12 The QUIC transport protocol has several features that are desirable 13 in a transport for HTTP, such as stream multiplexing, per-stream flow 14 control, and low-latency connection establishment. This document 15 describes a mapping of HTTP semantics over QUIC. This document also 16 identifies HTTP/2 features that are subsumed by QUIC, and describes 17 how HTTP/2 extensions can be ported to HTTP/3. 19 DO NOT DEPLOY THIS VERSION OF HTTP 21 DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This 22 version is still a work in progress. For trial deployments, please 23 use earlier versions. 25 Note to Readers 27 Discussion of this draft takes place on the QUIC working group 28 mailing list (quic@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/search/?email_list=quic. 31 Working Group information can be found at https://github.com/quicwg; 32 source code and issues list for this draft can be found at 33 https://github.com/quicwg/base-drafts/labels/-http. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 18 June 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 5 69 1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 70 2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5 71 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 72 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 7 73 3. Connection Setup and Management . . . . . . . . . . . . . . . 8 74 3.1. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8 75 3.1.1. HTTP Alternative Services . . . . . . . . . . . . . . 9 76 3.1.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 10 77 3.2. Connection Establishment . . . . . . . . . . . . . . . . 10 78 3.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 11 79 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 11 80 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 11 81 4.1.1. Field Formatting and Compression . . . . . . . . . . 13 82 4.1.2. Request Cancellation and Rejection . . . . . . . . . 17 83 4.1.3. Malformed Requests and Responses . . . . . . . . . . 18 84 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 19 85 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 20 86 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 20 87 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 22 88 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 22 89 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 23 90 5.3. Immediate Application Closure . . . . . . . . . . . . . . 25 91 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 25 92 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 25 93 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 26 94 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 26 95 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 28 96 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 28 97 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 29 98 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 29 99 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 30 100 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 31 101 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 31 102 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 31 103 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 32 104 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 33 105 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 36 106 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 38 107 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 38 108 7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 39 109 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 40 110 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 40 111 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 42 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 113 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 43 114 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 43 115 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 43 116 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 44 117 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 44 118 10.5.1. Limits on Field Section Size . . . . . . . . . . . . 45 119 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 46 120 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 46 121 10.7. Padding and Traffic Analysis . . . . . . . . . . . . . . 46 122 10.8. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 47 123 10.9. Early Data . . . . . . . . . . . . . . . . . . . . . . . 47 124 10.10. Migration . . . . . . . . . . . . . . . . . . . . . . . 48 125 10.11. Privacy Considerations . . . . . . . . . . . . . . . . . 48 126 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 127 11.1. Registration of HTTP/3 Identification String . . . . . . 48 128 11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 49 129 11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 49 130 11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 50 131 11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 51 132 11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 54 133 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 134 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 135 12.2. Informative References . . . . . . . . . . . . . . . . . 56 136 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 57 137 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 57 138 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 58 139 A.2.1. Prioritization Differences . . . . . . . . . . . . . 59 140 A.2.2. Field Compression Differences . . . . . . . . . . . . 59 141 A.2.3. Flow Control Differences . . . . . . . . . . . . . . 59 142 A.2.4. Guidance for New Frame Type Definitions . . . . . . . 59 143 A.2.5. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 60 144 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 61 145 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 62 146 A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors . . . . . . 63 147 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 64 148 B.1. Since draft-ietf-quic-http-32 . . . . . . . . . . . . . . 64 149 B.2. Since draft-ietf-quic-http-31 . . . . . . . . . . . . . . 64 150 B.3. Since draft-ietf-quic-http-30 . . . . . . . . . . . . . . 64 151 B.4. Since draft-ietf-quic-http-29 . . . . . . . . . . . . . . 64 152 B.5. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 64 153 B.6. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 64 154 B.7. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 65 155 B.8. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 65 156 B.9. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 65 157 B.10. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 65 158 B.11. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 65 159 B.12. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 66 160 B.13. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 66 161 B.14. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 67 162 B.15. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 67 163 B.16. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 68 164 B.17. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 68 165 B.18. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 69 166 B.19. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 69 167 B.20. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 69 168 B.21. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 69 169 B.22. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 70 170 B.23. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 70 171 B.24. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 70 172 B.25. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 70 173 B.26. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 70 174 B.27. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 70 175 B.28. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 70 176 B.29. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 70 177 B.30. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 71 178 B.31. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 71 179 B.32. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 71 180 B.33. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 72 181 B.34. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 72 182 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 72 183 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 73 185 1. Introduction 187 HTTP semantics ([SEMANTICS]) are used for a broad range of services 188 on the Internet. These semantics have most commonly been used with 189 HTTP/1.1, over a variety of transport and session layers, and with 190 HTTP/2 over TLS. HTTP/3 supports the same semantics over a new 191 transport protocol, QUIC. 193 1.1. Prior versions of HTTP 195 HTTP/1.1 ([HTTP11]) uses whitespace-delimited text fields to convey 196 HTTP messages. While these exchanges are human-readable, using 197 whitespace for message formatting leads to parsing complexity and 198 excessive tolerance of variant behavior. Because HTTP/1.x does not 199 include a multiplexing layer, multiple TCP connections are often used 200 to service requests in parallel. However, that has a negative impact 201 on congestion control and network efficiency, since TCP does not 202 share congestion control across multiple connections. 204 HTTP/2 ([HTTP2]) introduced a binary framing and multiplexing layer 205 to improve latency without modifying the transport layer. However, 206 because the parallel nature of HTTP/2's multiplexing is not visible 207 to TCP's loss recovery mechanisms, a lost or reordered packet causes 208 all active transactions to experience a stall regardless of whether 209 that transaction was directly impacted by the lost packet. 211 1.2. Delegation to QUIC 213 The QUIC transport protocol incorporates stream multiplexing and per- 214 stream flow control, similar to that provided by the HTTP/2 framing 215 layer. By providing reliability at the stream level and congestion 216 control across the entire connection, QUIC has the capability to 217 improve the performance of HTTP compared to a TCP mapping. QUIC also 218 incorporates TLS 1.3 ([TLS13]) at the transport layer, offering 219 comparable confidentiality and integrity to running TLS over TCP, 220 with the improved connection setup latency of TCP Fast Open ([TFO]). 222 This document defines a mapping of HTTP semantics over the QUIC 223 transport protocol, drawing heavily on the design of HTTP/2. While 224 delegating stream lifetime and flow control issues to QUIC, a similar 225 binary framing is used on each stream. Some HTTP/2 features are 226 subsumed by QUIC, while other features are implemented atop QUIC. 228 QUIC is described in [QUIC-TRANSPORT]. For a full description of 229 HTTP/2, see [HTTP2]. 231 2. HTTP/3 Protocol Overview 233 HTTP/3 provides a transport for HTTP semantics using the QUIC 234 transport protocol and an internal framing layer similar to HTTP/2. 236 Once a client knows that an HTTP/3 server exists at a certain 237 endpoint, it opens a QUIC connection. QUIC provides protocol 238 negotiation, stream-based multiplexing, and flow control. Discovery 239 of an HTTP/3 endpoint is described in Section 3.1. 241 Within each stream, the basic unit of HTTP/3 communication is a frame 242 (Section 7.2). Each frame type serves a different purpose. For 243 example, HEADERS and DATA frames form the basis of HTTP requests and 244 responses (Section 4.1). 246 Multiplexing of requests is performed using the QUIC stream 247 abstraction, described in Section 2 of [QUIC-TRANSPORT]. Each 248 request-response pair consumes a single QUIC stream. Streams are 249 independent of each other, so one stream that is blocked or suffers 250 packet loss does not prevent progress on other streams. 252 Server push is an interaction mode introduced in HTTP/2 ([HTTP2]) 253 that permits a server to push a request-response exchange to a client 254 in anticipation of the client making the indicated request. This 255 trades off network usage against a potential latency gain. Several 256 HTTP/3 frames are used to manage server push, such as PUSH_PROMISE, 257 MAX_PUSH_ID, and CANCEL_PUSH. 259 As in HTTP/2, request and response fields are compressed for 260 transmission. Because HPACK ([HPACK]) relies on in-order 261 transmission of compressed field sections (a guarantee not provided 262 by QUIC), HTTP/3 replaces HPACK with QPACK ([QPACK]). QPACK uses 263 separate unidirectional streams to modify and track field table 264 state, while encoded field sections refer to the state of the table 265 without modifying it. 267 2.1. Document Organization 269 The following sections provide a detailed overview of the lifecycle 270 of an HTTP/3 connection: 272 * Connection Setup and Management (Section 3) covers how an HTTP/3 273 endpoint is discovered and an HTTP/3 connection is established. 275 * HTTP Request Lifecycle (Section 4) describes how HTTP semantics 276 are expressed using frames. 278 * Connection Closure (Section 5) describes how HTTP/3 connections 279 are terminated, either gracefully or abruptly. 281 The details of the wire protocol and interactions with the transport 282 are described in subsequent sections: 284 * Stream Mapping and Usage (Section 6) describes the way QUIC 285 streams are used. 287 * HTTP Framing Layer (Section 7) describes the frames used on most 288 streams. 290 * Error Handling (Section 8) describes how error conditions are 291 handled and expressed, either on a particular stream or for the 292 connection as a whole. 294 Additional resources are provided in the final sections: 296 * Extensions to HTTP/3 (Section 9) describes how new capabilities 297 can be added in future documents. 299 * A more detailed comparison between HTTP/2 and HTTP/3 can be found 300 in Appendix A. 302 2.2. Conventions and Terminology 304 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 305 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 306 "OPTIONAL" in this document are to be interpreted as described in 307 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 308 capitals, as shown here. 310 This document uses the variable-length integer encoding from 311 [QUIC-TRANSPORT]. 313 The following terms are used: 315 abort: An abrupt termination of a connection or stream, possibly due 316 to an error condition. 318 client: The endpoint that initiates an HTTP/3 connection. Clients 319 send HTTP requests and receive HTTP responses. 321 connection: A transport-layer connection between two endpoints, 322 using QUIC as the transport protocol. 324 connection error: An error that affects the entire HTTP/3 325 connection. 327 endpoint: Either the client or server of the connection. 329 frame: The smallest unit of communication on a stream in HTTP/3, 330 consisting of a header and a variable-length sequence of bytes 331 structured according to the frame type. Protocol elements called 332 "frames" exist in both this document and [QUIC-TRANSPORT]. Where 333 frames from [QUIC-TRANSPORT] are referenced, the frame name will 334 be prefaced with "QUIC." For example, "QUIC CONNECTION_CLOSE 335 frames." References without this preface refer to frames defined 336 in Section 7.2. 338 HTTP/3 connection: A QUIC connection where the negotiated 339 application protocol is HTTP/3. 341 peer: An endpoint. When discussing a particular endpoint, "peer" 342 refers to the endpoint that is remote to the primary subject of 343 discussion. 345 receiver: An endpoint that is receiving frames. 347 sender: An endpoint that is transmitting frames. 349 server: The endpoint that accepts an HTTP/3 connection. Servers 350 receive HTTP requests and send HTTP responses. 352 stream: A bidirectional or unidirectional bytestream provided by the 353 QUIC transport. All streams within an HTTP/3 connection can be 354 considered "HTTP/3 streams," but multiple stream types are defined 355 within HTTP/3. 357 stream error: An application-level error on the individual stream. 359 The term "payload data" is defined in Section 6.4 of [SEMANTICS]. 361 Finally, the terms "resource", "message", "user agent", "origin 362 server", "gateway", "intermediary", "proxy", and "tunnel" are defined 363 in Section 3 of [SEMANTICS]. 365 Packet diagrams in this document use the format defined in 366 Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of 367 fields. 369 3. Connection Setup and Management 371 3.1. Discovering an HTTP/3 Endpoint 373 HTTP relies on the notion of an authoritative response: a response 374 that has been determined to be the most appropriate response for that 375 request given the state of the target resource at the time of 376 response message origination by (or at the direction of) the origin 377 server identified within the target URI. Locating an authoritative 378 server for an HTTP URL is discussed in Section 4.3 of [SEMANTICS]. 380 The "https" scheme associates authority with possession of a 381 certificate that the client considers to be trustworthy for the host 382 identified by the authority component of the URL. 384 If a server presents a valid certificate and proof that it controls 385 the corresponding private key, then a client will accept a secured 386 TLS session with that server as being authoritative for all origins 387 with the "https" scheme and a host identified in the certificate. 388 The host must be listed either as the CN field of the certificate 389 subject or as a dNSName in the subjectAltName field of the 390 certificate; see [RFC6125]. For a host that is an IP address, the 391 client MUST verify that the address appears as an iPAddress in the 392 subjectAltName field of the certificate. 394 If the hostname or address is not present in the certificate, the 395 client MUST NOT consider the server authoritative for origins 396 containing that hostname or address. See Section 4.3 of [SEMANTICS] 397 for more detail on authoritative access. 399 A client MAY attempt access to a resource with an "https" URI by 400 resolving the host identifier to an IP address, establishing a QUIC 401 connection to that address on the indicated port, and sending an 402 HTTP/3 request message targeting the URI to the server over that 403 secured connection. Unless some other mechanism is used to select 404 HTTP/3, the token "h3" is used in the Application Layer Protocol 405 Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake. 407 Connectivity problems (e.g., blocking UDP) can result in QUIC 408 connection establishment failure; clients SHOULD attempt to use TCP- 409 based versions of HTTP in this case. 411 Servers MAY serve HTTP/3 on any UDP port; an alternative service 412 advertisement always includes an explicit port, and URLs contain 413 either an explicit port or a default port associated with the scheme. 415 3.1.1. HTTP Alternative Services 417 An HTTP origin advertises the availability of an equivalent HTTP/3 418 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 419 ALTSVC frame ([ALTSVC]), using the "h3" ALPN token. 421 For example, an origin could indicate in an HTTP response that HTTP/3 422 was available on UDP port 50781 at the same hostname by including the 423 following header field: 425 Alt-Svc: h3=":50781" 427 On receipt of an Alt-Svc record indicating HTTP/3 support, a client 428 MAY attempt to establish a QUIC connection to the indicated host and 429 port; if this connection is successful, the client can send HTTP 430 requests using the mapping described in this document. 432 3.1.2. Other Schemes 434 Although HTTP is independent of the transport protocol, the "http" 435 scheme associates authority with the ability to receive TCP 436 connections on the indicated port of whatever host is identified 437 within the authority component. Because HTTP/3 does not use TCP, 438 HTTP/3 cannot be used for direct access to the authoritative server 439 for a resource identified by an "http" URI. However, protocol 440 extensions such as [ALTSVC] permit the authoritative server to 441 identify other services that are also authoritative and that might be 442 reachable over HTTP/3. 444 Prior to making requests for an origin whose scheme is not "https", 445 the client MUST ensure the server is willing to serve that scheme. 446 For origins whose scheme is "http", an experimental method to 447 accomplish this is described in [RFC8164]. Other mechanisms might be 448 defined for various schemes in the future. 450 3.2. Connection Establishment 452 HTTP/3 relies on QUIC version 1 as the underlying transport. The use 453 of other QUIC transport versions with HTTP/3 MAY be defined by future 454 specifications. 456 QUIC version 1 uses TLS version 1.3 or greater as its handshake 457 protocol. HTTP/3 clients MUST support a mechanism to indicate the 458 target host to the server during the TLS handshake. If the server is 459 identified by a DNS name, clients MUST send the Server Name 460 Indication (SNI; [RFC6066]) TLS extension unless an alternative 461 mechanism to indicate the target host is used. 463 QUIC connections are established as described in [QUIC-TRANSPORT]. 464 During connection establishment, HTTP/3 support is indicated by 465 selecting the ALPN token "h3" in the TLS handshake. Support for 466 other application-layer protocols MAY be offered in the same 467 handshake. 469 While connection-level options pertaining to the core QUIC protocol 470 are set in the initial crypto handshake, HTTP/3-specific settings are 471 conveyed in the SETTINGS frame. After the QUIC connection is 472 established, a SETTINGS frame (Section 7.2.4) MUST be sent by each 473 endpoint as the initial frame of their respective HTTP control 474 stream; see Section 6.2.1. 476 3.3. Connection Reuse 478 HTTP/3 connections are persistent across multiple requests. For best 479 performance, it is expected that clients will not close connections 480 until it is determined that no further communication with a server is 481 necessary (for example, when a user navigates away from a particular 482 web page) or until the server closes the connection. 484 Once a connection exists to a server endpoint, this connection MAY be 485 reused for requests with multiple different URI authority components. 486 Clients SHOULD NOT open more than one HTTP/3 connection to a given 487 host and port pair, where the host is derived from a URI, a selected 488 alternative service ([ALTSVC]), or a configured proxy. A client MAY 489 open multiple HTTP/3 connections to the same IP address and UDP port 490 using different transport or TLS configurations but SHOULD avoid 491 creating multiple connections with the same configuration. 493 Servers are encouraged to maintain open HTTP/3 connections for as 494 long as possible but are permitted to terminate idle connections if 495 necessary. When either endpoint chooses to close the HTTP/3 496 connection, the terminating endpoint SHOULD first send a GOAWAY frame 497 (Section 5.2) so that both endpoints can reliably determine whether 498 previously sent frames have been processed and gracefully complete or 499 terminate any necessary remaining tasks. 501 A server that does not wish clients to reuse HTTP/3 connections for a 502 particular origin can indicate that it is not authoritative for a 503 request by sending a 421 (Misdirected Request) status code in 504 response to the request; see Section 9.1.2 of [HTTP2]. 506 4. HTTP Request Lifecycle 508 4.1. HTTP Message Exchanges 510 A client sends an HTTP request on a request stream, which is a 511 client-initiated bidirectional QUIC stream; see Section 6.1. A 512 client MUST send only a single request on a given stream. A server 513 sends zero or more interim HTTP responses on the same stream as the 514 request, followed by a single final HTTP response, as detailed below. 515 See Section 15 of [SEMANTICS] for a description of interim and final 516 HTTP responses. 518 Pushed responses are sent on a server-initiated unidirectional QUIC 519 stream; see Section 6.2.2. A server sends zero or more interim HTTP 520 responses, followed by a single final HTTP response, in the same 521 manner as a standard response. Push is described in more detail in 522 Section 4.4. 524 On a given stream, receipt of multiple requests or receipt of an 525 additional HTTP response following a final HTTP response MUST be 526 treated as malformed (Section 4.1.3). 528 An HTTP message (request or response) consists of: 530 1. the header field section, sent as a single HEADERS frame (see 531 Section 7.2.2), 533 2. optionally, the payload data, if present, sent as a series of 534 DATA frames (see Section 7.2.1), and 536 3. optionally, the trailer field section, if present, sent as a 537 single HEADERS frame. 539 Header and trailer field sections are described in Sections 6.3 and 540 6.5 of [SEMANTICS]; the payload data is described in Section 6.4 of 541 [SEMANTICS]. 543 Receipt of an invalid sequence of frames MUST be treated as a 544 connection error of type H3_FRAME_UNEXPECTED; see Section 8. In 545 particular, a DATA frame before any HEADERS frame, or a HEADERS or 546 DATA frame after the trailing HEADERS frame is considered invalid. 547 Other frame types, especially unknown frame types, might be permitted 548 subject to their own rules; see Section 9. 550 A server MAY send one or more PUSH_PROMISE frames (Section 7.2.5) 551 before, after, or interleaved with the frames of a response message. 552 These PUSH_PROMISE frames are not part of the response; see 553 Section 4.4 for more details. PUSH_PROMISE frames are not permitted 554 on push streams; a pushed response that includes PUSH_PROMISE frames 555 MUST be treated as a connection error of type H3_FRAME_UNEXPECTED; 556 see Section 8. 558 Frames of unknown types (Section 9), including reserved frames 559 (Section 7.2.8) MAY be sent on a request or push stream before, 560 after, or interleaved with other frames described in this section. 562 The HEADERS and PUSH_PROMISE frames might reference updates to the 563 QPACK dynamic table. While these updates are not directly part of 564 the message exchange, they must be received and processed before the 565 message can be consumed. See Section 4.1.1 for more details. 567 The "chunked" transfer encoding defined in Section 7.1 of [HTTP11] 568 MUST NOT be used. 570 A response MAY consist of multiple messages when and only when one or 571 more interim responses (1xx; see Section 15.2 of [SEMANTICS]) precede 572 a final response to the same request. Interim responses do not 573 contain payload data or trailers. 575 An HTTP request/response exchange fully consumes a client-initiated 576 bidirectional QUIC stream. After sending a request, a client MUST 577 close the stream for sending. Unless using the CONNECT method (see 578 Section 4.2), clients MUST NOT make stream closure dependent on 579 receiving a response to their request. After sending a final 580 response, the server MUST close the stream for sending. At this 581 point, the QUIC stream is fully closed. 583 When a stream is closed, this indicates the end of the final HTTP 584 message. Because some messages are large or unbounded, endpoints 585 SHOULD begin processing partial HTTP messages once enough of the 586 message has been received to make progress. If a client-initiated 587 stream terminates without enough of the HTTP message to provide a 588 complete response, the server SHOULD abort its response with the 589 error code H3_REQUEST_INCOMPLETE; see Section 8. 591 A server can send a complete response prior to the client sending an 592 entire request if the response does not depend on any portion of the 593 request that has not been sent and received. When the server does 594 not need to receive the remainder of the request, it MAY abort 595 reading the request stream, send a complete response, and cleanly 596 close the sending part of the stream. The error code H3_NO_ERROR 597 SHOULD be used when requesting that the client stop sending on the 598 request stream. Clients MUST NOT discard complete responses as a 599 result of having their request terminated abruptly, though clients 600 can always discard responses at their discretion for other reasons. 601 If the server sends a partial or complete response but does not abort 602 reading the request, clients SHOULD continue sending the body of the 603 request and close the stream normally. 605 4.1.1. Field Formatting and Compression 607 HTTP messages carry metadata as a series of key-value pairs called 608 HTTP fields; see Sections 6.3 and 6.5 of [SEMANTICS]. For a listing 609 of registered HTTP fields, see the "Hypertext Transfer Protocol 610 (HTTP) Field Name Registry" maintained at 611 https://www.iana.org/assignments/http-fields/. 613 *Note:* This registry will not exist until [SEMANTICS] is 614 approved. *RFC Editor*, please remove this note prior to 615 publication. 617 As in previous versions of HTTP, field names are strings containing a 618 subset of ASCII characters that are compared in a case-insensitive 619 fashion. Properties of HTTP field names and values are discussed in 620 more detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters 621 in field names MUST be converted to lowercase prior to their 622 encoding. A request or response containing uppercase characters in 623 field names MUST be treated as malformed (Section 4.1.3). 625 Like HTTP/2, HTTP/3 does not use the Connection header field to 626 indicate connection-specific fields; in this protocol, connection- 627 specific metadata is conveyed by other means. An endpoint MUST NOT 628 generate an HTTP/3 field section containing connection-specific 629 fields; any message containing connection-specific fields MUST be 630 treated as malformed (Section 4.1.3). 632 The only exception to this is the TE header field, which MAY be 633 present in an HTTP/3 request header; when it is, it MUST NOT contain 634 any value other than "trailers". 636 This means that an intermediary transforming an HTTP/1.x message to 637 HTTP/3 will need to remove any fields nominated by the Connection 638 field, along with the Connection field itself. Such intermediaries 639 SHOULD also remove other connection-specific fields, such as Keep- 640 Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they 641 are not nominated by the Connection field. 643 4.1.1.1. Pseudo-Header Fields 645 Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where 646 the field name begins with the ':' character (ASCII 0x3a). These 647 pseudo-header fields convey the target URI, the method of the 648 request, and the status code for the response. 650 Pseudo-header fields are not HTTP fields. Endpoints MUST NOT 651 generate pseudo-header fields other than those defined in this 652 document; however, an extension could negotiate a modification of 653 this restriction; see Section 9. 655 Pseudo-header fields are only valid in the context in which they are 656 defined. Pseudo-header fields defined for requests MUST NOT appear 657 in responses; pseudo-header fields defined for responses MUST NOT 658 appear in requests. Pseudo-header fields MUST NOT appear in 659 trailers. Endpoints MUST treat a request or response that contains 660 undefined or invalid pseudo-header fields as malformed 661 (Section 4.1.3). 663 All pseudo-header fields MUST appear in the header field section 664 before regular header fields. Any request or response that contains 665 a pseudo-header field that appears in a header field section after a 666 regular header field MUST be treated as malformed (Section 4.1.3). 668 The following pseudo-header fields are defined for requests: 670 ":method": Contains the HTTP method (Section 9 of [SEMANTICS]) 672 ":scheme": Contains the scheme portion of the target URI 673 (Section 3.1 of [URI]) 675 ":scheme" is not restricted to "http" and "https" schemed URIs. A 676 proxy or gateway can translate requests for non-HTTP schemes, 677 enabling the use of HTTP to interact with non-HTTP services. 679 ":authority": Contains the authority portion of the target URI 680 (Section 3.2 of [URI]). The authority MUST NOT include the 681 deprecated "userinfo" subcomponent for "http" or "https" schemed 682 URIs. 684 To ensure that the HTTP/1.1 request line can be reproduced 685 accurately, this pseudo-header field MUST be omitted when 686 translating from an HTTP/1.1 request that has a request target in 687 origin or asterisk form; see Section 3.2 of [HTTP11]. Clients 688 that generate HTTP/3 requests directly SHOULD use the ":authority" 689 pseudo-header field instead of the Host field. An intermediary 690 that converts an HTTP/3 request to HTTP/1.1 MUST create a Host 691 field if one is not present in a request by copying the value of 692 the ":authority" pseudo-header field. 694 ":path": Contains the path and query parts of the target URI (the 695 "path-absolute" production and optionally a '?' character followed 696 by the "query" production; see Sections 3.3 and 3.4 of [URI]. A 697 request in asterisk form includes the value '*' for the ":path" 698 pseudo-header field. 700 This pseudo-header field MUST NOT be empty for "http" or "https" 701 URIs; "http" or "https" URIs that do not contain a path component 702 MUST include a value of '/'. The exception to this rule is an 703 OPTIONS request for an "http" or "https" URI that does not include 704 a path component; these MUST include a ":path" pseudo-header field 705 with a value of '*'; see Section 3.2.4 of [HTTP11]. 707 All HTTP/3 requests MUST include exactly one value for the ":method", 708 ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT 709 request; see Section 4.2. 711 If the ":scheme" pseudo-header field identifies a scheme that has a 712 mandatory authority component (including "http" and "https"), the 713 request MUST contain either an ":authority" pseudo-header field or a 714 "Host" header field. If these fields are present, they MUST NOT be 715 empty. If both fields are present, they MUST contain the same value. 716 If the scheme does not have a mandatory authority component and none 717 is provided in the request target, the request MUST NOT contain the 718 ":authority" pseudo-header or "Host" header fields. 720 An HTTP request that omits mandatory pseudo-header fields or contains 721 invalid values for those pseudo-header fields is malformed 722 (Section 4.1.3). 724 HTTP/3 does not define a way to carry the version identifier that is 725 included in the HTTP/1.1 request line. 727 For responses, a single ":status" pseudo-header field is defined that 728 carries the HTTP status code; see Section 15 of [SEMANTICS]. This 729 pseudo-header field MUST be included in all responses; otherwise, the 730 response is malformed (Section 4.1.3). 732 HTTP/3 does not define a way to carry the version or reason phrase 733 that is included in an HTTP/1.1 status line. 735 4.1.1.2. Field Compression 737 HTTP/3 uses QPACK field compression as described in [QPACK], a 738 variation of HPACK that allows the flexibility to avoid compression- 739 induced head-of-line blocking. See that document for additional 740 details. 742 To allow for better compression efficiency, the "Cookie" field 743 ([RFC6265]) MAY be split into separate field lines, each with one or 744 more cookie-pairs, before compression. If a decompressed field 745 section contains multiple cookie field lines, these MUST be 746 concatenated into a single octet string using the two-octet delimiter 747 of 0x3b, 0x20 (the ASCII string "; ") before being passed into a 748 context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, 749 or a generic HTTP server application. 751 4.1.1.3. Header Size Constraints 753 An HTTP/3 implementation MAY impose a limit on the maximum size of 754 the message header it will accept on an individual HTTP message. A 755 server that receives a larger header section than it is willing to 756 handle can send an HTTP 431 (Request Header Fields Too Large) status 757 code ([RFC6585]). A client can discard responses that it cannot 758 process. The size of a field list is calculated based on the 759 uncompressed size of fields, including the length of the name and 760 value in bytes plus an overhead of 32 bytes for each field. 762 If an implementation wishes to advise its peer of this limit, it can 763 be conveyed as a number of bytes in the 764 SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that 765 has received this parameter SHOULD NOT send an HTTP message header 766 that exceeds the indicated size, as the peer will likely refuse to 767 process it. However, an HTTP message can traverse one or more 768 intermediaries before reaching the origin server; see Section 3.6 of 769 [SEMANTICS]. Because this limit is applied separately by each 770 implementation which processes the message, messages below this limit 771 are not guaranteed to be accepted. 773 4.1.2. Request Cancellation and Rejection 775 Once a request stream has been opened, the request MAY be cancelled 776 by either endpoint. Clients cancel requests if the response is no 777 longer of interest; servers cancel requests if they are unable to or 778 choose not to respond. When possible, it is RECOMMENDED that servers 779 send an HTTP response with an appropriate status code rather than 780 canceling a request it has already begun processing. 782 Implementations SHOULD cancel requests by abruptly terminating any 783 directions of a stream that are still open. This means resetting the 784 sending parts of streams and aborting reading on receiving parts of 785 streams; see Section 2.4 of [QUIC-TRANSPORT]. 787 When the server cancels a request without performing any application 788 processing, the request is considered "rejected." The server SHOULD 789 abort its response stream with the error code H3_REQUEST_REJECTED. 790 In this context, "processed" means that some data from the stream was 791 passed to some higher layer of software that might have taken some 792 action as a result. The client can treat requests rejected by the 793 server as though they had never been sent at all, thereby allowing 794 them to be retried later. 796 Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests 797 that were partially or fully processed. When a server abandons a 798 response after partial processing, it SHOULD abort its response 799 stream with the error code H3_REQUEST_CANCELLED. 801 Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel 802 requests. Upon receipt of this error code, a server MAY abruptly 803 terminate the response using the error code H3_REQUEST_REJECTED if no 804 processing was performed. Clients MUST NOT use the 805 H3_REQUEST_REJECTED error code, except when a server has requested 806 closure of the request stream with this error code. 808 If a stream is canceled after receiving a complete response, the 809 client MAY ignore the cancellation and use the response. However, if 810 a stream is cancelled after receiving a partial response, the 811 response SHOULD NOT be used. Only idempotent actions such as GET, 812 PUT, or DELETE can be safely retried; a client SHOULD NOT 813 automatically retry a request with a non-idempotent method unless it 814 has some means to know that the request semantics are idempotent 815 independent of the method or some means to detect that the original 816 request was never applied. See Section 9.2.2 of [SEMANTICS] for more 817 details. 819 4.1.3. Malformed Requests and Responses 821 A malformed request or response is one that is an otherwise valid 822 sequence of frames but is invalid due to: 824 * the presence of prohibited fields or pseudo-header fields, 826 * the absence of mandatory pseudo-header fields, 828 * invalid values for pseudo-header fields, 830 * pseudo-header fields after fields, 832 * an invalid sequence of HTTP messages, 834 * the inclusion of uppercase field names, or 836 * the inclusion of invalid characters in field names or values. 838 A request or response that includes payload data can include a 839 Content-Length header field. A request or response is also malformed 840 if the value of a Content-Length header field does not equal the sum 841 of the DATA frame lengths that form the payload data. A response 842 that is defined to have no payload, as described in Section 6.4 of 843 [SEMANTICS], can have a non-zero Content-Length field, even though no 844 content is included in DATA frames. 846 Intermediaries that process HTTP requests or responses (i.e., any 847 intermediary not acting as a tunnel) MUST NOT forward a malformed 848 request or response. Malformed requests or responses that are 849 detected MUST be treated as a stream error (Section 8) of type 850 H3_MESSAGE_ERROR. 852 For malformed requests, a server MAY send an HTTP response indicating 853 the error prior to closing or resetting the stream. Clients MUST NOT 854 accept a malformed response. Note that these requirements are 855 intended to protect against several types of common attacks against 856 HTTP; they are deliberately strict because being permissive can 857 expose implementations to these vulnerabilities. 859 4.2. The CONNECT Method 861 The CONNECT method requests that the recipient establish a tunnel to 862 the destination origin server identified by the request-target; see 863 Section 9.3.6 of [SEMANTICS]. It is primarily used with HTTP proxies 864 to establish a TLS session with an origin server for the purposes of 865 interacting with "https" resources. 867 In HTTP/1.x, CONNECT is used to convert an entire HTTP connection 868 into a tunnel to a remote host. In HTTP/2 and HTTP/3, the CONNECT 869 method is used to establish a tunnel over a single stream. 871 A CONNECT request MUST be constructed as follows: 873 * The ":method" pseudo-header field is set to "CONNECT" 875 * The ":scheme" and ":path" pseudo-header fields are omitted 877 * The ":authority" pseudo-header field contains the host and port to 878 connect to (equivalent to the authority-form of the request-target 879 of CONNECT requests; see Section 3.2.3 of [HTTP11]) 881 The request stream remains open at the end of the request to carry 882 the data to be transferred. A CONNECT request that does not conform 883 to these restrictions is malformed; see Section 4.1.3. 885 A proxy that supports CONNECT establishes a TCP connection 886 ([RFC0793]) to the server identified in the ":authority" pseudo- 887 header field. Once this connection is successfully established, the 888 proxy sends a HEADERS frame containing a 2xx series status code to 889 the client, as defined in Section 15.3 of [SEMANTICS]. 891 All DATA frames on the stream correspond to data sent or received on 892 the TCP connection. The payload of any DATA frame sent by the client 893 is transmitted by the proxy to the TCP server; data received from the 894 TCP server is packaged into DATA frames by the proxy. Note that the 895 size and number of TCP segments is not guaranteed to map predictably 896 to the size and number of HTTP DATA or QUIC STREAM frames. 898 Once the CONNECT method has completed, only DATA frames are permitted 899 to be sent on the stream. Extension frames MAY be used if 900 specifically permitted by the definition of the extension. Receipt 901 of any other known frame type MUST be treated as a connection error 902 of type H3_FRAME_UNEXPECTED; see Section 8. 904 The TCP connection can be closed by either peer. When the client 905 ends the request stream (that is, the receive stream at the proxy 906 enters the "Data Recvd" state), the proxy will set the FIN bit on its 907 connection to the TCP server. When the proxy receives a packet with 908 the FIN bit set, it will close the send stream that it sends to the 909 client. TCP connections that remain half-closed in a single 910 direction are not invalid, but are often handled poorly by servers, 911 so clients SHOULD NOT close a stream for sending while they still 912 expect to receive data from the target of the CONNECT. 914 A TCP connection error is signaled by abruptly terminating the 915 stream. A proxy treats any error in the TCP connection, which 916 includes receiving a TCP segment with the RST bit set, as a stream 917 error of type H3_CONNECT_ERROR; see Section 8. Correspondingly, if a 918 proxy detects an error with the stream or the QUIC connection, it 919 MUST close the TCP connection. If the underlying TCP implementation 920 permits it, the proxy SHOULD send a TCP segment with the RST bit set. 922 4.3. HTTP Upgrade 924 HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of 925 [SEMANTICS]) or 101 (Switching Protocols) informational status code 926 (Section 15.2.2 of [SEMANTICS]). 928 4.4. Server Push 930 Server push is an interaction mode that permits a server to push a 931 request-response exchange to a client in anticipation of the client 932 making the indicated request. This trades off network usage against 933 a potential latency gain. HTTP/3 server push is similar to what is 934 described in Section 8.2 of [HTTP2], but uses different mechanisms. 936 Each server push is assigned a unique Push ID by the server. The 937 Push ID is used to refer to the push in various contexts throughout 938 the lifetime of the HTTP/3 connection. 940 The Push ID space begins at zero, and ends at a maximum value set by 941 the MAX_PUSH_ID frame; see Section 7.2.7. In particular, a server is 942 not able to push until after the client sends a MAX_PUSH_ID frame. A 943 client sends MAX_PUSH_ID frames to control the number of pushes that 944 a server can promise. A server SHOULD use Push IDs sequentially, 945 beginning from zero. A client MUST treat receipt of a push stream as 946 a connection error of type H3_ID_ERROR (Section 8) when no 947 MAX_PUSH_ID frame has been sent or when the stream references a Push 948 ID that is greater than the maximum Push ID. 950 The Push ID is used in one or more PUSH_PROMISE frames 951 (Section 7.2.5) that carry the header section of the request message. 952 These frames are sent on the request stream that generated the push. 953 This allows the server push to be associated with a client request. 954 When the same Push ID is promised on multiple request streams, the 955 decompressed request field sections MUST contain the same fields in 956 the same order, and both the name and the value in each field MUST be 957 identical. 959 The Push ID is then included with the push stream that ultimately 960 fulfills those promises; see Section 6.2.2. The push stream 961 identifies the Push ID of the promise that it fulfills, then contains 962 a response to the promised request as described in Section 4.1. 964 Finally, the Push ID can be used in CANCEL_PUSH frames; see 965 Section 7.2.3. Clients use this frame to indicate they do not wish 966 to receive a promised resource. Servers use this frame to indicate 967 they will not be fulfilling a previous promise. 969 Not all requests can be pushed. A server MAY push requests that have 970 the following properties: 972 * cacheable; see Section 9.2.3 of [SEMANTICS] 974 * safe; see Section 9.2.1 of [SEMANTICS] 976 * does not include a request body or trailer section 978 The server MUST include a value in the ":authority" pseudo-header 979 field for which the server is authoritative; see Section 3.3. 981 Clients SHOULD send a CANCEL_PUSH frame upon receipt of a 982 PUSH_PROMISE frame carrying a request that is not cacheable, is not 983 known to be safe, that indicates the presence of a request body, or 984 for which it does not consider the server authoritative. Any 985 corresponding responses MUST NOT be used or cached. 987 Each pushed response is associated with one or more client requests. 988 The push is associated with the request stream on which the 989 PUSH_PROMISE frame was received. The same server push can be 990 associated with additional client requests using a PUSH_PROMISE frame 991 with the same Push ID on multiple request streams. These 992 associations do not affect the operation of the protocol, but MAY be 993 considered by user agents when deciding how to use pushed resources. 995 Ordering of a PUSH_PROMISE frame in relation to certain parts of the 996 response is important. The server SHOULD send PUSH_PROMISE frames 997 prior to sending HEADERS or DATA frames that reference the promised 998 responses. This reduces the chance that a client requests a resource 999 that will be pushed by the server. 1001 Due to reordering, push stream data can arrive before the 1002 corresponding PUSH_PROMISE frame. When a client receives a new push 1003 stream with an as-yet-unknown Push ID, both the associated client 1004 request and the pushed request header fields are unknown. The client 1005 can buffer the stream data in expectation of the matching 1006 PUSH_PROMISE. The client can use stream flow control (see section 1007 4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server may 1008 commit to the pushed stream. 1010 Push stream data can also arrive after a client has canceled a push. 1011 In this case, the client can abort reading the stream with an error 1012 code of H3_REQUEST_CANCELLED. This asks the server not to transfer 1013 additional data and indicates that it will be discarded upon receipt. 1015 Pushed responses that are cacheable (see Section 3 of [CACHING]) can 1016 be stored by the client, if it implements an HTTP cache. Pushed 1017 responses are considered successfully validated on the origin server 1018 (e.g., if the "no-cache" cache response directive is present; see 1019 Section 5.2.2.3 of [CACHING]) at the time the pushed response is 1020 received. 1022 Pushed responses that are not cacheable MUST NOT be stored by any 1023 HTTP cache. They MAY be made available to the application 1024 separately. 1026 5. Connection Closure 1028 Once established, an HTTP/3 connection can be used for many requests 1029 and responses over time until the connection is closed. Connection 1030 closure can happen in any of several different ways. 1032 5.1. Idle Connections 1034 Each QUIC endpoint declares an idle timeout during the handshake. If 1035 the QUIC connection remains idle (no packets received) for longer 1036 than this duration, the peer will assume that the connection has been 1037 closed. HTTP/3 implementations will need to open a new HTTP/3 1038 connection for new requests if the existing connection has been idle 1039 for longer than the idle timeout negotiated during the QUIC 1040 handshake, and SHOULD do so if approaching the idle timeout; see 1041 Section 10.1 of [QUIC-TRANSPORT]. 1043 HTTP clients are expected to request that the transport keep 1044 connections open while there are responses outstanding for requests 1045 or server pushes, as described in Section 10.1.2 of [QUIC-TRANSPORT]. 1046 If the client is not expecting a response from the server, allowing 1047 an idle connection to time out is preferred over expending effort 1048 maintaining a connection that might not be needed. A gateway MAY 1049 maintain connections in anticipation of need rather than incur the 1050 latency cost of connection establishment to servers. Servers SHOULD 1051 NOT actively keep connections open. 1053 5.2. Connection Shutdown 1055 Even when a connection is not idle, either endpoint can decide to 1056 stop using the connection and initiate a graceful connection close. 1057 Endpoints initiate the graceful shutdown of an HTTP/3 connection by 1058 sending a GOAWAY frame (Section 7.2.6). The GOAWAY frame contains an 1059 identifier that indicates to the receiver the range of requests or 1060 pushes that were or might be processed in this connection. The 1061 server sends a client-initiated bidirectional Stream ID; the client 1062 sends a Push ID (Section 4.4). Requests or pushes with the indicated 1063 identifier or greater are rejected (Section 4.1.2) by the sender of 1064 the GOAWAY. This identifier MAY be zero if no requests or pushes 1065 were processed. 1067 The information in the GOAWAY frame enables a client and server to 1068 agree on which requests or pushes were accepted prior to the shutdown 1069 of the HTTP/3 connection. Upon sending a GOAWAY frame, the endpoint 1070 SHOULD explicitly cancel (see Section 4.1.2 and Section 7.2.3) any 1071 requests or pushes that have identifiers greater than or equal to 1072 that indicated, in order to clean up transport state for the affected 1073 streams. The endpoint SHOULD continue to do so as more requests or 1074 pushes arrive. 1076 Endpoints MUST NOT initiate new requests or promise new pushes on the 1077 connection after receipt of a GOAWAY frame from the peer. Clients 1078 MAY establish a new connection to send additional requests. 1080 Some requests or pushes might already be in transit: 1082 * Upon receipt of a GOAWAY frame, if the client has already sent 1083 requests with a Stream ID greater than or equal to the identifier 1084 contained in the GOAWAY frame, those requests will not be 1085 processed. Clients can safely retry unprocessed requests on a 1086 different HTTP connection. A client that is unable to retry 1087 requests loses all requests that are in flight when the server 1088 closes the connection. 1090 Requests on Stream IDs less than the Stream ID in a GOAWAY frame 1091 from the server might have been processed; their status cannot be 1092 known until a response is received, the stream is reset 1093 individually, another GOAWAY is received, or the connection 1094 terminates. 1096 Servers MAY reject individual requests on streams below the 1097 indicated ID if these requests were not processed. 1099 * If a server receives a GOAWAY frame after having promised pushes 1100 with a Push ID greater than or equal to the identifier contained 1101 in the GOAWAY frame, those pushes will not be accepted. 1103 Servers SHOULD send a GOAWAY frame when the closing of a connection 1104 is known in advance, even if the advance notice is small, so that the 1105 remote peer can know whether a request has been partially processed 1106 or not. For example, if an HTTP client sends a POST at the same time 1107 that a server closes a QUIC connection, the client cannot know if the 1108 server started to process that POST request if the server does not 1109 send a GOAWAY frame to indicate what streams it might have acted on. 1111 An endpoint MAY send multiple GOAWAY frames indicating different 1112 identifiers, but the identifier in each frame MUST NOT be greater 1113 than the identifier in any previous frame, since clients might 1114 already have retried unprocessed requests on another HTTP connection. 1115 Receiving a GOAWAY containing a larger identifier than previously 1116 received MUST be treated as a connection error of type H3_ID_ERROR; 1117 see Section 8. 1119 An endpoint that is attempting to gracefully shut down a connection 1120 can send a GOAWAY frame with a value set to the maximum possible 1121 value (2^62-4 for servers, 2^62-1 for clients). This ensures that 1122 the peer stops creating new requests or pushes. After allowing time 1123 for any in-flight requests or pushes to arrive, the endpoint can send 1124 another GOAWAY frame indicating which requests or pushes it might 1125 accept before the end of the connection. This ensures that a 1126 connection can be cleanly shut down without losing requests. 1128 A client has more flexibility in the value it chooses for the Push ID 1129 in a GOAWAY that it sends. A value of 2^62 - 1 indicates that the 1130 server can continue fulfilling pushes that have already been 1131 promised. A smaller value indicates the client will reject pushes 1132 with Push IDs greater than or equal to this value. Like the server, 1133 the client MAY send subsequent GOAWAY frames so long as the specified 1134 Push ID is no greater than any previously sent value. 1136 Even when a GOAWAY indicates that a given request or push will not be 1137 processed or accepted upon receipt, the underlying transport 1138 resources still exist. The endpoint that initiated these requests 1139 can cancel them to clean up transport state. 1141 Once all accepted requests and pushes have been processed, the 1142 endpoint can permit the connection to become idle, or MAY initiate an 1143 immediate closure of the connection. An endpoint that completes a 1144 graceful shutdown SHOULD use the H3_NO_ERROR error code when closing 1145 the connection. 1147 If a client has consumed all available bidirectional stream IDs with 1148 requests, the server need not send a GOAWAY frame, since the client 1149 is unable to make further requests. 1151 5.3. Immediate Application Closure 1153 An HTTP/3 implementation can immediately close the QUIC connection at 1154 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 1155 the peer indicating that the application layer has terminated the 1156 connection. The application error code in this frame indicates to 1157 the peer why the connection is being closed. See Section 8 for error 1158 codes that can be used when closing a connection in HTTP/3. 1160 Before closing the connection, a GOAWAY frame MAY be sent to allow 1161 the client to retry some requests. Including the GOAWAY frame in the 1162 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 1163 of the frame being received by clients. 1165 5.4. Transport Closure 1167 For various reasons, the QUIC transport could indicate to the 1168 application layer that the connection has terminated. This might be 1169 due to an explicit closure by the peer, a transport-level error, or a 1170 change in network topology that interrupts connectivity. 1172 If a connection terminates without a GOAWAY frame, clients MUST 1173 assume that any request that was sent, whether in whole or in part, 1174 might have been processed. 1176 6. Stream Mapping and Usage 1178 A QUIC stream provides reliable in-order delivery of bytes, but makes 1179 no guarantees about order of delivery with regard to bytes on other 1180 streams. On the wire, data is framed into QUIC STREAM frames, but 1181 this framing is invisible to the HTTP framing layer. The transport 1182 layer buffers and orders received QUIC STREAM frames, exposing the 1183 data contained within as a reliable byte stream to the application. 1185 Although QUIC permits out-of-order delivery within a stream, HTTP/3 1186 does not make use of this feature. 1188 QUIC streams can be either unidirectional, carrying data only from 1189 initiator to receiver, or bidirectional. Streams can be initiated by 1190 either the client or the server. For more detail on QUIC streams, 1191 see Section 2 of [QUIC-TRANSPORT]. 1193 When HTTP fields and data are sent over QUIC, the QUIC layer handles 1194 most of the stream management. HTTP does not need to do any separate 1195 multiplexing when using QUIC - data sent over a QUIC stream always 1196 maps to a particular HTTP transaction or to the entire HTTP/3 1197 connection context. 1199 6.1. Bidirectional Streams 1201 All client-initiated bidirectional streams are used for HTTP requests 1202 and responses. A bidirectional stream ensures that the response can 1203 be readily correlated with the request. These streams are referred 1204 to as request streams. 1206 This means that the client's first request occurs on QUIC stream 0, 1207 with subsequent requests on stream 4, 8, and so on. In order to 1208 permit these streams to open, an HTTP/3 server SHOULD configure non- 1209 zero minimum values for the number of permitted streams and the 1210 initial stream flow control window. So as to not unnecessarily limit 1211 parallelism, at least 100 requests SHOULD be permitted at a time. 1213 HTTP/3 does not use server-initiated bidirectional streams, though an 1214 extension could define a use for these streams. Clients MUST treat 1215 receipt of a server-initiated bidirectional stream as a connection 1216 error of type H3_STREAM_CREATION_ERROR (Section 8) unless such an 1217 extension has been negotiated. 1219 6.2. Unidirectional Streams 1221 Unidirectional streams, in either direction, are used for a range of 1222 purposes. The purpose is indicated by a stream type, which is sent 1223 as a variable-length integer at the start of the stream. The format 1224 and structure of data that follows this integer is determined by the 1225 stream type. 1227 Unidirectional Stream Header { 1228 Stream Type (i), 1229 } 1231 Figure 1: Unidirectional Stream Header 1233 Two stream types are defined in this document: control streams 1234 (Section 6.2.1) and push streams (Section 6.2.2). [QPACK] defines 1235 two additional stream types. Other stream types can be defined by 1236 extensions to HTTP/3; see Section 9 for more details. Some stream 1237 types are reserved (Section 6.2.3). 1239 The performance of HTTP/3 connections in the early phase of their 1240 lifetime is sensitive to the creation and exchange of data on 1241 unidirectional streams. Endpoints that excessively restrict the 1242 number of streams or the flow control window of these streams will 1243 increase the chance that the remote peer reaches the limit early and 1244 becomes blocked. In particular, implementations should consider that 1245 remote peers may wish to exercise reserved stream behavior 1246 (Section 6.2.3) with some of the unidirectional streams they are 1247 permitted to use. To avoid blocking, the transport parameters sent 1248 by both clients and servers MUST allow the peer to create at least 1249 one unidirectional stream for the HTTP control stream plus the number 1250 of unidirectional streams required by mandatory extensions (three 1251 being the minimum number required for the base HTTP/3 protocol and 1252 QPACK), and SHOULD provide at least 1,024 bytes of flow control 1253 credit to each stream. 1255 Note that an endpoint is not required to grant additional credits to 1256 create more unidirectional streams if its peer consumes all the 1257 initial credits before creating the critical unidirectional streams. 1258 Endpoints SHOULD create the HTTP control stream as well as the 1259 unidirectional streams required by mandatory extensions (such as the 1260 QPACK encoder and decoder streams) first, and then create additional 1261 streams as allowed by their peer. 1263 If the stream header indicates a stream type that is not supported by 1264 the recipient, the remainder of the stream cannot be consumed as the 1265 semantics are unknown. Recipients of unknown stream types MAY abort 1266 reading of the stream with an error code of H3_STREAM_CREATION_ERROR 1267 or a reserved error code (Section 8.1), but MUST NOT consider such 1268 streams to be a connection error of any kind. 1270 Implementations MAY send stream types before knowing whether the peer 1271 supports them. However, stream types that could modify the state or 1272 semantics of existing protocol components, including QPACK or other 1273 extensions, MUST NOT be sent until the peer is known to support them. 1275 A sender can close or reset a unidirectional stream unless otherwise 1276 specified. A receiver MUST tolerate unidirectional streams being 1277 closed or reset prior to the reception of the unidirectional stream 1278 header. 1280 6.2.1. Control Streams 1282 A control stream is indicated by a stream type of 0x00. Data on this 1283 stream consists of HTTP/3 frames, as defined in Section 7.2. 1285 Each side MUST initiate a single control stream at the beginning of 1286 the connection and send its SETTINGS frame as the first frame on this 1287 stream. If the first frame of the control stream is any other frame 1288 type, this MUST be treated as a connection error of type 1289 H3_MISSING_SETTINGS. Only one control stream per peer is permitted; 1290 receipt of a second stream claiming to be a control stream MUST be 1291 treated as a connection error of type H3_STREAM_CREATION_ERROR. The 1292 sender MUST NOT close the control stream, and the receiver MUST NOT 1293 request that the sender close the control stream. If either control 1294 stream is closed at any point, this MUST be treated as a connection 1295 error of type H3_CLOSED_CRITICAL_STREAM. Connection errors are 1296 described in Section 8. 1298 A pair of unidirectional streams is used rather than a single 1299 bidirectional stream. This allows either peer to send data as soon 1300 as it is able. Depending on whether 0-RTT is enabled on the QUIC 1301 connection, either client or server might be able to send stream data 1302 first after the cryptographic handshake completes. 1304 6.2.2. Push Streams 1306 Server push is an optional feature introduced in HTTP/2 that allows a 1307 server to initiate a response before a request has been made. See 1308 Section 4.4 for more details. 1310 A push stream is indicated by a stream type of 0x01, followed by the 1311 Push ID of the promise that it fulfills, encoded as a variable-length 1312 integer. The remaining data on this stream consists of HTTP/3 1313 frames, as defined in Section 7.2, and fulfills a promised server 1314 push by zero or more interim HTTP responses followed by a single 1315 final HTTP response, as defined in Section 4.1. Server push and Push 1316 IDs are described in Section 4.4. 1318 Only servers can push; if a server receives a client-initiated push 1319 stream, this MUST be treated as a connection error of type 1320 H3_STREAM_CREATION_ERROR; see Section 8. 1322 Push Stream Header { 1323 Stream Type (i) = 0x01, 1324 Push ID (i), 1325 } 1327 Figure 2: Push Stream Header 1329 Each Push ID MUST only be used once in a push stream header. If a 1330 push stream header includes a Push ID that was used in another push 1331 stream header, the client MUST treat this as a connection error of 1332 type H3_ID_ERROR; see Section 8. 1334 6.2.3. Reserved Stream Types 1336 Stream types of the format "0x1f * N + 0x21" for non-negative integer 1337 values of N are reserved to exercise the requirement that unknown 1338 types be ignored. These streams have no semantics, and can be sent 1339 when application-layer padding is desired. They MAY also be sent on 1340 connections where no data is currently being transferred. Endpoints 1341 MUST NOT consider these streams to have any meaning upon receipt. 1343 The payload and length of the stream are selected in any manner the 1344 sending implementation chooses. When sending a reserved stream type, 1345 the implementation MAY either terminate the stream cleanly or reset 1346 it. When resetting the stream, either the H3_NO_ERROR error code or 1347 a reserved error code (Section 8.1) SHOULD be used. 1349 7. HTTP Framing Layer 1351 HTTP frames are carried on QUIC streams, as described in Section 6. 1352 HTTP/3 defines three stream types: control stream, request stream, 1353 and push stream. This section describes HTTP/3 frame formats and 1354 their permitted stream types; see Table 1 for an overview. A 1355 comparison between HTTP/2 and HTTP/3 frames is provided in 1356 Appendix A.2. 1358 +==============+================+================+========+=========+ 1359 | Frame | Control Stream | Request | Push | Section | 1360 | | | Stream | Stream | | 1361 +==============+================+================+========+=========+ 1362 | DATA | No | Yes | Yes | Section | 1363 | | | | | 7.2.1 | 1364 +--------------+----------------+----------------+--------+---------+ 1365 | HEADERS | No | Yes | Yes | Section | 1366 | | | | | 7.2.2 | 1367 +--------------+----------------+----------------+--------+---------+ 1368 | CANCEL_PUSH | Yes | No | No | Section | 1369 | | | | | 7.2.3 | 1370 +--------------+----------------+----------------+--------+---------+ 1371 | SETTINGS | Yes (1) | No | No | Section | 1372 | | | | | 7.2.4 | 1373 +--------------+----------------+----------------+--------+---------+ 1374 | PUSH_PROMISE | No | Yes | No | Section | 1375 | | | | | 7.2.5 | 1376 +--------------+----------------+----------------+--------+---------+ 1377 | GOAWAY | Yes | No | No | Section | 1378 | | | | | 7.2.6 | 1379 +--------------+----------------+----------------+--------+---------+ 1380 | MAX_PUSH_ID | Yes | No | No | Section | 1381 | | | | | 7.2.7 | 1382 +--------------+----------------+----------------+--------+---------+ 1383 | Reserved | Yes | Yes | Yes | Section | 1384 | | | | | 7.2.8 | 1385 +--------------+----------------+----------------+--------+---------+ 1387 Table 1: HTTP/3 Frames and Stream Type Overview 1389 Certain frames can only occur as the first frame of a particular 1390 stream type; these are indicated in Table 1 with a (1). Specific 1391 guidance is provided in the relevant section. 1393 Note that, unlike QUIC frames, HTTP/3 frames can span multiple 1394 packets. 1396 7.1. Frame Layout 1398 All frames have the following format: 1400 HTTP/3 Frame Format { 1401 Type (i), 1402 Length (i), 1403 Frame Payload (..), 1404 } 1405 Figure 3: HTTP/3 Frame Format 1407 A frame includes the following fields: 1409 Type: A variable-length integer that identifies the frame type. 1411 Length: A variable-length integer that describes the length in bytes 1412 of the Frame Payload. 1414 Frame Payload: A payload, the semantics of which are determined by 1415 the Type field. 1417 Each frame's payload MUST contain exactly the fields identified in 1418 its description. A frame payload that contains additional bytes 1419 after the identified fields or a frame payload that terminates before 1420 the end of the identified fields MUST be treated as a connection 1421 error of type H3_FRAME_ERROR; see Section 8. 1423 When a stream terminates cleanly, if the last frame on the stream was 1424 truncated, this MUST be treated as a connection error of type 1425 H3_FRAME_ERROR; see Section 8. Streams that terminate abruptly may 1426 be reset at any point in a frame. 1428 7.2. Frame Definitions 1430 7.2.1. DATA 1432 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1433 bytes associated with HTTP request or response payload data. 1435 DATA frames MUST be associated with an HTTP request or response. If 1436 a DATA frame is received on a control stream, the recipient MUST 1437 respond with a connection error of type H3_FRAME_UNEXPECTED; see 1438 Section 8. 1440 DATA Frame { 1441 Type (i) = 0x0, 1442 Length (i), 1443 Data (..), 1444 } 1446 Figure 4: DATA Frame 1448 7.2.2. HEADERS 1450 The HEADERS frame (type=0x1) is used to carry an HTTP field section, 1451 encoded using QPACK. See [QPACK] for more details. 1453 HEADERS Frame { 1454 Type (i) = 0x1, 1455 Length (i), 1456 Encoded Field Section (..), 1457 } 1459 Figure 5: HEADERS Frame 1461 HEADERS frames can only be sent on request or push streams. If a 1462 HEADERS frame is received on a control stream, the recipient MUST 1463 respond with a connection error (Section 8) of type 1464 H3_FRAME_UNEXPECTED. 1466 7.2.3. CANCEL_PUSH 1468 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 1469 server push prior to the push stream being received. The CANCEL_PUSH 1470 frame identifies a server push by Push ID (see Section 4.4), encoded 1471 as a variable-length integer. 1473 When a client sends CANCEL_PUSH, it is indicating that it does not 1474 wish to receive the promised resource. The server SHOULD abort 1475 sending the resource, but the mechanism to do so depends on the state 1476 of the corresponding push stream. If the server has not yet created 1477 a push stream, it does not create one. If the push stream is open, 1478 the server SHOULD abruptly terminate that stream. If the push stream 1479 has already ended, the server MAY still abruptly terminate the stream 1480 or MAY take no action. 1482 A server sends CANCEL_PUSH to indicate that it will not be fulfilling 1483 a promise which was previously sent. The client cannot expect the 1484 corresponding promise to be fulfilled, unless it has already received 1485 and processed the promised response. Regardless of whether a push 1486 stream has been opened, a server SHOULD send a CANCEL_PUSH frame when 1487 it determines that promise will not be fulfilled. If a stream has 1488 already been opened, the server can abort sending on the stream with 1489 an error code of H3_REQUEST_CANCELLED. 1491 Sending a CANCEL_PUSH frame has no direct effect on the state of 1492 existing push streams. A client SHOULD NOT send a CANCEL_PUSH frame 1493 when it has already received a corresponding push stream. A push 1494 stream could arrive after a client has sent a CANCEL_PUSH frame, 1495 because a server might not have processed the CANCEL_PUSH. The 1496 client SHOULD abort reading the stream with an error code of 1497 H3_REQUEST_CANCELLED. 1499 A CANCEL_PUSH frame is sent on the control stream. Receiving a 1500 CANCEL_PUSH frame on a stream other than the control stream MUST be 1501 treated as a connection error of type H3_FRAME_UNEXPECTED. 1503 CANCEL_PUSH Frame { 1504 Type (i) = 0x3, 1505 Length (i), 1506 Push ID (..), 1507 } 1509 Figure 6: CANCEL_PUSH Frame 1511 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 1512 integer. The Push ID identifies the server push that is being 1513 cancelled; see Section 4.4. If a CANCEL_PUSH frame is received that 1514 references a Push ID greater than currently allowed on the 1515 connection, this MUST be treated as a connection error of type 1516 H3_ID_ERROR. 1518 If the client receives a CANCEL_PUSH frame, that frame might identify 1519 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due 1520 to reordering. If a server receives a CANCEL_PUSH frame for a Push 1521 ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST 1522 be treated as a connection error of type H3_ID_ERROR. 1524 7.2.4. SETTINGS 1526 The SETTINGS frame (type=0x4) conveys configuration parameters that 1527 affect how endpoints communicate, such as preferences and constraints 1528 on peer behavior. Individually, a SETTINGS parameter can also be 1529 referred to as a "setting"; the identifier and value of each setting 1530 parameter can be referred to as a "setting identifier" and a "setting 1531 value". 1533 SETTINGS frames always apply to an entire HTTP/3 connection, never a 1534 single stream. A SETTINGS frame MUST be sent as the first frame of 1535 each control stream (see Section 6.2.1) by each peer, and MUST NOT be 1536 sent subsequently. If an endpoint receives a second SETTINGS frame 1537 on the control stream, the endpoint MUST respond with a connection 1538 error of type H3_FRAME_UNEXPECTED. 1540 SETTINGS frames MUST NOT be sent on any stream other than the control 1541 stream. If an endpoint receives a SETTINGS frame on a different 1542 stream, the endpoint MUST respond with a connection error of type 1543 H3_FRAME_UNEXPECTED. 1545 SETTINGS parameters are not negotiated; they describe characteristics 1546 of the sending peer that can be used by the receiving peer. However, 1547 a negotiation can be implied by the use of SETTINGS - each peer uses 1548 SETTINGS to advertise a set of supported values. The definition of 1549 the setting would describe how each peer combines the two sets to 1550 conclude which choice will be used. SETTINGS does not provide a 1551 mechanism to identify when the choice takes effect. 1553 Different values for the same parameter can be advertised by each 1554 peer. For example, a client might be willing to consume a very large 1555 response field section, while servers are more cautious about request 1556 size. 1558 The same setting identifier MUST NOT occur more than once in the 1559 SETTINGS frame. A receiver MAY treat the presence of duplicate 1560 setting identifiers as a connection error of type H3_SETTINGS_ERROR. 1562 The payload of a SETTINGS frame consists of zero or more parameters. 1563 Each parameter consists of a setting identifier and a value, both 1564 encoded as QUIC variable-length integers. 1566 Setting { 1567 Identifier (i), 1568 Value (i), 1569 } 1571 SETTINGS Frame { 1572 Type (i) = 0x4, 1573 Length (i), 1574 Setting (..) ..., 1575 } 1577 Figure 7: SETTINGS Frame 1579 An implementation MUST ignore the contents for any SETTINGS 1580 identifier it does not understand. 1582 7.2.4.1. Defined SETTINGS Parameters 1584 The following settings are defined in HTTP/3: 1586 SETTINGS_MAX_FIELD_SECTION_SIZE (0x6): The default value is 1587 unlimited. See Section 4.1.1.3 for usage. 1589 Setting identifiers of the format "0x1f * N + 0x21" for non-negative 1590 integer values of N are reserved to exercise the requirement that 1591 unknown identifiers be ignored. Such settings have no defined 1592 meaning. Endpoints SHOULD include at least one such setting in their 1593 SETTINGS frame. Endpoints MUST NOT consider such settings to have 1594 any meaning upon receipt. 1596 Because the setting has no defined meaning, the value of the setting 1597 can be any value the implementation selects. 1599 Setting identifiers which were used in HTTP/2 where there is no 1600 corresponding HTTP/3 setting have also been reserved 1601 (Section 11.2.2). These settings MUST NOT be sent, and their receipt 1602 MUST be treated as a connection error of type H3_SETTINGS_ERROR. 1604 Additional settings can be defined by extensions to HTTP/3; see 1605 Section 9 for more details. 1607 7.2.4.2. Initialization 1609 An HTTP implementation MUST NOT send frames or requests that would be 1610 invalid based on its current understanding of the peer's settings. 1612 All settings begin at an initial value. Each endpoint SHOULD use 1613 these initial values to send messages before the peer's SETTINGS 1614 frame has arrived, as packets carrying the settings can be lost or 1615 delayed. When the SETTINGS frame arrives, any settings are changed 1616 to their new values. 1618 This removes the need to wait for the SETTINGS frame before sending 1619 messages. Endpoints MUST NOT require any data to be received from 1620 the peer prior to sending the SETTINGS frame; settings MUST be sent 1621 as soon as the transport is ready to send data. 1623 For servers, the initial value of each client setting is the default 1624 value. 1626 For clients using a 1-RTT QUIC connection, the initial value of each 1627 server setting is the default value. 1-RTT keys will always become 1628 available prior to the packet containing SETTINGS being processed by 1629 QUIC, even if the server sends SETTINGS immediately. Clients SHOULD 1630 NOT wait indefinitely for SETTINGS to arrive before sending requests, 1631 but SHOULD process received datagrams in order to increase the 1632 likelihood of processing SETTINGS before sending the first request. 1634 When a 0-RTT QUIC connection is being used, the initial value of each 1635 server setting is the value used in the previous session. Clients 1636 SHOULD store the settings the server provided in the HTTP/3 1637 connection where resumption information was provided, but MAY opt not 1638 to store settings in certain cases (e.g., if the session ticket is 1639 received before the SETTINGS frame). A client MUST comply with 1640 stored settings - or default values, if no values are stored - when 1641 attempting 0-RTT. Once a server has provided new settings, clients 1642 MUST comply with those values. 1644 A server can remember the settings that it advertised, or store an 1645 integrity-protected copy of the values in the ticket and recover the 1646 information when accepting 0-RTT data. A server uses the HTTP/3 1647 settings values in determining whether to accept 0-RTT data. If the 1648 server cannot determine that the settings remembered by a client are 1649 compatible with its current settings, it MUST NOT accept 0-RTT data. 1650 Remembered settings are compatible if a client complying with those 1651 settings would not violate the server's current settings. 1653 A server MAY accept 0-RTT and subsequently provide different settings 1654 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 1655 SETTINGS frame MUST NOT reduce any limits or alter any values that 1656 might be violated by the client with its 0-RTT data. The server MUST 1657 include all settings that differ from their default values. If a 1658 server accepts 0-RTT but then sends settings that are not compatible 1659 with the previously specified settings, this MUST be treated as a 1660 connection error of type H3_SETTINGS_ERROR. If a server accepts 1661 0-RTT but then sends a SETTINGS frame that omits a setting value that 1662 the client understands (apart from reserved setting identifiers) that 1663 was previously specified to have a non-default value, this MUST be 1664 treated as a connection error of type H3_SETTINGS_ERROR. 1666 7.2.5. PUSH_PROMISE 1668 The PUSH_PROMISE frame (type=0x5) is used to carry a promised request 1669 header field section from server to client on a request stream, as in 1670 HTTP/2. 1672 PUSH_PROMISE Frame { 1673 Type (i) = 0x5, 1674 Length (i), 1675 Push ID (i), 1676 Encoded Field Section (..), 1677 } 1679 Figure 8: PUSH_PROMISE Frame 1681 The payload consists of: 1683 Push ID: A variable-length integer that identifies the server push 1684 operation. A Push ID is used in push stream headers (Section 4.4) 1685 and CANCEL_PUSH frames (Section 7.2.3). 1687 Encoded Field Section: QPACK-encoded request header fields for the 1688 promised response. See [QPACK] for more details. 1690 A server MUST NOT use a Push ID that is larger than the client has 1691 provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat 1692 receipt of a PUSH_PROMISE frame that contains a larger Push ID than 1693 the client has advertised as a connection error of H3_ID_ERROR. 1695 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 1696 If so, the decompressed request header sets MUST contain the same 1697 fields in the same order, and both the name and the value in each 1698 field MUST be exact matches. Clients SHOULD compare the request 1699 header sections for resources promised multiple times. If a client 1700 receives a Push ID that has already been promised and detects a 1701 mismatch, it MUST respond with a connection error of type 1702 H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sections match 1703 exactly, the client SHOULD associate the pushed content with each 1704 stream on which a PUSH_PROMISE frame was received. 1706 Allowing duplicate references to the same Push ID is primarily to 1707 reduce duplication caused by concurrent requests. A server SHOULD 1708 avoid reusing a Push ID over a long period. Clients are likely to 1709 consume server push responses and not retain them for reuse over 1710 time. Clients that see a PUSH_PROMISE frame that uses a Push ID that 1711 they have already consumed and discarded are forced to ignore the 1712 promise. 1714 If a PUSH_PROMISE frame is received on the control stream, the client 1715 MUST respond with a connection error of type H3_FRAME_UNEXPECTED; see 1716 Section 8. 1718 A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the 1719 receipt of a PUSH_PROMISE frame as a connection error of type 1720 H3_FRAME_UNEXPECTED; see Section 8. 1722 See Section 4.4 for a description of the overall server push 1723 mechanism. 1725 7.2.6. GOAWAY 1727 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 1728 an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint 1729 to stop accepting new requests or pushes while still finishing 1730 processing of previously received requests and pushes. This enables 1731 administrative actions, like server maintenance. GOAWAY by itself 1732 does not close a connection. 1734 GOAWAY Frame { 1735 Type (i) = 0x7, 1736 Length (i), 1737 Stream ID/Push ID (..), 1738 } 1740 Figure 9: GOAWAY Frame 1742 The GOAWAY frame is always sent on the control stream. In the server 1743 to client direction, it carries a QUIC Stream ID for a client- 1744 initiated bidirectional stream encoded as a variable-length integer. 1745 A client MUST treat receipt of a GOAWAY frame containing a Stream ID 1746 of any other type as a connection error of type H3_ID_ERROR. 1748 In the client to server direction, the GOAWAY frame carries a Push ID 1749 encoded as a variable-length integer. 1751 The GOAWAY frame applies to the entire connection, not a specific 1752 stream. A client MUST treat a GOAWAY frame on a stream other than 1753 the control stream as a connection error of type H3_FRAME_UNEXPECTED; 1754 see Section 8. 1756 See Section 5.2 for more information on the use of the GOAWAY frame. 1758 7.2.7. MAX_PUSH_ID 1760 The MAX_PUSH_ID frame (type=0xd) is used by clients to control the 1761 number of server pushes that the server can initiate. This sets the 1762 maximum value for a Push ID that the server can use in PUSH_PROMISE 1763 and CANCEL_PUSH frames. Consequently, this also limits the number of 1764 push streams that the server can initiate in addition to the limit 1765 maintained by the QUIC transport. 1767 The MAX_PUSH_ID frame is always sent on the control stream. Receipt 1768 of a MAX_PUSH_ID frame on any other stream MUST be treated as a 1769 connection error of type H3_FRAME_UNEXPECTED. 1771 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1772 receipt of a MAX_PUSH_ID frame as a connection error of type 1773 H3_FRAME_UNEXPECTED. 1775 The maximum Push ID is unset when an HTTP/3 connection is created, 1776 meaning that a server cannot push until it receives a MAX_PUSH_ID 1777 frame. A client that wishes to manage the number of promised server 1778 pushes can increase the maximum Push ID by sending MAX_PUSH_ID frames 1779 as the server fulfills or cancels server pushes. 1781 MAX_PUSH_ID Frame { 1782 Type (i) = 0xd, 1783 Length (i), 1784 Push ID (i), 1785 } 1787 Figure 10: MAX_PUSH_ID Frame 1789 The MAX_PUSH_ID frame carries a single variable-length integer that 1790 identifies the maximum value for a Push ID that the server can use; 1791 see Section 4.4. A MAX_PUSH_ID frame cannot reduce the maximum Push 1792 ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than 1793 previously received MUST be treated as a connection error of type 1794 H3_ID_ERROR. 1796 7.2.8. Reserved Frame Types 1798 Frame types of the format "0x1f * N + 0x21" for non-negative integer 1799 values of N are reserved to exercise the requirement that unknown 1800 types be ignored (Section 9). These frames have no semantics, and 1801 MAY be sent on any stream where frames are allowed to be sent. This 1802 enables their use for application-layer padding. Endpoints MUST NOT 1803 consider these frames to have any meaning upon receipt. 1805 The payload and length of the frames are selected in any manner the 1806 implementation chooses. 1808 Frame types that were used in HTTP/2 where there is no corresponding 1809 HTTP/3 frame have also been reserved (Section 11.2.1). These frame 1810 types MUST NOT be sent, and their receipt MUST be treated as a 1811 connection error of type H3_FRAME_UNEXPECTED. 1813 8. Error Handling 1815 When a stream cannot be completed successfully, QUIC allows the 1816 application to abruptly terminate (reset) that stream and communicate 1817 a reason; see Section 2.4 of [QUIC-TRANSPORT]. This is referred to 1818 as a "stream error." An HTTP/3 implementation can decide to close a 1819 QUIC stream and communicate the type of error. Wire encodings of 1820 error codes are defined in Section 8.1. Stream errors are distinct 1821 from HTTP status codes which indicate error conditions. Stream 1822 errors indicate that the sender did not transfer or consume the full 1823 request or response, while HTTP status codes indicate the result of a 1824 request that was successfully received. 1826 If an entire connection needs to be terminated, QUIC similarly 1827 provides mechanisms to communicate a reason; see Section 5.3 of 1828 [QUIC-TRANSPORT]. This is referred to as a "connection error." 1829 Similar to stream errors, an HTTP/3 implementation can terminate a 1830 QUIC connection and communicate the reason using an error code from 1831 Section 8.1. 1833 Although the reasons for closing streams and connections are called 1834 "errors," these actions do not necessarily indicate a problem with 1835 the connection or either implementation. For example, a stream can 1836 be reset if the requested resource is no longer needed. 1838 An endpoint MAY choose to treat a stream error as a connection error 1839 under certain circumstances, closing the entire connection in 1840 response to a condition on a single stream. Implementations need to 1841 consider the impact on outstanding requests before making this 1842 choice. 1844 Because new error codes can be defined without negotiation (see 1845 Section 9), use of an error code in an unexpected context or receipt 1846 of an unknown error code MUST be treated as equivalent to 1847 H3_NO_ERROR. However, closing a stream can have other effects 1848 regardless of the error code; for example, see Section 4.1. 1850 8.1. HTTP/3 Error Codes 1852 The following error codes are defined for use when abruptly 1853 terminating streams, aborting reading of streams, or immediately 1854 closing HTTP/3 connections. 1856 H3_NO_ERROR (0x100): No error. This is used when the connection or 1857 stream needs to be closed, but there is no error to signal. 1859 H3_GENERAL_PROTOCOL_ERROR (0x101): Peer violated protocol 1860 requirements in a way that does not match a more specific error 1861 code, or endpoint declines to use the more specific error code. 1863 H3_INTERNAL_ERROR (0x102): An internal error has occurred in the 1864 HTTP stack. 1866 H3_STREAM_CREATION_ERROR (0x103): The endpoint detected that its 1867 peer created a stream that it will not accept. 1869 H3_CLOSED_CRITICAL_STREAM (0x104): A stream required by the HTTP/3 1870 connection was closed or reset. 1872 H3_FRAME_UNEXPECTED (0x105): A frame was received that was not 1873 permitted in the current state or on the current stream. 1875 H3_FRAME_ERROR (0x106): A frame that fails to satisfy layout 1876 requirements or with an invalid size was received. 1878 H3_EXCESSIVE_LOAD (0x107): The endpoint detected that its peer is 1879 exhibiting a behavior that might be generating excessive load. 1881 H3_ID_ERROR (0x108): A Stream ID or Push ID was used incorrectly, 1882 such as exceeding a limit, reducing a limit, or being reused. 1884 H3_SETTINGS_ERROR (0x109): An endpoint detected an error in the 1885 payload of a SETTINGS frame. 1887 H3_MISSING_SETTINGS (0x10a): No SETTINGS frame was received at the 1888 beginning of the control stream. 1890 H3_REQUEST_REJECTED (0x10b): A server rejected a request without 1891 performing any application processing. 1893 H3_REQUEST_CANCELLED (0x10c): The request or its response (including 1894 pushed response) is cancelled. 1896 H3_REQUEST_INCOMPLETE (0x10d): The client's stream terminated 1897 without containing a fully-formed request. 1899 H3_MESSAGE_ERROR (0x10e): An HTTP message was malformed and cannot 1900 be processed. 1902 H3_CONNECT_ERROR (0x10f): The TCP connection established in response 1903 to a CONNECT request was reset or abnormally closed. 1905 H3_VERSION_FALLBACK (0x110): The requested operation cannot be 1906 served over HTTP/3. The peer should retry over HTTP/1.1. 1908 Error codes of the format "0x1f * N + 0x21" for non-negative integer 1909 values of N are reserved to exercise the requirement that unknown 1910 error codes be treated as equivalent to H3_NO_ERROR (Section 9). 1911 Implementations SHOULD select an error code from this space with some 1912 probability when they would have sent H3_NO_ERROR. 1914 9. Extensions to HTTP/3 1916 HTTP/3 permits extension of the protocol. Within the limitations 1917 described in this section, protocol extensions can be used to provide 1918 additional services or alter any aspect of the protocol. Extensions 1919 are effective only within the scope of a single HTTP/3 connection. 1921 This applies to the protocol elements defined in this document. This 1922 does not affect the existing options for extending HTTP, such as 1923 defining new methods, status codes, or fields. 1925 Extensions are permitted to use new frame types (Section 7.2), new 1926 settings (Section 7.2.4.1), new error codes (Section 8), or new 1927 unidirectional stream types (Section 6.2). Registries are 1928 established for managing these extension points: frame types 1929 (Section 11.2.1), settings (Section 11.2.2), error codes 1930 (Section 11.2.3), and stream types (Section 11.2.4). 1932 Implementations MUST ignore unknown or unsupported values in all 1933 extensible protocol elements. Implementations MUST discard frames 1934 and unidirectional streams that have unknown or unsupported types. 1935 This means that any of these extension points can be safely used by 1936 extensions without prior arrangement or negotiation. However, where 1937 a known frame type is required to be in a specific location, such as 1938 the SETTINGS frame as the first frame of the control stream (see 1939 Section 6.2.1), an unknown frame type does not satisfy that 1940 requirement and SHOULD be treated as an error. 1942 Extensions that could change the semantics of existing protocol 1943 components MUST be negotiated before being used. For example, an 1944 extension that changes the layout of the HEADERS frame cannot be used 1945 until the peer has given a positive signal that this is acceptable. 1946 Coordinating when such a revised layout comes into effect could prove 1947 complex. As such, allocating new identifiers for new definitions of 1948 existing protocol elements is likely to be more effective. 1950 This document does not mandate a specific method for negotiating the 1951 use of an extension but notes that a setting (Section 7.2.4.1) could 1952 be used for that purpose. If both peers set a value that indicates 1953 willingness to use the extension, then the extension can be used. If 1954 a setting is used for extension negotiation, the default value MUST 1955 be defined in such a fashion that the extension is disabled if the 1956 setting is omitted. 1958 10. Security Considerations 1960 The security considerations of HTTP/3 should be comparable to those 1961 of HTTP/2 with TLS. However, many of the considerations from 1962 Section 10 of [HTTP2] apply to [QUIC-TRANSPORT] and are discussed in 1963 that document. 1965 10.1. Server Authority 1967 HTTP/3 relies on the HTTP definition of authority. The security 1968 considerations of establishing authority are discussed in 1969 Section 17.1 of [SEMANTICS]. 1971 10.2. Cross-Protocol Attacks 1973 The use of ALPN in the TLS and QUIC handshakes establishes the target 1974 application protocol before application-layer bytes are processed. 1975 This ensures that endpoints have strong assurances that peers are 1976 using the same protocol. 1978 This does not guarantee protection from all cross-protocol attacks. 1979 Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the 1980 plaintext of QUIC packets can be used to perform request forgery 1981 against endpoints that don't use authenticated transports. 1983 10.3. Intermediary Encapsulation Attacks 1985 The HTTP/3 field encoding allows the expression of names that are not 1986 valid field names in the syntax used by HTTP (Section 5.1 of 1987 [SEMANTICS]). Requests or responses containing invalid field names 1988 MUST be treated as malformed (Section 4.1.3). An intermediary 1989 therefore cannot translate an HTTP/3 request or response containing 1990 an invalid field name into an HTTP/1.1 message. 1992 Similarly, HTTP/3 can transport field values that are not valid. 1993 While most values that can be encoded will not alter field parsing, 1994 carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the 1995 zero character (NUL, ASCII 0x0) might be exploited by an attacker if 1996 they are translated verbatim. Any request or response that contains 1997 a character not permitted in a field value MUST be treated as 1998 malformed (Section 4.1.3). Valid characters are defined by the 1999 "field-content" ABNF rule in Section 5.5 of [SEMANTICS]. 2001 10.4. Cacheability of Pushed Responses 2003 Pushed responses do not have an explicit request from the client; the 2004 request is provided by the server in the PUSH_PROMISE frame. 2006 Caching responses that are pushed is possible based on the guidance 2007 provided by the origin server in the Cache-Control header field. 2008 However, this can cause issues if a single server hosts more than one 2009 tenant. For example, a server might offer multiple users each a 2010 small portion of its URI space. 2012 Where multiple tenants share space on the same server, that server 2013 MUST ensure that tenants are not able to push representations of 2014 resources that they do not have authority over. Failure to enforce 2015 this would allow a tenant to provide a representation that would be 2016 served out of cache, overriding the actual representation that the 2017 authoritative tenant provides. 2019 Clients are required to reject pushed responses for which an origin 2020 server is not authoritative; see Section 4.4. 2022 10.5. Denial-of-Service Considerations 2024 An HTTP/3 connection can demand a greater commitment of resources to 2025 operate than an HTTP/1.1 or HTTP/2 connection. The use of field 2026 compression and flow control depend on a commitment of resources for 2027 storing a greater amount of state. Settings for these features 2028 ensure that memory commitments for these features are strictly 2029 bounded. 2031 The number of PUSH_PROMISE frames is constrained in a similar 2032 fashion. A client that accepts server push SHOULD limit the number 2033 of Push IDs it issues at a time. 2035 Processing capacity cannot be guarded as effectively as state 2036 capacity. 2038 The ability to send undefined protocol elements that the peer is 2039 required to ignore can be abused to cause a peer to expend additional 2040 processing time. This might be done by setting multiple undefined 2041 SETTINGS parameters, unknown frame types, or unknown stream types. 2042 Note, however, that some uses are entirely legitimate, such as 2043 optional-to-understand extensions and padding to increase resistance 2044 to traffic analysis. 2046 Compression of field sections also offers some opportunities to waste 2047 processing resources; see Section 7 of [QPACK] for more details on 2048 potential abuses. 2050 All these features - i.e., server push, unknown protocol elements, 2051 field compression - have legitimate uses. These features become a 2052 burden only when they are used unnecessarily or to excess. 2054 An endpoint that does not monitor this behavior exposes itself to a 2055 risk of denial-of-service attack. Implementations SHOULD track the 2056 use of these features and set limits on their use. An endpoint MAY 2057 treat activity that is suspicious as a connection error of type 2058 H3_EXCESSIVE_LOAD (Section 8), but false positives will result in 2059 disrupting valid connections and requests. 2061 10.5.1. Limits on Field Section Size 2063 A large field section (Section 4.1) can cause an implementation to 2064 commit a large amount of state. Header fields that are critical for 2065 routing can appear toward the end of a header field section, which 2066 prevents streaming of the header field section to its ultimate 2067 destination. This ordering and other reasons, such as ensuring cache 2068 correctness, mean that an endpoint likely needs to buffer the entire 2069 header field section. Since there is no hard limit to the size of a 2070 field section, some endpoints could be forced to commit a large 2071 amount of available memory for header fields. 2073 An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE 2074 (Section 4.1.1.3) setting to advise peers of limits that might apply 2075 on the size of field sections. This setting is only advisory, so 2076 endpoints MAY choose to send field sections that exceed this limit 2077 and risk having the request or response being treated as malformed. 2078 This setting is specific to an HTTP/3 connection, so any request or 2079 response could encounter a hop with a lower, unknown limit. An 2080 intermediary can attempt to avoid this problem by passing on values 2081 presented by different peers, but they are not obligated to do so. 2083 A server that receives a larger field section than it is willing to 2084 handle can send an HTTP 431 (Request Header Fields Too Large) status 2085 code ([RFC6585]). A client can discard responses that it cannot 2086 process. 2088 10.5.2. CONNECT Issues 2090 The CONNECT method can be used to create disproportionate load on a 2091 proxy, since stream creation is relatively inexpensive when compared 2092 to the creation and maintenance of a TCP connection. A proxy might 2093 also maintain some resources for a TCP connection beyond the closing 2094 of the stream that carries the CONNECT request, since the outgoing 2095 TCP connection remains in the TIME_WAIT state. Therefore, a proxy 2096 cannot rely on QUIC stream limits alone to control the resources 2097 consumed by CONNECT requests. 2099 10.6. Use of Compression 2101 Compression can allow an attacker to recover secret data when it is 2102 compressed in the same context as data under attacker control. 2103 HTTP/3 enables compression of fields (Section 4.1.1); the following 2104 concerns also apply to the use of HTTP compressed content-codings; 2105 see Section 8.5.1 of [SEMANTICS]. 2107 There are demonstrable attacks on compression that exploit the 2108 characteristics of the web (e.g., [BREACH]). The attacker induces 2109 multiple requests containing varying plaintext, observing the length 2110 of the resulting ciphertext in each, which reveals a shorter length 2111 when a guess about the secret is correct. 2113 Implementations communicating on a secure channel MUST NOT compress 2114 content that includes both confidential and attacker-controlled data 2115 unless separate compression contexts are used for each source of 2116 data. Compression MUST NOT be used if the source of data cannot be 2117 reliably determined. 2119 Further considerations regarding the compression of fields sections 2120 are described in [QPACK]. 2122 10.7. Padding and Traffic Analysis 2124 Padding can be used to obscure the exact size of frame content and is 2125 provided to mitigate specific attacks within HTTP, for example, 2126 attacks where compressed content includes both attacker-controlled 2127 plaintext and secret data (e.g., [BREACH]). 2129 Where HTTP/2 employs PADDING frames and Padding fields in other 2130 frames to make a connection more resistant to traffic analysis, 2131 HTTP/3 can either rely on transport-layer padding or employ the 2132 reserved frame and stream types discussed in Section 7.2.8 and 2133 Section 6.2.3. These methods of padding produce different results in 2134 terms of the granularity of padding, how padding is arranged in 2135 relation to the information that is being protected, whether padding 2136 is applied in the case of packet loss, and how an implementation 2137 might control padding. 2139 Reserved stream types can be used to give the appearance of sending 2140 traffic even when the connection is idle. Because HTTP traffic often 2141 occurs in bursts, apparent traffic can be used to obscure the timing 2142 or duration of such bursts, even to the point of appearing to send a 2143 constant stream of data. However, as such traffic is still flow 2144 controlled by the receiver, a failure to promptly drain such streams 2145 and provide additional flow control credit can limit the sender's 2146 ability to send real traffic. 2148 To mitigate attacks that rely on compression, disabling or limiting 2149 compression might be preferable to padding as a countermeasure. 2151 Use of padding can result in less protection than might seem 2152 immediately obvious. Redundant padding could even be 2153 counterproductive. At best, padding only makes it more difficult for 2154 an attacker to infer length information by increasing the number of 2155 frames an attacker has to observe. Incorrectly implemented padding 2156 schemes can be easily defeated. In particular, randomized padding 2157 with a predictable distribution provides very little protection; 2158 similarly, padding payloads to a fixed size exposes information as 2159 payload sizes cross the fixed-sized boundary, which could be possible 2160 if an attacker can control plaintext. 2162 10.8. Frame Parsing 2164 Several protocol elements contain nested length elements, typically 2165 in the form of frames with an explicit length containing variable- 2166 length integers. This could pose a security risk to an incautious 2167 implementer. An implementation MUST ensure that the length of a 2168 frame exactly matches the length of the fields it contains. 2170 10.9. Early Data 2172 The use of 0-RTT with HTTP/3 creates an exposure to replay attack. 2173 The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when 2174 using HTTP/3 with 0-RTT. 2176 10.10. Migration 2178 Certain HTTP implementations use the client address for logging or 2179 access-control purposes. Since a QUIC client's address might change 2180 during a connection (and future versions might support simultaneous 2181 use of multiple addresses), such implementations will need to either 2182 actively retrieve the client's current address or addresses when they 2183 are relevant or explicitly accept that the original address might 2184 change. 2186 10.11. Privacy Considerations 2188 Several characteristics of HTTP/3 provide an observer an opportunity 2189 to correlate actions of a single client or server over time. These 2190 include the value of settings, the timing of reactions to stimulus, 2191 and the handling of any features that are controlled by settings. 2193 As far as these create observable differences in behavior, they could 2194 be used as a basis for fingerprinting a specific client. 2196 HTTP/3's preference for using a single QUIC connection allows 2197 correlation of a user's activity on a site. Reusing connections for 2198 different origins allows for correlation of activity across those 2199 origins. 2201 Several features of QUIC solicit immediate responses and can be used 2202 by an endpoint to measure latency to their peer; this might have 2203 privacy implications in certain scenarios. 2205 11. IANA Considerations 2207 This document registers a new ALPN protocol ID (Section 11.1) and 2208 creates new registries that manage the assignment of codepoints in 2209 HTTP/3. 2211 11.1. Registration of HTTP/3 Identification String 2213 This document creates a new registration for the identification of 2214 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 2215 IDs" registry established in [RFC7301]. 2217 The "h3" string identifies HTTP/3: 2219 Protocol: HTTP/3 2221 Identification Sequence: 0x68 0x33 ("h3") 2223 Specification: This document 2225 11.2. New Registries 2227 New registries created in this document operate under the QUIC 2228 registration policy documented in Section 22.1 of [QUIC-TRANSPORT]. 2229 These registries all include the common set of fields listed in 2230 Section 22.1.1 of [QUIC-TRANSPORT]. These registries [SHALL be/are] 2231 collected under a "Hypertext Transfer Protocol version 3 (HTTP/3) 2232 Parameters" heading. 2234 The initial allocations in these registries created in this document 2235 are all assigned permanent status and list a change controller of the 2236 IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). 2238 11.2.1. Frame Types 2240 This document establishes a registry for HTTP/3 frame type codes. 2241 The "HTTP/3 Frame Type" registry governs a 62-bit space. This 2242 registry follows the QUIC registry policy; see Section 11.2. 2243 Permanent registrations in this registry are assigned using the 2244 Specification Required policy ([RFC8126]), except for values between 2245 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 2246 Standards Action or IESG Approval as defined in Section 4.9 and 4.10 2247 of [RFC8126]. 2249 While this registry is separate from the "HTTP/2 Frame Type" registry 2250 defined in [HTTP2], it is preferable that the assignments parallel 2251 each other where the code spaces overlap. If an entry is present in 2252 only one registry, every effort SHOULD be made to avoid assigning the 2253 corresponding value to an unrelated operation. 2255 In addition to common fields as described in Section 11.2, permanent 2256 registrations in this registry MUST include the following field: 2258 Frame Type: A name or label for the frame type. 2260 Specifications of frame types MUST include a description of the frame 2261 layout and its semantics, including any parts of the frame that are 2262 conditionally present. 2264 The entries in Table 2 are registered by this document. 2266 +==============+=======+===============+ 2267 | Frame Type | Value | Specification | 2268 +==============+=======+===============+ 2269 | DATA | 0x0 | Section 7.2.1 | 2270 +--------------+-------+---------------+ 2271 | HEADERS | 0x1 | Section 7.2.2 | 2272 +--------------+-------+---------------+ 2273 | Reserved | 0x2 | N/A | 2274 +--------------+-------+---------------+ 2275 | CANCEL_PUSH | 0x3 | Section 7.2.3 | 2276 +--------------+-------+---------------+ 2277 | SETTINGS | 0x4 | Section 7.2.4 | 2278 +--------------+-------+---------------+ 2279 | PUSH_PROMISE | 0x5 | Section 7.2.5 | 2280 +--------------+-------+---------------+ 2281 | Reserved | 0x6 | N/A | 2282 +--------------+-------+---------------+ 2283 | GOAWAY | 0x7 | Section 7.2.6 | 2284 +--------------+-------+---------------+ 2285 | Reserved | 0x8 | N/A | 2286 +--------------+-------+---------------+ 2287 | Reserved | 0x9 | N/A | 2288 +--------------+-------+---------------+ 2289 | MAX_PUSH_ID | 0xd | Section 7.2.7 | 2290 +--------------+-------+---------------+ 2292 Table 2: Initial HTTP/3 Frame Types 2294 Each code of the format "0x1f * N + 0x21" for non-negative integer 2295 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2296 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2297 assigned values. 2299 11.2.2. Settings Parameters 2301 This document establishes a registry for HTTP/3 settings. The 2302 "HTTP/3 Settings" registry governs a 62-bit space. This registry 2303 follows the QUIC registry policy; see Section 11.2. Permanent 2304 registrations in this registry are assigned using the Specification 2305 Required policy ([RFC8126]), except for values between 0x00 and 0x3f 2306 (in hexadecimal; inclusive), which are assigned using Standards 2307 Action or IESG Approval as defined in Section 4.9 and 4.10 of 2308 [RFC8126]. 2310 While this registry is separate from the "HTTP/2 Settings" registry 2311 defined in [HTTP2], it is preferable that the assignments parallel 2312 each other. If an entry is present in only one registry, every 2313 effort SHOULD be made to avoid assigning the corresponding value to 2314 an unrelated operation. 2316 In addition to common fields as described in Section 11.2, permanent 2317 registrations in this registry MUST include the following fields: 2319 Setting Name: A symbolic name for the setting. Specifying a setting 2320 name is optional. 2322 Default: The value of the setting unless otherwise indicated. A 2323 default SHOULD be the most restrictive possible value. 2325 The entries in Table 3 are registered by this document. 2327 +========================+=======+=================+===========+ 2328 | Setting Name | Value | Specification | Default | 2329 +========================+=======+=================+===========+ 2330 | Reserved | 0x2 | N/A | N/A | 2331 +------------------------+-------+-----------------+-----------+ 2332 | Reserved | 0x3 | N/A | N/A | 2333 +------------------------+-------+-----------------+-----------+ 2334 | Reserved | 0x4 | N/A | N/A | 2335 +------------------------+-------+-----------------+-----------+ 2336 | Reserved | 0x5 | N/A | N/A | 2337 +------------------------+-------+-----------------+-----------+ 2338 | MAX_FIELD_SECTION_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | 2339 +------------------------+-------+-----------------+-----------+ 2341 Table 3: Initial HTTP/3 Settings 2343 Each code of the format "0x1f * N + 0x21" for non-negative integer 2344 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2345 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2346 assigned values. 2348 11.2.3. Error Codes 2350 This document establishes a registry for HTTP/3 error codes. The 2351 "HTTP/3 Error Code" registry manages a 62-bit space. This registry 2352 follows the QUIC registry policy; see Section 11.2. Permanent 2353 registrations in this registry are assigned using the Specification 2354 Required policy ([RFC8126]), except for values between 0x00 and 0x3f 2355 (in hexadecimal; inclusive), which are assigned using Standards 2356 Action or IESG Approval as defined in Section 4.9 and 4.10 of 2357 [RFC8126]. 2359 Registrations for error codes are required to include a description 2360 of the error code. An expert reviewer is advised to examine new 2361 registrations for possible duplication with existing error codes. 2362 Use of existing registrations is to be encouraged, but not mandated. 2363 Use of values that are registered in the "HTTP/2 Error Code" registry 2364 is discouraged. 2366 In addition to common fields as described in Section 11.2, this 2367 registry includes two additional fields. Permanent registrations in 2368 this registry MUST include the following field: 2370 Name: A name for the error code. 2372 Description: A brief description of the error code semantics. 2374 The entries in Table 4 are registered by this document. These error 2375 codes were selected from the range that operates on a Specification 2376 Required policy to avoid collisions with HTTP/2 error codes. 2378 +===========================+========+==============+===============+ 2379 | Name | Value | Description | Specification | 2380 +===========================+========+==============+===============+ 2381 | H3_NO_ERROR | 0x0100 | No error | Section 8.1 | 2382 +---------------------------+--------+--------------+---------------+ 2383 | H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | Section 8.1 | 2384 | | | protocol | | 2385 | | | error | | 2386 +---------------------------+--------+--------------+---------------+ 2387 | H3_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 | 2388 | | | error | | 2389 +---------------------------+--------+--------------+---------------+ 2390 | H3_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 | 2391 | | | creation | | 2392 | | | error | | 2393 +---------------------------+--------+--------------+---------------+ 2394 | H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | Section 8.1 | 2395 | | | stream was | | 2396 | | | closed | | 2397 +---------------------------+--------+--------------+---------------+ 2398 | H3_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 | 2399 | | | permitted | | 2400 | | | in the | | 2401 | | | current | | 2402 | | | state | | 2403 +---------------------------+--------+--------------+---------------+ 2404 | H3_FRAME_ERROR | 0x0106 | Frame | Section 8.1 | 2405 | | | violated | | 2406 | | | layout or | | 2407 | | | size rules | | 2408 +---------------------------+--------+--------------+---------------+ 2409 | H3_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 | 2410 | | | generating | | 2411 | | | excessive | | 2412 | | | load | | 2413 +---------------------------+--------+--------------+---------------+ 2414 | H3_ID_ERROR | 0x0108 | An | Section 8.1 | 2415 | | | identifier | | 2416 | | | was used | | 2417 | | | incorrectly | | 2418 +---------------------------+--------+--------------+---------------+ 2419 | H3_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 | 2420 | | | frame | | 2421 | | | contained | | 2422 | | | invalid | | 2423 | | | values | | 2424 +---------------------------+--------+--------------+---------------+ 2425 | H3_MISSING_SETTINGS | 0x010a | No SETTINGS | Section 8.1 | 2426 | | | frame | | 2427 | | | received | | 2428 +---------------------------+--------+--------------+---------------+ 2429 | H3_REQUEST_REJECTED | 0x010b | Request not | Section 8.1 | 2430 | | | processed | | 2431 +---------------------------+--------+--------------+---------------+ 2432 | H3_REQUEST_CANCELLED | 0x010c | Data no | Section 8.1 | 2433 | | | longer | | 2434 | | | needed | | 2435 +---------------------------+--------+--------------+---------------+ 2436 | H3_REQUEST_INCOMPLETE | 0x010d | Stream | Section 8.1 | 2437 | | | terminated | | 2438 | | | early | | 2439 +---------------------------+--------+--------------+---------------+ 2440 | H3_MESSAGE_ERROR | 0x010e | Malformed | Section 8.1 | 2441 | | | message | | 2442 +---------------------------+--------+--------------+---------------+ 2443 | H3_CONNECT_ERROR | 0x010f | TCP reset | Section 8.1 | 2444 | | | or error on | | 2445 | | | CONNECT | | 2446 | | | request | | 2447 +---------------------------+--------+--------------+---------------+ 2448 | H3_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 | 2449 | | | HTTP/1.1 | | 2450 +---------------------------+--------+--------------+---------------+ 2452 Table 4: Initial HTTP/3 Error Codes 2454 Each code of the format "0x1f * N + 0x21" for non-negative integer 2455 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2456 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2457 assigned values. 2459 11.2.4. Stream Types 2461 This document establishes a registry for HTTP/3 unidirectional stream 2462 types. The "HTTP/3 Stream Type" registry governs a 62-bit space. 2463 This registry follows the QUIC registry policy; see Section 11.2. 2464 Permanent registrations in this registry are assigned using the 2465 Specification Required policy ([RFC8126]), except for values between 2466 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 2467 Standards Action or IESG Approval as defined in Section 4.9 and 4.10 2468 of [RFC8126]. 2470 In addition to common fields as described in Section 11.2, permanent 2471 registrations in this registry MUST include the following fields: 2473 Stream Type: A name or label for the stream type. 2475 Sender: Which endpoint on an HTTP/3 connection may initiate a stream 2476 of this type. Values are "Client", "Server", or "Both". 2478 Specifications for permanent registrations MUST include a description 2479 of the stream type, including the layout and semantics of the stream 2480 contents. 2482 The entries in the following table are registered by this document. 2484 +================+=======+===============+========+ 2485 | Stream Type | Value | Specification | Sender | 2486 +================+=======+===============+========+ 2487 | Control Stream | 0x00 | Section 6.2.1 | Both | 2488 +----------------+-------+---------------+--------+ 2489 | Push Stream | 0x01 | Section 4.4 | Server | 2490 +----------------+-------+---------------+--------+ 2492 Table 5 2494 Each code of the format "0x1f * N + 0x21" for non-negative integer 2495 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2496 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2497 assigned values. 2499 12. References 2501 12.1. Normative References 2503 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2504 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2505 April 2016, . 2507 [CACHING] Fielding, R., Nottingham, M., and J. Reschke, "HTTP 2508 Caching", Work in Progress, Internet-Draft, draft-ietf- 2509 httpbis-cache-13, 14 December 2020, . 2512 [HTTP-REPLAY] 2513 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 2514 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2515 2018, . 2517 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 2518 Header Compression for HTTP over QUIC", Work in Progress, 2519 Internet-Draft, draft-ietf-quic-qpack-20, 15 December 2520 2020, 2521 . 2523 [QUIC-TRANSPORT] 2524 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2525 Multiplexed and Secure Transport", Work in Progress, 2526 Internet-Draft, draft-ietf-quic-transport-34, 15 December 2527 2020, . 2530 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2531 RFC 793, DOI 10.17487/RFC0793, September 1981, 2532 . 2534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2535 Requirement Levels", BCP 14, RFC 2119, 2536 DOI 10.17487/RFC2119, March 1997, 2537 . 2539 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2540 Extensions: Extension Definitions", RFC 6066, 2541 DOI 10.17487/RFC6066, January 2011, 2542 . 2544 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2545 Verification of Domain-Based Application Service Identity 2546 within Internet Public Key Infrastructure Using X.509 2547 (PKIX) Certificates in the Context of Transport Layer 2548 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2549 2011, . 2551 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2552 DOI 10.17487/RFC6265, April 2011, 2553 . 2555 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2556 "Transport Layer Security (TLS) Application-Layer Protocol 2557 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2558 July 2014, . 2560 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2561 Writing an IANA Considerations Section in RFCs", BCP 26, 2562 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2563 . 2565 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2566 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2567 May 2017, . 2569 [SEMANTICS] 2570 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 2571 Semantics", Work in Progress, Internet-Draft, draft-ietf- 2572 httpbis-semantics-13, 14 December 2020, 2573 . 2576 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2577 Resource Identifier (URI): Generic Syntax", STD 66, 2578 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2579 . 2581 12.2. Informative References 2583 [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the 2584 CRIME Attack", July 2013, 2585 . 2588 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 2589 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 2590 . 2592 [HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1", 2593 Work in Progress, Internet-Draft, draft-ietf-httpbis- 2594 messaging-13, 14 December 2020, . 2597 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2598 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2599 DOI 10.17487/RFC7540, May 2015, 2600 . 2602 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 2603 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 2604 . 2606 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 2607 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 2608 . 2610 [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2611 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2612 . 2614 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2615 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2616 . 2618 Appendix A. Considerations for Transitioning from HTTP/2 2620 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 2621 This section describes the approach taken to design HTTP/3, points 2622 out important differences from HTTP/2, and describes how to map 2623 HTTP/2 extensions into HTTP/3. 2625 HTTP/3 begins from the premise that similarity to HTTP/2 is 2626 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 2627 where QUIC differs from TCP, either to take advantage of QUIC 2628 features (like streams) or to accommodate important shortcomings 2629 (such as a lack of total ordering). These differences make HTTP/3 2630 similar to HTTP/2 in key aspects, such as the relationship of 2631 requests and responses to streams. However, the details of the 2632 HTTP/3 design are substantially different from HTTP/2. 2634 These departures are noted in this section. 2636 A.1. Streams 2638 HTTP/3 permits use of a larger number of streams (2^62-1) than 2639 HTTP/2. The same considerations about exhaustion of stream 2640 identifier space apply, though the space is significantly larger such 2641 that it is likely that other limits in QUIC are reached first, such 2642 as the limit on the connection flow control window. 2644 In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by 2645 QUIC. QUIC considers a stream closed when all data has been received 2646 and sent data has been acknowledged by the peer. HTTP/2 considers a 2647 stream closed when the frame containing the END_STREAM bit has been 2648 committed to the transport. As a result, the stream for an 2649 equivalent exchange could remain "active" for a longer period of 2650 time. HTTP/3 servers might choose to permit a larger number of 2651 concurrent client-initiated bidirectional streams to achieve 2652 equivalent concurrency to HTTP/2, depending on the expected usage 2653 patterns. 2655 Due to the presence of other unidirectional stream types, HTTP/3 does 2656 not rely exclusively on the number of concurrent unidirectional 2657 streams to control the number of concurrent in-flight pushes. 2658 Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the 2659 number of pushes received from an HTTP/3 server. 2661 A.2. HTTP Frame Types 2663 Many framing concepts from HTTP/2 can be elided on QUIC, because the 2664 transport deals with them. Because frames are already on a stream, 2665 they can omit the stream number. Because frames do not block 2666 multiplexing (QUIC's multiplexing occurs below this layer), the 2667 support for variable-maximum-length packets can be removed. Because 2668 stream termination is handled by QUIC, an END_STREAM flag is not 2669 required. This permits the removal of the Flags field from the 2670 generic frame layout. 2672 Frame payloads are largely drawn from [HTTP2]. However, QUIC 2673 includes many features (e.g., flow control) that are also present in 2674 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 2675 As a result, several HTTP/2 frame types are not required in HTTP/3. 2676 Where an HTTP/2-defined frame is no longer used, the frame ID has 2677 been reserved in order to maximize portability between HTTP/2 and 2678 HTTP/3 implementations. However, even equivalent frames between the 2679 two mappings are not identical. 2681 Many of the differences arise from the fact that HTTP/2 provides an 2682 absolute ordering between frames across all streams, while QUIC 2683 provides this guarantee on each stream only. As a result, if a frame 2684 type makes assumptions that frames from different streams will still 2685 be received in the order sent, HTTP/3 will break them. 2687 Some examples of feature adaptations are described below, as well as 2688 general guidance to extension frame implementors converting an HTTP/2 2689 extension to HTTP/3. 2691 A.2.1. Prioritization Differences 2693 HTTP/2 specifies priority assignments in PRIORITY frames and 2694 (optionally) in HEADERS frames. HTTP/3 does not provide a means of 2695 signaling priority. 2697 Note that while there is no explicit signaling for priority, this 2698 does not mean that prioritization is not important for achieving good 2699 performance. 2701 A.2.2. Field Compression Differences 2703 HPACK was designed with the assumption of in-order delivery. A 2704 sequence of encoded field sections must arrive (and be decoded) at an 2705 endpoint in the same order in which they were encoded. This ensures 2706 that the dynamic state at the two endpoints remains in sync. 2708 Because this total ordering is not provided by QUIC, HTTP/3 uses a 2709 modified version of HPACK, called QPACK. QPACK uses a single 2710 unidirectional stream to make all modifications to the dynamic table, 2711 ensuring a total order of updates. All frames that contain encoded 2712 fields merely reference the table state at a given time without 2713 modifying it. 2715 [QPACK] provides additional details. 2717 A.2.3. Flow Control Differences 2719 HTTP/2 specifies a stream flow control mechanism. Although all 2720 HTTP/2 frames are delivered on streams, only the DATA frame payload 2721 is subject to flow control. QUIC provides flow control for stream 2722 data and all HTTP/3 frame types defined in this document are sent on 2723 streams. Therefore, all frame headers and payload are subject to 2724 flow control. 2726 A.2.4. Guidance for New Frame Type Definitions 2728 Frame type definitions in HTTP/3 often use the QUIC variable-length 2729 integer encoding. In particular, Stream IDs use this encoding, which 2730 allows for a larger range of possible values than the encoding used 2731 in HTTP/2. Some frames in HTTP/3 use an identifier rather than a 2732 Stream ID (e.g., Push IDs). Redefinition of the encoding of 2733 extension frame types might be necessary if the encoding includes a 2734 Stream ID. 2736 Because the Flags field is not present in generic HTTP/3 frames, 2737 those frames that depend on the presence of flags need to allocate 2738 space for flags as part of their frame payload. 2740 Other than these issues, frame type HTTP/2 extensions are typically 2741 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2742 control stream in HTTP/3. HTTP/3 extensions will not assume 2743 ordering, but would not be harmed by ordering, and would be portable 2744 to HTTP/2 in the same manner. 2746 A.2.5. Mapping Between HTTP/2 and HTTP/3 Frame Types 2748 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2749 Section 7.2.1. 2751 HEADERS (0x1): The PRIORITY region of HEADERS is not defined in 2752 HTTP/3 frames. Padding is not defined in HTTP/3 frames. See 2753 Section 7.2.2. 2755 PRIORITY (0x2): As described in Appendix A.2.1, HTTP/3 does not 2756 provide a means of signaling priority. 2758 RST_STREAM (0x3): RST_STREAM frames do not exist in HTTP/3, since 2759 QUIC provides stream lifecycle management. The same code point is 2760 used for the CANCEL_PUSH frame (Section 7.2.3). 2762 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2763 the connection. See Section 7.2.4 and Appendix A.3. 2765 PUSH_PROMISE (0x5): The PUSH_PROMISE frame does not reference a 2766 stream; instead the push stream references the PUSH_PROMISE frame 2767 using a Push ID. See Section 7.2.5. 2769 PING (0x6): PING frames do not exist in HTTP/3, as QUIC provides 2770 equivalent functionality. 2772 GOAWAY (0x7): GOAWAY does not contain an error code. In the client 2773 to server direction, it carries a Push ID instead of a server 2774 initiated stream ID. See Section 7.2.6. 2776 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist in HTTP/3, 2777 since QUIC provides flow control. 2779 CONTINUATION (0x9): CONTINUATION frames do not exist in HTTP/3; 2780 instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are 2781 permitted. 2783 Frame types defined by extensions to HTTP/2 need to be separately 2784 registered for HTTP/3 if still applicable. The IDs of frames defined 2785 in [HTTP2] have been reserved for simplicity. Note that the frame 2786 type space in HTTP/3 is substantially larger (62 bits versus 8 bits), 2787 so many HTTP/3 frame types have no equivalent HTTP/2 code points. 2788 See Section 11.2.1. 2790 A.3. HTTP/2 SETTINGS Parameters 2792 An important difference from HTTP/2 is that settings are sent once, 2793 as the first frame of the control stream, and thereafter cannot 2794 change. This eliminates many corner cases around synchronization of 2795 changes. 2797 Some transport-level options that HTTP/2 specifies via the SETTINGS 2798 frame are superseded by QUIC transport parameters in HTTP/3. The 2799 HTTP-level options that are retained in HTTP/3 have the same value as 2800 in HTTP/2. The superseded settings are reserved, and their receipt 2801 is an error. See Section 7.2.4.1 for discussion of both the retained 2802 and reserved values. 2804 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2806 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 2808 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 2809 frame, which provides a more granular control over server push. 2810 Specifying a setting with the identifier 0x2 (corresponding to the 2811 SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame is an 2812 error. 2814 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 2815 Stream ID as part of its flow control logic. Specifying a setting 2816 with the identifier 0x3 (corresponding to the 2817 SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS 2818 frame is an error. 2820 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 2821 connection flow control window sizes to be specified in the 2822 initial transport handshake. Specifying a setting with the 2823 identifier 0x4 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE 2824 parameter) in the HTTP/3 SETTINGS frame is an error. 2826 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. 2827 Specifying a setting with the identifier 0x5 (corresponding to the 2828 SETTINGS_MAX_FRAME_SIZE parameter) in the HTTP/3 SETTINGS frame is 2829 an error. 2831 SETTINGS_MAX_HEADER_LIST_SIZE: This setting identifier has been 2832 renamed SETTINGS_MAX_FIELD_SECTION_SIZE. 2834 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2835 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2836 This will often produce a shorter encoding, but can produce a longer 2837 encoding for settings that use the full 32-bit space. Settings 2838 ported from HTTP/2 might choose to redefine their value to limit it 2839 to 30 bits for more efficient encoding, or to make use of the 62-bit 2840 space if more than 30 bits are required. 2842 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2843 IDs of settings defined in [HTTP2] have been reserved for simplicity. 2844 Note that the settings identifier space in HTTP/3 is substantially 2845 larger (62 bits versus 16 bits), so many HTTP/3 settings have no 2846 equivalent HTTP/2 code point. See Section 11.2.2. 2848 As QUIC streams might arrive out of order, endpoints are advised not 2849 to wait for the peers' settings to arrive before responding to other 2850 streams. See Section 7.2.4.2. 2852 A.4. HTTP/2 Error Codes 2854 QUIC has the same concepts of "stream" and "connection" errors that 2855 HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 2856 mean that error codes are not directly portable between versions. 2858 The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map 2859 to the HTTP/3 error codes as follows: 2861 NO_ERROR (0x0): H3_NO_ERROR in Section 8.1. 2863 PROTOCOL_ERROR (0x1): This is mapped to H3_GENERAL_PROTOCOL_ERROR 2864 except in cases where more specific error codes have been defined. 2865 Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and 2866 H3_CLOSED_CRITICAL_STREAM defined in Section 8.1. 2868 INTERNAL_ERROR (0x2): H3_INTERNAL_ERROR in Section 8.1. 2870 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2871 control. 2873 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2874 SETTINGS is defined. 2876 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2877 management. 2879 FRAME_SIZE_ERROR (0x6): H3_FRAME_ERROR error code defined in 2880 Section 8.1. 2882 REFUSED_STREAM (0x7): H3_REQUEST_REJECTED (in Section 8.1) is used 2883 to indicate that a request was not processed. Otherwise, not 2884 applicable because QUIC handles stream management. 2886 CANCEL (0x8): H3_REQUEST_CANCELLED in Section 8.1. 2888 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2889 [QPACK]. 2891 CONNECT_ERROR (0xa): H3_CONNECT_ERROR in Section 8.1. 2893 ENHANCE_YOUR_CALM (0xb): H3_EXCESSIVE_LOAD in Section 8.1. 2895 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2896 provide sufficient security on all connections. 2898 HTTP_1_1_REQUIRED (0xd): H3_VERSION_FALLBACK in Section 8.1. 2900 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2901 Section 11.2.3. 2903 A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors 2905 An intermediary that converts between HTTP/2 and HTTP/3 may encounter 2906 error conditions from either upstream. It is useful to communicate 2907 the occurrence of error to the downstream but error codes largely 2908 reflect connection-local problems that generally do not make sense to 2909 propagate. 2911 An intermediary that encounters an error from an upstream origin can 2912 indicate this by sending an HTTP status code such as 502, which is 2913 suitable for a broad class of errors. 2915 There are some rare cases where it is beneficial to propagate the 2916 error by mapping it to the closest matching error type to the 2917 receiver. For example, an intermediary that receives an HTTP/2 2918 stream error of type REFUSED_STREAM from the origin has a clear 2919 signal that the request was not processed and that the request is 2920 safe to retry. Propagating this error condition to the client as an 2921 HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to 2922 take the action it deems most appropriate. In the reverse direction, 2923 the intermediary might deem it beneficial to pass on client request 2924 cancellations that are indicated by terminating a stream with 2925 H3_REQUEST_CANCELLED; see Section 4.1.2. 2927 Conversion between errors is described in the logical mapping. The 2928 error codes are defined in non-overlapping spaces in order to protect 2929 against accidental conversion that could result in the use of 2930 inappropriate or unknown error codes for the target version. An 2931 intermediary is permitted to promote stream errors to connection 2932 errors but they should be aware of the cost to the HTTP/3 connection 2933 for what might be a temporary or intermittent error. 2935 Appendix B. Change Log 2937 *RFC Editor's Note:* Please remove this section prior to 2938 publication of a final version of this document. 2940 B.1. Since draft-ietf-quic-http-32 2942 * Removed draft version guidance; added final version string 2944 * Added H3_MESSAGE_ERROR for malformed messages 2946 B.2. Since draft-ietf-quic-http-31 2948 Editorial changes only. 2950 B.3. Since draft-ietf-quic-http-30 2952 Editorial changes only. 2954 B.4. Since draft-ietf-quic-http-29 2956 * Require a connection error if a reserved frame type that 2957 corresponds to a frame in HTTP/2 is received (#3991, #3993) 2959 * Require a connection error if a reserved setting that corresponds 2960 to a setting in HTTP/2 is received (#3954, #3955) 2962 B.5. Since draft-ietf-quic-http-28 2964 * CANCEL_PUSH is recommended even when the stream is reset (#3698, 2965 #3700) 2967 * Use H3_ID_ERROR when GOAWAY contains a larger identifier (#3631, 2968 #3634) 2970 B.6. Since draft-ietf-quic-http-27 2972 * Updated text to refer to latest HTTP revisions 2973 * Use the HTTP definition of authority for establishing and 2974 coalescing connections (#253, #2223, #3558) 2976 * Define use of GOAWAY from both endpoints (#2632, #3129) 2978 * Require either :authority or Host if the URI scheme has a 2979 mandatory authority component (#3408, #3475) 2981 B.7. Since draft-ietf-quic-http-26 2983 * No changes 2985 B.8. Since draft-ietf-quic-http-25 2987 * Require QUICv1 for HTTP/3 (#3117, #3323) 2989 * Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275, 2990 #3309) 2992 * Clarify the definition of "malformed" (#3352, #3345) 2994 B.9. Since draft-ietf-quic-http-24 2996 * Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended 2997 instead (#3130,#3208) 2999 * Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331) 3001 * Some error codes are reserved for greasing (#3325,#3360) 3003 B.10. Since draft-ietf-quic-http-23 3005 * Removed "quic" Alt-Svc parameter (#3061,#3118) 3007 * Clients need not persist unknown settings for use in 0-RTT 3008 (#3110,#3113) 3010 * Clarify error cases around CANCEL_PUSH (#2819,#3083) 3012 B.11. Since draft-ietf-quic-http-22 3014 * Removed priority signaling (#2922,#2924) 3016 * Further changes to error codes (#2662,#2551): 3018 - Error codes renumbered 3019 - HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR, 3020 HTTP_ID_ERROR, and others 3022 * Clarify how unknown frame types interact with required frame 3023 sequence (#2867,#2858) 3025 * Describe interactions with the transport in terms of defined 3026 interface terms (#2857,#2805) 3028 * Require the use of the "http-opportunistic" resource (RFC 8164) 3029 when scheme is "http" (#2439,#2973) 3031 * Settings identifiers cannot be duplicated (#2979) 3033 * Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945): 3035 - Servers must send all settings with non-default values in their 3036 SETTINGS frame, even when resuming 3038 - If a client doesn't have settings associated with a 0-RTT 3039 ticket, it uses the defaults 3041 - Servers can't accept early data if they cannot recover the 3042 settings the client will have remembered 3044 * Clarify that Upgrade and the 101 status code are prohibited 3045 (#2898,#2889) 3047 * Clarify that frame types reserved for greasing can occur on any 3048 stream, but frame types reserved due to HTTP/2 correspondence are 3049 prohibited (#2997,#2692,#2693) 3051 * Unknown error codes cannot be treated as errors (#2998,#2816) 3053 B.12. Since draft-ietf-quic-http-21 3055 No changes 3057 B.13. Since draft-ietf-quic-http-20 3059 * Prohibit closing the control stream (#2509, #2666) 3061 * Change default priority to use an orphan node (#2502, #2690) 3063 * Exclusive priorities are restored (#2754, #2781) 3065 * Restrict use of frames when using CONNECT (#2229, #2702) 3066 * Close and maybe reset streams if a connection error occurs for 3067 CONNECT (#2228, #2703) 3069 * Encourage provision of sufficient unidirectional streams for QPACK 3070 (#2100, #2529, #2762) 3072 * Allow extensions to use server-initiated bidirectional streams 3073 (#2711, #2773) 3075 * Clarify use of maximum header list size setting (#2516, #2774) 3077 * Extensive changes to error codes and conditions of their sending 3079 - Require connection errors for more error conditions (#2511, 3080 #2510) 3082 - Updated the error codes for illegal GOAWAY frames (#2714, 3083 #2707) 3085 - Specified error code for HEADERS on control stream (#2708) 3087 - Specified error code for servers receiving PUSH_PROMISE (#2709) 3089 - Specified error code for receiving DATA before HEADERS (#2715) 3091 - Describe malformed messages and their handling (#2410, #2764) 3093 - Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813) 3095 - Refactor Push ID related errors (#2818, #2820) 3097 - Rationalize HTTP/3 stream creation errors (#2821, #2822) 3099 B.14. Since draft-ietf-quic-http-19 3101 * SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530) 3103 * Non-zero bits in the Empty field of the PRIORITY frame MAY be 3104 treated as an error (#2501) 3106 B.15. Since draft-ietf-quic-http-18 3108 * Resetting streams following a GOAWAY is recommended, but not 3109 required (#2256,#2457) 3111 * Use variable-length integers throughout (#2437,#2233,#2253,#2275) 3112 - Variable-length frame types, stream types, and settings 3113 identifiers 3115 - Renumbered stream type assignments 3117 - Modified associated reserved values 3119 * Frame layout switched from Length-Type-Value to Type-Length-Value 3120 (#2395,#2235) 3122 * Specified error code for servers receiving DUPLICATE_PUSH (#2497) 3124 * Use connection error for invalid PRIORITY (#2507, #2508) 3126 B.16. Since draft-ietf-quic-http-17 3128 * HTTP_REQUEST_REJECTED is used to indicate a request can be retried 3129 (#2106, #2325) 3131 * Changed error code for GOAWAY on the wrong stream (#2231, #2343) 3133 B.17. Since draft-ietf-quic-http-16 3135 * Rename "HTTP/QUIC" to "HTTP/3" (#1973) 3137 * Changes to PRIORITY frame (#1865, #2075) 3139 - Permitted as first frame of request streams 3141 - Remove exclusive reprioritization 3143 - Changes to Prioritized Element Type bits 3145 * Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 3146 (#2072) 3148 * Set defaults for settings, allow request before receiving SETTINGS 3149 (#1809, #1846, #2038) 3151 * Clarify message processing rules for streams that aren't closed 3152 (#1972, #2003) 3154 * Removed reservation of error code 0 and moved HTTP_NO_ERROR to 3155 this value (#1922) 3157 * Removed prohibition of zero-length DATA frames (#2098) 3159 B.18. Since draft-ietf-quic-http-15 3161 Substantial editorial reorganization; no technical changes. 3163 B.19. Since draft-ietf-quic-http-14 3165 * Recommend sensible values for QUIC transport parameters 3166 (#1720,#1806) 3168 * Define error for missing SETTINGS frame (#1697,#1808) 3170 * Setting values are variable-length integers (#1556,#1807) and do 3171 not have separate maximum values (#1820) 3173 * Expanded discussion of connection closure (#1599,#1717,#1712) 3175 * HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 3177 B.20. Since draft-ietf-quic-http-13 3179 * Reserved some frame types for grease (#1333, #1446) 3181 * Unknown unidirectional stream types are tolerated, not errors; 3182 some reserved for grease (#1490, #1525) 3184 * Require settings to be remembered for 0-RTT, prohibit reductions 3185 (#1541, #1641) 3187 * Specify behavior for truncated requests (#1596, #1643) 3189 B.21. Since draft-ietf-quic-http-12 3191 * TLS SNI extension isn't mandatory if an alternative method is used 3192 (#1459, #1462, #1466) 3194 * Removed flags from HTTP/3 frames (#1388, #1398) 3196 * Reserved frame types and settings for use in preserving 3197 extensibility (#1333, #1446) 3199 * Added general error code (#1391, #1397) 3201 * Unidirectional streams carry a type byte and are extensible 3202 (#910,#1359) 3204 * Priority mechanism now uses explicit placeholders to enable 3205 persistent structure in the tree (#441,#1421,#1422) 3207 B.22. Since draft-ietf-quic-http-11 3209 * Moved QPACK table updates and acknowledgments to dedicated streams 3210 (#1121, #1122, #1238) 3212 B.23. Since draft-ietf-quic-http-10 3214 * Settings need to be remembered when attempting and accepting 0-RTT 3215 (#1157, #1207) 3217 B.24. Since draft-ietf-quic-http-09 3219 * Selected QCRAM for header compression (#228, #1117) 3221 * The server_name TLS extension is now mandatory (#296, #495) 3223 * Specified handling of unsupported versions in Alt-Svc (#1093, 3224 #1097) 3226 B.25. Since draft-ietf-quic-http-08 3228 * Clarified connection coalescing rules (#940, #1024) 3230 B.26. Since draft-ietf-quic-http-07 3232 * Changes for integer encodings in QUIC (#595,#905) 3234 * Use unidirectional streams as appropriate (#515, #240, #281, #886) 3236 * Improvement to the description of GOAWAY (#604, #898) 3238 * Improve description of server push usage (#947, #950, #957) 3240 B.27. Since draft-ietf-quic-http-06 3242 * Track changes in QUIC error code usage (#485) 3244 B.28. Since draft-ietf-quic-http-05 3246 * Made push ID sequential, add MAX_PUSH_ID, remove 3247 SETTINGS_ENABLE_PUSH (#709) 3249 * Guidance about keep-alive and QUIC PINGs (#729) 3251 * Expanded text on GOAWAY and cancellation (#757) 3253 B.29. Since draft-ietf-quic-http-04 3254 * Cite RFC 5234 (#404) 3256 * Return to a single stream per request (#245,#557) 3258 * Use separate frame type and settings registries from HTTP/2 (#81) 3260 * SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 3262 * Restored GOAWAY (#696) 3264 * Identify server push using Push ID rather than a stream ID 3265 (#702,#281) 3267 * DATA frames cannot be empty (#700) 3269 B.30. Since draft-ietf-quic-http-03 3271 None. 3273 B.31. Since draft-ietf-quic-http-02 3275 * Track changes in transport draft 3277 B.32. Since draft-ietf-quic-http-01 3279 * SETTINGS changes (#181): 3281 - SETTINGS can be sent only once at the start of a connection; no 3282 changes thereafter 3284 - SETTINGS_ACK removed 3286 - Settings can only occur in the SETTINGS frame a single time 3288 - Boolean format updated 3290 * Alt-Svc parameter changed from "v" to "quic"; format updated 3291 (#229) 3293 * Closing the connection control stream or any message control 3294 stream is a fatal error (#176) 3296 * HPACK Sequence counter can wrap (#173) 3298 * 0-RTT guidance added 3300 * Guide to differences from HTTP/2 and porting HTTP/2 extensions 3301 added (#127,#242) 3303 B.33. Since draft-ietf-quic-http-00 3305 * Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 3307 * Changed from using HTTP/2 framing within Stream 3 to new framing 3308 format and two-stream-per-request model (#71,#72,#73) 3310 * Adopted SETTINGS format from draft-bishop-httpbis-extended- 3311 settings-01 3313 * Reworked SETTINGS_ACK to account for indeterminate inter-stream 3314 order (#75) 3316 * Described CONNECT pseudo-method (#95) 3318 * Updated ALPN token and Alt-Svc guidance (#13,#87) 3320 * Application-layer-defined error codes (#19,#74) 3322 B.34. Since draft-shade-quic-http2-mapping-00 3324 * Adopted as base for draft-ietf-quic-http 3326 * Updated authors/editors list 3328 Acknowledgements 3330 The original authors of this specification were Robbie Shade and Mike 3331 Warres. 3333 The IETF QUIC Working Group received an enormous amount of support 3334 from many people. Among others, the following people provided 3335 substantial contributions to this document: 3337 * Bence Beky 3339 * Daan De Meyer 3341 * Martin Duke 3343 * Roy Fielding 3345 * Alan Frindell 3347 * Alessandro Ghedini 3349 * Nick Harper 3350 * Ryan Hamilton 3352 * Christian Huitema 3354 * Subodh Iyengar 3356 * Robin Marx 3358 * Patrick McManus 3360 * Luca Niccolini 3362 * 奥 一穂 (Kazuho Oku) 3364 * Lucas Pardue 3366 * Roberto Peon 3368 * Julian Reschke 3370 * Eric Rescorla 3372 * Martin Seemann 3374 * Ben Schwartz 3376 * Ian Swett 3378 * Willy Taureau 3380 * Martin Thomson 3382 * Dmitri Tikhonov 3384 * Tatsuhiro Tsujikawa 3386 A portion of Mike's contribution was supported by Microsoft during 3387 his employment there. 3389 Author's Address 3391 Mike Bishop (editor) 3392 Akamai 3394 Email: mbishop@evequefou.be