idnits 2.17.1 draft-ietf-quic-http-34.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 (2 February 2021) is 1178 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-14 -- Possible downref: Normative reference to a draft: ref. 'CACHING' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-14 -- Possible downref: Normative reference to a draft: ref. 'SEMANTICS' -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'DNS-TERMS') (Obsoleted by RFC 9499) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-14 -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 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 2 February 2021 5 Expires: 6 August 2021 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-34 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 6 August 2021. 51 Copyright Notice 53 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . 12 80 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 12 81 4.1.1. Field Formatting and Compression . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 21 86 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 87 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 23 88 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 23 89 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 24 90 5.3. Immediate Application Closure . . . . . . . . . . . . . . 26 91 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 26 92 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 27 93 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 27 94 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 28 95 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 29 96 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 30 97 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 30 98 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 31 99 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 32 100 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 32 101 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 32 102 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 33 103 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 33 104 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 35 105 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 38 106 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 39 107 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 40 108 7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 41 109 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 41 110 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 42 111 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 43 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 44 113 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 44 114 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 44 115 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 45 116 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 45 117 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 45 118 10.5.1. Limits on Field Section Size . . . . . . . . . . . . 46 119 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 47 120 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 47 121 10.7. Padding and Traffic Analysis . . . . . . . . . . . . . . 48 122 10.8. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 48 123 10.9. Early Data . . . . . . . . . . . . . . . . . . . . . . . 49 124 10.10. Migration . . . . . . . . . . . . . . . . . . . . . . . 49 125 10.11. Privacy Considerations . . . . . . . . . . . . . . . . . 49 126 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 127 11.1. Registration of HTTP/3 Identification String . . . . . . 50 128 11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 50 129 11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 50 130 11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 52 131 11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 53 132 11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 55 133 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 134 12.1. Normative References . . . . . . . . . . . . . . . . . . 56 135 12.2. Informative References . . . . . . . . . . . . . . . . . 57 136 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 58 137 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 59 138 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 60 139 A.2.1. Prioritization Differences . . . . . . . . . . . . . 60 140 A.2.2. Field Compression Differences . . . . . . . . . . . . 60 141 A.2.3. Flow Control Differences . . . . . . . . . . . . . . 61 142 A.2.4. Guidance for New Frame Type Definitions . . . . . . . 61 143 A.2.5. Comparison Between HTTP/2 and HTTP/3 Frame Types . . 61 144 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 62 145 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 64 146 A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors . . . . . . 65 147 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 65 148 B.1. Since draft-ietf-quic-http-32 . . . . . . . . . . . . . . 65 149 B.2. Since draft-ietf-quic-http-31 . . . . . . . . . . . . . . 66 150 B.3. Since draft-ietf-quic-http-30 . . . . . . . . . . . . . . 66 151 B.4. Since draft-ietf-quic-http-29 . . . . . . . . . . . . . . 66 152 B.5. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 66 153 B.6. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 66 154 B.7. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 66 155 B.8. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 66 156 B.9. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 67 157 B.10. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 67 158 B.11. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 67 159 B.12. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 68 160 B.13. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 68 161 B.14. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 69 162 B.15. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 69 163 B.16. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 69 164 B.17. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 70 165 B.18. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 70 166 B.19. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 70 167 B.20. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 70 168 B.21. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 71 169 B.22. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 71 170 B.23. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 71 171 B.24. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 71 172 B.25. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 72 173 B.26. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 72 174 B.27. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 72 175 B.28. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 72 176 B.29. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 72 177 B.30. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 72 178 B.31. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 73 179 B.32. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 73 180 B.33. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 73 181 B.34. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 74 182 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 74 183 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 75 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 and HTTP/2. HTTP/1.1 has been used over a variety of 190 transport and session layers, while HTTP/2 has been used primarily 191 with TLS over TCP. HTTP/3 supports the same semantics over a new 192 transport protocol, QUIC. 194 1.1. Prior versions of HTTP 196 HTTP/1.1 ([HTTP11]) uses whitespace-delimited text fields to convey 197 HTTP messages. While these exchanges are human-readable, using 198 whitespace for message formatting leads to parsing complexity and 199 excessive tolerance of variant behavior. 201 Because HTTP/1.1 does not include a multiplexing layer, multiple TCP 202 connections are often used to service requests in parallel. However, 203 that has a negative impact on congestion control and network 204 efficiency, since TCP does not share congestion control across 205 multiple connections. 207 HTTP/2 ([HTTP2]) introduced a binary framing and multiplexing layer 208 to improve latency without modifying the transport layer. However, 209 because the parallel nature of HTTP/2's multiplexing is not visible 210 to TCP's loss recovery mechanisms, a lost or reordered packet causes 211 all active transactions to experience a stall regardless of whether 212 that transaction was directly impacted by the lost packet. 214 1.2. Delegation to QUIC 216 The QUIC transport protocol incorporates stream multiplexing and per- 217 stream flow control, similar to that provided by the HTTP/2 framing 218 layer. By providing reliability at the stream level and congestion 219 control across the entire connection, QUIC has the capability to 220 improve the performance of HTTP compared to a TCP mapping. QUIC also 221 incorporates TLS 1.3 ([TLS13]) at the transport layer, offering 222 comparable confidentiality and integrity to running TLS over TCP, 223 with the improved connection setup latency of TCP Fast Open ([TFO]). 225 This document defines HTTP/3, a mapping of HTTP semantics over the 226 QUIC transport protocol, drawing heavily on the design of HTTP/2. 227 HTTP/3 relies on QUIC to provide confidentiality and integrity 228 protection of data; peer authentication; and reliable, in-order, per- 229 stream delivery. While delegating stream lifetime and flow control 230 issues to QUIC, a binary framing similar to the HTTP/2 framing is 231 used on each stream. Some HTTP/2 features are subsumed by QUIC, 232 while other features are implemented atop QUIC. 234 QUIC is described in [QUIC-TRANSPORT]. For a full description of 235 HTTP/2, see [HTTP2]. 237 2. HTTP/3 Protocol Overview 239 HTTP/3 provides a transport for HTTP semantics using the QUIC 240 transport protocol and an internal framing layer similar to HTTP/2. 242 Once a client knows that an HTTP/3 server exists at a certain 243 endpoint, it opens a QUIC connection. QUIC provides protocol 244 negotiation, stream-based multiplexing, and flow control. Discovery 245 of an HTTP/3 endpoint is described in Section 3.1. 247 Within each stream, the basic unit of HTTP/3 communication is a frame 248 (Section 7.2). Each frame type serves a different purpose. For 249 example, HEADERS and DATA frames form the basis of HTTP requests and 250 responses (Section 4.1). Frames that apply to the entire connection 251 are conveyed on a dedicated control stream. 253 Multiplexing of requests is performed using the QUIC stream 254 abstraction, described in Section 2 of [QUIC-TRANSPORT]. Each 255 request-response pair consumes a single QUIC stream. Streams are 256 independent of each other, so one stream that is blocked or suffers 257 packet loss does not prevent progress on other streams. 259 Server push is an interaction mode introduced in HTTP/2 ([HTTP2]) 260 that permits a server to push a request-response exchange to a client 261 in anticipation of the client making the indicated request. This 262 trades off network usage against a potential latency gain. Several 263 HTTP/3 frames are used to manage server push, such as PUSH_PROMISE, 264 MAX_PUSH_ID, and CANCEL_PUSH. 266 As in HTTP/2, request and response fields are compressed for 267 transmission. Because HPACK ([HPACK]) relies on in-order 268 transmission of compressed field sections (a guarantee not provided 269 by QUIC), HTTP/3 replaces HPACK with QPACK ([QPACK]). QPACK uses 270 separate unidirectional streams to modify and track field table 271 state, while encoded field sections refer to the state of the table 272 without modifying it. 274 2.1. Document Organization 276 The following sections provide a detailed overview of the lifecycle 277 of an HTTP/3 connection: 279 * Connection Setup and Management (Section 3) covers how an HTTP/3 280 endpoint is discovered and an HTTP/3 connection is established. 282 * HTTP Request Lifecycle (Section 4) describes how HTTP semantics 283 are expressed using frames. 285 * Connection Closure (Section 5) describes how HTTP/3 connections 286 are terminated, either gracefully or abruptly. 288 The details of the wire protocol and interactions with the transport 289 are described in subsequent sections: 291 * Stream Mapping and Usage (Section 6) describes the way QUIC 292 streams are used. 294 * HTTP Framing Layer (Section 7) describes the frames used on most 295 streams. 297 * Error Handling (Section 8) describes how error conditions are 298 handled and expressed, either on a particular stream or for the 299 connection as a whole. 301 Additional resources are provided in the final sections: 303 * Extensions to HTTP/3 (Section 9) describes how new capabilities 304 can be added in future documents. 306 * A more detailed comparison between HTTP/2 and HTTP/3 can be found 307 in Appendix A. 309 2.2. Conventions and Terminology 311 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 312 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 313 "OPTIONAL" in this document are to be interpreted as described in 314 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 315 capitals, as shown here. 317 This document uses the variable-length integer encoding from 318 [QUIC-TRANSPORT]. 320 The following terms are used: 322 abort: An abrupt termination of a connection or stream, possibly due 323 to an error condition. 325 client: The endpoint that initiates an HTTP/3 connection. Clients 326 send HTTP requests and receive HTTP responses. 328 connection: A transport-layer connection between two endpoints, 329 using QUIC as the transport protocol. 331 connection error: An error that affects the entire HTTP/3 332 connection. 334 endpoint: Either the client or server of the connection. 336 frame: The smallest unit of communication on a stream in HTTP/3, 337 consisting of a header and a variable-length sequence of bytes 338 structured according to the frame type. 340 Protocol elements called "frames" exist in both this document and 341 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are 342 referenced, the frame name will be prefaced with "QUIC." For 343 example, "QUIC CONNECTION_CLOSE frames." References without this 344 preface refer to frames defined in Section 7.2. 346 HTTP/3 connection: A QUIC connection where the negotiated 347 application protocol is HTTP/3. 349 peer: An endpoint. When discussing a particular endpoint, "peer" 350 refers to the endpoint that is remote to the primary subject of 351 discussion. 353 receiver: An endpoint that is receiving frames. 355 sender: An endpoint that is transmitting frames. 357 server: The endpoint that accepts an HTTP/3 connection. Servers 358 receive HTTP requests and send HTTP responses. 360 stream: A bidirectional or unidirectional bytestream provided by the 361 QUIC transport. All streams within an HTTP/3 connection can be 362 considered "HTTP/3 streams," but multiple stream types are defined 363 within HTTP/3. 365 stream error: An application-level error on the individual stream. 367 The term "content" is defined in Section 6.4 of [SEMANTICS]. 369 Finally, the terms "resource", "message", "user agent", "origin 370 server", "gateway", "intermediary", "proxy", and "tunnel" are defined 371 in Section 3 of [SEMANTICS]. 373 Packet diagrams in this document use the format defined in 374 Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of 375 fields. 377 3. Connection Setup and Management 379 3.1. Discovering an HTTP/3 Endpoint 381 HTTP relies on the notion of an authoritative response: a response 382 that has been determined to be the most appropriate response for that 383 request given the state of the target resource at the time of 384 response message origination by (or at the direction of) the origin 385 server identified within the target URI. Locating an authoritative 386 server for an HTTP URI is discussed in Section 4.3 of [SEMANTICS]. 388 The "https" scheme associates authority with possession of a 389 certificate that the client considers to be trustworthy for the host 390 identified by the authority component of the URI. Upon receiving a 391 server certificate in the TLS handshake, the client MUST verify that 392 the certificate is an acceptable match for the URI's origin server 393 using the process described in Section 4.3.4 of [SEMANTICS]. If the 394 certificate cannot be verified with respect to the URI's origin 395 server, the client MUST NOT consider the server authoritative for 396 that origin. 398 A client MAY attempt access to a resource with an "https" URI by 399 resolving the host identifier to an IP address, establishing a QUIC 400 connection to that address on the indicated port (including 401 validation of the server certificate as described above), and sending 402 an 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 URIs 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 can advertise 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 domain name ([DNS-TERMS]), clients MUST send the 460 Server Name Indication (SNI; [RFC6066]) TLS extension unless an 461 alternative 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 To use an existing connection for a new origin, clients MUST validate 487 the certificate presented by the server for the new origin server 488 using the process described in Section 4.3.4 of [SEMANTICS]. This 489 implies that clients will need to retain the server certificate and 490 any additional information needed to verify that certificate; clients 491 which do not do so will be unable to reuse the connection for 492 additional origins. 494 If the certificate is not acceptable with regard to the new origin 495 for any reason, the connection MUST NOT be reused and a new 496 connection SHOULD be established for the new origin. If the reason 497 the certificate cannot be verified might apply to other origins 498 already associated with the connection, the client SHOULD re-validate 499 the server certificate for those origins. For instance, if 500 validation of a certificate fails because the certificate has expired 501 or been revoked, this might be used to invalidate all other origins 502 for which that certificate was used to establish authority. 504 Clients SHOULD NOT open more than one HTTP/3 connection to a given IP 505 address and UDP port, where the IP address and port might be derived 506 from a URI, a selected alternative service ([ALTSVC]), a configured 507 proxy, or name resolution of any of these. A client MAY open 508 multiple HTTP/3 connections to the same IP address and UDP port using 509 different transport or TLS configurations but SHOULD avoid creating 510 multiple connections with the same configuration. 512 Servers are encouraged to maintain open HTTP/3 connections for as 513 long as possible but are permitted to terminate idle connections if 514 necessary. When either endpoint chooses to close the HTTP/3 515 connection, the terminating endpoint SHOULD first send a GOAWAY frame 516 (Section 5.2) so that both endpoints can reliably determine whether 517 previously sent frames have been processed and gracefully complete or 518 terminate any necessary remaining tasks. 520 A server that does not wish clients to reuse HTTP/3 connections for a 521 particular origin can indicate that it is not authoritative for a 522 request by sending a 421 (Misdirected Request) status code in 523 response to the request; see Section 7.4 of [SEMANTICS]. 525 4. HTTP Request Lifecycle 527 4.1. HTTP Message Exchanges 529 A client sends an HTTP request on a request stream, which is a 530 client-initiated bidirectional QUIC stream; see Section 6.1. A 531 client MUST send only a single request on a given stream. A server 532 sends zero or more interim HTTP responses on the same stream as the 533 request, followed by a single final HTTP response, as detailed below. 534 See Section 15 of [SEMANTICS] for a description of interim and final 535 HTTP responses. 537 Pushed responses are sent on a server-initiated unidirectional QUIC 538 stream; see Section 6.2.2. A server sends zero or more interim HTTP 539 responses, followed by a single final HTTP response, in the same 540 manner as a standard response. Push is described in more detail in 541 Section 4.4. 543 On a given stream, receipt of multiple requests or receipt of an 544 additional HTTP response following a final HTTP response MUST be 545 treated as malformed (Section 4.1.3). 547 An HTTP message (request or response) consists of: 549 1. the header section, sent as a single HEADERS frame (see 550 Section 7.2.2), 552 2. optionally, the content, if present, sent as a series of DATA 553 frames (see Section 7.2.1), and 555 3. optionally, the trailer section, if present, sent as a single 556 HEADERS frame. 558 Header and trailer sections are described in Sections 6.3 and 6.5 of 559 [SEMANTICS]; the content is described in Section 6.4 of [SEMANTICS]. 561 Receipt of an invalid sequence of frames MUST be treated as a 562 connection error of type H3_FRAME_UNEXPECTED; see Section 8. In 563 particular, a DATA frame before any HEADERS frame, or a HEADERS or 564 DATA frame after the trailing HEADERS frame, is considered invalid. 565 Other frame types, especially unknown frame types, might be permitted 566 subject to their own rules; see Section 9. 568 A server MAY send one or more PUSH_PROMISE frames (Section 7.2.5) 569 before, after, or interleaved with the frames of a response message. 570 These PUSH_PROMISE frames are not part of the response; see 571 Section 4.4 for more details. PUSH_PROMISE frames are not permitted 572 on push streams; a pushed response that includes PUSH_PROMISE frames 573 MUST be treated as a connection error of type H3_FRAME_UNEXPECTED; 574 see Section 8. 576 Frames of unknown types (Section 9), including reserved frames 577 (Section 7.2.8) MAY be sent on a request or push stream before, 578 after, or interleaved with other frames described in this section. 580 The HEADERS and PUSH_PROMISE frames might reference updates to the 581 QPACK dynamic table. While these updates are not directly part of 582 the message exchange, they must be received and processed before the 583 message can be consumed. See Section 4.1.1 for more details. 585 Transfer codings (see Section 6.1 of [HTTP11]) are not defined for 586 HTTP/3; the Transfer-Encoding header field MUST NOT be used. 588 A response MAY consist of multiple messages when and only when one or 589 more interim responses (1xx; see Section 15.2 of [SEMANTICS]) precede 590 a final response to the same request. Interim responses do not 591 contain content or trailer sections. 593 An HTTP request/response exchange fully consumes a client-initiated 594 bidirectional QUIC stream. After sending a request, a client MUST 595 close the stream for sending. Unless using the CONNECT method (see 596 Section 4.2), clients MUST NOT make stream closure dependent on 597 receiving a response to their request. After sending a final 598 response, the server MUST close the stream for sending. At this 599 point, the QUIC stream is fully closed. 601 When a stream is closed, this indicates the end of the final HTTP 602 message. Because some messages are large or unbounded, endpoints 603 SHOULD begin processing partial HTTP messages once enough of the 604 message has been received to make progress. If a client-initiated 605 stream terminates without enough of the HTTP message to provide a 606 complete response, the server SHOULD abort its response stream with 607 the error code H3_REQUEST_INCOMPLETE; see Section 8. 609 A server can send a complete response prior to the client sending an 610 entire request if the response does not depend on any portion of the 611 request that has not been sent and received. When the server does 612 not need to receive the remainder of the request, it MAY abort 613 reading the request stream, send a complete response, and cleanly 614 close the sending part of the stream. The error code H3_NO_ERROR 615 SHOULD be used when requesting that the client stop sending on the 616 request stream. Clients MUST NOT discard complete responses as a 617 result of having their request terminated abruptly, though clients 618 can always discard responses at their discretion for other reasons. 619 If the server sends a partial or complete response but does not abort 620 reading the request, clients SHOULD continue sending the body of the 621 request and close the stream normally. 623 4.1.1. Field Formatting and Compression 625 HTTP messages carry metadata as a series of key-value pairs called 626 HTTP fields; see Sections 6.3 and 6.5 of [SEMANTICS]. For a listing 627 of registered HTTP fields, see the "Hypertext Transfer Protocol 628 (HTTP) Field Name Registry" maintained at 629 https://www.iana.org/assignments/http-fields/. 631 *Note:* This registry will not exist until [SEMANTICS] is 632 approved. *RFC Editor*, please remove this note prior to 633 publication. 635 Field names are strings containing a subset of ASCII characters. 636 Properties of HTTP field names and values are discussed in more 637 detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters in 638 field names MUST be converted to lowercase prior to their encoding. 639 A request or response containing uppercase characters in field names 640 MUST be treated as malformed (Section 4.1.3). 642 Like HTTP/2, HTTP/3 does not use the Connection header field to 643 indicate connection-specific fields; in this protocol, connection- 644 specific metadata is conveyed by other means. An endpoint MUST NOT 645 generate an HTTP/3 field section containing connection-specific 646 fields; any message containing connection-specific fields MUST be 647 treated as malformed (Section 4.1.3). 649 The only exception to this is the TE header field, which MAY be 650 present in an HTTP/3 request header; when it is, it MUST NOT contain 651 any value other than "trailers". 653 An intermediary transforming an HTTP/1.x message to HTTP/3 MUST 654 remove connection-specific header fields as discussed in 655 Section 7.6.1 of [SEMANTICS], or their messages will be treated by 656 other HTTP/3 endpoints as malformed (Section 4.1.3). 658 4.1.1.1. Pseudo-Header Fields 660 Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where 661 the field name begins with the ':' character (ASCII 0x3a). These 662 pseudo-header fields convey the target URI, the method of the 663 request, and the status code for the response. 665 Pseudo-header fields are not HTTP fields. Endpoints MUST NOT 666 generate pseudo-header fields other than those defined in this 667 document; however, an extension could negotiate a modification of 668 this restriction; see Section 9. 670 Pseudo-header fields are only valid in the context in which they are 671 defined. Pseudo-header fields defined for requests MUST NOT appear 672 in responses; pseudo-header fields defined for responses MUST NOT 673 appear in requests. Pseudo-header fields MUST NOT appear in trailer 674 sections. Endpoints MUST treat a request or response that contains 675 undefined or invalid pseudo-header fields as malformed 676 (Section 4.1.3). 678 All pseudo-header fields MUST appear in the header section before 679 regular header fields. Any request or response that contains a 680 pseudo-header field that appears in a header section after a regular 681 header field MUST be treated as malformed (Section 4.1.3). 683 The following pseudo-header fields are defined for requests: 685 ":method": Contains the HTTP method (Section 9 of [SEMANTICS]) 687 ":scheme": Contains the scheme portion of the target URI 688 (Section 3.1 of [URI]) 690 ":scheme" is not restricted to URIs with scheme "http" and 691 "https". A proxy or gateway can translate requests for non-HTTP 692 schemes, enabling the use of HTTP to interact with non-HTTP 693 services. 695 See Section 3.1.2 for guidance on using a scheme other than 696 "https". 698 ":authority": Contains the authority portion of the target URI 699 (Section 3.2 of [URI]). The authority MUST NOT include the 700 deprecated "userinfo" subcomponent for URIs of scheme "http" or 701 "https". 703 To ensure that the HTTP/1.1 request line can be reproduced 704 accurately, this pseudo-header field MUST be omitted when 705 translating from an HTTP/1.1 request that has a request target in 706 origin or asterisk form; see Section 7.1 of [SEMANTICS]. Clients 707 that generate HTTP/3 requests directly SHOULD use the ":authority" 708 pseudo-header field instead of the Host field. An intermediary 709 that converts an HTTP/3 request to HTTP/1.1 MUST create a Host 710 field if one is not present in a request by copying the value of 711 the ":authority" pseudo-header field. 713 ":path": Contains the path and query parts of the target URI (the 714 "path-absolute" production and optionally a '?' character followed 715 by the "query" production; see Sections 3.3 and 3.4 of [URI]. A 716 request in asterisk form includes the value '*' for the ":path" 717 pseudo-header field. 719 This pseudo-header field MUST NOT be empty for "http" or "https" 720 URIs; "http" or "https" URIs that do not contain a path component 721 MUST include a value of '/'. The exception to this rule is an 722 OPTIONS request for an "http" or "https" URI that does not include 723 a path component; these MUST include a ":path" pseudo-header field 724 with a value of '*'; see Section 7.1 of [SEMANTICS]. 726 All HTTP/3 requests MUST include exactly one value for the ":method", 727 ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT 728 request; see Section 4.2. 730 If the ":scheme" pseudo-header field identifies a scheme that has a 731 mandatory authority component (including "http" and "https"), the 732 request MUST contain either an ":authority" pseudo-header field or a 733 "Host" header field. If these fields are present, they MUST NOT be 734 empty. If both fields are present, they MUST contain the same value. 735 If the scheme does not have a mandatory authority component and none 736 is provided in the request target, the request MUST NOT contain the 737 ":authority" pseudo-header or "Host" header fields. 739 An HTTP request that omits mandatory pseudo-header fields or contains 740 invalid values for those pseudo-header fields is malformed 741 (Section 4.1.3). 743 HTTP/3 does not define a way to carry the version identifier that is 744 included in the HTTP/1.1 request line. 746 For responses, a single ":status" pseudo-header field is defined that 747 carries the HTTP status code; see Section 15 of [SEMANTICS]. This 748 pseudo-header field MUST be included in all responses; otherwise, the 749 response is malformed (Section 4.1.3). 751 HTTP/3 does not define a way to carry the version or reason phrase 752 that is included in an HTTP/1.1 status line. 754 4.1.1.2. Field Compression 756 [QPACK] describes a variation of HPACK that gives an encoder some 757 control over how much head-of-line blocking can be caused by 758 compression. This allows an encoder to balance compression 759 efficiency with latency. HTTP/3 uses QPACK to compress header and 760 trailer sections, including the pseudo-header fields present in the 761 header section. 763 To allow for better compression efficiency, the "Cookie" field 764 ([RFC6265]) MAY be split into separate field lines, each with one or 765 more cookie-pairs, before compression. If a decompressed field 766 section contains multiple cookie field lines, these MUST be 767 concatenated into a single byte string using the two-byte delimiter 768 of 0x3b, 0x20 (the ASCII string "; ") before being passed into a 769 context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, 770 or a generic HTTP server application. 772 4.1.1.3. Header Size Constraints 774 An HTTP/3 implementation MAY impose a limit on the maximum size of 775 the message header it will accept on an individual HTTP message. A 776 server that receives a larger header section than it is willing to 777 handle can send an HTTP 431 (Request Header Fields Too Large) status 778 code ([RFC6585]). A client can discard responses that it cannot 779 process. The size of a field list is calculated based on the 780 uncompressed size of fields, including the length of the name and 781 value in bytes plus an overhead of 32 bytes for each field. 783 If an implementation wishes to advise its peer of this limit, it can 784 be conveyed as a number of bytes in the 785 SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that 786 has received this parameter SHOULD NOT send an HTTP message header 787 that exceeds the indicated size, as the peer will likely refuse to 788 process it. However, an HTTP message can traverse one or more 789 intermediaries before reaching the origin server; see Section 3.7 of 790 [SEMANTICS]. Because this limit is applied separately by each 791 implementation which processes the message, messages below this limit 792 are not guaranteed to be accepted. 794 4.1.2. Request Cancellation and Rejection 796 Once a request stream has been opened, the request MAY be cancelled 797 by either endpoint. Clients cancel requests if the response is no 798 longer of interest; servers cancel requests if they are unable to or 799 choose not to respond. When possible, it is RECOMMENDED that servers 800 send an HTTP response with an appropriate status code rather than 801 canceling a request it has already begun processing. 803 Implementations SHOULD cancel requests by abruptly terminating any 804 directions of a stream that are still open. This means resetting the 805 sending parts of streams and aborting reading on receiving parts of 806 streams; see Section 2.4 of [QUIC-TRANSPORT]. 808 When the server cancels a request without performing any application 809 processing, the request is considered "rejected." The server SHOULD 810 abort its response stream with the error code H3_REQUEST_REJECTED. 811 In this context, "processed" means that some data from the stream was 812 passed to some higher layer of software that might have taken some 813 action as a result. The client can treat requests rejected by the 814 server as though they had never been sent at all, thereby allowing 815 them to be retried later. 817 Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests 818 that were partially or fully processed. When a server abandons a 819 response after partial processing, it SHOULD abort its response 820 stream with the error code H3_REQUEST_CANCELLED. 822 Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel 823 requests. Upon receipt of this error code, a server MAY abruptly 824 terminate the response using the error code H3_REQUEST_REJECTED if no 825 processing was performed. Clients MUST NOT use the 826 H3_REQUEST_REJECTED error code, except when a server has requested 827 closure of the request stream with this error code. 829 If a stream is canceled after receiving a complete response, the 830 client MAY ignore the cancellation and use the response. However, if 831 a stream is cancelled after receiving a partial response, the 832 response SHOULD NOT be used. Only idempotent actions such as GET, 833 PUT, or DELETE can be safely retried; a client SHOULD NOT 834 automatically retry a request with a non-idempotent method unless it 835 has some means to know that the request semantics are idempotent 836 independent of the method or some means to detect that the original 837 request was never applied. See Section 9.2.2 of [SEMANTICS] for more 838 details. 840 4.1.3. Malformed Requests and Responses 842 A malformed request or response is one that is an otherwise valid 843 sequence of frames but is invalid due to: 845 * the presence of prohibited fields or pseudo-header fields, 847 * the absence of mandatory pseudo-header fields, 849 * invalid values for pseudo-header fields, 850 * pseudo-header fields after fields, 852 * an invalid sequence of HTTP messages, 854 * the inclusion of uppercase field names, or 856 * the inclusion of invalid characters in field names or values. 858 A request or response that is defined as having content when it 859 contains a Content-Length header field (Section 6.4.1 of 860 [SEMANTICS]), is malformed if the value of a Content-Length header 861 field does not equal the sum of the DATA frame lengths received. A 862 response that is defined as never having content, even when a 863 Content-Length is present, can have a non-zero Content-Length field 864 even though no content is included in DATA frames. 866 Intermediaries that process HTTP requests or responses (i.e., any 867 intermediary not acting as a tunnel) MUST NOT forward a malformed 868 request or response. Malformed requests or responses that are 869 detected MUST be treated as a stream error (Section 8) of type 870 H3_MESSAGE_ERROR. 872 For malformed requests, a server MAY send an HTTP response indicating 873 the error prior to closing or resetting the stream. Clients MUST NOT 874 accept a malformed response. Note that these requirements are 875 intended to protect against several types of common attacks against 876 HTTP; they are deliberately strict because being permissive can 877 expose implementations to these vulnerabilities. 879 4.2. The CONNECT Method 881 The CONNECT method requests that the recipient establish a tunnel to 882 the destination origin server identified by the request-target; see 883 Section 9.3.6 of [SEMANTICS]. It is primarily used with HTTP proxies 884 to establish a TLS session with an origin server for the purposes of 885 interacting with "https" resources. 887 In HTTP/1.x, CONNECT is used to convert an entire HTTP connection 888 into a tunnel to a remote host. In HTTP/2 and HTTP/3, the CONNECT 889 method is used to establish a tunnel over a single stream. 891 A CONNECT request MUST be constructed as follows: 893 * The ":method" pseudo-header field is set to "CONNECT" 895 * The ":scheme" and ":path" pseudo-header fields are omitted 896 * The ":authority" pseudo-header field contains the host and port to 897 connect to (equivalent to the authority-form of the request-target 898 of CONNECT requests; see Section 7.1 of [SEMANTICS]) 900 The request stream remains open at the end of the request to carry 901 the data to be transferred. A CONNECT request that does not conform 902 to these restrictions is malformed; see Section 4.1.3. 904 A proxy that supports CONNECT establishes a TCP connection 905 ([RFC0793]) to the server identified in the ":authority" pseudo- 906 header field. Once this connection is successfully established, the 907 proxy sends a HEADERS frame containing a 2xx series status code to 908 the client, as defined in Section 15.3 of [SEMANTICS]. 910 All DATA frames on the stream correspond to data sent or received on 911 the TCP connection. The payload of any DATA frame sent by the client 912 is transmitted by the proxy to the TCP server; data received from the 913 TCP server is packaged into DATA frames by the proxy. Note that the 914 size and number of TCP segments is not guaranteed to map predictably 915 to the size and number of HTTP DATA or QUIC STREAM frames. 917 Once the CONNECT method has completed, only DATA frames are permitted 918 to be sent on the stream. Extension frames MAY be used if 919 specifically permitted by the definition of the extension. Receipt 920 of any other known frame type MUST be treated as a connection error 921 of type H3_FRAME_UNEXPECTED; see Section 8. 923 The TCP connection can be closed by either peer. When the client 924 ends the request stream (that is, the receive stream at the proxy 925 enters the "Data Recvd" state), the proxy will set the FIN bit on its 926 connection to the TCP server. When the proxy receives a packet with 927 the FIN bit set, it will close the send stream that it sends to the 928 client. TCP connections that remain half-closed in a single 929 direction are not invalid, but are often handled poorly by servers, 930 so clients SHOULD NOT close a stream for sending while they still 931 expect to receive data from the target of the CONNECT. 933 A TCP connection error is signaled by abruptly terminating the 934 stream. A proxy treats any error in the TCP connection, which 935 includes receiving a TCP segment with the RST bit set, as a stream 936 error of type H3_CONNECT_ERROR; see Section 8. Correspondingly, if a 937 proxy detects an error with the stream or the QUIC connection, it 938 MUST close the TCP connection. If the underlying TCP implementation 939 permits it, the proxy SHOULD send a TCP segment with the RST bit set. 941 Since CONNECT creates a tunnel to an arbitrary server, proxies that 942 support CONNECT SHOULD restrict its use to a set of known ports or a 943 list of safe request targets; see Section 9.3.6 of [SEMANTICS] for 944 more detail. 946 4.3. HTTP Upgrade 948 HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of 949 [SEMANTICS]) or 101 (Switching Protocols) informational status code 950 (Section 15.2.2 of [SEMANTICS]). 952 4.4. Server Push 954 Server push is an interaction mode that permits a server to push a 955 request-response exchange to a client in anticipation of the client 956 making the indicated request. This trades off network usage against 957 a potential latency gain. HTTP/3 server push is similar to what is 958 described in Section 8.2 of [HTTP2], but uses different mechanisms. 960 Each server push is assigned a unique Push ID by the server. The 961 Push ID is used to refer to the push in various contexts throughout 962 the lifetime of the HTTP/3 connection. 964 The Push ID space begins at zero, and ends at a maximum value set by 965 the MAX_PUSH_ID frame; see Section 7.2.7. In particular, a server is 966 not able to push until after the client sends a MAX_PUSH_ID frame. A 967 client sends MAX_PUSH_ID frames to control the number of pushes that 968 a server can promise. A server SHOULD use Push IDs sequentially, 969 beginning from zero. A client MUST treat receipt of a push stream as 970 a connection error of type H3_ID_ERROR (Section 8) when no 971 MAX_PUSH_ID frame has been sent or when the stream references a Push 972 ID that is greater than the maximum Push ID. 974 The Push ID is used in one or more PUSH_PROMISE frames 975 (Section 7.2.5) that carry the header section of the request message. 976 These frames are sent on the request stream that generated the push. 977 This allows the server push to be associated with a client request. 978 When the same Push ID is promised on multiple request streams, the 979 decompressed request field sections MUST contain the same fields in 980 the same order, and both the name and the value in each field MUST be 981 identical. 983 The Push ID is then included with the push stream that ultimately 984 fulfills those promises; see Section 6.2.2. The push stream 985 identifies the Push ID of the promise that it fulfills, then contains 986 a response to the promised request as described in Section 4.1. 988 Finally, the Push ID can be used in CANCEL_PUSH frames; see 989 Section 7.2.3. Clients use this frame to indicate they do not wish 990 to receive a promised resource. Servers use this frame to indicate 991 they will not be fulfilling a previous promise. 993 Not all requests can be pushed. A server MAY push requests that have 994 the following properties: 996 * cacheable; see Section 9.2.3 of [SEMANTICS] 998 * safe; see Section 9.2.1 of [SEMANTICS] 1000 * does not include a request body or trailer section 1002 The server MUST include a value in the ":authority" pseudo-header 1003 field for which the server is authoritative. If the client has not 1004 yet validated the connection for the origin indicated by the pushed 1005 request, it MUST perform the same verification process it would do 1006 before sending a request for that origin on the connection; see 1007 Section 3.3. If this verification fails, the client MUST NOT 1008 consider the server authoritative for that origin. 1010 Clients SHOULD send a CANCEL_PUSH frame upon receipt of a 1011 PUSH_PROMISE frame carrying a request that is not cacheable, is not 1012 known to be safe, that indicates the presence of a request body, or 1013 for which it does not consider the server authoritative. Any 1014 corresponding responses MUST NOT be used or cached. 1016 Each pushed response is associated with one or more client requests. 1017 The push is associated with the request stream on which the 1018 PUSH_PROMISE frame was received. The same server push can be 1019 associated with additional client requests using a PUSH_PROMISE frame 1020 with the same Push ID on multiple request streams. These 1021 associations do not affect the operation of the protocol, but MAY be 1022 considered by user agents when deciding how to use pushed resources. 1024 Ordering of a PUSH_PROMISE frame in relation to certain parts of the 1025 response is important. The server SHOULD send PUSH_PROMISE frames 1026 prior to sending HEADERS or DATA frames that reference the promised 1027 responses. This reduces the chance that a client requests a resource 1028 that will be pushed by the server. 1030 Due to reordering, push stream data can arrive before the 1031 corresponding PUSH_PROMISE frame. When a client receives a new push 1032 stream with an as-yet-unknown Push ID, both the associated client 1033 request and the pushed request header fields are unknown. The client 1034 can buffer the stream data in expectation of the matching 1035 PUSH_PROMISE. The client can use stream flow control (see 1036 Section 4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server 1037 may commit to the pushed stream. 1039 Push stream data can also arrive after a client has canceled a push. 1040 In this case, the client can abort reading the stream with an error 1041 code of H3_REQUEST_CANCELLED. This asks the server not to transfer 1042 additional data and indicates that it will be discarded upon receipt. 1044 Pushed responses that are cacheable (see Section 3 of [CACHING]) can 1045 be stored by the client, if it implements an HTTP cache. Pushed 1046 responses are considered successfully validated on the origin server 1047 (e.g., if the "no-cache" cache response directive is present; see 1048 Section 5.2.2.3 of [CACHING]) at the time the pushed response is 1049 received. 1051 Pushed responses that are not cacheable MUST NOT be stored by any 1052 HTTP cache. They MAY be made available to the application 1053 separately. 1055 5. Connection Closure 1057 Once established, an HTTP/3 connection can be used for many requests 1058 and responses over time until the connection is closed. Connection 1059 closure can happen in any of several different ways. 1061 5.1. Idle Connections 1063 Each QUIC endpoint declares an idle timeout during the handshake. If 1064 the QUIC connection remains idle (no packets received) for longer 1065 than this duration, the peer will assume that the connection has been 1066 closed. HTTP/3 implementations will need to open a new HTTP/3 1067 connection for new requests if the existing connection has been idle 1068 for longer than the idle timeout negotiated during the QUIC 1069 handshake, and SHOULD do so if approaching the idle timeout; see 1070 Section 10.1 of [QUIC-TRANSPORT]. 1072 HTTP clients are expected to request that the transport keep 1073 connections open while there are responses outstanding for requests 1074 or server pushes, as described in Section 10.1.2 of [QUIC-TRANSPORT]. 1075 If the client is not expecting a response from the server, allowing 1076 an idle connection to time out is preferred over expending effort 1077 maintaining a connection that might not be needed. A gateway MAY 1078 maintain connections in anticipation of need rather than incur the 1079 latency cost of connection establishment to servers. Servers SHOULD 1080 NOT actively keep connections open. 1082 5.2. Connection Shutdown 1084 Even when a connection is not idle, either endpoint can decide to 1085 stop using the connection and initiate a graceful connection close. 1086 Endpoints initiate the graceful shutdown of an HTTP/3 connection by 1087 sending a GOAWAY frame (Section 7.2.6). The GOAWAY frame contains an 1088 identifier that indicates to the receiver the range of requests or 1089 pushes that were or might be processed in this connection. The 1090 server sends a client-initiated bidirectional Stream ID; the client 1091 sends a Push ID (Section 4.4). Requests or pushes with the indicated 1092 identifier or greater are rejected (Section 4.1.2) by the sender of 1093 the GOAWAY. This identifier MAY be zero if no requests or pushes 1094 were processed. 1096 The information in the GOAWAY frame enables a client and server to 1097 agree on which requests or pushes were accepted prior to the shutdown 1098 of the HTTP/3 connection. Upon sending a GOAWAY frame, the endpoint 1099 SHOULD explicitly cancel (see Section 4.1.2 and Section 7.2.3) any 1100 requests or pushes that have identifiers greater than or equal to 1101 that indicated, in order to clean up transport state for the affected 1102 streams. The endpoint SHOULD continue to do so as more requests or 1103 pushes arrive. 1105 Endpoints MUST NOT initiate new requests or promise new pushes on the 1106 connection after receipt of a GOAWAY frame from the peer. Clients 1107 MAY establish a new connection to send additional requests. 1109 Some requests or pushes might already be in transit: 1111 * Upon receipt of a GOAWAY frame, if the client has already sent 1112 requests with a Stream ID greater than or equal to the identifier 1113 contained in the GOAWAY frame, those requests will not be 1114 processed. Clients can safely retry unprocessed requests on a 1115 different HTTP connection. A client that is unable to retry 1116 requests loses all requests that are in flight when the server 1117 closes the connection. 1119 Requests on Stream IDs less than the Stream ID in a GOAWAY frame 1120 from the server might have been processed; their status cannot be 1121 known until a response is received, the stream is reset 1122 individually, another GOAWAY is received with a lower Stream ID 1123 than that of the request in question, or the connection 1124 terminates. 1126 Servers MAY reject individual requests on streams below the 1127 indicated ID if these requests were not processed. 1129 * If a server receives a GOAWAY frame after having promised pushes 1130 with a Push ID greater than or equal to the identifier contained 1131 in the GOAWAY frame, those pushes will not be accepted. 1133 Servers SHOULD send a GOAWAY frame when the closing of a connection 1134 is known in advance, even if the advance notice is small, so that the 1135 remote peer can know whether a request has been partially processed 1136 or not. For example, if an HTTP client sends a POST at the same time 1137 that a server closes a QUIC connection, the client cannot know if the 1138 server started to process that POST request if the server does not 1139 send a GOAWAY frame to indicate what streams it might have acted on. 1141 An endpoint MAY send multiple GOAWAY frames indicating different 1142 identifiers, but the identifier in each frame MUST NOT be greater 1143 than the identifier in any previous frame, since clients might 1144 already have retried unprocessed requests on another HTTP connection. 1145 Receiving a GOAWAY containing a larger identifier than previously 1146 received MUST be treated as a connection error of type H3_ID_ERROR; 1147 see Section 8. 1149 An endpoint that is attempting to gracefully shut down a connection 1150 can send a GOAWAY frame with a value set to the maximum possible 1151 value (2^(62)-4 for servers, 2^(62)-1 for clients). This ensures 1152 that the peer stops creating new requests or pushes. After allowing 1153 time for any in-flight requests or pushes to arrive, the endpoint can 1154 send another GOAWAY frame indicating which requests or pushes it 1155 might accept before the end of the connection. This ensures that a 1156 connection can be cleanly shut down without losing requests. 1158 A client has more flexibility in the value it chooses for the Push ID 1159 in a GOAWAY that it sends. A value of 2^(62)-1 indicates that the 1160 server can continue fulfilling pushes that have already been 1161 promised. A smaller value indicates the client will reject pushes 1162 with Push IDs greater than or equal to this value. Like the server, 1163 the client MAY send subsequent GOAWAY frames so long as the specified 1164 Push ID is no greater than any previously sent value. 1166 Even when a GOAWAY indicates that a given request or push will not be 1167 processed or accepted upon receipt, the underlying transport 1168 resources still exist. The endpoint that initiated these requests 1169 can cancel them to clean up transport state. 1171 Once all accepted requests and pushes have been processed, the 1172 endpoint can permit the connection to become idle, or MAY initiate an 1173 immediate closure of the connection. An endpoint that completes a 1174 graceful shutdown SHOULD use the H3_NO_ERROR error code when closing 1175 the connection. 1177 If a client has consumed all available bidirectional stream IDs with 1178 requests, the server need not send a GOAWAY frame, since the client 1179 is unable to make further requests. 1181 5.3. Immediate Application Closure 1183 An HTTP/3 implementation can immediately close the QUIC connection at 1184 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 1185 the peer indicating that the application layer has terminated the 1186 connection. The application error code in this frame indicates to 1187 the peer why the connection is being closed. See Section 8 for error 1188 codes that can be used when closing a connection in HTTP/3. 1190 Before closing the connection, a GOAWAY frame MAY be sent to allow 1191 the client to retry some requests. Including the GOAWAY frame in the 1192 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 1193 of the frame being received by clients. 1195 If there are open streams that have not been explicitly closed, they 1196 are implicitly closed when the connection is closed; see Section 10.2 1197 of [QUIC-TRANSPORT]. 1199 5.4. Transport Closure 1201 For various reasons, the QUIC transport could indicate to the 1202 application layer that the connection has terminated. This might be 1203 due to an explicit closure by the peer, a transport-level error, or a 1204 change in network topology that interrupts connectivity. 1206 If a connection terminates without a GOAWAY frame, clients MUST 1207 assume that any request that was sent, whether in whole or in part, 1208 might have been processed. 1210 6. Stream Mapping and Usage 1212 A QUIC stream provides reliable in-order delivery of bytes, but makes 1213 no guarantees about order of delivery with regard to bytes on other 1214 streams. In version 1 of QUIC, the stream data containing HTTP 1215 frames is carried by QUIC STREAM frames, but this framing is 1216 invisible to the HTTP framing layer. The transport layer buffers and 1217 orders received stream data, exposing a reliable byte stream to the 1218 application. Although QUIC permits out-of-order delivery within a 1219 stream, HTTP/3 does not make use of this feature. 1221 QUIC streams can be either unidirectional, carrying data only from 1222 initiator to receiver, or bidirectional. Streams can be initiated by 1223 either the client or the server. For more detail on QUIC streams, 1224 see Section 2 of [QUIC-TRANSPORT]. 1226 When HTTP fields and data are sent over QUIC, the QUIC layer handles 1227 most of the stream management. HTTP does not need to do any separate 1228 multiplexing when using QUIC - data sent over a QUIC stream always 1229 maps to a particular HTTP transaction or to the entire HTTP/3 1230 connection context. 1232 6.1. Bidirectional Streams 1234 All client-initiated bidirectional streams are used for HTTP requests 1235 and responses. A bidirectional stream ensures that the response can 1236 be readily correlated with the request. These streams are referred 1237 to as request streams. 1239 This means that the client's first request occurs on QUIC stream 0, 1240 with subsequent requests on stream 4, 8, and so on. In order to 1241 permit these streams to open, an HTTP/3 server SHOULD configure non- 1242 zero minimum values for the number of permitted streams and the 1243 initial stream flow control window. So as to not unnecessarily limit 1244 parallelism, at least 100 request streams SHOULD be permitted at a 1245 time. 1247 HTTP/3 does not use server-initiated bidirectional streams, though an 1248 extension could define a use for these streams. Clients MUST treat 1249 receipt of a server-initiated bidirectional stream as a connection 1250 error of type H3_STREAM_CREATION_ERROR (Section 8) unless such an 1251 extension has been negotiated. 1253 6.2. Unidirectional Streams 1255 Unidirectional streams, in either direction, are used for a range of 1256 purposes. The purpose is indicated by a stream type, which is sent 1257 as a variable-length integer at the start of the stream. The format 1258 and structure of data that follows this integer is determined by the 1259 stream type. 1261 Unidirectional Stream Header { 1262 Stream Type (i), 1263 } 1265 Figure 1: Unidirectional Stream Header 1267 Two stream types are defined in this document: control streams 1268 (Section 6.2.1) and push streams (Section 6.2.2). [QPACK] defines 1269 two additional stream types. Other stream types can be defined by 1270 extensions to HTTP/3; see Section 9 for more details. Some stream 1271 types are reserved (Section 6.2.3). 1273 The performance of HTTP/3 connections in the early phase of their 1274 lifetime is sensitive to the creation and exchange of data on 1275 unidirectional streams. Endpoints that excessively restrict the 1276 number of streams or the flow control window of these streams will 1277 increase the chance that the remote peer reaches the limit early and 1278 becomes blocked. In particular, implementations should consider that 1279 remote peers may wish to exercise reserved stream behavior 1280 (Section 6.2.3) with some of the unidirectional streams they are 1281 permitted to use. To avoid blocking, the transport parameters sent 1282 by both clients and servers MUST allow the peer to create at least 1283 one unidirectional stream for the HTTP control stream plus the number 1284 of unidirectional streams required by mandatory extensions (three 1285 being the minimum number required for the base HTTP/3 protocol and 1286 QPACK), and SHOULD provide at least 1,024 bytes of flow control 1287 credit to each stream. 1289 Note that an endpoint is not required to grant additional credits to 1290 create more unidirectional streams if its peer consumes all the 1291 initial credits before creating the critical unidirectional streams. 1292 Endpoints SHOULD create the HTTP control stream as well as the 1293 unidirectional streams required by mandatory extensions (such as the 1294 QPACK encoder and decoder streams) first, and then create additional 1295 streams as allowed by their peer. 1297 If the stream header indicates a stream type that is not supported by 1298 the recipient, the remainder of the stream cannot be consumed as the 1299 semantics are unknown. Recipients of unknown stream types MAY abort 1300 reading of the stream with an error code of H3_STREAM_CREATION_ERROR 1301 or a reserved error code (Section 8.1), but MUST NOT consider such 1302 streams to be a connection error of any kind. 1304 Implementations MAY send stream types before knowing whether the peer 1305 supports them. However, stream types that could modify the state or 1306 semantics of existing protocol components, including QPACK or other 1307 extensions, MUST NOT be sent until the peer is known to support them. 1309 A sender can close or reset a unidirectional stream unless otherwise 1310 specified. A receiver MUST tolerate unidirectional streams being 1311 closed or reset prior to the reception of the unidirectional stream 1312 header. 1314 6.2.1. Control Streams 1316 A control stream is indicated by a stream type of 0x00. Data on this 1317 stream consists of HTTP/3 frames, as defined in Section 7.2. 1319 Each side MUST initiate a single control stream at the beginning of 1320 the connection and send its SETTINGS frame as the first frame on this 1321 stream. If the first frame of the control stream is any other frame 1322 type, this MUST be treated as a connection error of type 1323 H3_MISSING_SETTINGS. Only one control stream per peer is permitted; 1324 receipt of a second stream claiming to be a control stream MUST be 1325 treated as a connection error of type H3_STREAM_CREATION_ERROR. The 1326 sender MUST NOT close the control stream, and the receiver MUST NOT 1327 request that the sender close the control stream. If either control 1328 stream is closed at any point, this MUST be treated as a connection 1329 error of type H3_CLOSED_CRITICAL_STREAM. Connection errors are 1330 described in Section 8. 1332 Because the contents of the control stream are used to manage the 1333 behavior of other streams, endpoints SHOULD provide enough flow 1334 control credit to keep the peer's control stream from becoming 1335 blocked. 1337 A pair of unidirectional streams is used rather than a single 1338 bidirectional stream. This allows either peer to send data as soon 1339 as it is able. Depending on whether 0-RTT is available on the QUIC 1340 connection, either client or server might be able to send stream data 1341 first. 1343 6.2.2. Push Streams 1345 Server push is an optional feature introduced in HTTP/2 that allows a 1346 server to initiate a response before a request has been made. See 1347 Section 4.4 for more details. 1349 A push stream is indicated by a stream type of 0x01, followed by the 1350 Push ID of the promise that it fulfills, encoded as a variable-length 1351 integer. The remaining data on this stream consists of HTTP/3 1352 frames, as defined in Section 7.2, and fulfills a promised server 1353 push by zero or more interim HTTP responses followed by a single 1354 final HTTP response, as defined in Section 4.1. Server push and Push 1355 IDs are described in Section 4.4. 1357 Only servers can push; if a server receives a client-initiated push 1358 stream, this MUST be treated as a connection error of type 1359 H3_STREAM_CREATION_ERROR; see Section 8. 1361 Push Stream Header { 1362 Stream Type (i) = 0x01, 1363 Push ID (i), 1364 } 1366 Figure 2: Push Stream Header 1368 Each Push ID MUST only be used once in a push stream header. If a 1369 push stream header includes a Push ID that was used in another push 1370 stream header, the client MUST treat this as a connection error of 1371 type H3_ID_ERROR; see Section 8. 1373 6.2.3. Reserved Stream Types 1375 Stream types of the format "0x1f * N + 0x21" for non-negative integer 1376 values of N are reserved to exercise the requirement that unknown 1377 types be ignored. These streams have no semantics, and can be sent 1378 when application-layer padding is desired. They MAY also be sent on 1379 connections where no data is currently being transferred. Endpoints 1380 MUST NOT consider these streams to have any meaning upon receipt. 1382 The payload and length of the stream are selected in any manner the 1383 sending implementation chooses. When sending a reserved stream type, 1384 the implementation MAY either terminate the stream cleanly or reset 1385 it. When resetting the stream, either the H3_NO_ERROR error code or 1386 a reserved error code (Section 8.1) SHOULD be used. 1388 7. HTTP Framing Layer 1390 HTTP frames are carried on QUIC streams, as described in Section 6. 1391 HTTP/3 defines three stream types: control stream, request stream, 1392 and push stream. This section describes HTTP/3 frame formats and 1393 their permitted stream types; see Table 1 for an overview. A 1394 comparison between HTTP/2 and HTTP/3 frames is provided in 1395 Appendix A.2. 1397 +==============+================+================+========+=========+ 1398 | Frame | Control Stream | Request | Push | Section | 1399 | | | Stream | Stream | | 1400 +==============+================+================+========+=========+ 1401 | DATA | No | Yes | Yes | Section | 1402 | | | | | 7.2.1 | 1403 +--------------+----------------+----------------+--------+---------+ 1404 | HEADERS | No | Yes | Yes | Section | 1405 | | | | | 7.2.2 | 1406 +--------------+----------------+----------------+--------+---------+ 1407 | CANCEL_PUSH | Yes | No | No | Section | 1408 | | | | | 7.2.3 | 1409 +--------------+----------------+----------------+--------+---------+ 1410 | SETTINGS | Yes (1) | No | No | Section | 1411 | | | | | 7.2.4 | 1412 +--------------+----------------+----------------+--------+---------+ 1413 | PUSH_PROMISE | No | Yes | No | Section | 1414 | | | | | 7.2.5 | 1415 +--------------+----------------+----------------+--------+---------+ 1416 | GOAWAY | Yes | No | No | Section | 1417 | | | | | 7.2.6 | 1418 +--------------+----------------+----------------+--------+---------+ 1419 | MAX_PUSH_ID | Yes | No | No | Section | 1420 | | | | | 7.2.7 | 1421 +--------------+----------------+----------------+--------+---------+ 1422 | Reserved | Yes | Yes | Yes | Section | 1423 | | | | | 7.2.8 | 1424 +--------------+----------------+----------------+--------+---------+ 1426 Table 1: HTTP/3 Frames and Stream Type Overview 1428 The SETTINGS frame can only occur as the first frame of a Control 1429 stream; this is indicated in Table 1 with a (1). Specific guidance 1430 is provided in the relevant section. 1432 Note that, unlike QUIC frames, HTTP/3 frames can span multiple 1433 packets. 1435 7.1. Frame Layout 1437 All frames have the following format: 1439 HTTP/3 Frame Format { 1440 Type (i), 1441 Length (i), 1442 Frame Payload (..), 1443 } 1445 Figure 3: HTTP/3 Frame Format 1447 A frame includes the following fields: 1449 Type: A variable-length integer that identifies the frame type. 1451 Length: A variable-length integer that describes the length in bytes 1452 of the Frame Payload. 1454 Frame Payload: A payload, the semantics of which are determined by 1455 the Type field. 1457 Each frame's payload MUST contain exactly the fields identified in 1458 its description. A frame payload that contains additional bytes 1459 after the identified fields or a frame payload that terminates before 1460 the end of the identified fields MUST be treated as a connection 1461 error of type H3_FRAME_ERROR; see Section 8. In particular, 1462 redundant length encodings MUST be verified to be self-consistent; 1463 see Section 10.8. 1465 When a stream terminates cleanly, if the last frame on the stream was 1466 truncated, this MUST be treated as a connection error of type 1467 H3_FRAME_ERROR; see Section 8. Streams that terminate abruptly may 1468 be reset at any point in a frame. 1470 7.2. Frame Definitions 1472 7.2.1. DATA 1474 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1475 bytes associated with HTTP request or response content. 1477 DATA frames MUST be associated with an HTTP request or response. If 1478 a DATA frame is received on a control stream, the recipient MUST 1479 respond with a connection error of type H3_FRAME_UNEXPECTED; see 1480 Section 8. 1482 DATA Frame { 1483 Type (i) = 0x0, 1484 Length (i), 1485 Data (..), 1486 } 1488 Figure 4: DATA Frame 1490 7.2.2. HEADERS 1492 The HEADERS frame (type=0x1) is used to carry an HTTP field section, 1493 encoded using QPACK. See [QPACK] for more details. 1495 HEADERS Frame { 1496 Type (i) = 0x1, 1497 Length (i), 1498 Encoded Field Section (..), 1499 } 1501 Figure 5: HEADERS Frame 1503 HEADERS frames can only be sent on request or push streams. If a 1504 HEADERS frame is received on a control stream, the recipient MUST 1505 respond with a connection error (Section 8) of type 1506 H3_FRAME_UNEXPECTED. 1508 7.2.3. CANCEL_PUSH 1510 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 1511 server push prior to the push stream being received. The CANCEL_PUSH 1512 frame identifies a server push by Push ID (see Section 4.4), encoded 1513 as a variable-length integer. 1515 When a client sends CANCEL_PUSH, it is indicating that it does not 1516 wish to receive the promised resource. The server SHOULD abort 1517 sending the resource, but the mechanism to do so depends on the state 1518 of the corresponding push stream. If the server has not yet created 1519 a push stream, it does not create one. If the push stream is open, 1520 the server SHOULD abruptly terminate that stream. If the push stream 1521 has already ended, the server MAY still abruptly terminate the stream 1522 or MAY take no action. 1524 A server sends CANCEL_PUSH to indicate that it will not be fulfilling 1525 a promise which was previously sent. The client cannot expect the 1526 corresponding promise to be fulfilled, unless it has already received 1527 and processed the promised response. Regardless of whether a push 1528 stream has been opened, a server SHOULD send a CANCEL_PUSH frame when 1529 it determines that promise will not be fulfilled. If a stream has 1530 already been opened, the server can abort sending on the stream with 1531 an error code of H3_REQUEST_CANCELLED. 1533 Sending a CANCEL_PUSH frame has no direct effect on the state of 1534 existing push streams. A client SHOULD NOT send a CANCEL_PUSH frame 1535 when it has already received a corresponding push stream. A push 1536 stream could arrive after a client has sent a CANCEL_PUSH frame, 1537 because a server might not have processed the CANCEL_PUSH. The 1538 client SHOULD abort reading the stream with an error code of 1539 H3_REQUEST_CANCELLED. 1541 A CANCEL_PUSH frame is sent on the control stream. Receiving a 1542 CANCEL_PUSH frame on a stream other than the control stream MUST be 1543 treated as a connection error of type H3_FRAME_UNEXPECTED. 1545 CANCEL_PUSH Frame { 1546 Type (i) = 0x3, 1547 Length (i), 1548 Push ID (i), 1549 } 1551 Figure 6: CANCEL_PUSH Frame 1553 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 1554 integer. The Push ID identifies the server push that is being 1555 cancelled; see Section 4.4. If a CANCEL_PUSH frame is received that 1556 references a Push ID greater than currently allowed on the 1557 connection, this MUST be treated as a connection error of type 1558 H3_ID_ERROR. 1560 If the client receives a CANCEL_PUSH frame, that frame might identify 1561 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due 1562 to reordering. If a server receives a CANCEL_PUSH frame for a Push 1563 ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST 1564 be treated as a connection error of type H3_ID_ERROR. 1566 7.2.4. SETTINGS 1568 The SETTINGS frame (type=0x4) conveys configuration parameters that 1569 affect how endpoints communicate, such as preferences and constraints 1570 on peer behavior. Individually, a SETTINGS parameter can also be 1571 referred to as a "setting"; the identifier and value of each setting 1572 parameter can be referred to as a "setting identifier" and a "setting 1573 value". 1575 SETTINGS frames always apply to an entire HTTP/3 connection, never a 1576 single stream. A SETTINGS frame MUST be sent as the first frame of 1577 each control stream (see Section 6.2.1) by each peer, and MUST NOT be 1578 sent subsequently. If an endpoint receives a second SETTINGS frame 1579 on the control stream, the endpoint MUST respond with a connection 1580 error of type H3_FRAME_UNEXPECTED. 1582 SETTINGS frames MUST NOT be sent on any stream other than the control 1583 stream. If an endpoint receives a SETTINGS frame on a different 1584 stream, the endpoint MUST respond with a connection error of type 1585 H3_FRAME_UNEXPECTED. 1587 SETTINGS parameters are not negotiated; they describe characteristics 1588 of the sending peer that can be used by the receiving peer. However, 1589 a negotiation can be implied by the use of SETTINGS - each peer uses 1590 SETTINGS to advertise a set of supported values. The definition of 1591 the setting would describe how each peer combines the two sets to 1592 conclude which choice will be used. SETTINGS does not provide a 1593 mechanism to identify when the choice takes effect. 1595 Different values for the same parameter can be advertised by each 1596 peer. For example, a client might be willing to consume a very large 1597 response field section, while servers are more cautious about request 1598 size. 1600 The same setting identifier MUST NOT occur more than once in the 1601 SETTINGS frame. A receiver MAY treat the presence of duplicate 1602 setting identifiers as a connection error of type H3_SETTINGS_ERROR. 1604 The payload of a SETTINGS frame consists of zero or more parameters. 1605 Each parameter consists of a setting identifier and a value, both 1606 encoded as QUIC variable-length integers. 1608 Setting { 1609 Identifier (i), 1610 Value (i), 1611 } 1613 SETTINGS Frame { 1614 Type (i) = 0x4, 1615 Length (i), 1616 Setting (..) ..., 1617 } 1619 Figure 7: SETTINGS Frame 1621 An implementation MUST ignore any parameter with an identifier it 1622 does not understand. 1624 7.2.4.1. Defined SETTINGS Parameters 1626 The following settings are defined in HTTP/3: 1628 SETTINGS_MAX_FIELD_SECTION_SIZE (0x6): The default value is 1629 unlimited. See Section 4.1.1.3 for usage. 1631 Setting identifiers of the format "0x1f * N + 0x21" for non-negative 1632 integer values of N are reserved to exercise the requirement that 1633 unknown identifiers be ignored. Such settings have no defined 1634 meaning. Endpoints SHOULD include at least one such setting in their 1635 SETTINGS frame. Endpoints MUST NOT consider such settings to have 1636 any meaning upon receipt. 1638 Because the setting has no defined meaning, the value of the setting 1639 can be any value the implementation selects. 1641 Setting identifiers which were defined in [HTTP2] where there is no 1642 corresponding HTTP/3 setting have also been reserved 1643 (Section 11.2.2). These reserved settings MUST NOT be sent, and 1644 their receipt MUST be treated as a connection error of type 1645 H3_SETTINGS_ERROR. 1647 Additional settings can be defined by extensions to HTTP/3; see 1648 Section 9 for more details. 1650 7.2.4.2. Initialization 1652 An HTTP implementation MUST NOT send frames or requests that would be 1653 invalid based on its current understanding of the peer's settings. 1655 All settings begin at an initial value. Each endpoint SHOULD use 1656 these initial values to send messages before the peer's SETTINGS 1657 frame has arrived, as packets carrying the settings can be lost or 1658 delayed. When the SETTINGS frame arrives, any settings are changed 1659 to their new values. 1661 This removes the need to wait for the SETTINGS frame before sending 1662 messages. Endpoints MUST NOT require any data to be received from 1663 the peer prior to sending the SETTINGS frame; settings MUST be sent 1664 as soon as the transport is ready to send data. 1666 For servers, the initial value of each client setting is the default 1667 value. 1669 For clients using a 1-RTT QUIC connection, the initial value of each 1670 server setting is the default value. 1-RTT keys will always become 1671 available prior to the packet containing SETTINGS being processed by 1672 QUIC, even if the server sends SETTINGS immediately. Clients SHOULD 1673 NOT wait indefinitely for SETTINGS to arrive before sending requests, 1674 but SHOULD process received datagrams in order to increase the 1675 likelihood of processing SETTINGS before sending the first request. 1677 When a 0-RTT QUIC connection is being used, the initial value of each 1678 server setting is the value used in the previous session. Clients 1679 SHOULD store the settings the server provided in the HTTP/3 1680 connection where resumption information was provided, but MAY opt not 1681 to store settings in certain cases (e.g., if the session ticket is 1682 received before the SETTINGS frame). A client MUST comply with 1683 stored settings -- or default values, if no values are stored -- when 1684 attempting 0-RTT. Once a server has provided new settings, clients 1685 MUST comply with those values. 1687 A server can remember the settings that it advertised, or store an 1688 integrity-protected copy of the values in the ticket and recover the 1689 information when accepting 0-RTT data. A server uses the HTTP/3 1690 settings values in determining whether to accept 0-RTT data. If the 1691 server cannot determine that the settings remembered by a client are 1692 compatible with its current settings, it MUST NOT accept 0-RTT data. 1693 Remembered settings are compatible if a client complying with those 1694 settings would not violate the server's current settings. 1696 A server MAY accept 0-RTT and subsequently provide different settings 1697 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 1698 SETTINGS frame MUST NOT reduce any limits or alter any values that 1699 might be violated by the client with its 0-RTT data. The server MUST 1700 include all settings that differ from their default values. If a 1701 server accepts 0-RTT but then sends settings that are not compatible 1702 with the previously specified settings, this MUST be treated as a 1703 connection error of type H3_SETTINGS_ERROR. If a server accepts 1704 0-RTT but then sends a SETTINGS frame that omits a setting value that 1705 the client understands (apart from reserved setting identifiers) that 1706 was previously specified to have a non-default value, this MUST be 1707 treated as a connection error of type H3_SETTINGS_ERROR. 1709 7.2.5. PUSH_PROMISE 1711 The PUSH_PROMISE frame (type=0x5) is used to carry a promised request 1712 header section from server to client on a request stream, as in 1713 HTTP/2. 1715 PUSH_PROMISE Frame { 1716 Type (i) = 0x5, 1717 Length (i), 1718 Push ID (i), 1719 Encoded Field Section (..), 1720 } 1722 Figure 8: PUSH_PROMISE Frame 1724 The payload consists of: 1726 Push ID: A variable-length integer that identifies the server push 1727 operation. A Push ID is used in push stream headers (Section 4.4) 1728 and CANCEL_PUSH frames (Section 7.2.3). 1730 Encoded Field Section: QPACK-encoded request header fields for the 1731 promised response. See [QPACK] for more details. 1733 A server MUST NOT use a Push ID that is larger than the client has 1734 provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat 1735 receipt of a PUSH_PROMISE frame that contains a larger Push ID than 1736 the client has advertised as a connection error of H3_ID_ERROR. 1738 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 1739 If so, the decompressed request header sets MUST contain the same 1740 fields in the same order, and both the name and the value in each 1741 field MUST be exact matches. Clients SHOULD compare the request 1742 header sections for resources promised multiple times. If a client 1743 receives a Push ID that has already been promised and detects a 1744 mismatch, it MUST respond with a connection error of type 1745 H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sections match 1746 exactly, the client SHOULD associate the pushed content with each 1747 stream on which a PUSH_PROMISE frame was received. 1749 Allowing duplicate references to the same Push ID is primarily to 1750 reduce duplication caused by concurrent requests. A server SHOULD 1751 avoid reusing a Push ID over a long period. Clients are likely to 1752 consume server push responses and not retain them for reuse over 1753 time. Clients that see a PUSH_PROMISE frame that uses a Push ID that 1754 they have already consumed and discarded are forced to ignore the 1755 promise. 1757 If a PUSH_PROMISE frame is received on the control stream, the client 1758 MUST respond with a connection error of type H3_FRAME_UNEXPECTED; see 1759 Section 8. 1761 A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the 1762 receipt of a PUSH_PROMISE frame as a connection error of type 1763 H3_FRAME_UNEXPECTED; see Section 8. 1765 See Section 4.4 for a description of the overall server push 1766 mechanism. 1768 7.2.6. GOAWAY 1770 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 1771 an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint 1772 to stop accepting new requests or pushes while still finishing 1773 processing of previously received requests and pushes. This enables 1774 administrative actions, like server maintenance. GOAWAY by itself 1775 does not close a connection. 1777 GOAWAY Frame { 1778 Type (i) = 0x7, 1779 Length (i), 1780 Stream ID/Push ID (..), 1781 } 1783 Figure 9: GOAWAY Frame 1785 The GOAWAY frame is always sent on the control stream. In the server 1786 to client direction, it carries a QUIC Stream ID for a client- 1787 initiated bidirectional stream encoded as a variable-length integer. 1788 A client MUST treat receipt of a GOAWAY frame containing a Stream ID 1789 of any other type as a connection error of type H3_ID_ERROR. 1791 In the client to server direction, the GOAWAY frame carries a Push ID 1792 encoded as a variable-length integer. 1794 The GOAWAY frame applies to the entire connection, not a specific 1795 stream. A client MUST treat a GOAWAY frame on a stream other than 1796 the control stream as a connection error of type H3_FRAME_UNEXPECTED; 1797 see Section 8. 1799 See Section 5.2 for more information on the use of the GOAWAY frame. 1801 7.2.7. MAX_PUSH_ID 1803 The MAX_PUSH_ID frame (type=0xd) is used by clients to control the 1804 number of server pushes that the server can initiate. This sets the 1805 maximum value for a Push ID that the server can use in PUSH_PROMISE 1806 and CANCEL_PUSH frames. Consequently, this also limits the number of 1807 push streams that the server can initiate in addition to the limit 1808 maintained by the QUIC transport. 1810 The MAX_PUSH_ID frame is always sent on the control stream. Receipt 1811 of a MAX_PUSH_ID frame on any other stream MUST be treated as a 1812 connection error of type H3_FRAME_UNEXPECTED. 1814 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1815 receipt of a MAX_PUSH_ID frame as a connection error of type 1816 H3_FRAME_UNEXPECTED. 1818 The maximum Push ID is unset when an HTTP/3 connection is created, 1819 meaning that a server cannot push until it receives a MAX_PUSH_ID 1820 frame. A client that wishes to manage the number of promised server 1821 pushes can increase the maximum Push ID by sending MAX_PUSH_ID frames 1822 as the server fulfills or cancels server pushes. 1824 MAX_PUSH_ID Frame { 1825 Type (i) = 0xd, 1826 Length (i), 1827 Push ID (i), 1828 } 1830 Figure 10: MAX_PUSH_ID Frame 1832 The MAX_PUSH_ID frame carries a single variable-length integer that 1833 identifies the maximum value for a Push ID that the server can use; 1834 see Section 4.4. A MAX_PUSH_ID frame cannot reduce the maximum Push 1835 ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than 1836 previously received MUST be treated as a connection error of type 1837 H3_ID_ERROR. 1839 7.2.8. Reserved Frame Types 1841 Frame types of the format "0x1f * N + 0x21" for non-negative integer 1842 values of N are reserved to exercise the requirement that unknown 1843 types be ignored (Section 9). These frames have no semantics, and 1844 MAY be sent on any stream where frames are allowed to be sent. This 1845 enables their use for application-layer padding. Endpoints MUST NOT 1846 consider these frames to have any meaning upon receipt. 1848 The payload and length of the frames are selected in any manner the 1849 implementation chooses. 1851 Frame types that were used in HTTP/2 where there is no corresponding 1852 HTTP/3 frame have also been reserved (Section 11.2.1). These frame 1853 types MUST NOT be sent, and their receipt MUST be treated as a 1854 connection error of type H3_FRAME_UNEXPECTED. 1856 8. Error Handling 1858 When a stream cannot be completed successfully, QUIC allows the 1859 application to abruptly terminate (reset) that stream and communicate 1860 a reason; see Section 2.4 of [QUIC-TRANSPORT]. This is referred to 1861 as a "stream error." An HTTP/3 implementation can decide to close a 1862 QUIC stream and communicate the type of error. Wire encodings of 1863 error codes are defined in Section 8.1. Stream errors are distinct 1864 from HTTP status codes which indicate error conditions. Stream 1865 errors indicate that the sender did not transfer or consume the full 1866 request or response, while HTTP status codes indicate the result of a 1867 request that was successfully received. 1869 If an entire connection needs to be terminated, QUIC similarly 1870 provides mechanisms to communicate a reason; see Section 5.3 of 1871 [QUIC-TRANSPORT]. This is referred to as a "connection error." 1872 Similar to stream errors, an HTTP/3 implementation can terminate a 1873 QUIC connection and communicate the reason using an error code from 1874 Section 8.1. 1876 Although the reasons for closing streams and connections are called 1877 "errors," these actions do not necessarily indicate a problem with 1878 the connection or either implementation. For example, a stream can 1879 be reset if the requested resource is no longer needed. 1881 An endpoint MAY choose to treat a stream error as a connection error 1882 under certain circumstances, closing the entire connection in 1883 response to a condition on a single stream. Implementations need to 1884 consider the impact on outstanding requests before making this 1885 choice. 1887 Because new error codes can be defined without negotiation (see 1888 Section 9), use of an error code in an unexpected context or receipt 1889 of an unknown error code MUST be treated as equivalent to 1890 H3_NO_ERROR. However, closing a stream can have other effects 1891 regardless of the error code; for example, see Section 4.1. 1893 8.1. HTTP/3 Error Codes 1895 The following error codes are defined for use when abruptly 1896 terminating streams, aborting reading of streams, or immediately 1897 closing HTTP/3 connections. 1899 H3_NO_ERROR (0x100): No error. This is used when the connection or 1900 stream needs to be closed, but there is no error to signal. 1902 H3_GENERAL_PROTOCOL_ERROR (0x101): Peer violated protocol 1903 requirements in a way that does not match a more specific error 1904 code, or endpoint declines to use the more specific error code. 1906 H3_INTERNAL_ERROR (0x102): An internal error has occurred in the 1907 HTTP stack. 1909 H3_STREAM_CREATION_ERROR (0x103): The endpoint detected that its 1910 peer created a stream that it will not accept. 1912 H3_CLOSED_CRITICAL_STREAM (0x104): A stream required by the HTTP/3 1913 connection was closed or reset. 1915 H3_FRAME_UNEXPECTED (0x105): A frame was received that was not 1916 permitted in the current state or on the current stream. 1918 H3_FRAME_ERROR (0x106): A frame that fails to satisfy layout 1919 requirements or with an invalid size was received. 1921 H3_EXCESSIVE_LOAD (0x107): The endpoint detected that its peer is 1922 exhibiting a behavior that might be generating excessive load. 1924 H3_ID_ERROR (0x108): A Stream ID or Push ID was used incorrectly, 1925 such as exceeding a limit, reducing a limit, or being reused. 1927 H3_SETTINGS_ERROR (0x109): An endpoint detected an error in the 1928 payload of a SETTINGS frame. 1930 H3_MISSING_SETTINGS (0x10a): No SETTINGS frame was received at the 1931 beginning of the control stream. 1933 H3_REQUEST_REJECTED (0x10b): A server rejected a request without 1934 performing any application processing. 1936 H3_REQUEST_CANCELLED (0x10c): The request or its response (including 1937 pushed response) is cancelled. 1939 H3_REQUEST_INCOMPLETE (0x10d): The client's stream terminated 1940 without containing a fully-formed request. 1942 H3_MESSAGE_ERROR (0x10e): An HTTP message was malformed and cannot 1943 be processed. 1945 H3_CONNECT_ERROR (0x10f): The TCP connection established in response 1946 to a CONNECT request was reset or abnormally closed. 1948 H3_VERSION_FALLBACK (0x110): The requested operation cannot be 1949 served over HTTP/3. The peer should retry over HTTP/1.1. 1951 Error codes of the format "0x1f * N + 0x21" for non-negative integer 1952 values of N are reserved to exercise the requirement that unknown 1953 error codes be treated as equivalent to H3_NO_ERROR (Section 9). 1954 Implementations SHOULD select an error code from this space with some 1955 probability when they would have sent H3_NO_ERROR. 1957 9. Extensions to HTTP/3 1959 HTTP/3 permits extension of the protocol. Within the limitations 1960 described in this section, protocol extensions can be used to provide 1961 additional services or alter any aspect of the protocol. Extensions 1962 are effective only within the scope of a single HTTP/3 connection. 1964 This applies to the protocol elements defined in this document. This 1965 does not affect the existing options for extending HTTP, such as 1966 defining new methods, status codes, or fields. 1968 Extensions are permitted to use new frame types (Section 7.2), new 1969 settings (Section 7.2.4.1), new error codes (Section 8), or new 1970 unidirectional stream types (Section 6.2). Registries are 1971 established for managing these extension points: frame types 1972 (Section 11.2.1), settings (Section 11.2.2), error codes 1973 (Section 11.2.3), and stream types (Section 11.2.4). 1975 Implementations MUST ignore unknown or unsupported values in all 1976 extensible protocol elements. Implementations MUST discard frames 1977 and abort reading on unidirectional streams that have unknown or 1978 unsupported types. This means that any of these extension points can 1979 be safely used by extensions without prior arrangement or 1980 negotiation. However, where a known frame type is required to be in 1981 a specific location, such as the SETTINGS frame as the first frame of 1982 the control stream (see Section 6.2.1), an unknown frame type does 1983 not satisfy that requirement and SHOULD be treated as an error. 1985 Extensions that could change the semantics of existing protocol 1986 components MUST be negotiated before being used. For example, an 1987 extension that changes the layout of the HEADERS frame cannot be used 1988 until the peer has given a positive signal that this is acceptable. 1989 Coordinating when such a revised layout comes into effect could prove 1990 complex. As such, allocating new identifiers for new definitions of 1991 existing protocol elements is likely to be more effective. 1993 This document does not mandate a specific method for negotiating the 1994 use of an extension but notes that a setting (Section 7.2.4.1) could 1995 be used for that purpose. If both peers set a value that indicates 1996 willingness to use the extension, then the extension can be used. If 1997 a setting is used for extension negotiation, the default value MUST 1998 be defined in such a fashion that the extension is disabled if the 1999 setting is omitted. 2001 10. Security Considerations 2003 The security considerations of HTTP/3 should be comparable to those 2004 of HTTP/2 with TLS. However, many of the considerations from 2005 Section 10 of [HTTP2] apply to [QUIC-TRANSPORT] and are discussed in 2006 that document. 2008 10.1. Server Authority 2010 HTTP/3 relies on the HTTP definition of authority. The security 2011 considerations of establishing authority are discussed in 2012 Section 17.1 of [SEMANTICS]. 2014 10.2. Cross-Protocol Attacks 2016 The use of ALPN in the TLS and QUIC handshakes establishes the target 2017 application protocol before application-layer bytes are processed. 2018 This ensures that endpoints have strong assurances that peers are 2019 using the same protocol. 2021 This does not guarantee protection from all cross-protocol attacks. 2022 Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the 2023 plaintext of QUIC packets can be used to perform request forgery 2024 against endpoints that don't use authenticated transports. 2026 10.3. Intermediary Encapsulation Attacks 2028 The HTTP/3 field encoding allows the expression of names that are not 2029 valid field names in the syntax used by HTTP (Section 5.1 of 2030 [SEMANTICS]). Requests or responses containing invalid field names 2031 MUST be treated as malformed (Section 4.1.3). An intermediary 2032 therefore cannot translate an HTTP/3 request or response containing 2033 an invalid field name into an HTTP/1.1 message. 2035 Similarly, HTTP/3 can transport field values that are not valid. 2036 While most values that can be encoded will not alter field parsing, 2037 carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the 2038 zero character (NUL, ASCII 0x0) might be exploited by an attacker if 2039 they are translated verbatim. Any request or response that contains 2040 a character not permitted in a field value MUST be treated as 2041 malformed (Section 4.1.3). Valid characters are defined by the 2042 "field-content" ABNF rule in Section 5.5 of [SEMANTICS]. 2044 10.4. Cacheability of Pushed Responses 2046 Pushed responses do not have an explicit request from the client; the 2047 request is provided by the server in the PUSH_PROMISE frame. 2049 Caching responses that are pushed is possible based on the guidance 2050 provided by the origin server in the Cache-Control header field. 2051 However, this can cause issues if a single server hosts more than one 2052 tenant. For example, a server might offer multiple users each a 2053 small portion of its URI space. 2055 Where multiple tenants share space on the same server, that server 2056 MUST ensure that tenants are not able to push representations of 2057 resources that they do not have authority over. Failure to enforce 2058 this would allow a tenant to provide a representation that would be 2059 served out of cache, overriding the actual representation that the 2060 authoritative tenant provides. 2062 Clients are required to reject pushed responses for which an origin 2063 server is not authoritative; see Section 4.4. 2065 10.5. Denial-of-Service Considerations 2067 An HTTP/3 connection can demand a greater commitment of resources to 2068 operate than an HTTP/1.1 or HTTP/2 connection. The use of field 2069 compression and flow control depend on a commitment of resources for 2070 storing a greater amount of state. Settings for these features 2071 ensure that memory commitments for these features are strictly 2072 bounded. 2074 The number of PUSH_PROMISE frames is constrained in a similar 2075 fashion. A client that accepts server push SHOULD limit the number 2076 of Push IDs it issues at a time. 2078 Processing capacity cannot be guarded as effectively as state 2079 capacity. 2081 The ability to send undefined protocol elements that the peer is 2082 required to ignore can be abused to cause a peer to expend additional 2083 processing time. This might be done by setting multiple undefined 2084 SETTINGS parameters, unknown frame types, or unknown stream types. 2085 Note, however, that some uses are entirely legitimate, such as 2086 optional-to-understand extensions and padding to increase resistance 2087 to traffic analysis. 2089 Compression of field sections also offers some opportunities to waste 2090 processing resources; see Section 7 of [QPACK] for more details on 2091 potential abuses. 2093 All these features -- i.e., server push, unknown protocol elements, 2094 field compression -- have legitimate uses. These features become a 2095 burden only when they are used unnecessarily or to excess. 2097 An endpoint that does not monitor such behavior exposes itself to a 2098 risk of denial-of-service attack. Implementations SHOULD track the 2099 use of these features and set limits on their use. An endpoint MAY 2100 treat activity that is suspicious as a connection error of type 2101 H3_EXCESSIVE_LOAD (Section 8), but false positives will result in 2102 disrupting valid connections and requests. 2104 10.5.1. Limits on Field Section Size 2106 A large field section (Section 4.1) can cause an implementation to 2107 commit a large amount of state. Header fields that are critical for 2108 routing can appear toward the end of a header section, which prevents 2109 streaming of the header section to its ultimate destination. This 2110 ordering and other reasons, such as ensuring cache correctness, mean 2111 that an endpoint likely needs to buffer the entire header section. 2112 Since there is no hard limit to the size of a field section, some 2113 endpoints could be forced to commit a large amount of available 2114 memory for header fields. 2116 An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE 2117 (Section 4.1.1.3) setting to advise peers of limits that might apply 2118 on the size of field sections. This setting is only advisory, so 2119 endpoints MAY choose to send field sections that exceed this limit 2120 and risk having the request or response being treated as malformed. 2121 This setting is specific to an HTTP/3 connection, so any request or 2122 response could encounter a hop with a lower, unknown limit. An 2123 intermediary can attempt to avoid this problem by passing on values 2124 presented by different peers, but they are not obligated to do so. 2126 A server that receives a larger field section than it is willing to 2127 handle can send an HTTP 431 (Request Header Fields Too Large) status 2128 code ([RFC6585]). A client can discard responses that it cannot 2129 process. 2131 10.5.2. CONNECT Issues 2133 The CONNECT method can be used to create disproportionate load on a 2134 proxy, since stream creation is relatively inexpensive when compared 2135 to the creation and maintenance of a TCP connection. Therefore, a 2136 proxy that supports CONNECT might be more conservative in the number 2137 of simultaneous requests it accepts. 2139 A proxy might also maintain some resources for a TCP connection 2140 beyond the closing of the stream that carries the CONNECT request, 2141 since the outgoing TCP connection remains in the TIME_WAIT state. To 2142 account for this, a proxy might delay increasing the QUIC stream 2143 limits for some time after a TCP connection terminates. 2145 10.6. Use of Compression 2147 Compression can allow an attacker to recover secret data when it is 2148 compressed in the same context as data under attacker control. 2149 HTTP/3 enables compression of fields (Section 4.1.1); the following 2150 concerns also apply to the use of HTTP compressed content-codings; 2151 see Section 8.4.1 of [SEMANTICS]. 2153 There are demonstrable attacks on compression that exploit the 2154 characteristics of the web (e.g., [BREACH]). The attacker induces 2155 multiple requests containing varying plaintext, observing the length 2156 of the resulting ciphertext in each, which reveals a shorter length 2157 when a guess about the secret is correct. 2159 Implementations communicating on a secure channel MUST NOT compress 2160 content that includes both confidential and attacker-controlled data 2161 unless separate compression contexts are used for each source of 2162 data. Compression MUST NOT be used if the source of data cannot be 2163 reliably determined. 2165 Further considerations regarding the compression of field sections 2166 are described in [QPACK]. 2168 10.7. Padding and Traffic Analysis 2170 Padding can be used to obscure the exact size of frame content and is 2171 provided to mitigate specific attacks within HTTP, for example, 2172 attacks where compressed content includes both attacker-controlled 2173 plaintext and secret data (e.g., [BREACH]). 2175 Where HTTP/2 employs PADDING frames and Padding fields in other 2176 frames to make a connection more resistant to traffic analysis, 2177 HTTP/3 can either rely on transport-layer padding or employ the 2178 reserved frame and stream types discussed in Section 7.2.8 and 2179 Section 6.2.3. These methods of padding produce different results in 2180 terms of the granularity of padding, how padding is arranged in 2181 relation to the information that is being protected, whether padding 2182 is applied in the case of packet loss, and how an implementation 2183 might control padding. 2185 Reserved stream types can be used to give the appearance of sending 2186 traffic even when the connection is idle. Because HTTP traffic often 2187 occurs in bursts, apparent traffic can be used to obscure the timing 2188 or duration of such bursts, even to the point of appearing to send a 2189 constant stream of data. However, as such traffic is still flow 2190 controlled by the receiver, a failure to promptly drain such streams 2191 and provide additional flow control credit can limit the sender's 2192 ability to send real traffic. 2194 To mitigate attacks that rely on compression, disabling or limiting 2195 compression might be preferable to padding as a countermeasure. 2197 Use of padding can result in less protection than might seem 2198 immediately obvious. Redundant padding could even be 2199 counterproductive. At best, padding only makes it more difficult for 2200 an attacker to infer length information by increasing the number of 2201 frames an attacker has to observe. Incorrectly implemented padding 2202 schemes can be easily defeated. In particular, randomized padding 2203 with a predictable distribution provides very little protection; 2204 similarly, padding payloads to a fixed size exposes information as 2205 payload sizes cross the fixed-sized boundary, which could be possible 2206 if an attacker can control plaintext. 2208 10.8. Frame Parsing 2210 Several protocol elements contain nested length elements, typically 2211 in the form of frames with an explicit length containing variable- 2212 length integers. This could pose a security risk to an incautious 2213 implementer. An implementation MUST ensure that the length of a 2214 frame exactly matches the length of the fields it contains. 2216 10.9. Early Data 2218 The use of 0-RTT with HTTP/3 creates an exposure to replay attack. 2219 The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when 2220 using HTTP/3 with 0-RTT. When applying [HTTP-REPLAY] to HTTP/3, 2221 references to the TLS layer refer to the handshake performed within 2222 QUIC, while all references to application data refer to the contents 2223 of streams. 2225 10.10. Migration 2227 Certain HTTP implementations use the client address for logging or 2228 access-control purposes. Since a QUIC client's address might change 2229 during a connection (and future versions might support simultaneous 2230 use of multiple addresses), such implementations will need to either 2231 actively retrieve the client's current address or addresses when they 2232 are relevant or explicitly accept that the original address might 2233 change. 2235 10.11. Privacy Considerations 2237 Several characteristics of HTTP/3 provide an observer an opportunity 2238 to correlate actions of a single client or server over time. These 2239 include the value of settings, the timing of reactions to stimulus, 2240 and the handling of any features that are controlled by settings. 2242 As far as these create observable differences in behavior, they could 2243 be used as a basis for fingerprinting a specific client. 2245 HTTP/3's preference for using a single QUIC connection allows 2246 correlation of a user's activity on a site. Reusing connections for 2247 different origins allows for correlation of activity across those 2248 origins. 2250 Several features of QUIC solicit immediate responses and can be used 2251 by an endpoint to measure latency to their peer; this might have 2252 privacy implications in certain scenarios. 2254 11. IANA Considerations 2256 This document registers a new ALPN protocol ID (Section 11.1) and 2257 creates new registries that manage the assignment of codepoints in 2258 HTTP/3. 2260 11.1. Registration of HTTP/3 Identification String 2262 This document creates a new registration for the identification of 2263 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 2264 IDs" registry established in [RFC7301]. 2266 The "h3" string identifies HTTP/3: 2268 Protocol: HTTP/3 2270 Identification Sequence: 0x68 0x33 ("h3") 2272 Specification: This document 2274 11.2. New Registries 2276 New registries created in this document operate under the QUIC 2277 registration policy documented in Section 22.1 of [QUIC-TRANSPORT]. 2278 These registries all include the common set of fields listed in 2279 Section 22.1.1 of [QUIC-TRANSPORT]. These registries [SHALL be/are] 2280 collected under a "Hypertext Transfer Protocol version 3 (HTTP/3) 2281 Parameters" heading. 2283 The initial allocations in these registries created in this document 2284 are all assigned permanent status and list a change controller of the 2285 IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). 2287 11.2.1. Frame Types 2289 This document establishes a registry for HTTP/3 frame type codes. 2290 The "HTTP/3 Frame Type" registry governs a 62-bit space. This 2291 registry follows the QUIC registry policy; see Section 11.2. 2292 Permanent registrations in this registry are assigned using the 2293 Specification Required policy ([RFC8126]), except for values between 2294 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 2295 Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 2296 of [RFC8126]. 2298 While this registry is separate from the "HTTP/2 Frame Type" registry 2299 defined in [HTTP2], it is preferable that the assignments parallel 2300 each other where the code spaces overlap. If an entry is present in 2301 only one registry, every effort SHOULD be made to avoid assigning the 2302 corresponding value to an unrelated operation. Expert reviewers MAY 2303 reject unrelated registrations which would conflict with the same 2304 value in the corresponding registry. 2306 In addition to common fields as described in Section 11.2, permanent 2307 registrations in this registry MUST include the following field: 2309 Frame Type: A name or label for the frame type. 2311 Specifications of frame types MUST include a description of the frame 2312 layout and its semantics, including any parts of the frame that are 2313 conditionally present. 2315 The entries in Table 2 are registered by this document. 2317 +==============+=======+===============+ 2318 | Frame Type | Value | Specification | 2319 +==============+=======+===============+ 2320 | DATA | 0x0 | Section 7.2.1 | 2321 +--------------+-------+---------------+ 2322 | HEADERS | 0x1 | Section 7.2.2 | 2323 +--------------+-------+---------------+ 2324 | Reserved | 0x2 | N/A | 2325 +--------------+-------+---------------+ 2326 | CANCEL_PUSH | 0x3 | Section 7.2.3 | 2327 +--------------+-------+---------------+ 2328 | SETTINGS | 0x4 | Section 7.2.4 | 2329 +--------------+-------+---------------+ 2330 | PUSH_PROMISE | 0x5 | Section 7.2.5 | 2331 +--------------+-------+---------------+ 2332 | Reserved | 0x6 | N/A | 2333 +--------------+-------+---------------+ 2334 | GOAWAY | 0x7 | Section 7.2.6 | 2335 +--------------+-------+---------------+ 2336 | Reserved | 0x8 | N/A | 2337 +--------------+-------+---------------+ 2338 | Reserved | 0x9 | N/A | 2339 +--------------+-------+---------------+ 2340 | MAX_PUSH_ID | 0xd | Section 7.2.7 | 2341 +--------------+-------+---------------+ 2343 Table 2: Initial HTTP/3 Frame Types 2345 Each code of the format "0x1f * N + 0x21" for non-negative integer 2346 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2347 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2348 assigned values. 2350 11.2.2. Settings Parameters 2352 This document establishes a registry for HTTP/3 settings. The 2353 "HTTP/3 Settings" registry governs a 62-bit space. This registry 2354 follows the QUIC registry policy; see Section 11.2. Permanent 2355 registrations in this registry are assigned using the Specification 2356 Required policy ([RFC8126]), except for values between 0x00 and 0x3f 2357 (in hexadecimal; inclusive), which are assigned using Standards 2358 Action or IESG Approval as defined in Sections 4.9 and 4.10 of 2359 [RFC8126]. 2361 While this registry is separate from the "HTTP/2 Settings" registry 2362 defined in [HTTP2], it is preferable that the assignments parallel 2363 each other. If an entry is present in only one registry, every 2364 effort SHOULD be made to avoid assigning the corresponding value to 2365 an unrelated operation. Expert reviewers MAY reject unrelated 2366 registrations which would conflict with the same value in the 2367 corresponding registry. 2369 In addition to common fields as described in Section 11.2, permanent 2370 registrations in this registry MUST include the following fields: 2372 Setting Name: A symbolic name for the setting. Specifying a setting 2373 name is optional. 2375 Default: The value of the setting unless otherwise indicated. A 2376 default SHOULD be the most restrictive possible value. 2378 The entries in Table 3 are registered by this document. 2380 +========================+=======+=================+===========+ 2381 | Setting Name | Value | Specification | Default | 2382 +========================+=======+=================+===========+ 2383 | Reserved | 0x0 | N/A | N/A | 2384 +------------------------+-------+-----------------+-----------+ 2385 | Reserved | 0x2 | N/A | N/A | 2386 +------------------------+-------+-----------------+-----------+ 2387 | Reserved | 0x3 | N/A | N/A | 2388 +------------------------+-------+-----------------+-----------+ 2389 | Reserved | 0x4 | N/A | N/A | 2390 +------------------------+-------+-----------------+-----------+ 2391 | Reserved | 0x5 | N/A | N/A | 2392 +------------------------+-------+-----------------+-----------+ 2393 | MAX_FIELD_SECTION_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | 2394 +------------------------+-------+-----------------+-----------+ 2396 Table 3: Initial HTTP/3 Settings 2398 Each code of the format "0x1f * N + 0x21" for non-negative integer 2399 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2400 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2401 assigned values. 2403 11.2.3. Error Codes 2405 This document establishes a registry for HTTP/3 error codes. The 2406 "HTTP/3 Error Code" registry manages a 62-bit space. This registry 2407 follows the QUIC registry policy; see Section 11.2. Permanent 2408 registrations in this registry are assigned using the Specification 2409 Required policy ([RFC8126]), except for values between 0x00 and 0x3f 2410 (in hexadecimal; inclusive), which are assigned using Standards 2411 Action or IESG Approval as defined in Sections 4.9 and 4.10 of 2412 [RFC8126]. 2414 Registrations for error codes are required to include a description 2415 of the error code. An expert reviewer is advised to examine new 2416 registrations for possible duplication with existing error codes. 2417 Use of existing registrations is to be encouraged, but not mandated. 2418 Use of values that are registered in the "HTTP/2 Error Code" registry 2419 is discouraged, and expert reviewers MAY reject such registrations. 2421 In addition to common fields as described in Section 11.2, this 2422 registry includes two additional fields. Permanent registrations in 2423 this registry MUST include the following field: 2425 Name: A name for the error code. 2427 Description: A brief description of the error code semantics. 2429 The entries in Table 4 are registered by this document. These error 2430 codes were selected from the range that operates on a Specification 2431 Required policy to avoid collisions with HTTP/2 error codes. 2433 +===========================+=======+==============+===============+ 2434 | Name | Value | Description | Specification | 2435 +===========================+=======+==============+===============+ 2436 | H3_NO_ERROR | 0x100 | No error | Section 8.1 | 2437 +---------------------------+-------+--------------+---------------+ 2438 | H3_GENERAL_PROTOCOL_ERROR | 0x101 | General | Section 8.1 | 2439 | | | protocol | | 2440 | | | error | | 2441 +---------------------------+-------+--------------+---------------+ 2442 | H3_INTERNAL_ERROR | 0x102 | Internal | Section 8.1 | 2443 | | | error | | 2444 +---------------------------+-------+--------------+---------------+ 2445 | H3_STREAM_CREATION_ERROR | 0x103 | Stream | Section 8.1 | 2446 | | | creation | | 2447 | | | error | | 2448 +---------------------------+-------+--------------+---------------+ 2449 | H3_CLOSED_CRITICAL_STREAM | 0x104 | Critical | Section 8.1 | 2450 | | | stream was | | 2451 | | | closed | | 2452 +---------------------------+-------+--------------+---------------+ 2453 | H3_FRAME_UNEXPECTED | 0x105 | Frame not | Section 8.1 | 2454 | | | permitted in | | 2455 | | | the current | | 2456 | | | state | | 2457 +---------------------------+-------+--------------+---------------+ 2458 | H3_FRAME_ERROR | 0x106 | Frame | Section 8.1 | 2459 | | | violated | | 2460 | | | layout or | | 2461 | | | size rules | | 2462 +---------------------------+-------+--------------+---------------+ 2463 | H3_EXCESSIVE_LOAD | 0x107 | Peer | Section 8.1 | 2464 | | | generating | | 2465 | | | excessive | | 2466 | | | load | | 2467 +---------------------------+-------+--------------+---------------+ 2468 | H3_ID_ERROR | 0x108 | An | Section 8.1 | 2469 | | | identifier | | 2470 | | | was used | | 2471 | | | incorrectly | | 2472 +---------------------------+-------+--------------+---------------+ 2473 | H3_SETTINGS_ERROR | 0x109 | SETTINGS | Section 8.1 | 2474 | | | frame | | 2475 | | | contained | | 2476 | | | invalid | | 2477 | | | values | | 2478 +---------------------------+-------+--------------+---------------+ 2479 | H3_MISSING_SETTINGS | 0x10a | No SETTINGS | Section 8.1 | 2480 | | | frame | | 2481 | | | received | | 2482 +---------------------------+-------+--------------+---------------+ 2483 | H3_REQUEST_REJECTED | 0x10b | Request not | Section 8.1 | 2484 | | | processed | | 2485 +---------------------------+-------+--------------+---------------+ 2486 | H3_REQUEST_CANCELLED | 0x10c | Data no | Section 8.1 | 2487 | | | longer | | 2488 | | | needed | | 2489 +---------------------------+-------+--------------+---------------+ 2490 | H3_REQUEST_INCOMPLETE | 0x10d | Stream | Section 8.1 | 2491 | | | terminated | | 2492 | | | early | | 2493 +---------------------------+-------+--------------+---------------+ 2494 | H3_MESSAGE_ERROR | 0x10e | Malformed | Section 8.1 | 2495 | | | message | | 2496 +---------------------------+-------+--------------+---------------+ 2497 | H3_CONNECT_ERROR | 0x10f | TCP reset or | Section 8.1 | 2498 | | | error on | | 2499 | | | CONNECT | | 2500 | | | request | | 2501 +---------------------------+-------+--------------+---------------+ 2502 | H3_VERSION_FALLBACK | 0x110 | Retry over | Section 8.1 | 2503 | | | HTTP/1.1 | | 2504 +---------------------------+-------+--------------+---------------+ 2506 Table 4: Initial HTTP/3 Error Codes 2508 Each code of the format "0x1f * N + 0x21" for non-negative integer 2509 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2510 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2511 assigned values. 2513 11.2.4. Stream Types 2515 This document establishes a registry for HTTP/3 unidirectional stream 2516 types. The "HTTP/3 Stream Type" registry governs a 62-bit space. 2517 This registry follows the QUIC registry policy; see Section 11.2. 2518 Permanent registrations in this registry are assigned using the 2519 Specification Required policy ([RFC8126]), except for values between 2520 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 2521 Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 2522 of [RFC8126]. 2524 In addition to common fields as described in Section 11.2, permanent 2525 registrations in this registry MUST include the following fields: 2527 Stream Type: A name or label for the stream type. 2529 Sender: Which endpoint on an HTTP/3 connection may initiate a stream 2530 of this type. Values are "Client", "Server", or "Both". 2532 Specifications for permanent registrations MUST include a description 2533 of the stream type, including the layout and semantics of the stream 2534 contents. 2536 The entries in the following table are registered by this document. 2538 +================+=======+===============+========+ 2539 | Stream Type | Value | Specification | Sender | 2540 +================+=======+===============+========+ 2541 | Control Stream | 0x00 | Section 6.2.1 | Both | 2542 +----------------+-------+---------------+--------+ 2543 | Push Stream | 0x01 | Section 4.4 | Server | 2544 +----------------+-------+---------------+--------+ 2546 Table 5 2548 Each code of the format "0x1f * N + 0x21" for non-negative integer 2549 values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) 2550 MUST NOT be assigned by IANA and MUST NOT appear in the listing of 2551 assigned values. 2553 12. References 2555 12.1. Normative References 2557 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2558 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2559 April 2016, . 2561 [CACHING] Fielding, R., Nottingham, M., and J. Reschke, "HTTP 2562 Caching", Work in Progress, Internet-Draft, draft-ietf- 2563 httpbis-cache-14, 12 January 2021, . 2566 [HTTP-REPLAY] 2567 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 2568 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2569 2018, . 2571 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 2572 Header Compression for HTTP over QUIC", Work in Progress, 2573 Internet-Draft, draft-ietf-quic-qpack-21, 2 February 2021, 2574 . 2576 [QUIC-TRANSPORT] 2577 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2578 Multiplexed and Secure Transport", Work in Progress, 2579 Internet-Draft, draft-ietf-quic-transport-34, 2 February 2580 2021, . 2583 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2584 RFC 793, DOI 10.17487/RFC0793, September 1981, 2585 . 2587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2588 Requirement Levels", BCP 14, RFC 2119, 2589 DOI 10.17487/RFC2119, March 1997, 2590 . 2592 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2593 Extensions: Extension Definitions", RFC 6066, 2594 DOI 10.17487/RFC6066, January 2011, 2595 . 2597 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2598 DOI 10.17487/RFC6265, April 2011, 2599 . 2601 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2602 "Transport Layer Security (TLS) Application-Layer Protocol 2603 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2604 July 2014, . 2606 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2607 Writing an IANA Considerations Section in RFCs", BCP 26, 2608 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2609 . 2611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2613 May 2017, . 2615 [SEMANTICS] 2616 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 2617 Semantics", Work in Progress, Internet-Draft, draft-ietf- 2618 httpbis-semantics-14, 12 January 2021, 2619 . 2622 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2623 Resource Identifier (URI): Generic Syntax", STD 66, 2624 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2625 . 2627 12.2. Informative References 2629 [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the 2630 CRIME Attack", July 2013, 2631 . 2634 [DNS-TERMS] 2635 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2636 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2637 January 2019, . 2639 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 2640 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 2641 . 2643 [HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1", 2644 Work in Progress, Internet-Draft, draft-ietf-httpbis- 2645 messaging-14, 12 January 2021, . 2648 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2649 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2650 DOI 10.17487/RFC7540, May 2015, 2651 . 2653 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 2654 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 2655 . 2657 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 2658 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 2659 . 2661 [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2662 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2663 . 2665 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2666 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2667 . 2669 Appendix A. Considerations for Transitioning from HTTP/2 2671 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 2672 This section describes the approach taken to design HTTP/3, points 2673 out important differences from HTTP/2, and describes how to map 2674 HTTP/2 extensions into HTTP/3. 2676 HTTP/3 begins from the premise that similarity to HTTP/2 is 2677 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 2678 where QUIC differs from TCP, either to take advantage of QUIC 2679 features (like streams) or to accommodate important shortcomings 2680 (such as a lack of total ordering). These differences make HTTP/3 2681 similar to HTTP/2 in key aspects, such as the relationship of 2682 requests and responses to streams. However, the details of the 2683 HTTP/3 design are substantially different from HTTP/2. 2685 Some important departures are noted in this section. 2687 A.1. Streams 2689 HTTP/3 permits use of a larger number of streams (2^(62)-1) than 2690 HTTP/2. The same considerations about exhaustion of stream 2691 identifier space apply, though the space is significantly larger such 2692 that it is likely that other limits in QUIC are reached first, such 2693 as the limit on the connection flow control window. 2695 In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by 2696 QUIC. QUIC considers a stream closed when all data has been received 2697 and sent data has been acknowledged by the peer. HTTP/2 considers a 2698 stream closed when the frame containing the END_STREAM bit has been 2699 committed to the transport. As a result, the stream for an 2700 equivalent exchange could remain "active" for a longer period of 2701 time. HTTP/3 servers might choose to permit a larger number of 2702 concurrent client-initiated bidirectional streams to achieve 2703 equivalent concurrency to HTTP/2, depending on the expected usage 2704 patterns. 2706 In HTTP/2, only request and response bodies (the frame payload of 2707 DATA frames) are subject to flow control. All HTTP/3 frames are sent 2708 on QUIC streams, so all frames on all streams are flow-controlled in 2709 HTTP/3. 2711 Due to the presence of other unidirectional stream types, HTTP/3 does 2712 not rely exclusively on the number of concurrent unidirectional 2713 streams to control the number of concurrent in-flight pushes. 2714 Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the 2715 number of pushes received from an HTTP/3 server. 2717 A.2. HTTP Frame Types 2719 Many framing concepts from HTTP/2 can be elided on QUIC, because the 2720 transport deals with them. Because frames are already on a stream, 2721 they can omit the stream number. Because frames do not block 2722 multiplexing (QUIC's multiplexing occurs below this layer), the 2723 support for variable-maximum-length packets can be removed. Because 2724 stream termination is handled by QUIC, an END_STREAM flag is not 2725 required. This permits the removal of the Flags field from the 2726 generic frame layout. 2728 Frame payloads are largely drawn from [HTTP2]. However, QUIC 2729 includes many features (e.g., flow control) that are also present in 2730 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 2731 As a result, several HTTP/2 frame types are not required in HTTP/3. 2732 Where an HTTP/2-defined frame is no longer used, the frame ID has 2733 been reserved in order to maximize portability between HTTP/2 and 2734 HTTP/3 implementations. However, even frame types that appear in 2735 both mappings do not have identical semantics. 2737 Many of the differences arise from the fact that HTTP/2 provides an 2738 absolute ordering between frames across all streams, while QUIC 2739 provides this guarantee on each stream only. As a result, if a frame 2740 type makes assumptions that frames from different streams will still 2741 be received in the order sent, HTTP/3 will break them. 2743 Some examples of feature adaptations are described below, as well as 2744 general guidance to extension frame implementors converting an HTTP/2 2745 extension to HTTP/3. 2747 A.2.1. Prioritization Differences 2749 HTTP/2 specifies priority assignments in PRIORITY frames and 2750 (optionally) in HEADERS frames. HTTP/3 does not provide a means of 2751 signaling priority. 2753 Note that while there is no explicit signaling for priority, this 2754 does not mean that prioritization is not important for achieving good 2755 performance. 2757 A.2.2. Field Compression Differences 2759 HPACK was designed with the assumption of in-order delivery. A 2760 sequence of encoded field sections must arrive (and be decoded) at an 2761 endpoint in the same order in which they were encoded. This ensures 2762 that the dynamic state at the two endpoints remains in sync. 2764 Because this total ordering is not provided by QUIC, HTTP/3 uses a 2765 modified version of HPACK, called QPACK. QPACK uses a single 2766 unidirectional stream to make all modifications to the dynamic table, 2767 ensuring a total order of updates. All frames that contain encoded 2768 fields merely reference the table state at a given time without 2769 modifying it. 2771 [QPACK] provides additional details. 2773 A.2.3. Flow Control Differences 2775 HTTP/2 specifies a stream flow control mechanism. Although all 2776 HTTP/2 frames are delivered on streams, only the DATA frame payload 2777 is subject to flow control. QUIC provides flow control for stream 2778 data and all HTTP/3 frame types defined in this document are sent on 2779 streams. Therefore, all frame headers and payload are subject to 2780 flow control. 2782 A.2.4. Guidance for New Frame Type Definitions 2784 Frame type definitions in HTTP/3 often use the QUIC variable-length 2785 integer encoding. In particular, Stream IDs use this encoding, which 2786 allows for a larger range of possible values than the encoding used 2787 in HTTP/2. Some frames in HTTP/3 use an identifier other than a 2788 Stream ID (e.g., Push IDs). Redefinition of the encoding of 2789 extension frame types might be necessary if the encoding includes a 2790 Stream ID. 2792 Because the Flags field is not present in generic HTTP/3 frames, 2793 those frames that depend on the presence of flags need to allocate 2794 space for flags as part of their frame payload. 2796 Other than these issues, frame type HTTP/2 extensions are typically 2797 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2798 control stream in HTTP/3. HTTP/3 extensions will not assume 2799 ordering, but would not be harmed by ordering, and are expected to be 2800 portable to HTTP/2. 2802 A.2.5. Comparison Between HTTP/2 and HTTP/3 Frame Types 2804 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2805 Section 7.2.1. 2807 HEADERS (0x1): The PRIORITY region of HEADERS is not defined in 2808 HTTP/3 frames. Padding is not defined in HTTP/3 frames. See 2809 Section 7.2.2. 2811 PRIORITY (0x2): As described in Appendix A.2.1, HTTP/3 does not 2812 provide a means of signaling priority. 2814 RST_STREAM (0x3): RST_STREAM frames do not exist in HTTP/3, since 2815 QUIC provides stream lifecycle management. The same code point is 2816 used for the CANCEL_PUSH frame (Section 7.2.3). 2818 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2819 the connection. See Section 7.2.4 and Appendix A.3. 2821 PUSH_PROMISE (0x5): The PUSH_PROMISE frame does not reference a 2822 stream; instead the push stream references the PUSH_PROMISE frame 2823 using a Push ID. See Section 7.2.5. 2825 PING (0x6): PING frames do not exist in HTTP/3, as QUIC provides 2826 equivalent functionality. 2828 GOAWAY (0x7): GOAWAY does not contain an error code. In the client 2829 to server direction, it carries a Push ID instead of a server 2830 initiated stream ID. See Section 7.2.6. 2832 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist in HTTP/3, 2833 since QUIC provides flow control. 2835 CONTINUATION (0x9): CONTINUATION frames do not exist in HTTP/3; 2836 instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are 2837 permitted. 2839 Frame types defined by extensions to HTTP/2 need to be separately 2840 registered for HTTP/3 if still applicable. The IDs of frames defined 2841 in [HTTP2] have been reserved for simplicity. Note that the frame 2842 type space in HTTP/3 is substantially larger (62 bits versus 8 bits), 2843 so many HTTP/3 frame types have no equivalent HTTP/2 code points. 2844 See Section 11.2.1. 2846 A.3. HTTP/2 SETTINGS Parameters 2848 An important difference from HTTP/2 is that settings are sent once, 2849 as the first frame of the control stream, and thereafter cannot 2850 change. This eliminates many corner cases around synchronization of 2851 changes. 2853 Some transport-level options that HTTP/2 specifies via the SETTINGS 2854 frame are superseded by QUIC transport parameters in HTTP/3. The 2855 HTTP-level setting that is retained in HTTP/3 has the same value as 2856 in HTTP/2. The superseded settings are reserved, and their receipt 2857 is an error. See Section 7.2.4.1 for discussion of both the retained 2858 and reserved values. 2860 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2862 SETTINGS_HEADER_TABLE_SIZE (0x1): See [QPACK]. 2864 SETTINGS_ENABLE_PUSH (0x2): This is removed in favor of the 2865 MAX_PUSH_ID frame, which provides a more granular control over 2866 server push. Specifying a setting with the identifier 0x2 2867 (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the 2868 HTTP/3 SETTINGS frame is an error. 2870 SETTINGS_MAX_CONCURRENT_STREAMS (0x3): QUIC controls the largest 2871 open Stream ID as part of its flow control logic. Specifying a 2872 setting with the identifier 0x3 (corresponding to the 2873 SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS 2874 frame is an error. 2876 SETTINGS_INITIAL_WINDOW_SIZE (0x4): QUIC requires both stream and 2877 connection flow control window sizes to be specified in the 2878 initial transport handshake. Specifying a setting with the 2879 identifier 0x4 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE 2880 parameter) in the HTTP/3 SETTINGS frame is an error. 2882 SETTINGS_MAX_FRAME_SIZE (0x5): This setting has no equivalent in 2883 HTTP/3. Specifying a setting with the identifier 0x5 2884 (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the 2885 HTTP/3 SETTINGS frame is an error. 2887 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This setting identifier has 2888 been renamed SETTINGS_MAX_FIELD_SECTION_SIZE. 2890 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2891 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2892 This will often produce a shorter encoding, but can produce a longer 2893 encoding for settings that use the full 32-bit space. Settings 2894 ported from HTTP/2 might choose to redefine their value to limit it 2895 to 30 bits for more efficient encoding, or to make use of the 62-bit 2896 space if more than 30 bits are required. 2898 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2899 IDs of settings defined in [HTTP2] have been reserved for simplicity. 2900 Note that the settings identifier space in HTTP/3 is substantially 2901 larger (62 bits versus 16 bits), so many HTTP/3 settings have no 2902 equivalent HTTP/2 code point. See Section 11.2.2. 2904 As QUIC streams might arrive out of order, endpoints are advised not 2905 to wait for the peers' settings to arrive before responding to other 2906 streams. See Section 7.2.4.2. 2908 A.4. HTTP/2 Error Codes 2910 QUIC has the same concepts of "stream" and "connection" errors that 2911 HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 2912 mean that error codes are not directly portable between versions. 2914 The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map 2915 to the HTTP/3 error codes as follows: 2917 NO_ERROR (0x0): H3_NO_ERROR in Section 8.1. 2919 PROTOCOL_ERROR (0x1): This is mapped to H3_GENERAL_PROTOCOL_ERROR 2920 except in cases where more specific error codes have been defined. 2921 Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and 2922 H3_CLOSED_CRITICAL_STREAM defined in Section 8.1. 2924 INTERNAL_ERROR (0x2): H3_INTERNAL_ERROR in Section 8.1. 2926 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2927 control. 2929 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgment of 2930 SETTINGS is defined. 2932 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2933 management. 2935 FRAME_SIZE_ERROR (0x6): H3_FRAME_ERROR error code defined in 2936 Section 8.1. 2938 REFUSED_STREAM (0x7): H3_REQUEST_REJECTED (in Section 8.1) is used 2939 to indicate that a request was not processed. Otherwise, not 2940 applicable because QUIC handles stream management. 2942 CANCEL (0x8): H3_REQUEST_CANCELLED in Section 8.1. 2944 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2945 [QPACK]. 2947 CONNECT_ERROR (0xa): H3_CONNECT_ERROR in Section 8.1. 2949 ENHANCE_YOUR_CALM (0xb): H3_EXCESSIVE_LOAD in Section 8.1. 2951 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2952 provide sufficient security on all connections. 2954 HTTP_1_1_REQUIRED (0xd): H3_VERSION_FALLBACK in Section 8.1. 2956 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2957 Section 11.2.3. 2959 A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors 2961 An intermediary that converts between HTTP/2 and HTTP/3 may encounter 2962 error conditions from either upstream. It is useful to communicate 2963 the occurrence of error to the downstream but error codes largely 2964 reflect connection-local problems that generally do not make sense to 2965 propagate. 2967 An intermediary that encounters an error from an upstream origin can 2968 indicate this by sending an HTTP status code such as 502, which is 2969 suitable for a broad class of errors. 2971 There are some rare cases where it is beneficial to propagate the 2972 error by mapping it to the closest matching error type to the 2973 receiver. For example, an intermediary that receives an HTTP/2 2974 stream error of type REFUSED_STREAM from the origin has a clear 2975 signal that the request was not processed and that the request is 2976 safe to retry. Propagating this error condition to the client as an 2977 HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to 2978 take the action it deems most appropriate. In the reverse direction, 2979 the intermediary might deem it beneficial to pass on client request 2980 cancellations that are indicated by terminating a stream with 2981 H3_REQUEST_CANCELLED; see Section 4.1.2. 2983 Conversion between errors is described in the logical mapping. The 2984 error codes are defined in non-overlapping spaces in order to protect 2985 against accidental conversion that could result in the use of 2986 inappropriate or unknown error codes for the target version. An 2987 intermediary is permitted to promote stream errors to connection 2988 errors but they should be aware of the cost to the HTTP/3 connection 2989 for what might be a temporary or intermittent error. 2991 Appendix B. Change Log 2993 *RFC Editor's Note:* Please remove this section prior to 2994 publication of a final version of this document. 2996 B.1. Since draft-ietf-quic-http-32 2998 * Removed draft version guidance; added final version string 3000 * Added H3_MESSAGE_ERROR for malformed messages 3002 B.2. Since draft-ietf-quic-http-31 3004 Editorial changes only. 3006 B.3. Since draft-ietf-quic-http-30 3008 Editorial changes only. 3010 B.4. Since draft-ietf-quic-http-29 3012 * Require a connection error if a reserved frame type that 3013 corresponds to a frame in HTTP/2 is received (#3991, #3993) 3015 * Require a connection error if a reserved setting that corresponds 3016 to a setting in HTTP/2 is received (#3954, #3955) 3018 B.5. Since draft-ietf-quic-http-28 3020 * CANCEL_PUSH is recommended even when the stream is reset (#3698, 3021 #3700) 3023 * Use H3_ID_ERROR when GOAWAY contains a larger identifier (#3631, 3024 #3634) 3026 B.6. Since draft-ietf-quic-http-27 3028 * Updated text to refer to latest HTTP revisions 3030 * Use the HTTP definition of authority for establishing and 3031 coalescing connections (#253, #2223, #3558) 3033 * Define use of GOAWAY from both endpoints (#2632, #3129) 3035 * Require either :authority or Host if the URI scheme has a 3036 mandatory authority component (#3408, #3475) 3038 B.7. Since draft-ietf-quic-http-26 3040 * No changes 3042 B.8. Since draft-ietf-quic-http-25 3044 * Require QUICv1 for HTTP/3 (#3117, #3323) 3046 * Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275, 3047 #3309) 3049 * Clarify the definition of "malformed" (#3352, #3345) 3051 B.9. Since draft-ietf-quic-http-24 3053 * Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended 3054 instead (#3130,#3208) 3056 * Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331) 3058 * Some error codes are reserved for greasing (#3325,#3360) 3060 B.10. Since draft-ietf-quic-http-23 3062 * Removed "quic" Alt-Svc parameter (#3061,#3118) 3064 * Clients need not persist unknown settings for use in 0-RTT 3065 (#3110,#3113) 3067 * Clarify error cases around CANCEL_PUSH (#2819,#3083) 3069 B.11. Since draft-ietf-quic-http-22 3071 * Removed priority signaling (#2922,#2924) 3073 * Further changes to error codes (#2662,#2551): 3075 - Error codes renumbered 3077 - HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR, 3078 HTTP_ID_ERROR, and others 3080 * Clarify how unknown frame types interact with required frame 3081 sequence (#2867,#2858) 3083 * Describe interactions with the transport in terms of defined 3084 interface terms (#2857,#2805) 3086 * Require the use of the "http-opportunistic" resource (RFC 8164) 3087 when scheme is "http" (#2439,#2973) 3089 * Settings identifiers cannot be duplicated (#2979) 3091 * Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945): 3093 - Servers must send all settings with non-default values in their 3094 SETTINGS frame, even when resuming 3096 - If a client doesn't have settings associated with a 0-RTT 3097 ticket, it uses the defaults 3099 - Servers can't accept early data if they cannot recover the 3100 settings the client will have remembered 3102 * Clarify that Upgrade and the 101 status code are prohibited 3103 (#2898,#2889) 3105 * Clarify that frame types reserved for greasing can occur on any 3106 stream, but frame types reserved due to HTTP/2 correspondence are 3107 prohibited (#2997,#2692,#2693) 3109 * Unknown error codes cannot be treated as errors (#2998,#2816) 3111 B.12. Since draft-ietf-quic-http-21 3113 No changes 3115 B.13. Since draft-ietf-quic-http-20 3117 * Prohibit closing the control stream (#2509, #2666) 3119 * Change default priority to use an orphan node (#2502, #2690) 3121 * Exclusive priorities are restored (#2754, #2781) 3123 * Restrict use of frames when using CONNECT (#2229, #2702) 3125 * Close and maybe reset streams if a connection error occurs for 3126 CONNECT (#2228, #2703) 3128 * Encourage provision of sufficient unidirectional streams for QPACK 3129 (#2100, #2529, #2762) 3131 * Allow extensions to use server-initiated bidirectional streams 3132 (#2711, #2773) 3134 * Clarify use of maximum header list size setting (#2516, #2774) 3136 * Extensive changes to error codes and conditions of their sending 3138 - Require connection errors for more error conditions (#2511, 3139 #2510) 3141 - Updated the error codes for illegal GOAWAY frames (#2714, 3142 #2707) 3144 - Specified error code for HEADERS on control stream (#2708) 3146 - Specified error code for servers receiving PUSH_PROMISE (#2709) 3147 - Specified error code for receiving DATA before HEADERS (#2715) 3149 - Describe malformed messages and their handling (#2410, #2764) 3151 - Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813) 3153 - Refactor Push ID related errors (#2818, #2820) 3155 - Rationalize HTTP/3 stream creation errors (#2821, #2822) 3157 B.14. Since draft-ietf-quic-http-19 3159 * SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530) 3161 * Non-zero bits in the Empty field of the PRIORITY frame MAY be 3162 treated as an error (#2501) 3164 B.15. Since draft-ietf-quic-http-18 3166 * Resetting streams following a GOAWAY is recommended, but not 3167 required (#2256,#2457) 3169 * Use variable-length integers throughout (#2437,#2233,#2253,#2275) 3171 - Variable-length frame types, stream types, and settings 3172 identifiers 3174 - Renumbered stream type assignments 3176 - Modified associated reserved values 3178 * Frame layout switched from Length-Type-Value to Type-Length-Value 3179 (#2395,#2235) 3181 * Specified error code for servers receiving DUPLICATE_PUSH (#2497) 3183 * Use connection error for invalid PRIORITY (#2507, #2508) 3185 B.16. Since draft-ietf-quic-http-17 3187 * HTTP_REQUEST_REJECTED is used to indicate a request can be retried 3188 (#2106, #2325) 3190 * Changed error code for GOAWAY on the wrong stream (#2231, #2343) 3192 B.17. Since draft-ietf-quic-http-16 3194 * Rename "HTTP/QUIC" to "HTTP/3" (#1973) 3196 * Changes to PRIORITY frame (#1865, #2075) 3198 - Permitted as first frame of request streams 3200 - Remove exclusive reprioritization 3202 - Changes to Prioritized Element Type bits 3204 * Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 3205 (#2072) 3207 * Set defaults for settings, allow request before receiving SETTINGS 3208 (#1809, #1846, #2038) 3210 * Clarify message processing rules for streams that aren't closed 3211 (#1972, #2003) 3213 * Removed reservation of error code 0 and moved HTTP_NO_ERROR to 3214 this value (#1922) 3216 * Removed prohibition of zero-length DATA frames (#2098) 3218 B.18. Since draft-ietf-quic-http-15 3220 Substantial editorial reorganization; no technical changes. 3222 B.19. Since draft-ietf-quic-http-14 3224 * Recommend sensible values for QUIC transport parameters 3225 (#1720,#1806) 3227 * Define error for missing SETTINGS frame (#1697,#1808) 3229 * Setting values are variable-length integers (#1556,#1807) and do 3230 not have separate maximum values (#1820) 3232 * Expanded discussion of connection closure (#1599,#1717,#1712) 3234 * HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 3236 B.20. Since draft-ietf-quic-http-13 3238 * Reserved some frame types for grease (#1333, #1446) 3239 * Unknown unidirectional stream types are tolerated, not errors; 3240 some reserved for grease (#1490, #1525) 3242 * Require settings to be remembered for 0-RTT, prohibit reductions 3243 (#1541, #1641) 3245 * Specify behavior for truncated requests (#1596, #1643) 3247 B.21. Since draft-ietf-quic-http-12 3249 * TLS SNI extension isn't mandatory if an alternative method is used 3250 (#1459, #1462, #1466) 3252 * Removed flags from HTTP/3 frames (#1388, #1398) 3254 * Reserved frame types and settings for use in preserving 3255 extensibility (#1333, #1446) 3257 * Added general error code (#1391, #1397) 3259 * Unidirectional streams carry a type byte and are extensible 3260 (#910,#1359) 3262 * Priority mechanism now uses explicit placeholders to enable 3263 persistent structure in the tree (#441,#1421,#1422) 3265 B.22. Since draft-ietf-quic-http-11 3267 * Moved QPACK table updates and acknowledgments to dedicated streams 3268 (#1121, #1122, #1238) 3270 B.23. Since draft-ietf-quic-http-10 3272 * Settings need to be remembered when attempting and accepting 0-RTT 3273 (#1157, #1207) 3275 B.24. Since draft-ietf-quic-http-09 3277 * Selected QCRAM for header compression (#228, #1117) 3279 * The server_name TLS extension is now mandatory (#296, #495) 3281 * Specified handling of unsupported versions in Alt-Svc (#1093, 3282 #1097) 3284 B.25. Since draft-ietf-quic-http-08 3286 * Clarified connection coalescing rules (#940, #1024) 3288 B.26. Since draft-ietf-quic-http-07 3290 * Changes for integer encodings in QUIC (#595,#905) 3292 * Use unidirectional streams as appropriate (#515, #240, #281, #886) 3294 * Improvement to the description of GOAWAY (#604, #898) 3296 * Improve description of server push usage (#947, #950, #957) 3298 B.27. Since draft-ietf-quic-http-06 3300 * Track changes in QUIC error code usage (#485) 3302 B.28. Since draft-ietf-quic-http-05 3304 * Made push ID sequential, add MAX_PUSH_ID, remove 3305 SETTINGS_ENABLE_PUSH (#709) 3307 * Guidance about keep-alive and QUIC PINGs (#729) 3309 * Expanded text on GOAWAY and cancellation (#757) 3311 B.29. Since draft-ietf-quic-http-04 3313 * Cite RFC 5234 (#404) 3315 * Return to a single stream per request (#245,#557) 3317 * Use separate frame type and settings registries from HTTP/2 (#81) 3319 * SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 3321 * Restored GOAWAY (#696) 3323 * Identify server push using Push ID rather than a stream ID 3324 (#702,#281) 3326 * DATA frames cannot be empty (#700) 3328 B.30. Since draft-ietf-quic-http-03 3330 None. 3332 B.31. Since draft-ietf-quic-http-02 3334 * Track changes in transport draft 3336 B.32. Since draft-ietf-quic-http-01 3338 * SETTINGS changes (#181): 3340 - SETTINGS can be sent only once at the start of a connection; no 3341 changes thereafter 3343 - SETTINGS_ACK removed 3345 - Settings can only occur in the SETTINGS frame a single time 3347 - Boolean format updated 3349 * Alt-Svc parameter changed from "v" to "quic"; format updated 3350 (#229) 3352 * Closing the connection control stream or any message control 3353 stream is a fatal error (#176) 3355 * HPACK Sequence counter can wrap (#173) 3357 * 0-RTT guidance added 3359 * Guide to differences from HTTP/2 and porting HTTP/2 extensions 3360 added (#127,#242) 3362 B.33. Since draft-ietf-quic-http-00 3364 * Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 3366 * Changed from using HTTP/2 framing within Stream 3 to new framing 3367 format and two-stream-per-request model (#71,#72,#73) 3369 * Adopted SETTINGS format from draft-bishop-httpbis-extended- 3370 settings-01 3372 * Reworked SETTINGS_ACK to account for indeterminate inter-stream 3373 order (#75) 3375 * Described CONNECT pseudo-method (#95) 3377 * Updated ALPN token and Alt-Svc guidance (#13,#87) 3379 * Application-layer-defined error codes (#19,#74) 3381 B.34. Since draft-shade-quic-http2-mapping-00 3383 * Adopted as base for draft-ietf-quic-http 3385 * Updated authors/editors list 3387 Acknowledgments 3389 The original authors of this specification were Robbie Shade and Mike 3390 Warres. 3392 The IETF QUIC Working Group received an enormous amount of support 3393 from many people. Among others, the following people provided 3394 substantial contributions to this document: 3396 * Bence Beky 3398 * Daan De Meyer 3400 * Martin Duke 3402 * Roy Fielding 3404 * Alan Frindell 3406 * Alessandro Ghedini 3408 * Nick Harper 3410 * Ryan Hamilton 3412 * Christian Huitema 3414 * Subodh Iyengar 3416 * Robin Marx 3418 * Patrick McManus 3420 * Luca Niccolini 3422 * 奥 一穂 (Kazuho Oku) 3424 * Lucas Pardue 3426 * Roberto Peon 3428 * Julian Reschke 3429 * Eric Rescorla 3431 * Martin Seemann 3433 * Ben Schwartz 3435 * Ian Swett 3437 * Willy Taureau 3439 * Martin Thomson 3441 * Dmitri Tikhonov 3443 * Tatsuhiro Tsujikawa 3445 A portion of Mike's contribution was supported by Microsoft during 3446 his employment there. 3448 Author's Address 3450 Mike Bishop (editor) 3451 Akamai 3453 Email: mbishop@evequefou.be