idnits 2.17.00 (12 Aug 2021) /tmp/idnits37989/draft-ietf-quic-http-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2019) is 981 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) -- Looks like a reference, but probably isn't: '1' on line 2090 -- Looks like a reference, but probably isn't: '2' on line 2092 -- Looks like a reference, but probably isn't: '3' on line 2094 -- Looks like a reference, but probably isn't: '4' on line 2096 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-10 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALTSVC'. ** Downref: Normative reference to an Historic RFC: RFC 8164 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 September 12, 2019 5 Expires: March 15, 2020 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-23 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 Note to Readers 21 Discussion of this draft takes place on the QUIC working group 22 mailing list (quic@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 25 Working Group information can be found at https://github.com/quicwg 26 [2]; source code and issues list for this draft can be found at 27 https://github.com/quicwg/base-drafts/labels/-http [3]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 15, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4 65 1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 66 2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5 67 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 68 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 69 3. Connection Setup and Management . . . . . . . . . . . . . . . 8 70 3.1. Draft Version Identification . . . . . . . . . . . . . . 8 71 3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8 72 3.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 9 73 3.3. Connection Establishment . . . . . . . . . . . . . . . . 10 74 3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10 75 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 11 76 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 11 77 4.1.1. Header Formatting and Compression . . . . . . . . . . 12 78 4.1.2. Request Cancellation and Rejection . . . . . . . . . 13 79 4.1.3. Malformed Requests and Responses . . . . . . . . . . 14 80 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 15 81 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 16 82 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 16 83 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 17 84 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 18 85 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 18 86 5.3. Immediate Application Closure . . . . . . . . . . . . . . 19 87 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 20 88 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 20 89 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 20 90 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 21 91 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 22 92 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 23 93 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 23 95 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 24 96 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 24 97 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 25 98 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 25 99 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 26 100 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 26 101 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 27 102 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 30 103 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 31 104 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 31 105 7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 32 106 7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 33 107 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33 108 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34 109 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 35 110 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 111 10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 36 112 10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 36 113 10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 36 114 10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 37 115 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 116 11.1. Registration of HTTP/3 Identification String . . . . . . 37 117 11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 37 118 11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37 119 11.4. Settings Parameters . . . . . . . . . . . . . . . . . . 39 120 11.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 40 121 11.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 42 122 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 123 12.1. Normative References . . . . . . . . . . . . . . . . . . 43 124 12.2. Informative References . . . . . . . . . . . . . . . . . 44 125 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 126 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45 127 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45 128 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45 129 A.2.1. Prioritization Differences . . . . . . . . . . . . . 46 130 A.2.2. Header Compression Differences . . . . . . . . . . . 46 131 A.2.3. Guidance for New Frame Type Definitions . . . . . . . 47 132 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 47 133 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48 134 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49 135 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50 136 B.1. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 50 137 B.2. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 51 138 B.3. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 51 139 B.4. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 52 140 B.5. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 52 141 B.6. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 53 142 B.7. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 53 143 B.8. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 53 144 B.9. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 53 145 B.10. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 54 146 B.11. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 54 147 B.12. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 54 148 B.13. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 54 149 B.14. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 54 150 B.15. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 55 151 B.16. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 55 152 B.17. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 55 153 B.18. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 55 154 B.19. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 55 155 B.20. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 56 156 B.21. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 56 157 B.22. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 56 158 B.23. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 56 159 B.24. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 57 160 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 161 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 163 1. Introduction 165 HTTP semantics are used for a broad range of services on the 166 Internet. These semantics have commonly been used with two different 167 TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the same 168 semantics over a new transport protocol, QUIC. 170 1.1. Prior versions of HTTP 172 HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields 173 to convey HTTP messages. While these exchanges are human-readable, 174 using whitespace for message formatting leads to parsing difficulties 175 and workarounds to be tolerant of variant behavior. Because each 176 connection can transfer only a single HTTP request or response at a 177 time in each direction, multiple parallel TCP connections are often 178 used, reducing the ability of the congestion controller to accurately 179 manage traffic between endpoints. 181 HTTP/2 introduced a binary framing and multiplexing layer to improve 182 latency without modifying the transport layer. However, because the 183 parallel nature of HTTP/2's multiplexing is not visible to TCP's loss 184 recovery mechanisms, a lost or reordered packet causes all active 185 transactions to experience a stall regardless of whether that 186 transaction was impacted by the lost packet. 188 1.2. Delegation to QUIC 190 The QUIC transport protocol incorporates stream multiplexing and per- 191 stream flow control, similar to that provided by the HTTP/2 framing 192 layer. By providing reliability at the stream level and congestion 193 control across the entire connection, it has the capability to 194 improve the performance of HTTP compared to a TCP mapping. QUIC also 195 incorporates TLS 1.3 at the transport layer, offering comparable 196 security to running TLS over TCP, with the improved connection setup 197 latency of TCP Fast Open [RFC7413]. 199 This document defines a mapping of HTTP semantics over the QUIC 200 transport protocol, drawing heavily on the design of HTTP/2. While 201 delegating stream lifetime and flow control issues to QUIC, a similar 202 binary framing is used on each stream. Some HTTP/2 features are 203 subsumed by QUIC, while other features are implemented atop QUIC. 205 QUIC is described in [QUIC-TRANSPORT]. For a full description of 206 HTTP/2, see [HTTP2]. 208 2. HTTP/3 Protocol Overview 210 HTTP/3 provides a transport for HTTP semantics using the QUIC 211 transport protocol and an internal framing layer similar to HTTP/2. 213 Once a client knows that an HTTP/3 server exists at a certain 214 endpoint, it opens a QUIC connection. QUIC provides protocol 215 negotiation, stream-based multiplexing, and flow control. An HTTP/3 216 endpoint can be discovered using HTTP Alternative Services; this 217 process is described in greater detail in Section 3.2. 219 Within each stream, the basic unit of HTTP/3 communication is a frame 220 (Section 7.2). Each frame type serves a different purpose. For 221 example, HEADERS and DATA frames form the basis of HTTP requests and 222 responses (Section 4.1). 224 Multiplexing of requests is performed using the QUIC stream 225 abstraction, described in Section 2 of [QUIC-TRANSPORT]. Each 226 request and response consumes a single QUIC stream. Streams are 227 independent of each other, so one stream that is blocked or suffers 228 packet loss does not prevent progress on other streams. 230 Server push is an interaction mode introduced in HTTP/2 [HTTP2] which 231 permits a server to push a request-response exchange to a client in 232 anticipation of the client making the indicated request. This trades 233 off network usage against a potential latency gain. Several HTTP/3 234 frames are used to manage server push, such as PUSH_PROMISE, 235 DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH. 237 As in HTTP/2, request and response headers are compressed for 238 transmission. Because HPACK [HPACK] relies on in-order transmission 239 of compressed header blocks (a guarantee not provided by QUIC), 240 HTTP/3 replaces HPACK with QPACK [QPACK]. QPACK uses separate 241 unidirectional streams to modify and track header table state, while 242 header blocks refer to the state of the table without modifying it. 244 2.1. Document Organization 246 The HTTP/3 specification is split into seven parts. The document 247 begins with a detailed overview of the connection lifecycle and key 248 concepts: 250 o Connection Setup and Management (Section 3) covers how an HTTP/3 251 endpoint is discovered and a connection is established. 253 o HTTP Request Lifecycle (Section 4) describes how HTTP semantics 254 are expressed using frames. 256 o Connection Closure (Section 5) describes how connections are 257 terminated, either gracefully or abruptly. 259 The details of the wire protocol and interactions with the transport 260 are described in subsequent sections: 262 o Stream Mapping and Usage (Section 6) describes the way QUIC 263 streams are used. 265 o HTTP Framing Layer (Section 7) describes the frames used on most 266 streams. 268 o Error Handling (Section 8) describes how error conditions are 269 handled and expressed, either on a particular stream or for the 270 connection as a whole. 272 Additional resources are provided in the final sections: 274 o Extensions to HTTP/3 (Section 9) describes how new capabilities 275 can be added in future documents. 277 o A more detailed comparison between HTTP/2 and HTTP/3 can be found 278 in Appendix A. 280 2.2. Conventions and Terminology 282 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 283 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 284 "OPTIONAL" in this document are to be interpreted as described in BCP 285 14 [RFC2119] [RFC8174] when, and only when, they appear in all 286 capitals, as shown here. 288 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 289 defined in [RFC5234]. 291 This document uses the variable-length integer encoding from 292 [QUIC-TRANSPORT]. 294 The following terms are used: 296 abort: An abrupt termination of a connection or stream, possibly due 297 to an error condition. 299 client: The endpoint that initiates an HTTP/3 connection. Clients 300 send HTTP requests and receive HTTP responses. 302 connection: A transport-layer connection between two endpoints, 303 using QUIC as the transport protocol. 305 connection error: An error that affects the entire HTTP/3 306 connection. 308 endpoint: Either the client or server of the connection. 310 frame: The smallest unit of communication on a stream in HTTP/3, 311 consisting of a header and a variable-length sequence of octets 312 structured according to the frame type. Protocol elements called 313 "frames" exist in both this document and [QUIC-TRANSPORT]. Where 314 frames from [QUIC-TRANSPORT] are referenced, the frame name will 315 be prefaced with "QUIC." For example, "QUIC CONNECTION_CLOSE 316 frames." References without this preface refer to frames defined 317 in Section 7.2. 319 peer: An endpoint. When discussing a particular endpoint, "peer" 320 refers to the endpoint that is remote to the primary subject of 321 discussion. 323 receiver: An endpoint that is receiving frames. 325 sender: An endpoint that is transmitting frames. 327 server: The endpoint that accepts an HTTP/3 connection. Servers 328 receive HTTP requests and send HTTP responses. 330 stream: A bidirectional or unidirectional bytestream provided by the 331 QUIC transport. 333 stream error: An error on the individual HTTP/3 stream. 335 The term "payload body" is defined in Section 3.3 of [RFC7230]. 337 Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" 338 are defined in Section 2.3 of [RFC7230]. Intermediaries act as both 339 client and server at different times. 341 3. Connection Setup and Management 343 3.1. Draft Version Identification 345 *RFC Editor's Note:* Please remove this section prior to 346 publication of a final version of this document. 348 HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc. 349 Only implementations of the final, published RFC can identify 350 themselves as "h3". Until such an RFC exists, implementations MUST 351 NOT identify themselves using this string. 353 Implementations of draft versions of the protocol MUST add the string 354 "-" and the corresponding draft number to the identifier. For 355 example, draft-ietf-quic-http-01 is identified using the string 356 "h3-01". 358 Non-compatible experiments that are based on these draft versions 359 MUST append the string "-" and an experiment name to the identifier. 360 For example, an experimental implementation based on draft-ietf-quic- 361 http-09 which reserves an extra stream for unsolicited transmission 362 of 1980s pop music might identify itself as "h3-09-rickroll". Note 363 that any label MUST conform to the "token" syntax defined in 364 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 365 coordinate their experiments on the quic@ietf.org mailing list. 367 3.2. Discovering an HTTP/3 Endpoint 369 An HTTP origin advertises the availability of an equivalent HTTP/3 370 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 371 ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 3.3. 373 For example, an origin could indicate in an HTTP response that HTTP/3 374 was available on UDP port 50781 at the same hostname by including the 375 following header field: 377 Alt-Svc: h3=":50781" 379 On receipt of an Alt-Svc record indicating HTTP/3 support, a client 380 MAY attempt to establish a QUIC connection to the indicated host and 381 port and, if successful, send HTTP requests using the mapping 382 described in this document. 384 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 385 connection establishment failure, in which case the client SHOULD 386 continue using the existing connection or try another alternative 387 endpoint offered by the origin. 389 Servers MAY serve HTTP/3 on any UDP port, since an alternative always 390 includes an explicit port. 392 3.2.1. QUIC Version Hints 394 This document defines the "quic" parameter for Alt-Svc, which MAY be 395 used to provide version-negotiation hints to HTTP/3 clients. QUIC 396 versions are four-byte sequences with no additional constraints on 397 format. Leading zeros SHOULD be omitted for brevity. 399 Syntax: 401 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 402 version-number = 1*8HEXDIG; hex-encoded QUIC version 404 Where multiple versions are listed, the order of the values reflects 405 the server's preference (with the first value being the most 406 preferred version). Reserved versions MAY be listed, but unreserved 407 versions which are not supported by the alternative SHOULD NOT be 408 present in the list. Origins MAY omit supported versions for any 409 reason. 411 Clients MUST ignore any included versions which they do not support. 412 The "quic" parameter MUST NOT occur more than once; clients SHOULD 413 process only the first occurrence. 415 For example, suppose a server supported both version 0x00000001 and 416 the version rendered in ASCII as "Q034". If it also opted to include 417 the reserved version (from Section 15 of [QUIC-TRANSPORT]) 418 0x1abadaba, it could specify the following header field: 420 Alt-Svc: h3=":49288";quic="1,1abadaba,51303334" 422 A client acting on this header field would drop the reserved version 423 (not supported), then attempt to connect to the alternative using the 424 first version in the list which it does support, if any. 426 3.3. Connection Establishment 428 HTTP/3 relies on QUIC as the underlying transport. The QUIC version 429 being used MUST use TLS version 1.3 or greater as its handshake 430 protocol. HTTP/3 clients MUST indicate the target domain name during 431 the TLS handshake. This may be done using the Server Name Indication 432 (SNI) [RFC6066] extension to TLS or using some other mechanism. 434 QUIC connections are established as described in [QUIC-TRANSPORT]. 435 During connection establishment, HTTP/3 support is indicated by 436 selecting the ALPN token "h3" in the TLS handshake. Support for 437 other application-layer protocols MAY be offered in the same 438 handshake. 440 While connection-level options pertaining to the core QUIC protocol 441 are set in the initial crypto handshake, HTTP/3-specific settings are 442 conveyed in the SETTINGS frame. After the QUIC connection is 443 established, a SETTINGS frame (Section 7.2.4) MUST be sent by each 444 endpoint as the initial frame of their respective HTTP control stream 445 (see Section 6.2.1). 447 3.4. Connection Reuse 449 Once a connection exists to a server endpoint, this connection MAY be 450 reused for requests with multiple different URI authority components. 451 The client MAY send any requests for which the client considers the 452 server authoritative. 454 An authoritative HTTP/3 endpoint is typically discovered because the 455 client has received an Alt-Svc record from the request's origin which 456 nominates the endpoint as a valid HTTP Alternative Service for that 457 origin. As required by [RFC7838], clients MUST check that the 458 nominated server can present a valid certificate for the origin 459 before considering it authoritative. Clients MUST NOT assume that an 460 HTTP/3 endpoint is authoritative for other origins without an 461 explicit signal. 463 Prior to making requests for an origin whose scheme is not "https," 464 the client MUST ensure the server is willing to serve that scheme. 465 If the client intends to make requests for an origin whose scheme is 466 "http", this means that it MUST obtain a valid "http-opportunistic" 467 response for the origin as described in [RFC8164] prior to making any 468 such requests. Other schemes might define other mechanisms. 470 A server that does not wish clients to reuse connections for a 471 particular origin can indicate that it is not authoritative for a 472 request by sending a 421 (Misdirected Request) status code in 473 response to the request (see Section 9.1.2 of [HTTP2]). 475 The considerations discussed in Section 9.1 of [HTTP2] also apply to 476 the management of HTTP/3 connections. 478 4. HTTP Request Lifecycle 480 4.1. HTTP Message Exchanges 482 A client sends an HTTP request on a client-initiated bidirectional 483 QUIC stream. A client MUST send only a single request on a given 484 stream. A server sends zero or more non-final HTTP responses on the 485 same stream as the request, followed by a single final HTTP response, 486 as detailed below. 488 An HTTP message (request or response) consists of: 490 1. the message header (see [RFC7230], Section 3.2), sent as a single 491 HEADERS frame (see Section 7.2.2), 493 2. optionally, the payload body, if present (see [RFC7230], 494 Section 3.3), sent as a series of DATA frames (see 495 Section 7.2.1), 497 3. optionally, trailing headers, if present (see [RFC7230], 498 Section 4.1.2), sent as a single HEADERS frame. 500 A server MAY send one or more PUSH_PROMISE frames (see Section 7.2.5) 501 before, after, or interleaved with the frames of a response message. 502 These PUSH_PROMISE frames are not part of the response; see 503 Section 4.4 for more details. 505 Frames of unknown types (Section 9), including reserved frames 506 (Section 7.2.9) MAY be sent on a request or push stream before, 507 after, or interleaved with other frames described in this section. 509 The HEADERS and PUSH_PROMISE frames might reference updates to the 510 QPACK dynamic table. While these updates are not directly part of 511 the message exchange, they must be received and processed before the 512 message can be consumed. See Section 4.1.1 for more details. 514 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 515 MUST NOT be used. 517 A response MAY consist of multiple messages when and only when one or 518 more informational responses (1xx; see [RFC7231], Section 6.2) 519 precede a final response to the same request. Non-final responses do 520 not contain a payload body or trailers. 522 If an endpoint receives an invalid sequence of frames on either a 523 request or a push stream, it MUST respond with a connection error of 524 type HTTP_FRAME_UNEXPECTED (Section 8). In particular, a DATA frame 525 before any HEADERS frame, or a HEADERS or DATA frame after the 526 trailing HEADERS frame is considered invalid. 528 An HTTP request/response exchange fully consumes a bidirectional QUIC 529 stream. After sending a request, a client MUST close the stream for 530 sending. Unless using the CONNECT method (see Section 4.2), clients 531 MUST NOT make stream closure dependent on receiving a response to 532 their request. After sending a final response, the server MUST close 533 the stream for sending. At this point, the QUIC stream is fully 534 closed. 536 When a stream is closed, this indicates the end of an HTTP message. 537 Because some messages are large or unbounded, endpoints SHOULD begin 538 processing partial HTTP messages once enough of the message has been 539 received to make progress. If a client stream terminates without 540 enough of the HTTP message to provide a complete response, the server 541 SHOULD abort its response with the error code 542 HTTP_REQUEST_INCOMPLETE. 544 A server can send a complete response prior to the client sending an 545 entire request if the response does not depend on any portion of the 546 request that has not been sent and received. When this is true, a 547 server MAY abort reading the request stream with error code 548 HTTP_EARLY_RESPONSE, send a complete response, and cleanly close the 549 sending part of the stream. Clients MUST NOT discard complete 550 responses as a result of having their request terminated abruptly, 551 though clients can always discard responses at their discretion for 552 other reasons. 554 4.1.1. Header Formatting and Compression 556 HTTP message headers carry information as a series of key-value 557 pairs, called header fields. For a listing of registered HTTP header 558 fields, see the "Message Header Field" registry maintained at 559 https://www.iana.org/assignments/message-headers [4]. 561 Just as in previous versions of HTTP, header field names are strings 562 of ASCII characters that are compared in a case-insensitive fashion. 563 Properties of HTTP header field names and values are discussed in 564 more detail in Section 3.2 of [RFC7230], though the wire rendering in 565 HTTP/3 differs. As in HTTP/2, header field names MUST be converted 566 to lowercase prior to their encoding. A request or response 567 containing uppercase header field names MUST be treated as malformed 568 (Section 4.1.3). 570 As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with 571 the ':' character (ASCII 0x3a) to convey the target URI, the method 572 of the request, and the status code for the response. These pseudo- 573 header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2]. 574 Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT 575 generate pseudo-header fields other than those defined in [HTTP2]. 576 The restrictions on the use of pseudo-header fields in 577 Section 8.1.2.1 of [HTTP2] also apply to HTTP/3. 579 HTTP/3 uses QPACK header compression as described in [QPACK], a 580 variation of HPACK which allows the flexibility to avoid header- 581 compression-induced head-of-line blocking. See that document for 582 additional details. 584 To allow for better compression efficiency, the cookie header field 585 [RFC6265] MAY be split into separate header fields, each with one or 586 more cookie-pairs, before compression. If a decompressed header list 587 contains multiple cookie header fields, these MUST be concatenated 588 before being passed into a non-HTTP/2, non-HTTP/3 context, as 589 described in [HTTP2], Section 8.1.2.5. 591 An HTTP/3 implementation MAY impose a limit on the maximum size of 592 the message header it will accept on an individual HTTP message. A 593 server that receives a larger header field list than it is willing to 594 handle can send an HTTP 431 (Request Header Fields Too Large) status 595 code [RFC6585]. A client can discard responses that it cannot 596 process. The size of a header field list is calculated based on the 597 uncompressed size of header fields, including the length of the name 598 and value in bytes plus an overhead of 32 bytes for each header 599 field. 601 If an implementation wishes to advise its peer of this limit, it can 602 be conveyed as a number of bytes in the 603 "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. An implementation which 604 has received this parameter SHOULD NOT send an HTTP message header 605 which exceeds the indicated size, as the peer will likely refuse to 606 process it. However, because this limit is applied at each hop, 607 messages below this limit are not guaranteed to be accepted. 609 4.1.2. Request Cancellation and Rejection 611 Clients can cancel requests by resetting and aborting the request 612 stream with an error code of HTTP_REQUEST_CANCELLED (Section 8.1). 613 When the client aborts reading a response, it indicates that this 614 response is no longer of interest. Implementations SHOULD cancel 615 requests by abruptly terminating any directions of a stream that are 616 still open. 618 When the server rejects a request without performing any application 619 processing, it SHOULD abort its response stream with the error code 620 HTTP_REQUEST_REJECTED. In this context, "processed" means that some 621 data from the stream was passed to some higher layer of software that 622 might have taken some action as a result. The client can treat 623 requests rejected by the server as though they had never been sent at 624 all, thereby allowing them to be retried later on a new connection. 625 Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for 626 requests which were partially or fully processed. When a server 627 abandons a response after partial processing, it SHOULD abort its 628 response stream with the error code HTTP_REQUEST_CANCELLED. 630 When a client resets a request with the error code 631 HTTP_REQUEST_CANCELLED, a server MAY abruptly terminate the response 632 using the error code HTTP_REQUEST_REJECTED if no processing was 633 performed. Clients MUST NOT use the HTTP_REQUEST_REJECTED error 634 code, except when a server has requested closure of the request 635 stream with this error code. 637 If a stream is cancelled after receiving a complete response, the 638 client MAY ignore the cancellation and use the response. However, if 639 a stream is cancelled after receiving a partial response, the 640 response SHOULD NOT be used. Automatically retrying such requests is 641 not possible, unless this is otherwise permitted (e.g., idempotent 642 actions like GET, PUT, or DELETE). 644 4.1.3. Malformed Requests and Responses 646 A malformed request or response is one that is an otherwise valid 647 sequence of frames but is invalid due to the presence of extraneous 648 frames, prohibited header fields, the absence of mandatory header 649 fields, or the inclusion of uppercase header field names. 651 A request or response that includes a payload body can include a 652 "content-length" header field. A request or response is also 653 malformed if the value of a content-length header field does not 654 equal the sum of the DATA frame payload lengths that form the body. 655 A response that is defined to have no payload, as described in 656 Section 3.3.2 of [RFC7230] can have a non-zero content-length header 657 field, even though no content is included in DATA frames. 659 Intermediaries that process HTTP requests or responses (i.e., any 660 intermediary not acting as a tunnel) MUST NOT forward a malformed 661 request or response. Malformed requests or responses that are 662 detected MUST be treated as a stream error (Section 8) of type 663 HTTP_GENERAL_PROTOCOL_ERROR. 665 For malformed requests, a server MAY send an HTTP response prior to 666 closing or resetting the stream. Clients MUST NOT accept a malformed 667 response. Note that these requirements are intended to protect 668 against several types of common attacks against HTTP; they are 669 deliberately strict because being permissive can expose 670 implementations to these vulnerabilities. 672 4.2. The CONNECT Method 674 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 675 used with HTTP proxies to establish a TLS session with an origin 676 server for the purposes of interacting with "https" resources. In 677 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 678 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 679 establish a tunnel over a single HTTP/2 stream to a remote host for 680 similar purposes. 682 A CONNECT request in HTTP/3 functions in the same manner as in 683 HTTP/2. The request MUST be formatted as described in [HTTP2], 684 Section 8.3. A CONNECT request that does not conform to these 685 restrictions is malformed (see Section 4.1.3). The request stream 686 MUST NOT be closed at the end of the request. 688 A proxy that supports CONNECT establishes a TCP connection 689 ([RFC0793]) to the server identified in the ":authority" pseudo- 690 header field. Once this connection is successfully established, the 691 proxy sends a HEADERS frame containing a 2xx series status code to 692 the client, as defined in [RFC7231], Section 4.3.6. 694 All DATA frames on the stream correspond to data sent or received on 695 the TCP connection. Any DATA frame sent by the client is transmitted 696 by the proxy to the TCP server; data received from the TCP server is 697 packaged into DATA frames by the proxy. Note that the size and 698 number of TCP segments is not guaranteed to map predictably to the 699 size and number of HTTP DATA or QUIC STREAM frames. 701 Once the CONNECT method has completed, only DATA frames are permitted 702 to be sent on the stream. Extension frames MAY be used if 703 specifically permitted by the definition of the extension. Receipt 704 of any other frame type MUST be treated as a connection error of type 705 HTTP_FRAME_UNEXPECTED. 707 The TCP connection can be closed by either peer. When the client 708 ends the request stream (that is, the receive stream at the proxy 709 enters the "Data Recvd" state), the proxy will set the FIN bit on its 710 connection to the TCP server. When the proxy receives a packet with 711 the FIN bit set, it will terminate the send stream that it sends to 712 the client. TCP connections which remain half-closed in a single 713 direction are not invalid, but are often handled poorly by servers, 714 so clients SHOULD NOT close a stream for sending while they still 715 expect to receive data from the target of the CONNECT. 717 A TCP connection error is signaled by abruptly terminating the 718 stream. A proxy treats any error in the TCP connection, which 719 includes receiving a TCP segment with the RST bit set, as a stream 720 error of type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, if 721 a proxy detects an error with the stream or the QUIC connection, it 722 MUST close the TCP connection. If the underlying TCP implementation 723 permits it, the proxy SHOULD send a TCP segment with the RST bit set. 725 4.3. HTTP Upgrade 727 HTTP/3 does not support the HTTP Upgrade mechanism ([RFC7230], 728 Section 6.7) or 101 (Switching Protocols) informational status code 729 ([RFC7231], Section 6.2.2). 731 4.4. Server Push 733 Server push is an interaction mode introduced in HTTP/2 [HTTP2] which 734 permits a server to push a request-response exchange to a client in 735 anticipation of the client making the indicated request. This trades 736 off network usage against a potential latency gain. HTTP/3 server 737 push is similar to what is described in HTTP/2 [HTTP2], but uses 738 different mechanisms. 740 Each server push is identified by a unique Push ID. This Push ID is 741 used in a single PUSH_PROMISE frame (see Section 7.2.5) which carries 742 the request headers, possibly included in one or more DUPLICATE_PUSH 743 frames (see Section 7.2.8), then included with the push stream which 744 ultimately fulfills those promises. 746 Server push is only enabled on a connection when a client sends a 747 MAX_PUSH_ID frame (see Section 7.2.7). A server cannot use server 748 push until it receives a MAX_PUSH_ID frame. A client sends 749 additional MAX_PUSH_ID frames to control the number of pushes that a 750 server can promise. A server SHOULD use Push IDs sequentially, 751 starting at 0. A client MUST treat receipt of a push stream with a 752 Push ID that is greater than the maximum Push ID as a connection 753 error of type HTTP_ID_ERROR. 755 The header of the request message is carried by a PUSH_PROMISE frame 756 (see Section 7.2.5) on the request stream which generated the push. 757 This allows the server push to be associated with a client request. 758 Promised requests MUST conform to the requirements in Section 8.2 of 759 [HTTP2]. 761 The same server push can be associated with additional client 762 requests using a DUPLICATE_PUSH frame (see Section 7.2.8). 764 Ordering of a PUSH_PROMISE or DUPLICATE_PUSH in relation to certain 765 parts of the response is important. The server SHOULD send 766 PUSH_PROMISE or DUPLICATE_PUSH frames prior to sending HEADERS or 767 DATA frames that reference the promised responses. This reduces the 768 chance that a client requests a resource that will be pushed by the 769 server. 771 When a server later fulfills a promise, the server push response is 772 conveyed on a push stream (see Section 6.2.2). The push stream 773 identifies the Push ID of the promise that it fulfills, then contains 774 a response to the promised request using the same format described 775 for responses in Section 4.1. 777 Due to reordering, DUPLICATE_PUSH frames or push stream data can 778 arrive before the corresponding PUSH_PROMISE frame. When a client 779 receives a DUPLICATE_PUSH frame for an as-yet-unknown Push ID, the 780 request headers of the push are not immediately available. The 781 client can either delay generating new requests for content 782 referenced following the DUPLICATE_PUSH frame until the request 783 headers become available, or can initiate requests for discovered 784 resources and cancel the requests if the requested resource is 785 already being pushed. When a client receives a new push stream with 786 an as-yet-unknown Push ID, both the associated client request and the 787 pushed request headers are unknown. The client can buffer the stream 788 data in expectation of the matching PUSH_PROMISE. The client can use 789 stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit 790 the amount of data a server may commit to the pushed stream. 792 If a promised server push is not needed by the client, the client 793 SHOULD send a CANCEL_PUSH frame. If the push stream is already open 794 or opens after sending the CANCEL_PUSH frame, the client can abort 795 reading the stream with an error code of HTTP_REQUEST_CANCELLED. 796 This asks the server not to transfer additional data and indicates 797 that it will be discarded upon receipt. 799 5. Connection Closure 801 Once established, an HTTP/3 connection can be used for many requests 802 and responses over time until the connection is closed. Connection 803 closure can happen in any of several different ways. 805 5.1. Idle Connections 807 Each QUIC endpoint declares an idle timeout during the handshake. If 808 the connection remains idle (no packets received) for longer than 809 this duration, the peer will assume that the connection has been 810 closed. HTTP/3 implementations will need to open a new connection 811 for new requests if the existing connection has been idle for longer 812 than the server's advertised idle timeout, and SHOULD do so if 813 approaching the idle timeout. 815 HTTP clients are expected to request that the transport keep 816 connections open while there are responses outstanding for requests 817 or server pushes, as described in Section 19.2 of [QUIC-TRANSPORT]. 818 If the client is not expecting a response from the server, allowing 819 an idle connection to time out is preferred over expending effort 820 maintaining a connection that might not be needed. A gateway MAY 821 maintain connections in anticipation of need rather than incur the 822 latency cost of connection establishment to servers. Servers SHOULD 823 NOT actively keep connections open. 825 5.2. Connection Shutdown 827 Even when a connection is not idle, either endpoint can decide to 828 stop using the connection and let the connection close gracefully. 829 Since clients drive request generation, clients perform a connection 830 shutdown by not sending additional requests on the connection; 831 responses and pushed responses associated to previous requests will 832 continue to completion. Servers perform the same function by 833 communicating with clients. 835 Servers initiate the shutdown of a connection by sending a GOAWAY 836 frame (Section 7.2.6). The GOAWAY frame indicates that client- 837 initiated requests on lower stream IDs were or might be processed in 838 this connection, while requests on the indicated stream ID and 839 greater were rejected. This enables client and server to agree on 840 which requests were accepted prior to the connection shutdown. This 841 identifier MAY be zero if no requests were processed. Servers SHOULD 842 NOT permit additional QUIC streams after sending a GOAWAY frame. 844 Clients MUST NOT send new requests on the connection after receiving 845 GOAWAY; a new connection MAY be established to send additional 846 requests. 848 Some requests might already be in transit. If the client has already 849 sent requests on streams with a Stream ID greater than or equal to 850 that indicated in the GOAWAY frame, those requests will not be 851 processed and MAY be retried by the client on a different connection. 852 The client MAY cancel these requests. It is RECOMMENDED that the 853 server explicitly reject such requests (see Section 4.1.2) in order 854 to clean up transport state for the affected streams. 856 Requests on Stream IDs less than the Stream ID in the GOAWAY frame 857 might have been processed; their status cannot be known until a 858 response is received, the stream is reset individually, or the 859 connection terminates. Servers MAY reject individual requests on 860 streams below the indicated ID if these requests were not processed. 862 Servers SHOULD send a GOAWAY frame when the closing of a connection 863 is known in advance, even if the advance notice is small, so that the 864 remote peer can know whether a request has been partially processed 865 or not. For example, if an HTTP client sends a POST at the same time 866 that a server closes a QUIC connection, the client cannot know if the 867 server started to process that POST request if the server does not 868 send a GOAWAY frame to indicate what streams it might have acted on. 870 A client that is unable to retry requests loses all requests that are 871 in flight when the server closes the connection. A server MAY send 872 multiple GOAWAY frames indicating different stream IDs, but MUST NOT 873 increase the value they send in the last Stream ID, since clients 874 might already have retried unprocessed requests on another 875 connection. A server that is attempting to gracefully shut down a 876 connection SHOULD send an initial GOAWAY frame with the last Stream 877 ID set to the maximum value allowed by QUIC's MAX_STREAMS and SHOULD 878 NOT increase the MAX_STREAMS limit thereafter. This signals to the 879 client that a shutdown is imminent and that initiating further 880 requests is prohibited. After allowing time for any in-flight 881 requests (at least one round-trip time), the server MAY send another 882 GOAWAY frame with an updated last Stream ID. This ensures that a 883 connection can be cleanly shut down without losing requests. 885 Once all accepted requests have been processed, the server can permit 886 the connection to become idle, or MAY initiate an immediate closure 887 of the connection. An endpoint that completes a graceful shutdown 888 SHOULD use the HTTP_NO_ERROR code when closing the connection. 890 If a client has consumed all available bidirectional stream IDs with 891 requests, the server need not send a GOAWAY frame, since the client 892 is unable to make further requests. 894 5.3. Immediate Application Closure 896 An HTTP/3 implementation can immediately close the QUIC connection at 897 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 898 the peer; the error code in this frame indicates to the peer why the 899 connection is being closed. See Section 8 for error codes which can 900 be used when closing a connection. 902 Before closing the connection, a GOAWAY MAY be sent to allow the 903 client to retry some requests. Including the GOAWAY frame in the 904 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 905 of the frame being received by clients. 907 5.4. Transport Closure 909 For various reasons, the QUIC transport could indicate to the 910 application layer that the connection has terminated. This might be 911 due to an explicit closure by the peer, a transport-level error, or a 912 change in network topology which interrupts connectivity. 914 If a connection terminates without a GOAWAY frame, clients MUST 915 assume that any request which was sent, whether in whole or in part, 916 might have been processed. 918 6. Stream Mapping and Usage 920 A QUIC stream provides reliable in-order delivery of bytes, but makes 921 no guarantees about order of delivery with regard to bytes on other 922 streams. On the wire, data is framed into QUIC STREAM frames, but 923 this framing is invisible to the HTTP framing layer. The transport 924 layer buffers and orders received QUIC STREAM frames, exposing the 925 data contained within as a reliable byte stream to the application. 926 Although QUIC permits out-of-order delivery within a stream, HTTP/3 927 does not make use of this feature. 929 QUIC streams can be either unidirectional, carrying data only from 930 initiator to receiver, or bidirectional. Streams can be initiated by 931 either the client or the server. For more detail on QUIC streams, 932 see Section 2 of [QUIC-TRANSPORT]. 934 When HTTP headers and data are sent over QUIC, the QUIC layer handles 935 most of the stream management. HTTP does not need to do any separate 936 multiplexing when using QUIC - data sent over a QUIC stream always 937 maps to a particular HTTP transaction or connection context. 939 6.1. Bidirectional Streams 941 All client-initiated bidirectional streams are used for HTTP requests 942 and responses. A bidirectional stream ensures that the response can 943 be readily correlated with the request. This means that the client's 944 first request occurs on QUIC stream 0, with subsequent requests on 945 stream 4, 8, and so on. In order to permit these streams to open, an 946 HTTP/3 server SHOULD configure non-zero minimum values for the number 947 of permitted streams and the initial stream flow control window. It 948 is RECOMMENDED that at least 100 requests be permitted at a time, so 949 as to not unnecessarily limit parallelism. 951 HTTP/3 does not use server-initiated bidirectional streams, though an 952 extension could define a use for these streams. Clients MUST treat 953 receipt of a server-initiated bidirectional stream as a connection 954 error of type HTTP_STREAM_CREATION_ERROR unless such an extension has 955 been negotiated. 957 6.2. Unidirectional Streams 959 Unidirectional streams, in either direction, are used for a range of 960 purposes. The purpose is indicated by a stream type, which is sent 961 as a variable-length integer at the start of the stream. The format 962 and structure of data that follows this integer is determined by the 963 stream type. 965 0 1 2 3 966 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Stream Type (i) ... 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 Figure 1: Unidirectional Stream Header 973 Some stream types are reserved (Section 6.2.3). Two stream types are 974 defined in this document: control streams (Section 6.2.1) and push 975 streams (Section 6.2.2). Other stream types can be defined by 976 extensions to HTTP/3; see Section 9 for more details. 978 The performance of HTTP/3 connections in the early phase of their 979 lifetime is sensitive to the creation and exchange of data on 980 unidirectional streams. Endpoints that excessively restrict the 981 number of streams or the flow control window of these streams will 982 increase the chance that the remote peer reaches the limit early and 983 becomes blocked. In particular, implementations should consider that 984 remote peers may wish to exercise reserved stream behavior 985 (Section 6.2.3) with some of the unidirectional streams they are 986 permitted to use. To avoid blocking, the transport parameters sent 987 by both clients and servers MUST allow the peer to create at least 988 one unidirectional stream for the HTTP control stream plus the number 989 of unidirectional streams required by mandatory extensions (three 990 being the minimum number required for the base HTTP/3 protocol and 991 QPACK), and SHOULD provide at least 1,024 bytes of flow control 992 credit to each stream. 994 Note that an endpoint is not required to grant additional credits to 995 create more unidirectional streams if its peer consumes all the 996 initial credits before creating the critical unidirectional streams. 997 Endpoints SHOULD create the HTTP control stream as well as the 998 unidirectional streams required by mandatory extensions (such as the 999 QPACK encoder and decoder streams) first, and then create additional 1000 streams as allowed by their peer. 1002 If the stream header indicates a stream type which is not supported 1003 by the recipient, the remainder of the stream cannot be consumed as 1004 the semantics are unknown. Recipients of unknown stream types MAY 1005 abort reading of the stream with an error code of 1006 HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be 1007 a connection error of any kind. 1009 Implementations MAY send stream types before knowing whether the peer 1010 supports them. However, stream types which could modify the state or 1011 semantics of existing protocol components, including QPACK or other 1012 extensions, MUST NOT be sent until the peer is known to support them. 1014 A sender can close or reset a unidirectional stream unless otherwise 1015 specified. A receiver MUST tolerate unidirectional streams being 1016 closed or reset prior to the reception of the unidirectional stream 1017 header. 1019 6.2.1. Control Streams 1021 A control stream is indicated by a stream type of "0x00". Data on 1022 this stream consists of HTTP/3 frames, as defined in Section 7.2. 1024 Each side MUST initiate a single control stream at the beginning of 1025 the connection and send its SETTINGS frame as the first frame on this 1026 stream. If the first frame of the control stream is any other frame 1027 type, this MUST be treated as a connection error of type 1028 HTTP_MISSING_SETTINGS. Only one control stream per peer is 1029 permitted; receipt of a second stream which claims to be a control 1030 stream MUST be treated as a connection error of type 1031 HTTP_STREAM_CREATION_ERROR. The sender MUST NOT close the control 1032 stream, and the receiver MUST NOT request that the sender close the 1033 control stream. If either control stream is closed at any point, 1034 this MUST be treated as a connection error of type 1035 HTTP_CLOSED_CRITICAL_STREAM. 1037 A pair of unidirectional streams is used rather than a single 1038 bidirectional stream. This allows either peer to send data as soon 1039 as it is able. Depending on whether 0-RTT is enabled on the 1040 connection, either client or server might be able to send stream data 1041 first after the cryptographic handshake completes. 1043 6.2.2. Push Streams 1045 Server push is an optional feature introduced in HTTP/2 that allows a 1046 server to initiate a response before a request has been made. See 1047 Section 4.4 for more details. 1049 A push stream is indicated by a stream type of "0x01", followed by 1050 the Push ID of the promise that it fulfills, encoded as a variable- 1051 length integer. The remaining data on this stream consists of HTTP/3 1052 frames, as defined in Section 7.2, and fulfills a promised server 1053 push by zero or more non-final HTTP responses followed by a single 1054 final HTTP response, as defined in Section 4.1. Server push and Push 1055 IDs are described in Section 4.4. 1057 Only servers can push; if a server receives a client-initiated push 1058 stream, this MUST be treated as a connection error of type 1059 HTTP_STREAM_CREATION_ERROR. 1061 0 1 2 3 1062 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | 0x01 (i) ... 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Push ID (i) ... 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 Figure 2: Push Stream Header 1071 Each Push ID MUST only be used once in a push stream header. If a 1072 push stream header includes a Push ID that was used in another push 1073 stream header, the client MUST treat this as a connection error of 1074 type HTTP_ID_ERROR. 1076 6.2.3. Reserved Stream Types 1078 Stream types of the format "0x1f * N + 0x21" for integer values of N 1079 are reserved to exercise the requirement that unknown types be 1080 ignored. These streams have no semantics, and can be sent when 1081 application-layer padding is desired. They MAY also be sent on 1082 connections where no data is currently being transferred. Endpoints 1083 MUST NOT consider these streams to have any meaning upon receipt. 1085 The payload and length of the stream are selected in any manner the 1086 implementation chooses. 1088 7. HTTP Framing Layer 1090 HTTP frames are carried on QUIC streams, as described in Section 6. 1091 HTTP/3 defines three stream types: control stream, request stream, 1092 and push stream. This section describes HTTP/3 frame formats and the 1093 streams types on which they are permitted; see Table 1 for an 1094 overview. A comparison between HTTP/2 and HTTP/3 frames is provided 1095 in Appendix A.2. 1097 +----------------+---------+----------+---------+-------------------+ 1098 | Frame | Control | Request | Push | Section | 1099 | | Stream | Stream | Stream | | 1100 +----------------+---------+----------+---------+-------------------+ 1101 | DATA | No | Yes | Yes | Section 7.2.1 | 1102 | | | | | | 1103 | HEADERS | No | Yes | Yes | Section 7.2.2 | 1104 | | | | | | 1105 | CANCEL_PUSH | Yes | No | No | Section 7.2.3 | 1106 | | | | | | 1107 | SETTINGS | Yes (1) | No | No | Section 7.2.4 | 1108 | | | | | | 1109 | PUSH_PROMISE | No | Yes | No | Section 7.2.5 | 1110 | | | | | | 1111 | GOAWAY | Yes | No | No | Section 7.2.6 | 1112 | | | | | | 1113 | MAX_PUSH_ID | Yes | No | No | Section 7.2.7 | 1114 | | | | | | 1115 | DUPLICATE_PUSH | No | Yes | No | Section 7.2.8 | 1116 | | | | | | 1117 | Reserved | Yes | Yes | Yes | {{frame-reserved} | 1118 +----------------+---------+----------+---------+-------------------+ 1120 Table 1: HTTP/3 frames and stream type overview 1122 Certain frames can only occur as the first frame of a particular 1123 stream type; these are indicated in Table 1 with a (1). Specific 1124 guidance is provided in the relevant section. 1126 Note that, unlike QUIC frames, HTTP/3 frames can span multiple 1127 packets. 1129 7.1. Frame Layout 1131 All frames have the following format: 1133 0 1 2 3 1134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Type (i) ... 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Length (i) ... 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Frame Payload (*) ... 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 Figure 3: HTTP/3 frame format 1145 A frame includes the following fields: 1147 Type: A variable-length integer that identifies the frame type. 1149 Length: A variable-length integer that describes the length of the 1150 Frame Payload. 1152 Frame Payload: A payload, the semantics of which are determined by 1153 the Type field. 1155 Each frame's payload MUST contain exactly the fields identified in 1156 its description. A frame payload that contains additional bytes 1157 after the identified fields or a frame payload that terminates before 1158 the end of the identified fields MUST be treated as a connection 1159 error of type HTTP_FRAME_ERROR. 1161 When a stream terminates cleanly, if the last frame on the stream was 1162 truncated, this MUST be treated as a connection error (Section 8) of 1163 type HTTP_FRAME_ERROR. Streams which terminate abruptly may be reset 1164 at any point in a frame. 1166 7.2. Frame Definitions 1168 7.2.1. DATA 1170 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1171 bytes associated with an HTTP request or response payload. 1173 DATA frames MUST be associated with an HTTP request or response. If 1174 a DATA frame is received on a control stream, the recipient MUST 1175 respond with a connection error (Section 8) of type 1176 HTTP_FRAME_UNEXPECTED. 1178 0 1 2 3 1179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Payload (*) ... 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 Figure 4: DATA frame payload 1186 7.2.2. HEADERS 1188 The HEADERS frame (type=0x1) is used to carry a header block, 1189 compressed using QPACK. See [QPACK] for more details. 1191 0 1 2 3 1192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Header Block (*) ... 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Figure 5: HEADERS frame payload 1199 HEADERS frames can only be sent on request / push streams. If a 1200 HEADERS frame is received on a control stream, the recipient MUST 1201 respond with a connection error (Section 8) of type 1202 HTTP_FRAME_UNEXPECTED. 1204 7.2.3. CANCEL_PUSH 1206 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 1207 server push prior to the push stream being received. The CANCEL_PUSH 1208 frame identifies a server push by Push ID (see Section 7.2.5), 1209 encoded as a variable-length integer. 1211 When a server receives this frame, it aborts sending the response for 1212 the identified server push. If the server has not yet started to 1213 send the server push, it can use the receipt of a CANCEL_PUSH frame 1214 to avoid opening a push stream. If the push stream has been opened 1215 by the server, the server SHOULD abruptly terminate that stream. 1217 A server can send the CANCEL_PUSH frame to indicate that it will not 1218 be fulfilling a promise prior to creation of a push stream. Once the 1219 push stream has been created, sending CANCEL_PUSH has no effect on 1220 the state of the push stream. The server SHOULD abruptly terminate 1221 the push stream instead. 1223 A CANCEL_PUSH frame is sent on the control stream. Receiving a 1224 CANCEL_PUSH frame on a stream other than the control stream MUST be 1225 treated as a connection error of type HTTP_FRAME_UNEXPECTED. 1227 0 1 2 3 1228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Push ID (i) ... 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 Figure 6: CANCEL_PUSH frame payload 1235 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 1236 integer. The Push ID identifies the server push that is being 1237 cancelled (see Section 7.2.5). 1239 If the client receives a CANCEL_PUSH frame, that frame might identify 1240 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 1242 7.2.4. SETTINGS 1244 The SETTINGS frame (type=0x4) conveys configuration parameters that 1245 affect how endpoints communicate, such as preferences and constraints 1246 on peer behavior. Individually, a SETTINGS parameter can also be 1247 referred to as a "setting"; the identifier and value of each setting 1248 parameter can be referred to as a "setting identifier" and a "setting 1249 value". 1251 SETTINGS frames always apply to a connection, never a single stream. 1252 A SETTINGS frame MUST be sent as the first frame of each control 1253 stream (see Section 6.2.1) by each peer, and MUST NOT be sent 1254 subsequently. If an endpoint receives a second SETTINGS frame on the 1255 control stream, the endpoint MUST respond with a connection error of 1256 type HTTP_FRAME_UNEXPECTED. 1258 SETTINGS frames MUST NOT be sent on any stream other than the control 1259 stream. If an endpoint receives a SETTINGS frame on a different 1260 stream, the endpoint MUST respond with a connection error of type 1261 HTTP_FRAME_UNEXPECTED. 1263 SETTINGS parameters are not negotiated; they describe characteristics 1264 of the sending peer, which can be used by the receiving peer. 1265 However, a negotiation can be implied by the use of SETTINGS - each 1266 peer uses SETTINGS to advertise a set of supported values. The 1267 definition of the setting would describe how each peer combines the 1268 two sets to conclude which choice will be used. SETTINGS does not 1269 provide a mechanism to identify when the choice takes effect. 1271 Different values for the same parameter can be advertised by each 1272 peer. For example, a client might be willing to consume a very large 1273 response header, while servers are more cautious about request size. 1275 The same setting identifier MUST NOT occur more than once in the 1276 SETTINGS frame. A receiver MAY treat the presence of duplicate 1277 setting identifiers as a connection error of type 1278 HTTP_SETTINGS_ERROR. 1280 The payload of a SETTINGS frame consists of zero or more parameters. 1281 Each parameter consists of a setting identifier and a value, both 1282 encoded as QUIC variable-length integers. 1284 0 1 2 3 1285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Identifier (i) ... 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Value (i) ... 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 Figure 7: SETTINGS parameter format 1294 An implementation MUST ignore the contents for any SETTINGS 1295 identifier it does not understand. 1297 7.2.4.1. Defined SETTINGS Parameters 1299 The following settings are defined in HTTP/3: 1301 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. 1302 See Section 4.1.1 for usage. 1304 Setting identifiers of the format "0x1f * N + 0x21" for integer 1305 values of N are reserved to exercise the requirement that unknown 1306 identifiers be ignored. Such settings have no defined meaning. 1307 Endpoints SHOULD include at least one such setting in their SETTINGS 1308 frame. Endpoints MUST NOT consider such settings to have any meaning 1309 upon receipt. 1311 Because the setting has no defined meaning, the value of the setting 1312 can be any value the implementation selects. 1314 Additional settings can be defined by extensions to HTTP/3; see 1315 Section 9 for more details. 1317 7.2.4.2. Initialization 1319 An HTTP implementation MUST NOT send frames or requests which would 1320 be invalid based on its current understanding of the peer's settings. 1322 All settings begin at an initial value. Each endpoint SHOULD use 1323 these initial values to send messages before the peer's SETTINGS 1324 frame has arrived, as packets carrying the settings can be lost or 1325 delayed. When the SETTINGS frame arrives, any settings are changed 1326 to their new values. 1328 This removes the need to wait for the SETTINGS frame before sending 1329 messages. Endpoints MUST NOT require any data to be received from 1330 the peer prior to sending the SETTINGS frame; settings MUST be sent 1331 as soon as the transport is ready to send data. 1333 For servers, the initial value of each client setting is the default 1334 value. 1336 For clients using a 1-RTT QUIC connection, the initial value of each 1337 server setting is the default value. 1-RTT keys will always become 1338 available prior to SETTINGS arriving, even if the server sends 1339 SETTINGS immediately. Clients SHOULD NOT wait indefinitely for 1340 SETTINGS to arrive before sending requests, but SHOULD process 1341 received datagrams in order to increase the likelihood of processing 1342 SETTINGS before sending the first request. 1344 When a 0-RTT QUIC connection is being used, the initial value of each 1345 server setting is the value used in the previous session. Clients 1346 SHOULD store the settings the server provided in the connection where 1347 resumption information was provided, but MAY opt not to store 1348 settings in certain cases (e.g., if the session ticket is received 1349 before the SETTINGS frame). A client MUST comply with stored 1350 settings - or default values, if no values are stored - when 1351 attempting 0-RTT. Once a server has provided new settings, clients 1352 MUST comply with those values. 1354 A server can remember the settings that it advertised, or store an 1355 integrity-protected copy of the values in the ticket and recover the 1356 information when accepting 0-RTT data. A server uses the HTTP/3 1357 settings values in determining whether to accept 0-RTT data. If the 1358 server cannot determine that the settings remembered by a client are 1359 compatible with its current settings, it MUST NOT accept 0-RTT data. 1360 Remembered settings are compatible if a client complying with those 1361 settings would not violate the server's current settings. 1363 A server MAY accept 0-RTT and subsequently provide different settings 1364 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 1365 SETTINGS frame MUST NOT reduce any limits or alter any values that 1366 might be violated by the client with its 0-RTT data. The server MUST 1367 include all settings which differ from their default values. If a 1368 server accepts 0-RTT, but then sends a SETTINGS frame which reduces a 1369 setting the client understands or omits a value that was previously 1370 specified to have a non-default value, this MUST be treated as a 1371 connection error of type HTTP_SETTINGS_ERROR. 1373 7.2.5. PUSH_PROMISE 1375 The PUSH_PROMISE frame (type=0x5) is used to carry a promised request 1376 header set from server to client on a request stream, as in HTTP/2. 1378 0 1 2 3 1379 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Push ID (i) ... 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Header Block (*) ... 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 Figure 8: PUSH_PROMISE frame payload 1388 The payload consists of: 1390 Push ID: A variable-length integer that identifies the server push 1391 operation. A Push ID is used in push stream headers 1392 (Section 4.4), CANCEL_PUSH frames (Section 7.2.3), and 1393 DUPLICATE_PUSH frames (Section 7.2.8). 1395 Header Block: QPACK-compressed request header fields for the 1396 promised response. See [QPACK] for more details. 1398 A server MUST NOT use a Push ID that is larger than the client has 1399 provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat 1400 receipt of a PUSH_PROMISE frame that contains a larger Push ID than 1401 the client has advertised as a connection error of HTTP_ID_ERROR. 1403 A server MUST NOT use the same Push ID in multiple PUSH_PROMISE 1404 frames. A client MUST treat receipt of a Push ID which has already 1405 been promised as a connection error of type HTTP_ID_ERROR. 1407 If a PUSH_PROMISE frame is received on the control stream, the client 1408 MUST respond with a connection error (Section 8) of type 1409 HTTP_FRAME_UNEXPECTED. 1411 A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the 1412 receipt of a PUSH_PROMISE frame as a connection error of type 1413 HTTP_FRAME_UNEXPECTED. 1415 See Section 4.4 for a description of the overall server push 1416 mechanism. 1418 7.2.6. GOAWAY 1420 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 1421 a connection by a server. GOAWAY allows a server to stop accepting 1422 new requests while still finishing processing of previously received 1423 requests. This enables administrative actions, like server 1424 maintenance. GOAWAY by itself does not close a connection. 1426 0 1 2 3 1427 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Stream ID (i) ... 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Figure 9: GOAWAY frame payload 1434 The GOAWAY frame is always sent on the control stream. It carries a 1435 QUIC Stream ID for a client-initiated bidirectional stream encoded as 1436 a variable-length integer. A client MUST treat receipt of a GOAWAY 1437 frame containing a Stream ID of any other type as a connection error 1438 of type HTTP_ID_ERROR. 1440 Clients do not need to send GOAWAY to initiate a graceful shutdown; 1441 they simply stop making new requests. A server MUST treat receipt of 1442 a GOAWAY frame on any stream as a connection error (Section 8) of 1443 type HTTP_FRAME_UNEXPECTED. 1445 The GOAWAY frame applies to the connection, not a specific stream. A 1446 client MUST treat a GOAWAY frame on a stream other than the control 1447 stream as a connection error (Section 8) of type 1448 HTTP_FRAME_UNEXPECTED. 1450 See Section 5.2 for more information on the use of the GOAWAY frame. 1452 7.2.7. MAX_PUSH_ID 1454 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 1455 number of server pushes that the server can initiate. This sets the 1456 maximum value for a Push ID that the server can use in a PUSH_PROMISE 1457 frame. Consequently, this also limits the number of push streams 1458 that the server can initiate in addition to the limit maintained by 1459 the QUIC transport. 1461 The MAX_PUSH_ID frame is always sent on the control stream. Receipt 1462 of a MAX_PUSH_ID frame on any other stream MUST be treated as a 1463 connection error of type HTTP_FRAME_UNEXPECTED. 1465 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1466 receipt of a MAX_PUSH_ID frame as a connection error of type 1467 HTTP_FRAME_UNEXPECTED. 1469 The maximum Push ID is unset when a connection is created, meaning 1470 that a server cannot push until it receives a MAX_PUSH_ID frame. A 1471 client that wishes to manage the number of promised server pushes can 1472 increase the maximum Push ID by sending MAX_PUSH_ID frames as the 1473 server fulfills or cancels server pushes. 1475 0 1 2 3 1476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Push ID (i) ... 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 Figure 10: MAX_PUSH_ID frame payload 1483 The MAX_PUSH_ID frame carries a single variable-length integer that 1484 identifies the maximum value for a Push ID that the server can use 1485 (see Section 7.2.5). A MAX_PUSH_ID frame cannot reduce the maximum 1486 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 1487 previously received MUST be treated as a connection error of type 1488 HTTP_ID_ERROR. 1490 7.2.8. DUPLICATE_PUSH 1492 The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate 1493 that an existing pushed resource is related to multiple client 1494 requests. 1496 The DUPLICATE_PUSH frame is always sent on a request stream. Receipt 1497 of a DUPLICATE_PUSH frame on any other stream MUST be treated as a 1498 connection error of type HTTP_FRAME_UNEXPECTED. 1500 A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat 1501 the receipt of a DUPLICATE_PUSH frame as a connection error of type 1502 HTTP_FRAME_UNEXPECTED. 1504 0 1 2 3 1505 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Push ID (i) ... 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 Figure 11: DUPLICATE_PUSH frame payload 1512 The DUPLICATE_PUSH frame carries a single variable-length integer 1513 that identifies the Push ID of a resource that the server has 1514 previously promised (see Section 7.2.5), though that promise might 1515 not be received before this frame. A server MUST NOT use a Push ID 1516 that is larger than the client has provided in a MAX_PUSH_ID frame 1517 (Section 7.2.7). A client MUST treat receipt of a DUPLICATE_PUSH 1518 that contains a larger Push ID than the client has advertised as a 1519 connection error of type HTTP_ID_ERROR. 1521 This frame allows the server to use the same server push in response 1522 to multiple concurrent requests. Referencing the same server push 1523 ensures that a promise can be made in relation to every response in 1524 which server push might be needed without duplicating request headers 1525 or pushed responses. 1527 Allowing duplicate references to the same Push ID is primarily to 1528 reduce duplication caused by concurrent requests. A server SHOULD 1529 avoid reusing a Push ID over a long period. Clients are likely to 1530 consume server push responses and not retain them for reuse over 1531 time. Clients that see a DUPLICATE_PUSH that uses a Push ID that 1532 they have since consumed and discarded are forced to ignore the 1533 DUPLICATE_PUSH. 1535 7.2.9. Reserved Frame Types 1537 Frame types of the format "0x1f * N + 0x21" for integer values of N 1538 are reserved to exercise the requirement that unknown types be 1539 ignored (Section 9). These frames have no semantics, and can be sent 1540 on any open stream when application-layer padding is desired. They 1541 MAY also be sent on connections where no data is currently being 1542 transferred. Endpoints MUST NOT consider these frames to have any 1543 meaning upon receipt. 1545 The payload and length of the frames are selected in any manner the 1546 implementation chooses. 1548 Frame types which were used in HTTP/2 where there is no corresponding 1549 HTTP/3 frame have also been reserved (Section 11.3). These frame 1550 types MUST NOT be sent, and receipt MAY be treated as an error of 1551 type HTTP_UNEXPECTED_FRAME. 1553 8. Error Handling 1555 QUIC allows the application to abruptly terminate (reset) individual 1556 streams or the entire connection when an error is encountered. These 1557 are referred to as "stream errors" or "connection errors" and are 1558 described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose 1559 to treat a stream error as a connection error. 1561 Because new error codes can be defined without negotiation (see 1562 Section 9), receipt of an unknown error code or use of an error code 1563 in an unexpected context MUST NOT be treated as an error. However, 1564 closing a stream can constitute an error regardless of the error code 1565 (see Section 4.1). 1567 This section describes HTTP/3-specific error codes which can be used 1568 to express the cause of a connection or stream error. 1570 8.1. HTTP/3 Error Codes 1572 The following error codes are defined for use when abruptly 1573 terminating streams, aborting reading of streams, or immediately 1574 closing connections. 1576 HTTP_NO_ERROR (0x100): No error. This is used when the connection 1577 or stream needs to be closed, but there is no error to signal. 1579 HTTP_GENERAL_PROTOCOL_ERROR (0x101): Peer violated protocol 1580 requirements in a way which doesn't match a more specific error 1581 code, or endpoint declines to use the more specific error code. 1583 HTTP_INTERNAL_ERROR (0x102): An internal error has occurred in the 1584 HTTP stack. 1586 HTTP_STREAM_CREATION_ERROR (0x103): The endpoint detected that its 1587 peer created a stream that it will not accept. 1589 HTTP_CLOSED_CRITICAL_STREAM (0x104): A stream required by the 1590 connection was closed or reset. 1592 HTTP_FRAME_UNEXPECTED (0x105): A frame was received which was not 1593 permitted in the current state or on the current stream. 1595 HTTP_FRAME_ERROR (0x106): A frame that fails to satisfy layout 1596 requirements or with an invalid size was received. 1598 HTTP_EXCESSIVE_LOAD (0x107): The endpoint detected that its peer is 1599 exhibiting a behavior that might be generating excessive load. 1601 HTTP_ID_ERROR (0x108): A Stream ID or Push ID was used incorrectly, 1602 such as exceeding a limit, reducing a limit, or being reused. 1604 HTTP_SETTINGS_ERROR (0x109): An endpoint detected an error in the 1605 payload of a SETTINGS frame. 1607 HTTP_MISSING_SETTINGS (0x10A): No SETTINGS frame was received at the 1608 beginning of the control stream. 1610 HTTP_REQUEST_REJECTED (0x10B): A server rejected a request without 1611 performing any application processing. 1613 HTTP_REQUEST_CANCELLED (0x10C): The request or its response 1614 (including pushed response) is cancelled. 1616 HTTP_REQUEST_INCOMPLETE (0x10D): The client's stream terminated 1617 without containing a fully-formed request. 1619 HTTP_EARLY_RESPONSE (0x10E): The remainder of the client's request 1620 is not needed to produce a response. For use in STOP_SENDING 1621 only. 1623 HTTP_CONNECT_ERROR (0x10F): The connection established in response 1624 to a CONNECT request was reset or abnormally closed. 1626 HTTP_VERSION_FALLBACK (0x110): The requested operation cannot be 1627 served over HTTP/3. The peer should retry over HTTP/1.1. 1629 9. Extensions to HTTP/3 1631 HTTP/3 permits extension of the protocol. Within the limitations 1632 described in this section, protocol extensions can be used to provide 1633 additional services or alter any aspect of the protocol. Extensions 1634 are effective only within the scope of a single HTTP/3 connection. 1636 This applies to the protocol elements defined in this document. This 1637 does not affect the existing options for extending HTTP, such as 1638 defining new methods, status codes, or header fields. 1640 Extensions are permitted to use new frame types (Section 7.2), new 1641 settings (Section 7.2.4.1), new error codes (Section 8), or new 1642 unidirectional stream types (Section 6.2). Registries are 1643 established for managing these extension points: frame types 1644 (Section 11.3), settings (Section 11.4), error codes (Section 11.5), 1645 and stream types (Section 11.6). 1647 Implementations MUST ignore unknown or unsupported values in all 1648 extensible protocol elements. Implementations MUST discard frames 1649 and unidirectional streams that have unknown or unsupported types. 1650 This means that any of these extension points can be safely used by 1651 extensions without prior arrangement or negotiation. However, where 1652 a known frame type is required to be in a specific location, such as 1653 the SETTINGS frame as the first frame of the control stream (see 1654 Section 6.2.1), an unknown frame type does not satisfy that 1655 requirement and SHOULD be treated as an error. 1657 Extensions that could change the semantics of existing protocol 1658 components MUST be negotiated before being used. For example, an 1659 extension that changes the layout of the HEADERS frame cannot be used 1660 until the peer has given a positive signal that this is acceptable. 1661 In this case, it could also be necessary to coordinate when the 1662 revised layout comes into effect. 1664 This document doesn't mandate a specific method for negotiating the 1665 use of an extension but notes that a setting (Section 7.2.4.1) could 1666 be used for that purpose. If both peers set a value that indicates 1667 willingness to use the extension, then the extension can be used. If 1668 a setting is used for extension negotiation, the default value MUST 1669 be defined in such a fashion that the extension is disabled if the 1670 setting is omitted. 1672 10. Security Considerations 1674 The security considerations of HTTP/3 should be comparable to those 1675 of HTTP/2 with TLS; the considerations from Section 10 of [HTTP2] 1676 apply in addition to those listed here. 1678 When HTTP Alternative Services is used for discovery for HTTP/3 1679 endpoints, the security considerations of [ALTSVC] also apply. 1681 10.1. Traffic Analysis 1683 Where HTTP/2 employs PADDING frames and Padding fields in other 1684 frames to make a connection more resistant to traffic analysis, 1685 HTTP/3 can either rely on transport-layer padding or employ the 1686 reserved frame and stream types discussed in Section 7.2.9 and 1687 Section 6.2.3. These methods of padding produce different results in 1688 terms of the granularity of padding, the effect of packet loss and 1689 recovery, and how an implementation might control padding. 1691 10.2. Frame Parsing 1693 Several protocol elements contain nested length elements, typically 1694 in the form of frames with an explicit length containing variable- 1695 length integers. This could pose a security risk to an incautious 1696 implementer. An implementation MUST ensure that the length of a 1697 frame exactly matches the length of the fields it contains. 1699 10.3. Early Data 1701 The use of 0-RTT with HTTP/3 creates an exposure to replay attack. 1702 The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when 1703 using HTTP/3 with 0-RTT. 1705 10.4. Migration 1707 Certain HTTP implementations use the client address for logging or 1708 access-control purposes. Since a QUIC client's address might change 1709 during a connection (and future versions might support simultaneous 1710 use of multiple addresses), such implementations will need to either 1711 actively retrieve the client's current address or addresses when they 1712 are relevant or explicitly accept that the original address might 1713 change. 1715 11. IANA Considerations 1717 11.1. Registration of HTTP/3 Identification String 1719 This document creates a new registration for the identification of 1720 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 1721 IDs" registry established in [RFC7301]. 1723 The "h3" string identifies HTTP/3: 1725 Protocol: HTTP/3 1727 Identification Sequence: 0x68 0x33 ("h3") 1729 Specification: This document 1731 11.2. Registration of QUIC Version Hint Alt-Svc Parameter 1733 This document creates a new registration for version-negotiation 1734 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1735 registry established in [RFC7838]. 1737 Parameter: "quic" 1739 Specification: This document, Section 3.2.1 1741 11.3. Frame Types 1743 This document establishes a registry for HTTP/3 frame type codes. 1744 The "HTTP/3 Frame Type" registry governs a 62-bit space. This space 1745 is split into three spaces that are governed by different policies. 1746 Values between "0x00" and "0x3f" (in hexadecimal) are assigned via 1747 the Standards Action or IESG Review policies [RFC8126]. Values from 1748 "0x40" to "0x3fff" operate on the Specification Required policy 1749 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 1751 While this registry is separate from the "HTTP/2 Frame Type" registry 1752 defined in [HTTP2], it is preferable that the assignments parallel 1753 each other where the code spaces overlap. If an entry is present in 1754 only one registry, every effort SHOULD be made to avoid assigning the 1755 corresponding value to an unrelated operation. 1757 New entries in this registry require the following information: 1759 Frame Type: A name or label for the frame type. 1761 Code: The 62-bit code assigned to the frame type. 1763 Specification: A reference to a specification that includes a 1764 description of the frame layout and its semantics, including any 1765 parts of the frame that are conditionally present. 1767 The entries in the following table are registered by this document. 1769 +----------------+------+---------------+ 1770 | Frame Type | Code | Specification | 1771 +----------------+------+---------------+ 1772 | DATA | 0x0 | Section 7.2.1 | 1773 | | | | 1774 | HEADERS | 0x1 | Section 7.2.2 | 1775 | | | | 1776 | Reserved | 0x2 | N/A | 1777 | | | | 1778 | CANCEL_PUSH | 0x3 | Section 7.2.3 | 1779 | | | | 1780 | SETTINGS | 0x4 | Section 7.2.4 | 1781 | | | | 1782 | PUSH_PROMISE | 0x5 | Section 7.2.5 | 1783 | | | | 1784 | Reserved | 0x6 | N/A | 1785 | | | | 1786 | GOAWAY | 0x7 | Section 7.2.6 | 1787 | | | | 1788 | Reserved | 0x8 | N/A | 1789 | | | | 1790 | Reserved | 0x9 | N/A | 1791 | | | | 1792 | MAX_PUSH_ID | 0xD | Section 7.2.7 | 1793 | | | | 1794 | DUPLICATE_PUSH | 0xE | Section 7.2.8 | 1795 +----------------+------+---------------+ 1797 Additionally, each code of the format "0x1f * N + 0x21" for integer 1798 values of N (that is, "0x21", "0x40", ..., through 1799 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 1801 11.4. Settings Parameters 1803 This document establishes a registry for HTTP/3 settings. The 1804 "HTTP/3 Settings" registry governs a 62-bit space. This space is 1805 split into three spaces that are governed by different policies. 1806 Values between "0x00" and "0x3f" (in hexadecimal) are assigned via 1807 the Standards Action or IESG Review policies [RFC8126]. Values from 1808 "0x40" to "0x3fff" operate on the Specification Required policy 1809 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 1810 The designated experts are the same as those for the "HTTP/2 1811 Settings" registry defined in [HTTP2]. 1813 While this registry is separate from the "HTTP/2 Settings" registry 1814 defined in [HTTP2], it is preferable that the assignments parallel 1815 each other. If an entry is present in only one registry, every 1816 effort SHOULD be made to avoid assigning the corresponding value to 1817 an unrelated operation. 1819 New registrations are advised to provide the following information: 1821 Name: A symbolic name for the setting. Specifying a setting name is 1822 optional. 1824 Code: The 62-bit code assigned to the setting. 1826 Specification: An optional reference to a specification that 1827 describes the use of the setting. 1829 Default: The value of the setting unless otherwise indicated. 1830 SHOULD be the most restrictive possible value. 1832 The entries in the following table are registered by this document. 1834 +----------------------+------+-----------------+-----------+ 1835 | Setting Name | Code | Specification | Default | 1836 +----------------------+------+-----------------+-----------+ 1837 | Reserved | 0x2 | N/A | N/A | 1838 | | | | | 1839 | Reserved | 0x3 | N/A | N/A | 1840 | | | | | 1841 | Reserved | 0x4 | N/A | N/A | 1842 | | | | | 1843 | Reserved | 0x5 | N/A | N/A | 1844 | | | | | 1845 | MAX_HEADER_LIST_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | 1846 +----------------------+------+-----------------+-----------+ 1848 Additionally, each code of the format "0x1f * N + 0x21" for integer 1849 values of N (that is, "0x21", "0x40", ..., through 1850 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 1852 11.5. Error Codes 1854 This document establishes a registry for HTTP/3 error codes. The 1855 "HTTP/3 Error Code" registry manages a 62-bit space. The "HTTP/3 1856 Error Code" registry operates under the "Expert Review" policy 1857 [RFC8126]. 1859 Registrations for error codes are required to include a description 1860 of the error code. An expert reviewer is advised to examine new 1861 registrations for possible duplication with existing error codes. 1862 Use of existing registrations is to be encouraged, but not mandated. 1864 New registrations are advised to provide the following information: 1866 Name: A name for the error code. Specifying an error code name is 1867 optional. 1869 Code: The 62-bit error code value. 1871 Description: A brief description of the error code semantics, longer 1872 if no detailed specification is provided. 1874 Specification: An optional reference for a specification that 1875 defines the error code. 1877 The entries in the following table are registered by this document. 1879 +----------------------------+--------+-------------+---------------+ 1880 | Name | Code | Description | Specification | 1881 +----------------------------+--------+-------------+---------------+ 1882 | HTTP_NO_ERROR | 0x0100 | No error | Section 8.1 | 1883 | | | | | 1884 | HTTP_GENERAL_PROTOCOL_ERRO | 0x0101 | General | Section 8.1 | 1885 | R | | protocol | | 1886 | | | error | | 1887 | | | | | 1888 | HTTP_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 | 1889 | | | error | | 1890 | | | | | 1891 | HTTP_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 | 1892 | | | creation | | 1893 | | | error | | 1894 | | | | | 1895 | HTTP_CLOSED_CRITICAL_STREA | 0x0104 | Critical | Section 8.1 | 1896 | M | | stream was | | 1897 | | | closed | | 1898 | | | | | 1899 | HTTP_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 | 1900 | | | permitted | | 1901 | | | in the | | 1902 | | | current | | 1903 | | | state | | 1904 | | | | | 1905 | HTTP_FRAME_ERROR | 0x0106 | Frame | Section 8.1 | 1906 | | | violated | | 1907 | | | layout or | | 1908 | | | size rules | | 1909 | | | | | 1910 | HTTP_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 | 1911 | | | generating | | 1912 | | | excessive | | 1913 | | | load | | 1914 | | | | | 1915 | HTTP_ID_ERROR | 0x0108 | An | Section 8.1 | 1916 | | | identifier | | 1917 | | | was used | | 1918 | | | incorrectly | | 1919 | | | | | 1920 | HTTP_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 | 1921 | | | frame | | 1922 | | | contained | | 1923 | | | invalid | | 1924 | | | values | | 1925 | | | | | 1926 | HTTP_MISSING_SETTINGS | 0x010A | No SETTINGS | Section 8.1 | 1927 | | | frame | | 1928 | | | received | | 1929 | | | | | 1930 | HTTP_REQUEST_REJECTED | 0x010B | Request not | Section 8.1 | 1931 | | | processed | | 1932 | | | | | 1933 | HTTP_REQUEST_CANCELLED | 0x010C | Data no | Section 8.1 | 1934 | | | longer | | 1935 | | | needed | | 1936 | | | | | 1937 | HTTP_REQUEST_INCOMPLETE | 0x010D | Stream | Section 8.1 | 1938 | | | terminated | | 1939 | | | early | | 1940 | | | | | 1941 | HTTP_EARLY_RESPONSE | 0x010E | Remainder | Section 8.1 | 1942 | | | of request | | 1943 | | | not needed | | 1944 | | | | | 1945 | HTTP_CONNECT_ERROR | 0x010F | TCP reset | Section 8.1 | 1946 | | | or error on | | 1947 | | | CONNECT | | 1948 | | | request | | 1949 | | | | | 1950 | HTTP_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 | 1951 | | | HTTP/1.1 | | 1952 +----------------------------+--------+-------------+---------------+ 1954 11.6. Stream Types 1956 This document establishes a registry for HTTP/3 unidirectional stream 1957 types. The "HTTP/3 Stream Type" registry governs a 62-bit space. 1958 This space is split into three spaces that are governed by different 1959 policies. Values between "0x00" and 0x3f (in hexadecimal) are 1960 assigned via the Standards Action or IESG Review policies [RFC8126]. 1961 Values from "0x40" to "0x3fff" operate on the Specification Required 1962 policy [RFC8126]. All other values are assigned to Private Use 1963 [RFC8126]. 1965 New entries in this registry require the following information: 1967 Stream Type: A name or label for the stream type. 1969 Code: The 62-bit code assigned to the stream type. 1971 Specification: A reference to a specification that includes a 1972 description of the stream type, including the layout semantics of 1973 its payload. 1975 Sender: Which endpoint on a connection may initiate a stream of this 1976 type. Values are "Client", "Server", or "Both". 1978 The entries in the following table are registered by this document. 1980 +----------------+------+---------------+--------+ 1981 | Stream Type | Code | Specification | Sender | 1982 +----------------+------+---------------+--------+ 1983 | Control Stream | 0x00 | Section 6.2.1 | Both | 1984 | | | | | 1985 | Push Stream | 0x01 | Section 4.4 | Server | 1986 +----------------+------+---------------+--------+ 1988 Additionally, each code of the format "0x1f * N + 0x21" for integer 1989 values of N (that is, "0x21", "0x40", ..., through 1990 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 1992 12. References 1994 12.1. Normative References 1996 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1997 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1998 April 2016, . 2000 [HTTP-REPLAY] 2001 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 2002 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2003 2018, . 2005 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2006 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2007 DOI 10.17487/RFC7540, May 2015, 2008 . 2010 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 2011 Header Compression for HTTP over QUIC", draft-ietf-quic- 2012 qpack-10 (work in progress), September 2019. 2014 [QUIC-TRANSPORT] 2015 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2016 Multiplexed and Secure Transport", draft-ietf-quic- 2017 transport-23 (work in progress), September 2019. 2019 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2020 RFC 793, DOI 10.17487/RFC0793, September 1981, 2021 . 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2024 Requirement Levels", BCP 14, RFC 2119, 2025 DOI 10.17487/RFC2119, March 1997, 2026 . 2028 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2029 Specifications: ABNF", STD 68, RFC 5234, 2030 DOI 10.17487/RFC5234, January 2008, 2031 . 2033 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2034 Extensions: Extension Definitions", RFC 6066, 2035 DOI 10.17487/RFC6066, January 2011, 2036 . 2038 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2039 DOI 10.17487/RFC6265, April 2011, 2040 . 2042 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2043 Protocol (HTTP/1.1): Message Syntax and Routing", 2044 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2045 . 2047 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2048 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2049 DOI 10.17487/RFC7231, June 2014, 2050 . 2052 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2053 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2054 April 2016, . 2056 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2057 Writing an IANA Considerations Section in RFCs", BCP 26, 2058 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2059 . 2061 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 2062 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 2063 . 2065 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2066 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2067 May 2017, . 2069 12.2. Informative References 2071 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 2072 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 2073 . 2075 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 2076 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 2077 . 2079 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2080 "Transport Layer Security (TLS) Application-Layer Protocol 2081 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2082 July 2014, . 2084 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2085 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2086 . 2088 12.3. URIs 2090 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 2092 [2] https://github.com/quicwg 2094 [3] https://github.com/quicwg/base-drafts/labels/-http 2096 [4] https://www.iana.org/assignments/message-headers 2098 Appendix A. Considerations for Transitioning from HTTP/2 2100 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 2101 This section describes the approach taken to design HTTP/3, points 2102 out important differences from HTTP/2, and describes how to map 2103 HTTP/2 extensions into HTTP/3. 2105 HTTP/3 begins from the premise that similarity to HTTP/2 is 2106 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 2107 where QUIC differs from TCP, either to take advantage of QUIC 2108 features (like streams) or to accommodate important shortcomings 2109 (such as a lack of total ordering). These differences make HTTP/3 2110 similar to HTTP/2 in key aspects, such as the relationship of 2111 requests and responses to streams. However, the details of the 2112 HTTP/3 design are substantially different than HTTP/2. 2114 These departures are noted in this section. 2116 A.1. Streams 2118 HTTP/3 permits use of a larger number of streams (2^62-1) than 2119 HTTP/2. The considerations about exhaustion of stream identifier 2120 space apply, though the space is significantly larger such that it is 2121 likely that other limits in QUIC are reached first, such as the limit 2122 on the connection flow control window. 2124 A.2. HTTP Frame Types 2126 Many framing concepts from HTTP/2 can be elided on QUIC, because the 2127 transport deals with them. Because frames are already on a stream, 2128 they can omit the stream number. Because frames do not block 2129 multiplexing (QUIC's multiplexing occurs below this layer), the 2130 support for variable-maximum-length packets can be removed. Because 2131 stream termination is handled by QUIC, an END_STREAM flag is not 2132 required. This permits the removal of the Flags field from the 2133 generic frame layout. 2135 Frame payloads are largely drawn from [HTTP2]. However, QUIC 2136 includes many features (e.g., flow control) which are also present in 2137 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 2138 As a result, several HTTP/2 frame types are not required in HTTP/3. 2139 Where an HTTP/2-defined frame is no longer used, the frame ID has 2140 been reserved in order to maximize portability between HTTP/2 and 2141 HTTP/3 implementations. However, even equivalent frames between the 2142 two mappings are not identical. 2144 Many of the differences arise from the fact that HTTP/2 provides an 2145 absolute ordering between frames across all streams, while QUIC 2146 provides this guarantee on each stream only. As a result, if a frame 2147 type makes assumptions that frames from different streams will still 2148 be received in the order sent, HTTP/3 will break them. 2150 Some examples of feature adaptations are described below, as well as 2151 general guidance to extension frame implementors converting an HTTP/2 2152 extension to HTTP/3. 2154 A.2.1. Prioritization Differences 2156 HTTP/2 specifies priority assignments in PRIORITY frames and 2157 (optionally) in HEADERS frames. HTTP/3 does not provide a means of 2158 signaling priority. 2160 Note that while there is no explicit signaling for priority, this 2161 does not mean that prioritization is not important for achieving good 2162 performance. 2164 A.2.2. Header Compression Differences 2166 HPACK was designed with the assumption of in-order delivery. A 2167 sequence of encoded header blocks must arrive (and be decoded) at an 2168 endpoint in the same order in which they were encoded. This ensures 2169 that the dynamic state at the two endpoints remains in sync. 2171 Because this total ordering is not provided by QUIC, HTTP/3 uses a 2172 modified version of HPACK, called QPACK. QPACK uses a single 2173 unidirectional stream to make all modifications to the dynamic table, 2174 ensuring a total order of updates. All frames which contain encoded 2175 headers merely reference the table state at a given time without 2176 modifying it. 2178 [QPACK] provides additional details. 2180 A.2.3. Guidance for New Frame Type Definitions 2182 Frame type definitions in HTTP/3 often use the QUIC variable-length 2183 integer encoding. In particular, Stream IDs use this encoding, which 2184 allows for a larger range of possible values than the encoding used 2185 in HTTP/2. Some frames in HTTP/3 use an identifier rather than a 2186 Stream ID (e.g., Push IDs). Redefinition of the encoding of 2187 extension frame types might be necessary if the encoding includes a 2188 Stream ID. 2190 Because the Flags field is not present in generic HTTP/3 frames, 2191 those frames which depend on the presence of flags need to allocate 2192 space for flags as part of their frame payload. 2194 Other than this issue, frame type HTTP/2 extensions are typically 2195 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2196 control stream in HTTP/3. HTTP/3 extensions will not assume 2197 ordering, but would not be harmed by ordering, and would be portable 2198 to HTTP/2 in the same manner. 2200 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types 2202 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2203 Section 7.2.1. 2205 HEADERS (0x1): The PRIORITY region of HEADERS is not defined in 2206 HTTP/3 frames. Padding is not defined in HTTP/3 frames. See 2207 Section 7.2.2. 2209 PRIORITY (0x2): As described in Appendix A.2.1, HTTP/3 does not 2210 provide a means of signaling priority. 2212 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 2213 provides stream lifecycle management. The same code point is used 2214 for the CANCEL_PUSH frame (Section 7.2.3). 2216 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2217 the connection. See Section 7.2.4 and Appendix A.3. 2219 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 2220 instead the push stream references the PUSH_PROMISE frame using a 2221 Push ID. See Section 7.2.5. 2223 PING (0x6): PING frames do not exist, since QUIC provides equivalent 2224 functionality. 2226 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 2227 contain an error code. See Section 7.2.6. 2229 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 2230 provides flow control. 2232 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 2233 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. 2235 Frame types defined by extensions to HTTP/2 need to be separately 2236 registered for HTTP/3 if still applicable. The IDs of frames defined 2237 in [HTTP2] have been reserved for simplicity. Note that the frame 2238 type space in HTTP/3 is substantially larger (62 bits versus 8 bits), 2239 so many HTTP/3 frame types have no equivalent HTTP/2 code points. 2240 See Section 11.3. 2242 A.3. HTTP/2 SETTINGS Parameters 2244 An important difference from HTTP/2 is that settings are sent once, 2245 as the first frame of the control stream, and thereafter cannot 2246 change. This eliminates many corner cases around synchronization of 2247 changes. 2249 Some transport-level options that HTTP/2 specifies via the SETTINGS 2250 frame are superseded by QUIC transport parameters in HTTP/3. The 2251 HTTP-level options that are retained in HTTP/3 have the same value as 2252 in HTTP/2. 2254 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2256 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 2258 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 2259 which provides a more granular control over server push. 2261 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 2262 Stream ID as part of its flow control logic. Specifying 2263 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 2265 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 2266 connection flow control window sizes to be specified in the 2267 initial transport handshake. Specifying 2268 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 2270 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. 2271 Specifying it in the SETTINGS frame is an error. 2273 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 7.2.4.1. 2275 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2276 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2278 This will often produce a shorter encoding, but can produce a longer 2279 encoding for settings which use the full 32-bit space. Settings 2280 ported from HTTP/2 might choose to redefine the format of their 2281 settings to avoid using the 62-bit encoding. 2283 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2284 IDs of settings defined in [HTTP2] have been reserved for simplicity. 2285 Note that the settings identifier space in HTTP/3 is substantially 2286 larger (62 bits versus 16 bits), so many HTTP/3 settings have no 2287 equivalent HTTP/2 code point. See Section 11.4. 2289 As QUIC streams might arrive out-of-order, endpoints are advised to 2290 not wait for the peers' settings to arrive before responding to other 2291 streams. See Section 7.2.4.2. 2293 A.4. HTTP/2 Error Codes 2295 QUIC has the same concepts of "stream" and "connection" errors that 2296 HTTP/2 provides. However, there is no direct portability of HTTP/2 2297 error codes to HTTP/3 error codes; the values are shifted in order to 2298 prevent accidental or implicit conversion. 2300 The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map 2301 to the HTTP/3 error codes as follows: 2303 NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1. 2305 PROTOCOL_ERROR (0x1): This is mapped to HTTP_GENERAL_PROTOCOL_ERROR 2306 except in cases where more specific error codes have been defined. 2307 This includes HTTP_FRAME_UNEXPECTED and 2308 HTTP_CLOSED_CRITICAL_STREAM defined in Section 8.1. 2310 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1. 2312 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2313 control. 2315 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2316 SETTINGS is defined. 2318 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2319 management. 2321 FRAME_SIZE_ERROR (0x6): HTTP_FRAME_ERROR error code defined in 2322 Section 8.1. 2324 REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used 2325 to indicate that a request was not processed. Otherwise, not 2326 applicable because QUIC handles stream management. 2328 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. 2330 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2331 [QPACK]. 2333 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. 2335 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. 2337 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2338 provide sufficient security on all connections. 2340 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1. 2342 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2343 Section 11.5. 2345 Appendix B. Change Log 2347 *RFC Editor's Note:* Please remove this section prior to 2348 publication of a final version of this document. 2350 B.1. Since draft-ietf-quic-http-22 2352 o Removed priority signaling (#2922,#2924) 2354 o Further changes to error codes (#2662,#2551): 2356 * Error codes renumbered 2358 * HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR, 2359 HTTP_ID_ERROR, and others 2361 o Clarify how unknown frame types interact with required frame 2362 sequence (#2867,#2858) 2364 o Describe interactions with the transport in terms of defined 2365 interface terms (#2857,#2805) 2367 o Require the use of the "http-opportunistic" resource (RFC 8164) 2368 when scheme is "http" (#2439,#2973) 2370 o Settings identifiers cannot be duplicated (#2979) 2371 o Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945): 2373 * Servers must send all settings with non-default values in their 2374 SETTINGS frame, even when resuming 2376 * If a client doesn't have settings associated with a 0-RTT 2377 ticket, it uses the defaults 2379 * Servers can't accept early data if they cannot recover the 2380 settings the client will have remembered 2382 o Clarify that Upgrade and the 101 status code are prohibited 2383 (#2898,#2889) 2385 o Clarify that frame types reserved for greasing can occur on any 2386 stream, but frame types reserved due to HTTP/2 correspondence are 2387 prohibited (#2997,#2692,#2693) 2389 o Unknown error codes cannot be treated as errors (#2998,#2816) 2391 B.2. Since draft-ietf-quic-http-21 2393 o No changes 2395 B.3. Since draft-ietf-quic-http-20 2397 o Prohibit closing the control stream (#2509, #2666) 2399 o Change default priority to use an orphan node (#2502, #2690) 2401 o Exclusive priorities are restored (#2754, #2781) 2403 o Restrict use of frames when using CONNECT (#2229, #2702) 2405 o Close and maybe reset streams if a connection error occurs for 2406 CONNECT (#2228, #2703) 2408 o Encourage provision of sufficient unidirectional streams for QPACK 2409 (#2100, #2529, #2762) 2411 o Allow extensions to use server-initiated bidirectional streams 2412 (#2711, #2773) 2414 o Clarify use of maximum header list size setting (#2516, #2774) 2416 o Extensive changes to error codes and conditions of their sending 2417 * Require connection errors for more error conditions (#2511, 2418 #2510) 2420 * Updated the error codes for illegal GOAWAY frames (#2714, 2421 #2707) 2423 * Specified error code for HEADERS on control stream (#2708) 2425 * Specified error code for servers receiving PUSH_PROMISE (#2709) 2427 * Specified error code for receiving DATA before HEADERS (#2715) 2429 * Describe malformed messages and their handling (#2410, #2764) 2431 * Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813) 2433 * Refactor Push ID related errors (#2818, #2820) 2435 * Rationalize HTTP/3 stream creation errors (#2821, #2822) 2437 B.4. Since draft-ietf-quic-http-19 2439 o SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530) 2441 o Non-zero bits in the Empty field of the PRIORITY frame MAY be 2442 treated as an error (#2501) 2444 B.5. Since draft-ietf-quic-http-18 2446 o Resetting streams following a GOAWAY is recommended, but not 2447 required (#2256,#2457) 2449 o Use variable-length integers throughout (#2437,#2233,#2253,#2275) 2451 * Variable-length frame types, stream types, and settings 2452 identifiers 2454 * Renumbered stream type assignments 2456 * Modified associated reserved values 2458 o Frame layout switched from Length-Type-Value to Type-Length-Value 2459 (#2395,#2235) 2461 o Specified error code for servers receiving DUPLICATE_PUSH (#2497) 2463 o Use connection error for invalid PRIORITY (#2507, #2508) 2465 B.6. Since draft-ietf-quic-http-17 2467 o HTTP_REQUEST_REJECTED is used to indicate a request can be retried 2468 (#2106, #2325) 2470 o Changed error code for GOAWAY on the wrong stream (#2231, #2343) 2472 B.7. Since draft-ietf-quic-http-16 2474 o Rename "HTTP/QUIC" to "HTTP/3" (#1973) 2476 o Changes to PRIORITY frame (#1865, #2075) 2478 * Permitted as first frame of request streams 2480 * Remove exclusive reprioritization 2482 * Changes to Prioritized Element Type bits 2484 o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 2485 (#2072) 2487 o Set defaults for settings, allow request before receiving SETTINGS 2488 (#1809, #1846, #2038) 2490 o Clarify message processing rules for streams that aren't closed 2491 (#1972, #2003) 2493 o Removed reservation of error code 0 and moved HTTP_NO_ERROR to 2494 this value (#1922) 2496 o Removed prohibition of zero-length DATA frames (#2098) 2498 B.8. Since draft-ietf-quic-http-15 2500 Substantial editorial reorganization; no technical changes. 2502 B.9. Since draft-ietf-quic-http-14 2504 o Recommend sensible values for QUIC transport parameters 2505 (#1720,#1806) 2507 o Define error for missing SETTINGS frame (#1697,#1808) 2509 o Setting values are variable-length integers (#1556,#1807) and do 2510 not have separate maximum values (#1820) 2512 o Expanded discussion of connection closure (#1599,#1717,#1712) 2513 o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 2515 B.10. Since draft-ietf-quic-http-13 2517 o Reserved some frame types for grease (#1333, #1446) 2519 o Unknown unidirectional stream types are tolerated, not errors; 2520 some reserved for grease (#1490, #1525) 2522 o Require settings to be remembered for 0-RTT, prohibit reductions 2523 (#1541, #1641) 2525 o Specify behavior for truncated requests (#1596, #1643) 2527 B.11. Since draft-ietf-quic-http-12 2529 o TLS SNI extension isn't mandatory if an alternative method is used 2530 (#1459, #1462, #1466) 2532 o Removed flags from HTTP/3 frames (#1388, #1398) 2534 o Reserved frame types and settings for use in preserving 2535 extensibility (#1333, #1446) 2537 o Added general error code (#1391, #1397) 2539 o Unidirectional streams carry a type byte and are extensible 2540 (#910,#1359) 2542 o Priority mechanism now uses explicit placeholders to enable 2543 persistent structure in the tree (#441,#1421,#1422) 2545 B.12. Since draft-ietf-quic-http-11 2547 o Moved QPACK table updates and acknowledgments to dedicated streams 2548 (#1121, #1122, #1238) 2550 B.13. Since draft-ietf-quic-http-10 2552 o Settings need to be remembered when attempting and accepting 0-RTT 2553 (#1157, #1207) 2555 B.14. Since draft-ietf-quic-http-09 2557 o Selected QCRAM for header compression (#228, #1117) 2559 o The server_name TLS extension is now mandatory (#296, #495) 2560 o Specified handling of unsupported versions in Alt-Svc (#1093, 2561 #1097) 2563 B.15. Since draft-ietf-quic-http-08 2565 o Clarified connection coalescing rules (#940, #1024) 2567 B.16. Since draft-ietf-quic-http-07 2569 o Changes for integer encodings in QUIC (#595,#905) 2571 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 2573 o Improvement to the description of GOAWAY (#604, #898) 2575 o Improve description of server push usage (#947, #950, #957) 2577 B.17. Since draft-ietf-quic-http-06 2579 o Track changes in QUIC error code usage (#485) 2581 B.18. Since draft-ietf-quic-http-05 2583 o Made push ID sequential, add MAX_PUSH_ID, remove 2584 SETTINGS_ENABLE_PUSH (#709) 2586 o Guidance about keep-alive and QUIC PINGs (#729) 2588 o Expanded text on GOAWAY and cancellation (#757) 2590 B.19. Since draft-ietf-quic-http-04 2592 o Cite RFC 5234 (#404) 2594 o Return to a single stream per request (#245,#557) 2596 o Use separate frame type and settings registries from HTTP/2 (#81) 2598 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 2600 o Restored GOAWAY (#696) 2602 o Identify server push using Push ID rather than a stream ID 2603 (#702,#281) 2605 o DATA frames cannot be empty (#700) 2607 B.20. Since draft-ietf-quic-http-03 2609 None. 2611 B.21. Since draft-ietf-quic-http-02 2613 o Track changes in transport draft 2615 B.22. Since draft-ietf-quic-http-01 2617 o SETTINGS changes (#181): 2619 * SETTINGS can be sent only once at the start of a connection; no 2620 changes thereafter 2622 * SETTINGS_ACK removed 2624 * Settings can only occur in the SETTINGS frame a single time 2626 * Boolean format updated 2628 o Alt-Svc parameter changed from "v" to "quic"; format updated 2629 (#229) 2631 o Closing the connection control stream or any message control 2632 stream is a fatal error (#176) 2634 o HPACK Sequence counter can wrap (#173) 2636 o 0-RTT guidance added 2638 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 2639 added (#127,#242) 2641 B.23. Since draft-ietf-quic-http-00 2643 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 2645 o Changed from using HTTP/2 framing within Stream 3 to new framing 2646 format and two-stream-per-request model (#71,#72,#73) 2648 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 2649 settings-01 2651 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 2652 order (#75) 2654 o Described CONNECT pseudo-method (#95) 2655 o Updated ALPN token and Alt-Svc guidance (#13,#87) 2657 o Application-layer-defined error codes (#19,#74) 2659 B.24. Since draft-shade-quic-http2-mapping-00 2661 o Adopted as base for draft-ietf-quic-http 2663 o Updated authors/editors list 2665 Acknowledgements 2667 The original authors of this specification were Robbie Shade and Mike 2668 Warres. 2670 A substantial portion of Mike's contribution was supported by 2671 Microsoft during his employment there. 2673 Author's Address 2675 Mike Bishop (editor) 2676 Akamai 2678 Email: mbishop@evequefou.be