idnits 2.17.1 draft-ietf-quic-http-22.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 (July 09, 2019) is 1753 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 2298 -- Looks like a reference, but probably isn't: '2' on line 2300 -- Looks like a reference, but probably isn't: '3' on line 2302 -- Looks like a reference, but probably isn't: '4' on line 2304 == Unused Reference: 'RFC7413' is defined on line 2292, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-22 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Duplicate reference: RFC7540, mentioned in 'RFC7540', was also mentioned in 'HTTP2'. ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALTSVC'. -- Duplicate reference: RFC7231, mentioned in 'HPACK', was also mentioned in 'RFC7231'. -- Obsolete informational reference (is this intentional?): RFC 7231 (ref. 'HPACK') (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 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 July 09, 2019 5 Expires: January 10, 2020 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-22 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 January 10, 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . 9 74 3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10 75 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 10 76 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 14 81 4.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 15 82 4.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 17 83 4.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 17 84 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 18 85 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 20 86 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 20 87 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20 88 5.3. Immediate Application Closure . . . . . . . . . . . . . . 22 89 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 22 90 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 22 91 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 23 92 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 23 93 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 24 94 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 25 95 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 25 96 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 26 97 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 27 98 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 28 99 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 28 100 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 29 101 7.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 29 102 7.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 32 103 7.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 32 104 7.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 35 105 7.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 36 106 7.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 36 107 7.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 37 108 7.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 38 109 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 38 110 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 39 111 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 40 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 113 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 114 11.1. Registration of HTTP/3 Identification String . . . . . . 42 115 11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 42 116 11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 42 117 11.4. Settings Parameters . . . . . . . . . . . . . . . . . . 43 118 11.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 44 119 11.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 47 120 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 121 12.1. Normative References . . . . . . . . . . . . . . . . . . 48 122 12.2. Informative References . . . . . . . . . . . . . . . . . 49 123 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 50 124 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 50 125 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 50 126 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 50 127 A.2.1. Prioritization Differences . . . . . . . . . . . . . 51 128 A.2.2. Header Compression Differences . . . . . . . . . . . 51 129 A.2.3. Guidance for New Frame Type Definitions . . . . . . . 52 130 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 52 131 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 53 132 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 54 133 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 55 134 B.1. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 55 135 B.2. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 55 136 B.3. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 56 137 B.4. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 56 138 B.5. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 57 139 B.6. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 57 140 B.7. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 58 141 B.8. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 58 142 B.9. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 58 143 B.10. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 58 144 B.11. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 59 145 B.12. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 59 146 B.13. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 59 147 B.14. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 59 148 B.15. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 59 149 B.16. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 59 150 B.17. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 59 151 B.18. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 60 152 B.19. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 60 153 B.20. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 60 154 B.21. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 60 155 B.22. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 61 156 B.23. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 61 157 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 61 158 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61 160 1. Introduction 162 HTTP semantics are used for a broad range of services on the 163 Internet. These semantics have commonly been used with two different 164 TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the same 165 semantics over a new transport protocol, QUIC. 167 1.1. Prior versions of HTTP 169 HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields 170 to convey HTTP messages. While these exchanges are human-readable, 171 using whitespace for message formatting leads to parsing difficulties 172 and workarounds to be tolerant of variant behavior. Because each 173 connection can transfer only a single HTTP request or response at a 174 time in each direction, multiple parallel TCP connections are often 175 used, reducing the ability of the congestion controller to accurately 176 manage traffic between endpoints. 178 HTTP/2 introduced a binary framing and multiplexing layer to improve 179 latency without modifying the transport layer. However, because the 180 parallel nature of HTTP/2's multiplexing is not visible to TCP's loss 181 recovery mechanisms, a lost or reordered packet causes all active 182 transactions to experience a stall regardless of whether that 183 transaction was impacted by the lost packet. 185 1.2. Delegation to QUIC 187 The QUIC transport protocol incorporates stream multiplexing and per- 188 stream flow control, similar to that provided by the HTTP/2 framing 189 layer. By providing reliability at the stream level and congestion 190 control across the entire connection, it has the capability to 191 improve the performance of HTTP compared to a TCP mapping. QUIC also 192 incorporates TLS 1.3 at the transport layer, offering comparable 193 security to running TLS over TCP, with the improved connection setup 194 latency of TCP Fast Open [RFC7413]}. 196 This document defines a mapping of HTTP semantics over the QUIC 197 transport protocol, drawing heavily on the design of HTTP/2. While 198 delegating stream lifetime and flow control issues to QUIC, a similar 199 binary framing is used on each stream. Some HTTP/2 features are 200 subsumed by QUIC, while other features are implemented atop QUIC. 202 QUIC is described in [QUIC-TRANSPORT]. For a full description of 203 HTTP/2, see [HTTP2]. 205 2. HTTP/3 Protocol Overview 207 HTTP/3 provides a transport for HTTP semantics using the QUIC 208 transport protocol and an internal framing layer similar to HTTP/2. 210 Once a client knows that an HTTP/3 server exists at a certain 211 endpoint, it opens a QUIC connection. QUIC provides protocol 212 negotiation, stream-based multiplexing, and flow control. An HTTP/3 213 endpoint can be discovered using HTTP Alternative Services; this 214 process is described in greater detail in Section 3.2. 216 Within each stream, the basic unit of HTTP/3 communication is a frame 217 (Section 7.2). Each frame type serves a different purpose. For 218 example, HEADERS and DATA frames form the basis of HTTP requests and 219 responses (Section 4.1). Other frame types like SETTINGS, PRIORITY, 220 and GOAWAY are used to manage the overall connection and 221 relationships between streams. 223 Multiplexing of requests is performed using the QUIC stream 224 abstraction, described in Section 2 of [QUIC-TRANSPORT]. Each 225 request and response consumes a single QUIC stream. Streams are 226 independent of each other, so one stream that is blocked or suffers 227 packet loss does not prevent progress on other streams. 229 Server push is an interaction mode introduced in HTTP/2 [HTTP2] which 230 permits a server to push a request-response exchange to a client in 231 anticipation of the client making the indicated request. This trades 232 off network usage against a potential latency gain. Several HTTP/3 233 frames are used to manage server push, such as PUSH_PROMISE, 234 DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH. 236 As in HTTP/2, request and response headers are compressed for 237 transmission. Because HPACK [HPACK] relies on in-order transmission 238 of compressed header blocks (a guarantee not provided by QUIC), 239 HTTP/3 replaces HPACK with QPACK [QPACK]. QPACK uses separate 240 unidirectional streams to modify and track header table state, while 241 header blocks refer to the state of the table without modifying it. 243 2.1. Document Organization 245 The HTTP/3 specification is split into seven parts. The document 246 begins with a detailed overview of the connection lifecycle and key 247 concepts: 249 o Connection Setup and Management (Section 3) covers how an HTTP/3 250 endpoint is discovered and a connection is established. 252 o HTTP Request Lifecycle (Section 4) describes how HTTP semantics 253 are expressed using frames. 255 o Connection Closure (Section 5) describes how connections are 256 terminated, either gracefully or abruptly. 258 The details of the wire protocol and interactions with the transport 259 are described in subsequent sections: 261 o Stream Mapping and Usage (Section 6) describes the way QUIC 262 streams are used. 264 o HTTP Framing Layer (Section 7) describes the frames used on most 265 streams. 267 o Error Handling (Section 8) describes how error conditions are 268 handled and expressed, either on a particular stream or for the 269 connection as a whole. 271 Additional resources are provided in the final sections: 273 o Extensions to HTTP/3 (Section 9) describes how new capabilities 274 can be added in future documents. 276 o A more detailed comparison between HTTP/2 and HTTP/3 can be found 277 in Appendix A. 279 2.2. Conventions and Terminology 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 283 "OPTIONAL" in this document are to be interpreted as described in BCP 284 14 [RFC2119] [RFC8174] when, and only when, they appear in all 285 capitals, as shown here. 287 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 288 defined in [RFC5234]. 290 This document uses the variable-length integer encoding from 291 [QUIC-TRANSPORT]. 293 The following terms are used: 295 abort: An abrupt termination of a connection or stream, possibly due 296 to an error condition. 298 client: The endpoint that initiates an HTTP/3 connection. Clients 299 send HTTP requests and receive HTTP responses. 301 connection: A transport-layer connection between two endpoints, 302 using QUIC as the transport protocol. 304 connection error: An error that affects the entire HTTP/3 305 connection. 307 endpoint: Either the client or server of the connection. 309 frame: The smallest unit of communication on a stream in HTTP/3, 310 consisting of a header and a variable-length sequence of octets 311 structured according to the frame type. Protocol elements called 312 "frames" exist in both this document and [QUIC-TRANSPORT]. Where 313 frames from [QUIC-TRANSPORT] are referenced, the frame name will 314 be prefaced with "QUIC." For example, "QUIC CONNECTION_CLOSE 315 frames." References without this preface refer to frames defined 316 in Section 7.2. 318 peer: An endpoint. When discussing a particular endpoint, "peer" 319 refers to the endpoint that is remote to the primary subject of 320 discussion. 322 receiver: An endpoint that is receiving frames. 324 sender: An endpoint that is transmitting frames. 326 server: The endpoint that accepts an HTTP/3 connection. Servers 327 receive HTTP requests and send HTTP responses. 329 stream: A bidirectional or unidirectional bytestream provided by the 330 QUIC transport. 332 stream error: An error on the individual HTTP/3 stream. 334 The term "payload body" is defined in Section 3.3 of [RFC7230]. 336 Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" 337 are defined in Section 2.3 of [RFC7230]. Intermediaries act as both 338 client and server at different times. 340 3. Connection Setup and Management 342 3.1. Draft Version Identification 344 *RFC Editor's Note:* Please remove this section prior to 345 publication of a final version of this document. 347 HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc. 348 Only implementations of the final, published RFC can identify 349 themselves as "h3". Until such an RFC exists, implementations MUST 350 NOT identify themselves using this string. 352 Implementations of draft versions of the protocol MUST add the string 353 "-" and the corresponding draft number to the identifier. For 354 example, draft-ietf-quic-http-01 is identified using the string 355 "h3-01". 357 Non-compatible experiments that are based on these draft versions 358 MUST append the string "-" and an experiment name to the identifier. 359 For example, an experimental implementation based on draft-ietf-quic- 360 http-09 which reserves an extra stream for unsolicited transmission 361 of 1980s pop music might identify itself as "h3-09-rickroll". Note 362 that any label MUST conform to the "token" syntax defined in 363 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 364 coordinate their experiments on the quic@ietf.org mailing list. 366 3.2. Discovering an HTTP/3 Endpoint 368 An HTTP origin advertises the availability of an equivalent HTTP/3 369 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 370 ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 3.3. 372 For example, an origin could indicate in an HTTP response that HTTP/3 373 was available on UDP port 50781 at the same hostname by including the 374 following header field: 376 Alt-Svc: h3=":50781" 378 On receipt of an Alt-Svc record indicating HTTP/3 support, a client 379 MAY attempt to establish a QUIC connection to the indicated host and 380 port and, if successful, send HTTP requests using the mapping 381 described in this document. 383 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 384 connection establishment failure, in which case the client SHOULD 385 continue using the existing connection or try another alternative 386 endpoint offered by the origin. 388 Servers MAY serve HTTP/3 on any UDP port, since an alternative always 389 includes an explicit port. 391 3.2.1. QUIC Version Hints 393 This document defines the "quic" parameter for Alt-Svc, which MAY be 394 used to provide version-negotiation hints to HTTP/3 clients. QUIC 395 versions are four-byte sequences with no additional constraints on 396 format. Leading zeros SHOULD be omitted for brevity. 398 Syntax: 400 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 401 version-number = 1*8HEXDIG; hex-encoded QUIC version 403 Where multiple versions are listed, the order of the values reflects 404 the server's preference (with the first value being the most 405 preferred version). Reserved versions MAY be listed, but unreserved 406 versions which are not supported by the alternative SHOULD NOT be 407 present in the list. Origins MAY omit supported versions for any 408 reason. 410 Clients MUST ignore any included versions which they do not support. 411 The "quic" parameter MUST NOT occur more than once; clients SHOULD 412 process only the first occurrence. 414 For example, suppose a server supported both version 0x00000001 and 415 the version rendered in ASCII as "Q034". If it also opted to include 416 the reserved version (from Section 15 of [QUIC-TRANSPORT]) 417 0x1abadaba, it could specify the following header field: 419 Alt-Svc: h3=":49288";quic="1,1abadaba,51303334" 421 A client acting on this header field would drop the reserved version 422 (not supported), then attempt to connect to the alternative using the 423 first version in the list which it does support, if any. 425 3.3. Connection Establishment 427 HTTP/3 relies on QUIC as the underlying transport. The QUIC version 428 being used MUST use TLS version 1.3 or greater as its handshake 429 protocol. HTTP/3 clients MUST indicate the target domain name during 430 the TLS handshake. This may be done using the Server Name Indication 431 (SNI) [RFC6066] extension to TLS or using some other mechanism. 433 QUIC connections are established as described in [QUIC-TRANSPORT]. 434 During connection establishment, HTTP/3 support is indicated by 435 selecting the ALPN token "h3" in the TLS handshake. Support for 436 other application-layer protocols MAY be offered in the same 437 handshake. 439 While connection-level options pertaining to the core QUIC protocol 440 are set in the initial crypto handshake, HTTP/3-specific settings are 441 conveyed in the SETTINGS frame. After the QUIC connection is 442 established, a SETTINGS frame (Section 7.2.5) MUST be sent by each 443 endpoint as the initial frame of their respective HTTP control stream 444 (see Section 6.2.1). 446 3.4. Connection Reuse 448 Once a connection exists to a server endpoint, this connection MAY be 449 reused for requests with multiple different URI authority components. 450 The client MAY send any requests for which the client considers the 451 server authoritative. 453 An authoritative HTTP/3 endpoint is typically discovered because the 454 client has received an Alt-Svc record from the request's origin which 455 nominates the endpoint as a valid HTTP Alternative Service for that 456 origin. As required by [RFC7838], clients MUST check that the 457 nominated server can present a valid certificate for the origin 458 before considering it authoritative. Clients MUST NOT assume that an 459 HTTP/3 endpoint is authoritative for other origins without an 460 explicit signal. 462 A server that does not wish clients to reuse connections for a 463 particular origin can indicate that it is not authoritative for a 464 request by sending a 421 (Misdirected Request) status code in 465 response to the request (see Section 9.1.2 of [HTTP2]). 467 The considerations discussed in Section 9.1 of [HTTP2] also apply to 468 the management of HTTP/3 connections. 470 4. HTTP Request Lifecycle 472 4.1. HTTP Message Exchanges 474 A client sends an HTTP request on a client-initiated bidirectional 475 QUIC stream. A client MUST send only a single request on a given 476 stream. A server sends zero or more non-final HTTP responses on the 477 same stream as the request, followed by a single final HTTP response, 478 as detailed below. 480 An HTTP message (request or response) consists of: 482 1. the message header (see [RFC7230], Section 3.2), sent as a single 483 HEADERS frame (see Section 7.2.2), 485 2. the payload body (see [RFC7230], Section 3.3), sent as a series 486 of DATA frames (see Section 7.2.1), 488 3. optionally, one HEADERS frame containing the trailer-part, if 489 present (see [RFC7230], Section 4.1.2). 491 A server MAY send one or more PUSH_PROMISE frames (see Section 7.2.6) 492 before, after, or interleaved with the frames of a response message. 493 These PUSH_PROMISE frames are not part of the response; see 494 Section 4.4 for more details. 496 The HEADERS and PUSH_PROMISE frames might reference updates to the 497 QPACK dynamic table. While these updates are not directly part of 498 the message exchange, they must be received and processed before the 499 message can be consumed. See Section 4.1.1 for more details. 501 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 502 MUST NOT be used. 504 If a DATA frame is received before a HEADERS frame on a either a 505 request or push stream, the recipient MUST respond with a connection 506 error of type HTTP_UNEXPECTED_FRAME (Section 8). 508 Trailing header fields are carried in an additional HEADERS frame 509 following the body. Senders MUST send only one HEADERS frame in the 510 trailers section; receivers MUST discard any subsequent HEADERS 511 frames. 513 A response MAY consist of multiple messages when and only when one or 514 more informational responses (1xx; see [RFC7231], Section 6.2) 515 precede a final response to the same request. Non-final responses do 516 not contain a payload body or trailers. 518 An HTTP request/response exchange fully consumes a bidirectional QUIC 519 stream. After sending a request, a client MUST close the stream for 520 sending. Unless using the CONNECT method (see Section 4.2), clients 521 MUST NOT make stream closure dependent on receiving a response to 522 their request. After sending a final response, the server MUST close 523 the stream for sending. At this point, the QUIC stream is fully 524 closed. 526 When a stream is closed, this indicates the end of an HTTP message. 527 Because some messages are large or unbounded, endpoints SHOULD begin 528 processing partial HTTP messages once enough of the message has been 529 received to make progress. If a client stream terminates without 530 enough of the HTTP message to provide a complete response, the server 531 SHOULD abort its response with the error code 532 HTTP_INCOMPLETE_REQUEST. 534 A server can send a complete response prior to the client sending an 535 entire request if the response does not depend on any portion of the 536 request that has not been sent and received. When this is true, a 537 server MAY request that the client abort transmission of a request 538 without error by triggering a QUIC STOP_SENDING frame with error code 539 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 540 its stream. Clients MUST NOT discard complete responses as a result 541 of having their request terminated abruptly, though clients can 542 always discard responses at their discretion for other reasons. 544 4.1.1. Header Formatting and Compression 546 HTTP message headers carry information as a series of key-value 547 pairs, called header fields. For a listing of registered HTTP header 548 fields, see the "Message Header Field" registry maintained at 549 https://www.iana.org/assignments/message-headers [4]. 551 Just as in previous versions of HTTP, header field names are strings 552 of ASCII characters that are compared in a case-insensitive fashion. 553 Properties of HTTP header field names and values are discussed in 554 more detail in Section 3.2 of [RFC7230], though the wire rendering in 555 HTTP/3 differs. As in HTTP/2, header field names MUST be converted 556 to lowercase prior to their encoding. A request or response 557 containing uppercase header field names MUST be treated as malformed 558 (Section 4.1.3). 560 As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with 561 the ':' character (ASCII 0x3a) to convey the target URI, the method 562 of the request, and the status code for the response. These pseudo- 563 header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2]. 564 Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT 565 generate pseudo-header fields other than those defined in [HTTP2]. 566 The restrictions on the use of pseudo-header fields in 567 Section 8.1.2.1 of [HTTP2] also apply to HTTP/3. 569 HTTP/3 uses QPACK header compression as described in [QPACK], a 570 variation of HPACK which allows the flexibility to avoid header- 571 compression-induced head-of-line blocking. See that document for 572 additional details. 574 An HTTP/3 implementation MAY impose a limit on the maximum size of 575 the message header it will accept on an individual HTTP message. A 576 server that receives a larger header field list than it is willing to 577 handle can send an HTTP 431 (Request Header Fields Too Large) status 578 code [RFC6585]. A client can discard responses that it cannot 579 process. The size of a header field list is calculated based on the 580 uncompressed size of header fields, including the length of the name 581 and value in bytes plus an overhead of 32 bytes for each header 582 field. 584 If an implementation wishes to advise its peer of this limit, it can 585 be conveyed as a number of bytes in the 586 "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. An implementation which 587 has received this parameter SHOULD NOT send an HTTP message header 588 which exceeds the indicated size, as the peer will likely refuse to 589 process it. However, because this limit is applied at each hop, 590 messages below this limit are not guaranteed to be accepted. 592 4.1.2. Request Cancellation and Rejection 594 Clients can cancel requests by aborting the stream (QUIC RESET_STREAM 595 and/or STOP_SENDING frames, as appropriate) with an error code of 596 HTTP_REQUEST_CANCELLED (Section 8.1). When the client cancels a 597 response, it indicates that this response is no longer of interest. 598 Implementations SHOULD cancel requests by aborting both directions of 599 a stream. 601 When the server rejects a request without performing any application 602 processing, it SHOULD abort its response stream with the error code 603 HTTP_REQUEST_REJECTED. In this context, "processed" means that some 604 data from the stream was passed to some higher layer of software that 605 might have taken some action as a result. The client can treat 606 requests rejected by the server as though they had never been sent at 607 all, thereby allowing them to be retried later on a new connection. 608 Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for 609 requests which were partially or fully processed. When a server 610 abandons a response after partial processing, it SHOULD abort its 611 response stream with the error code HTTP_REQUEST_CANCELLED. 613 When a client sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a 614 server MAY send the error code HTTP_REQUEST_REJECTED in the 615 corresponding RESET_STREAM if no processing was performed. Clients 616 MUST NOT reset streams with the HTTP_REQUEST_REJECTED error code 617 except in response to a QUIC STOP_SENDING frame that contains the 618 same code. 620 If a stream is cancelled after receiving a complete response, the 621 client MAY ignore the cancellation and use the response. However, if 622 a stream is cancelled after receiving a partial response, the 623 response SHOULD NOT be used. Automatically retrying such requests is 624 not possible, unless this is otherwise permitted (e.g., idempotent 625 actions like GET, PUT, or DELETE). 627 4.1.3. Malformed Requests and Responses 629 A malformed request or response is one that is an otherwise valid 630 sequence of frames but is invalid due to the presence of extraneous 631 frames, prohibited header fields, the absence of mandatory header 632 fields, or the inclusion of uppercase header field names. 634 A request or response that includes a payload body can include a 635 "content-length" header field. A request or response is also 636 malformed if the value of a content-length header field does not 637 equal the sum of the DATA frame payload lengths that form the body. 638 A response that is defined to have no payload, as described in 639 Section 3.3.2 of [RFC7230] can have a non-zero content-length header 640 field, even though no content is included in DATA frames. 642 Intermediaries that process HTTP requests or responses (i.e., any 643 intermediary not acting as a tunnel) MUST NOT forward a malformed 644 request or response. Malformed requests or responses that are 645 detected MUST be treated as a stream error (Section 8) of type 646 HTTP_GENERAL_PROTOCOL_ERROR. 648 For malformed requests, a server MAY send an HTTP response prior to 649 closing or resetting the stream. Clients MUST NOT accept a malformed 650 response. Note that these requirements are intended to protect 651 against several types of common attacks against HTTP; they are 652 deliberately strict because being permissive can expose 653 implementations to these vulnerabilities. 655 4.2. The CONNECT Method 657 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 658 used with HTTP proxies to establish a TLS session with an origin 659 server for the purposes of interacting with "https" resources. In 660 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 661 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 662 establish a tunnel over a single HTTP/2 stream to a remote host for 663 similar purposes. 665 A CONNECT request in HTTP/3 functions in the same manner as in 666 HTTP/2. The request MUST be formatted as described in [HTTP2], 667 Section 8.3. A CONNECT request that does not conform to these 668 restrictions is malformed (see Section 4.1.3). The request stream 669 MUST NOT be closed at the end of the request. 671 A proxy that supports CONNECT establishes a TCP connection 672 ([RFC0793]) to the server identified in the ":authority" pseudo- 673 header field. Once this connection is successfully established, the 674 proxy sends a HEADERS frame containing a 2xx series status code to 675 the client, as defined in [RFC7231], Section 4.3.6. 677 All DATA frames on the stream correspond to data sent or received on 678 the TCP connection. Any DATA frame sent by the client is transmitted 679 by the proxy to the TCP server; data received from the TCP server is 680 packaged into DATA frames by the proxy. Note that the size and 681 number of TCP segments is not guaranteed to map predictably to the 682 size and number of HTTP DATA or QUIC STREAM frames. 684 Once the CONNECT method has completed, only DATA frames are permitted 685 to be sent on the stream. Extension frames MAY be used if 686 specifically permitted by the definition of the extension. Receipt 687 of any other frame type MUST be treated as a connection error of type 688 HTTP_UNEXPECTED_FRAME. 690 The TCP connection can be closed by either peer. When the client 691 ends the request stream (that is, the receive stream at the proxy 692 enters the "Data Recvd" state), the proxy will set the FIN bit on its 693 connection to the TCP server. When the proxy receives a packet with 694 the FIN bit set, it will terminate the send stream that it sends to 695 the client. TCP connections which remain half-closed in a single 696 direction are not invalid, but are often handled poorly by servers, 697 so clients SHOULD NOT close a stream for sending while they still 698 expect to receive data from the target of the CONNECT. 700 A TCP connection error is signaled with QUIC RESET_STREAM frame. A 701 proxy treats any error in the TCP connection, which includes 702 receiving a TCP segment with the RST bit set, as a stream error of 703 type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, if a proxy 704 detects an error with the stream or the QUIC connection, it MUST 705 close the TCP connection. If the underlying TCP implementation 706 permits it, the proxy SHOULD send a TCP segment with the RST bit set. 708 4.3. Prioritization 710 The purpose of prioritization is to allow a client to express how it 711 would prefer the server to allocate resources when managing 712 concurrent streams. Most importantly, priority can be used to select 713 streams for transmitting frames when there is limited capacity for 714 sending. 716 HTTP/3 uses a priority scheme similar to that described in [RFC7540], 717 Section 5.3. In this priority scheme, a given element can be 718 designated as dependent upon another element. Each dependency is 719 assigned a relative weight, a number that is used to determine the 720 relative proportion of available resources that are assigned to 721 streams dependent on the same stream. This information is expressed 722 in the PRIORITY frame Section 7.2.3 which identifies the element and 723 the dependency. The elements that can be prioritized are: 725 o Requests, identified by the ID of the request stream 727 o Pushes, identified by the Push ID of the promised resource 728 (Section 7.2.6) 730 o Placeholders, identified by a Placeholder ID 732 Taken together, the dependencies across all prioritized elements in a 733 connection form a dependency tree. An element can depend on another 734 element or on the root of the tree. The tree also contains an orphan 735 placeholder. This placeholder cannot be reprioritized, and no 736 resources should be allocated to descendants of the orphan 737 placeholder if progress can be made on descendants of the root. The 738 structure of the dependency tree changes as PRIORITY frames modify 739 the dependency links between other prioritized elements. 741 An exclusive flag allows for the insertion of a new level of 742 dependencies. The exclusive flag causes the prioritized element to 743 become the sole dependency of its parent, causing other dependencies 744 to become dependent on the exclusive element. 746 All dependent streams are allocated an integer weight between 1 and 747 256 (inclusive), derived by adding one to the weight expressed in the 748 PRIORITY frame. 750 Streams with the same parent SHOULD be allocated resources 751 proportionally based on their weight. Thus, if stream B depends on 752 stream A with weight 4, stream C depends on stream A with weight 12, 753 and no progress can be made on stream A, stream B ideally receives 754 one-third of the resources allocated to stream C. 756 A reference to an element which is no longer in the tree is treated 757 as a reference to the orphan placeholder. Due to reordering between 758 streams, an element can also be prioritized which is not yet in the 759 tree. Such elements are added to the tree with the requested 760 priority. If a prioritized element depends on another element which 761 is not yet in the tree, the requested parent is first added to the 762 tree with the default priority. 764 When a prioritized element is first created, it has a default initial 765 weight of 16 and a default dependency. Requests and placeholders are 766 dependent on the orphan placeholder; pushes are dependent on the 767 client request on which the PUSH_PROMISE frame was sent. 769 Priorities can be updated by sending a PRIORITY frame (see 770 Section 7.2.3) on the control stream. 772 4.3.1. Placeholders 774 In HTTP/2, certain implementations used closed or unused streams as 775 placeholders in describing the relative priority of requests. This 776 created confusion as servers could not reliably identify which 777 elements of the priority tree could be discarded safely. Clients 778 could potentially reference closed streams long after the server had 779 discarded state, leading to disparate views of the prioritization the 780 client had attempted to express. 782 In HTTP/3, a number of placeholders are explicitly permitted by the 783 server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because the 784 server commits to maintaining these placeholders in the 785 prioritization tree, clients can use them with confidence that the 786 server will not have discarded the state. Clients MUST NOT send the 787 "SETTINGS_NUM_PLACEHOLDERS" setting; receipt of this setting by a 788 server MUST be treated as a connection error of type 789 "HTTP_SETTINGS_ERROR". 791 Client-controlled placeholders are identified by an ID between zero 792 and one less than the number of placeholders the server has 793 permitted. The orphan placeholder cannot be prioritized or 794 referenced by the client. 796 Like streams, client-controlled placeholders have priority 797 information associated with them. 799 4.3.2. Priority Tree Maintenance 801 Because placeholders will be used to "root" any persistent structure 802 of the tree which the client cares about retaining, servers can 803 aggressively prune inactive regions from the priority tree. For 804 prioritization purposes, a node in the tree is considered "inactive" 805 when the corresponding stream has been closed for at least two round- 806 trip times (using any reasonable estimate available on the server). 807 This delay helps mitigate race conditions where the server has pruned 808 a node the client believed was still active and used as a Stream 809 Dependency. 811 Specifically, the server MAY at any time: 813 o Identify and discard branches of the tree containing only inactive 814 nodes (i.e. a node with only other inactive nodes as descendants, 815 along with those descendants) 817 o Identify and condense interior regions of the tree containing only 818 inactive nodes, allocating weight appropriately 820 x x x 821 | | | 822 P P P 823 / \ | | 824 I I ==> I ==> A 825 / \ | | 826 A I A A 827 | | 828 A A 830 Figure 1: Example of Priority Tree Pruning 832 In the example in Figure 1, "P" represents a Placeholder, "A" 833 represents an active node, and "I" represents an inactive node. In 834 the first step, the server discards two inactive branches (each a 835 single node). In the second step, the server condenses an interior 836 inactive node. Note that these transformations will result in no 837 change in the resources allocated to a particular active stream. 839 Clients SHOULD assume the server is actively performing such pruning 840 and SHOULD NOT declare a dependency on a stream it knows to have been 841 closed. 843 4.4. Server Push 845 Server push is an interaction mode introduced in HTTP/2 [HTTP2] which 846 permits a server to push a request-response exchange to a client in 847 anticipation of the client making the indicated request. This trades 848 off network usage against a potential latency gain. HTTP/3 server 849 push is similar to what is described in HTTP/2 [HTTP2], but uses 850 different mechanisms. 852 Each server push is identified by a unique Push ID. This Push ID is 853 used in a single PUSH_PROMISE frame (see Section 7.2.6) which carries 854 the request headers, possibly included in one or more DUPLICATE_PUSH 855 frames (see Section 7.2.9), then included with the push stream which 856 ultimately fulfills those promises. 858 Server push is only enabled on a connection when a client sends a 859 MAX_PUSH_ID frame (see Section 7.2.8). A server cannot use server 860 push until it receives a MAX_PUSH_ID frame. A client sends 861 additional MAX_PUSH_ID frames to control the number of pushes that a 862 server can promise. A server SHOULD use Push IDs sequentially, 863 starting at 0. A client MUST treat receipt of a push stream with a 864 Push ID that is greater than the maximum Push ID as a connection 865 error of type HTTP_ID_ERROR. 867 The header of the request message is carried by a PUSH_PROMISE frame 868 (see Section 7.2.6) on the request stream which generated the push. 869 This allows the server push to be associated with a client request. 870 Promised requests MUST conform to the requirements in Section 8.2 of 871 [HTTP2]. 873 The same server push can be associated with additional client 874 requests using a DUPLICATE_PUSH frame (see Section 7.2.9). 876 Ordering of a PUSH_PROMISE or DUPLICATE_PUSH in relation to certain 877 parts of the response is important. The server SHOULD send 878 PUSH_PROMISE or DUPLICATE_PUSH frames prior to sending HEADERS or 879 DATA frames that reference the promised responses. This reduces the 880 chance that a client requests a resource that will be pushed by the 881 server. 883 When a server later fulfills a promise, the server push response is 884 conveyed on a push stream (see Section 6.2.2). The push stream 885 identifies the Push ID of the promise that it fulfills, then contains 886 a response to the promised request using the same format described 887 for responses in Section 4.1. 889 Due to reordering, DUPLICATE_PUSH frames or push stream data can 890 arrive before the corresponding PUSH_PROMISE frame. When a client 891 receives a DUPLICATE_PUSH frame for an as-yet-unknown Push ID, the 892 request headers of the push are not immediately available. The 893 client can either delay generating new requests for content 894 referenced following the DUPLICATE_PUSH frame until the request 895 headers become available, or can initiate requests for discovered 896 resources and cancel the requests if the requested resource is 897 already being pushed. When a client receives a new push stream with 898 an as-yet-unknown Push ID, both the associated client request and the 899 pushed request headers are unknown. The client can buffer the stream 900 data in expectation of the matching PUSH_PROMISE. The client can use 901 stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit 902 the amount of data a server may commit to the pushed stream. 904 If a promised server push is not needed by the client, the client 905 SHOULD send a CANCEL_PUSH frame. If the push stream is already open 906 or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING 907 frame with an error code of HTTP_REQUEST_CANCELLED can be used. This 908 asks the server not to transfer additional data and indicates that it 909 will be discarded upon receipt. 911 5. Connection Closure 913 Once established, an HTTP/3 connection can be used for many requests 914 and responses over time until the connection is closed. Connection 915 closure can happen in any of several different ways. 917 5.1. Idle Connections 919 Each QUIC endpoint declares an idle timeout during the handshake. If 920 the connection remains idle (no packets received) for longer than 921 this duration, the peer will assume that the connection has been 922 closed. HTTP/3 implementations will need to open a new connection 923 for new requests if the existing connection has been idle for longer 924 than the server's advertised idle timeout, and SHOULD do so if 925 approaching the idle timeout. 927 HTTP clients are expected to request that the transport keep 928 connections open while there are responses outstanding for requests 929 or server pushes, as described in Section 19.2 of [QUIC-TRANSPORT]. 930 If the client is not expecting a response from the server, allowing 931 an idle connection to time out is preferred over expending effort 932 maintaining a connection that might not be needed. A gateway MAY 933 maintain connections in anticipation of need rather than incur the 934 latency cost of connection establishment to servers. Servers SHOULD 935 NOT actively keep connections open. 937 5.2. Connection Shutdown 939 Even when a connection is not idle, either endpoint can decide to 940 stop using the connection and let the connection close gracefully. 941 Since clients drive request generation, clients perform a connection 942 shutdown by not sending additional requests on the connection; 943 responses and pushed responses associated to previous requests will 944 continue to completion. Servers perform the same function by 945 communicating with clients. 947 Servers initiate the shutdown of a connection by sending a GOAWAY 948 frame (Section 7.2.7). The GOAWAY frame indicates that client- 949 initiated requests on lower stream IDs were or might be processed in 950 this connection, while requests on the indicated stream ID and 951 greater were rejected. This enables client and server to agree on 952 which requests were accepted prior to the connection shutdown. This 953 identifier MAY be zero if no requests were processed. Servers SHOULD 954 NOT increase the QUIC MAX_STREAMS limit after sending a GOAWAY frame. 956 Clients MUST NOT send new requests on the connection after receiving 957 GOAWAY; a new connection MAY be established to send additional 958 requests. 960 Some requests might already be in transit. If the client has already 961 sent requests on streams with a Stream ID greater than or equal to 962 that indicated in the GOAWAY frame, those requests will not be 963 processed and MAY be retried by the client on a different connection. 964 The client MAY cancel these requests. It is RECOMMENDED that the 965 server explicitly reject such requests (see Section 4.1.2) in order 966 to clean up transport state for the affected streams. 968 Requests on Stream IDs less than the Stream ID in the GOAWAY frame 969 might have been processed; their status cannot be known until a 970 response is received, the stream is reset individually, or the 971 connection terminates. Servers MAY reject individual requests on 972 streams below the indicated ID if these requests were not processed. 974 Servers SHOULD send a GOAWAY frame when the closing of a connection 975 is known in advance, even if the advance notice is small, so that the 976 remote peer can know whether a request has been partially processed 977 or not. For example, if an HTTP client sends a POST at the same time 978 that a server closes a QUIC connection, the client cannot know if the 979 server started to process that POST request if the server does not 980 send a GOAWAY frame to indicate what streams it might have acted on. 982 A client that is unable to retry requests loses all requests that are 983 in flight when the server closes the connection. A server MAY send 984 multiple GOAWAY frames indicating different stream IDs, but MUST NOT 985 increase the value they send in the last Stream ID, since clients 986 might already have retried unprocessed requests on another 987 connection. A server that is attempting to gracefully shut down a 988 connection SHOULD send an initial GOAWAY frame with the last Stream 989 ID set to the maximum value allowed by QUIC's MAX_STREAMS and SHOULD 990 NOT increase the MAX_STREAMS limit thereafter. This signals to the 991 client that a shutdown is imminent and that initiating further 992 requests is prohibited. After allowing time for any in-flight 993 requests (at least one round-trip time), the server MAY send another 994 GOAWAY frame with an updated last Stream ID. This ensures that a 995 connection can be cleanly shut down without losing requests. 997 Once all accepted requests have been processed, the server can permit 998 the connection to become idle, or MAY initiate an immediate closure 999 of the connection. An endpoint that completes a graceful shutdown 1000 SHOULD use the HTTP_NO_ERROR code when closing the connection. 1002 If a client has consumed all available bidirectional stream IDs with 1003 requests, the server need not send a GOAWAY frame, since the client 1004 is unable to make further requests. 1006 5.3. Immediate Application Closure 1008 An HTTP/3 implementation can immediately close the QUIC connection at 1009 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 1010 the peer; the error code in this frame indicates to the peer why the 1011 connection is being closed. See Section 8 for error codes which can 1012 be used when closing a connection. 1014 Before closing the connection, a GOAWAY MAY be sent to allow the 1015 client to retry some requests. Including the GOAWAY frame in the 1016 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 1017 of the frame being received by clients. 1019 5.4. Transport Closure 1021 For various reasons, the QUIC transport could indicate to the 1022 application layer that the connection has terminated. This might be 1023 due to an explicit closure by the peer, a transport-level error, or a 1024 change in network topology which interrupts connectivity. 1026 If a connection terminates without a GOAWAY frame, clients MUST 1027 assume that any request which was sent, whether in whole or in part, 1028 might have been processed. 1030 6. Stream Mapping and Usage 1032 A QUIC stream provides reliable in-order delivery of bytes, but makes 1033 no guarantees about order of delivery with regard to bytes on other 1034 streams. On the wire, data is framed into QUIC STREAM frames, but 1035 this framing is invisible to the HTTP framing layer. The transport 1036 layer buffers and orders received QUIC STREAM frames, exposing the 1037 data contained within as a reliable byte stream to the application. 1038 Although QUIC permits out-of-order delivery within a stream, HTTP/3 1039 does not make use of this feature. 1041 QUIC streams can be either unidirectional, carrying data only from 1042 initiator to receiver, or bidirectional. Streams can be initiated by 1043 either the client or the server. For more detail on QUIC streams, 1044 see Section 2 of [QUIC-TRANSPORT]. 1046 When HTTP headers and data are sent over QUIC, the QUIC layer handles 1047 most of the stream management. HTTP does not need to do any separate 1048 multiplexing when using QUIC - data sent over a QUIC stream always 1049 maps to a particular HTTP transaction or connection context. 1051 6.1. Bidirectional Streams 1053 All client-initiated bidirectional streams are used for HTTP requests 1054 and responses. A bidirectional stream ensures that the response can 1055 be readily correlated with the request. This means that the client's 1056 first request occurs on QUIC stream 0, with subsequent requests on 1057 stream 4, 8, and so on. In order to permit these streams to open, an 1058 HTTP/3 client SHOULD send non-zero values for the QUIC transport 1059 parameters "initial_max_stream_data_bidi_local". An HTTP/3 server 1060 SHOULD send non-zero values for the QUIC transport parameters 1061 "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". 1062 It is RECOMMENDED that "initial_max_bidi_streams" be no smaller than 1063 100, so as to not unnecessarily limit parallelism. 1065 HTTP/3 does not use server-initiated bidirectional streams, though an 1066 extension could define a use for these streams. Clients MUST treat 1067 receipt of a server-initiated bidirectional stream as a connection 1068 error of type HTTP_STREAM_CREATION_ERROR unless such an extension has 1069 been negotiated. 1071 6.2. Unidirectional Streams 1073 Unidirectional streams, in either direction, are used for a range of 1074 purposes. The purpose is indicated by a stream type, which is sent 1075 as a variable-length integer at the start of the stream. The format 1076 and structure of data that follows this integer is determined by the 1077 stream type. 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Stream Type (i) ... 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 Figure 2: Unidirectional Stream Header 1087 Some stream types are reserved (Section 6.2.3). Two stream types are 1088 defined in this document: control streams (Section 6.2.1) and push 1089 streams (Section 6.2.2). Other stream types can be defined by 1090 extensions to HTTP/3; see Section 9 for more details. 1092 The performance of HTTP/3 connections in the early phase of their 1093 lifetime is sensitive to the creation and exchange of data on 1094 unidirectional streams. Endpoints that set low values for the QUIC 1095 transport parameters "initial_max_uni_streams" and 1096 "initial_max_stream_data_uni" will increase the chance that the 1097 remote peer reaches the limit early and becomes blocked. In 1098 particular, the value chosen for "initial_max_uni_streams" should 1099 consider that remote peers may wish to exercise reserved stream 1100 behavior (Section 6.2.3). To avoid blocking, both clients and 1101 servers MUST allow the peer to create at least one unidirectional 1102 stream for the HTTP control stream plus the number of unidirectional 1103 streams required by mandatory extensions (such as QPACK) by setting 1104 an appropriate value for the QUIC transport parameter 1105 "initial_max_uni_streams" (three being the minimum value required for 1106 the base HTTP/3 protocol and QPACK), and SHOULD use a value of 1,024 1107 or greater for the QUIC transport parameter 1108 "initial_max_stream_data_uni". 1110 Note that an endpoint is not required to grant additional credits to 1111 create more unidirectional streams if its peer consumes all the 1112 initial credits before creating the critical unidirectional streams. 1113 Endpoints SHOULD create the HTTP control stream as well as the 1114 unidirectional streams required by mandatory extensions (such as the 1115 QPACK encoder and decoder streams) first, and then create additional 1116 streams as allowed by their peer. 1118 If the stream header indicates a stream type which is not supported 1119 by the recipient, the remainder of the stream cannot be consumed as 1120 the semantics are unknown. Recipients of unknown stream types MAY 1121 trigger a QUIC STOP_SENDING frame with an error code of 1122 HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be 1123 a connection error of any kind. 1125 Implementations MAY send stream types before knowing whether the peer 1126 supports them. However, stream types which could modify the state or 1127 semantics of existing protocol components, including QPACK or other 1128 extensions, MUST NOT be sent until the peer is known to support them. 1130 A sender can close or reset a unidirectional stream unless otherwise 1131 specified. A receiver MUST tolerate unidirectional streams being 1132 closed or reset prior to the reception of the unidirectional stream 1133 header. 1135 6.2.1. Control Streams 1137 A control stream is indicated by a stream type of "0x00". Data on 1138 this stream consists of HTTP/3 frames, as defined in Section 7.2. 1140 Each side MUST initiate a single control stream at the beginning of 1141 the connection and send its SETTINGS frame as the first frame on this 1142 stream. If the first frame of the control stream is any other frame 1143 type, this MUST be treated as a connection error of type 1144 HTTP_MISSING_SETTINGS. Only one control stream per peer is 1145 permitted; receipt of a second stream which claims to be a control 1146 stream MUST be treated as a connection error of type 1147 HTTP_STREAM_CREATION_ERROR. The sender MUST NOT close the control 1148 stream, and the receiver MUST NOT request that the sender close the 1149 control stream. If either control stream is closed at any point, 1150 this MUST be treated as a connection error of type 1151 HTTP_CLOSED_CRITICAL_STREAM. 1153 A pair of unidirectional streams is used rather than a single 1154 bidirectional stream. This allows either peer to send data as soon 1155 as it is able. Depending on whether 0-RTT is enabled on the 1156 connection, either client or server might be able to send stream data 1157 first after the cryptographic handshake completes. 1159 6.2.2. Push Streams 1161 Server push is an optional feature introduced in HTTP/2 that allows a 1162 server to initiate a response before a request has been made. See 1163 Section 4.4 for more details. 1165 A push stream is indicated by a stream type of "0x01", followed by 1166 the Push ID of the promise that it fulfills, encoded as a variable- 1167 length integer. The remaining data on this stream consists of HTTP/3 1168 frames, as defined in Section 7.2, and fulfills a promised server 1169 push. Server push and Push IDs are described in Section 4.4. 1171 Only servers can push; if a server receives a client-initiated push 1172 stream, this MUST be treated as a connection error of type 1173 HTTP_STREAM_CREATION_ERROR. 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | 0x01 (i) ... 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Push ID (i) ... 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 Figure 3: Push Stream Header 1185 Each Push ID MUST only be used once in a push stream header. If a 1186 push stream header includes a Push ID that was used in another push 1187 stream header, the client MUST treat this as a connection error of 1188 type HTTP_ID_ERROR. 1190 6.2.3. Reserved Stream Types 1192 Stream types of the format "0x1f * N + 0x21" for integer values of N 1193 are reserved to exercise the requirement that unknown types be 1194 ignored. These streams have no semantics, and can be sent when 1195 application-layer padding is desired. They MAY also be sent on 1196 connections where no data is currently being transferred. Endpoints 1197 MUST NOT consider these streams to have any meaning upon receipt. 1199 The payload and length of the stream are selected in any manner the 1200 implementation chooses. 1202 7. HTTP Framing Layer 1204 HTTP frames are carried on QUIC streams, as described in Section 6. 1205 HTTP/3 defines three stream types: control stream, request stream, 1206 and push stream. This section describes HTTP/3 frame formats and the 1207 streams types on which they are permitted; see Table 1 for an 1208 overview. A comparison between HTTP/2 and HTTP/3 frames is provided 1209 in Appendix A.2. 1211 +----------------+------------+------------+-----------+------------+ 1212 | Frame | Control | Request | Push | Section | 1213 | | Stream | Stream | Stream | | 1214 +----------------+------------+------------+-----------+------------+ 1215 | DATA | No | Yes | Yes | Section | 1216 | | | | | 7.2.1 | 1217 | | | | | | 1218 | HEADERS | No | Yes | Yes | Section | 1219 | | | | | 7.2.2 | 1220 | | | | | | 1221 | PRIORITY | Yes | No | No | Section | 1222 | | | | | 7.2.3 | 1223 | | | | | | 1224 | CANCEL_PUSH | Yes | No | No | Section | 1225 | | | | | 7.2.4 | 1226 | | | | | | 1227 | SETTINGS | Yes (1) | No | No | Section | 1228 | | | | | 7.2.5 | 1229 | | | | | | 1230 | PUSH_PROMISE | No | Yes | No | Section | 1231 | | | | | 7.2.6 | 1232 | | | | | | 1233 | GOAWAY | Yes | No | No | Section | 1234 | | | | | 7.2.7 | 1235 | | | | | | 1236 | MAX_PUSH_ID | Yes | No | No | Section | 1237 | | | | | 7.2.8 | 1238 | | | | | | 1239 | DUPLICATE_PUSH | No | Yes | No | Section | 1240 | | | | | 7.2.9 | 1241 +----------------+------------+------------+-----------+------------+ 1243 Table 1: HTTP/3 frames and stream type overview 1245 Certain frames can only occur as the first frame of a particular 1246 stream type; these are indicated in Table 1 with a (1). Specific 1247 guidance is provided in the relevant section. 1249 Note that, unlike QUIC frames, HTTP/3 frames can span multiple 1250 packets. 1252 7.1. Frame Layout 1254 All frames have the following format: 1256 0 1 2 3 1257 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 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Type (i) ... 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Length (i) ... 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Frame Payload (*) ... 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 Figure 4: HTTP/3 frame format 1268 A frame includes the following fields: 1270 Type: A variable-length integer that identifies the frame type. 1272 Length: A variable-length integer that describes the length of the 1273 Frame Payload. 1275 Frame Payload: A payload, the semantics of which are determined by 1276 the Type field. 1278 Each frame's payload MUST contain exactly the fields identified in 1279 its description. A frame payload that contains additional bytes 1280 after the identified fields or a frame payload that terminates before 1281 the end of the identified fields MUST be treated as a connection 1282 error of type HTTP_MALFORMED_FRAME. 1284 When a stream terminates cleanly, if the last frame on the stream was 1285 truncated, this MUST be treated as a connection error (Section 8) of 1286 type HTTP_MALFORMED_FRAME. Streams which terminate abruptly may be 1287 reset at any point in a frame. 1289 7.2. Frame Definitions 1291 7.2.1. DATA 1293 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1294 bytes associated with an HTTP request or response payload. 1296 DATA frames MUST be associated with an HTTP request or response. If 1297 a DATA frame is received on a control stream, the recipient MUST 1298 respond with a connection error (Section 8) of type 1299 HTTP_WRONG_STREAM. 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Payload (*) ... 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 Figure 5: DATA frame payload 1309 7.2.2. HEADERS 1311 The HEADERS frame (type=0x1) is used to carry a header block, 1312 compressed using QPACK. See [QPACK] for more details. 1314 0 1 2 3 1315 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 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | Header Block (*) ... 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 Figure 6: HEADERS frame payload 1322 HEADERS frames can only be sent on request / push streams. If a 1323 HEADERS frame is received on a control stream, the recipient MUST 1324 respond with a connection error (Section 8) of type 1325 HTTP_WRONG_STREAM. 1327 7.2.3. PRIORITY 1329 The PRIORITY (type=0x2) frame specifies the client-advised priority 1330 of a request, server push or placeholder. 1332 A PRIORITY frame identifies an element to prioritize, and an element 1333 upon which it depends. A Prioritized ID or Dependency ID identifies 1334 a client-initiated request using the corresponding stream ID, a 1335 server push using a Push ID (see Section 7.2.6), or a placeholder 1336 using a Placeholder ID (see Section 4.3.1). 1338 In order to ensure that prioritization is processed in a consistent 1339 order, PRIORITY frames MUST be sent on the control stream. 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 |PT |DT |X|Empty| Prioritized Element ID (i) ... 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | [Element Dependency ID (i)] ... 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Weight (8) | 1349 +-+-+-+-+-+-+-+-+ 1351 Figure 7: PRIORITY frame payload 1353 The PRIORITY frame payload has the following fields: 1355 PT (Prioritized Element Type): A two-bit field indicating the type 1356 of element being prioritized (see Table 2). This MUST NOT be set 1357 to "11". 1359 DT (Element Dependency Type): A two-bit field indicating the type of 1360 element being depended on (see Table 2). 1362 X (Exclusive Flag): A single-bit flag indicating that the dependency 1363 is exclusive (see Section 4.3). 1365 Empty: A three-bit field which MUST be zero when sent and has no 1366 semantic value on receipt. 1368 Prioritized Element ID: A variable-length integer that identifies 1369 the element being prioritized. Depending on the value of 1370 Prioritized Type, this contains the Stream ID of a request stream, 1371 the Push ID of a promised resource, or a Placeholder ID of a 1372 placeholder. 1374 Element Dependency ID: A variable-length integer that identifies the 1375 element on which a dependency is being expressed. Depending on 1376 the value of Dependency Type, this contains the Stream ID of a 1377 request stream, the Push ID of a promised resource, the 1378 Placeholder ID of a placeholder, or is absent. For details of 1379 dependencies, see Section 4.3 and [HTTP2], Section 5.3. 1381 Weight: An unsigned 8-bit integer representing a priority weight for 1382 the prioritized element (see [HTTP2], Section 5.3). Add one to 1383 the value to obtain a weight between 1 and 256. 1385 The values for the Prioritized Element Type and Element Dependency 1386 Type (Table 2) imply the interpretation of the associated Element ID 1387 fields. 1389 +-----------+------------------+---------------------+ 1390 | Type Bits | Type Description | Element ID Contents | 1391 +-----------+------------------+---------------------+ 1392 | 00 | Request stream | Stream ID | 1393 | | | | 1394 | 01 | Push stream | Push ID | 1395 | | | | 1396 | 10 | Placeholder | Placeholder ID | 1397 | | | | 1398 | 11 | Root of the tree | Absent | 1399 +-----------+------------------+---------------------+ 1401 Table 2: Element Types of a PRIORITY frame 1403 Note that unlike in [HTTP2], the root of the tree cannot be 1404 referenced using a Stream ID of 0, as in QUIC stream 0 carries a 1405 valid HTTP request. The root of the tree cannot be reprioritized. 1407 The PRIORITY frame can express relationships which might not be 1408 permitted based on the stream on which it is sent or its position in 1409 the stream. These situations MUST be treated as a connection error 1410 of type HTTP_MALFORMED_FRAME. The following situations are examples 1411 of invalid PRIORITY frames: 1413 o A PRIORITY frame with the Prioritized Element Type set to "11". 1415 o A PRIORITY frame which claims to reference a request, but the 1416 associated ID does not identify a client-initiated bidirectional 1417 stream 1419 A PRIORITY frame with Empty bits not set to zero MAY be treated as a 1420 connection error of type HTTP_MALFORMED_FRAME. 1422 A PRIORITY frame that references a non-existent Push ID, a 1423 Placeholder ID greater than the server's limit, or a Stream ID the 1424 client is not yet permitted to open MUST be treated as a connection 1425 error of type HTTP_ID_ERROR. 1427 A PRIORITY frame received on any stream other than the control stream 1428 MUST be treated as a connection error of type HTTP_WRONG_STREAM. 1430 PRIORITY frames received by a client MUST be treated as a connection 1431 error of type HTTP_UNEXPECTED_FRAME. 1433 7.2.4. CANCEL_PUSH 1435 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 1436 server push prior to the push stream being received. The CANCEL_PUSH 1437 frame identifies a server push by Push ID (see Section 7.2.6), 1438 encoded as a variable-length integer. 1440 When a server receives this frame, it aborts sending the response for 1441 the identified server push. If the server has not yet started to 1442 send the server push, it can use the receipt of a CANCEL_PUSH frame 1443 to avoid opening a push stream. If the push stream has been opened 1444 by the server, the server SHOULD send a QUIC RESET_STREAM frame on 1445 that stream and cease transmission of the response. 1447 A server can send the CANCEL_PUSH frame to indicate that it will not 1448 be fulfilling a promise prior to creation of a push stream. Once the 1449 push stream has been created, sending CANCEL_PUSH has no effect on 1450 the state of the push stream. A QUIC RESET_STREAM frame SHOULD be 1451 used instead to abort transmission of the server push response. 1453 A CANCEL_PUSH frame is sent on the control stream. Receiving a 1454 CANCEL_PUSH frame on a stream other than the control stream MUST be 1455 treated as a connection error of type HTTP_WRONG_STREAM. 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Push ID (i) ... 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 Figure 8: CANCEL_PUSH frame payload 1465 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 1466 integer. The Push ID identifies the server push that is being 1467 cancelled (see Section 7.2.6). 1469 If the client receives a CANCEL_PUSH frame, that frame might identify 1470 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 1472 7.2.5. SETTINGS 1474 The SETTINGS frame (type=0x4) conveys configuration parameters that 1475 affect how endpoints communicate, such as preferences and constraints 1476 on peer behavior. Individually, a SETTINGS parameter can also be 1477 referred to as a "setting"; the identifier and value of each setting 1478 parameter can be referred to as a "setting identifier" and a "setting 1479 value". 1481 SETTINGS frames always apply to a connection, never a single stream. 1482 A SETTINGS frame MUST be sent as the first frame of each control 1483 stream (see Section 6.2.1) by each peer, and MUST NOT be sent 1484 subsequently. If an endpoint receives a second SETTINGS frame on the 1485 control stream, the endpoint MUST respond with a connection error of 1486 type HTTP_UNEXPECTED_FRAME. 1488 SETTINGS frames MUST NOT be sent on any stream other than the control 1489 stream. If an endpoint receives a SETTINGS frame on a different 1490 stream, the endpoint MUST respond with a connection error of type 1491 HTTP_WRONG_STREAM. 1493 SETTINGS parameters are not negotiated; they describe characteristics 1494 of the sending peer, which can be used by the receiving peer. 1495 However, a negotiation can be implied by the use of SETTINGS - each 1496 peer uses SETTINGS to advertise a set of supported values. The 1497 definition of the setting would describe how each peer combines the 1498 two sets to conclude which choice will be used. SETTINGS does not 1499 provide a mechanism to identify when the choice takes effect. 1501 Different values for the same parameter can be advertised by each 1502 peer. For example, a client might be willing to consume a very large 1503 response header, while servers are more cautious about request size. 1505 Parameters MUST NOT occur more than once in the SETTINGS frame. A 1506 receiver MAY treat the presence of the same parameter more than once 1507 as a connection error of type HTTP_SETTINGS_ERROR. 1509 The payload of a SETTINGS frame consists of zero or more parameters. 1510 Each parameter consists of a setting identifier and a value, both 1511 encoded as QUIC variable-length integers. 1513 0 1 2 3 1514 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 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Identifier (i) ... 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Value (i) ... 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 Figure 9: SETTINGS parameter format 1523 An implementation MUST ignore the contents for any SETTINGS 1524 identifier it does not understand. 1526 7.2.5.1. Defined SETTINGS Parameters 1528 The following settings are defined in HTTP/3: 1530 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. 1531 See Section 4.1.1 for usage. 1533 SETTINGS_NUM_PLACEHOLDERS (0x9): The default value is 0. However, 1534 this value SHOULD be set to a non-zero value by servers. See 1535 Section 4.3.1 for usage. 1537 Setting identifiers of the format "0x1f * N + 0x21" for integer 1538 values of N are reserved to exercise the requirement that unknown 1539 identifiers be ignored. Such settings have no defined meaning. 1540 Endpoints SHOULD include at least one such setting in their SETTINGS 1541 frame. Endpoints MUST NOT consider such settings to have any meaning 1542 upon receipt. 1544 Because the setting has no defined meaning, the value of the setting 1545 can be any value the implementation selects. 1547 Additional settings can be defined by extensions to HTTP/3; see 1548 Section 9 for more details. 1550 7.2.5.2. Initialization 1552 An HTTP implementation MUST NOT send frames or requests which would 1553 be invalid based on its current understanding of the peer's settings. 1554 All settings begin at an initial value, and are updated upon receipt 1555 of a SETTINGS frame. For servers, the initial value of each client 1556 setting is the default value. 1558 For clients using a 1-RTT QUIC connection, the initial value of each 1559 server setting is the default value. When a 0-RTT QUIC connection is 1560 being used, the initial value of each server setting is the value 1561 used in the previous session. Clients MUST store the settings the 1562 server provided in the session being resumed and MUST comply with 1563 stored settings until the current server settings are received. A 1564 client can use these initial values to send requests before the 1565 server's SETTINGS frame has arrived. This removes the need for a 1566 client to wait for the SETTINGS frame before sending requests. 1568 A server can remember the settings that it advertised, or store an 1569 integrity-protected copy of the values in the ticket and recover the 1570 information when accepting 0-RTT data. A server uses the HTTP/3 1571 settings values in determining whether to accept 0-RTT data. 1573 A server MAY accept 0-RTT and subsequently provide different settings 1574 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 1575 SETTINGS frame MUST NOT reduce any limits or alter any values that 1576 might be violated by the client with its 0-RTT data. The server MAY 1577 omit settings from its SETTINGS frame which are unchanged from the 1578 initial value. 1580 7.2.6. PUSH_PROMISE 1582 The PUSH_PROMISE frame (type=0x5) is used to carry a promised request 1583 header set from server to client on a request stream, as in HTTP/2. 1585 0 1 2 3 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Push ID (i) ... 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Header Block (*) ... 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 Figure 10: PUSH_PROMISE frame payload 1595 The payload consists of: 1597 Push ID: A variable-length integer that identifies the server push 1598 operation. A Push ID is used in push stream headers 1599 (Section 4.4), CANCEL_PUSH frames (Section 7.2.4), DUPLICATE_PUSH 1600 frames (Section 7.2.9), and PRIORITY frames (Section 7.2.3). 1602 Header Block: QPACK-compressed request header fields for the 1603 promised response. See [QPACK] for more details. 1605 A server MUST NOT use a Push ID that is larger than the client has 1606 provided in a MAX_PUSH_ID frame (Section 7.2.8). A client MUST treat 1607 receipt of a PUSH_PROMISE frame that contains a larger Push ID than 1608 the client has advertised as a connection error of HTTP_ID_ERROR. 1610 A server MUST NOT use the same Push ID in multiple PUSH_PROMISE 1611 frames. A client MUST treat receipt of a Push ID which has already 1612 been promised as a connection error of type HTTP_ID_ERROR. 1614 If a PUSH_PROMISE frame is received on the control stream, the client 1615 MUST respond with a connection error (Section 8) of type 1616 HTTP_WRONG_STREAM. 1618 A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the 1619 receipt of a PUSH_PROMISE frame as a connection error of type 1620 HTTP_UNEXPECTED_FRAME. 1622 See Section 4.4 for a description of the overall server push 1623 mechanism. 1625 7.2.7. GOAWAY 1627 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 1628 a connection by a server. GOAWAY allows a server to stop accepting 1629 new requests while still finishing processing of previously received 1630 requests. This enables administrative actions, like server 1631 maintenance. GOAWAY by itself does not close a connection. 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Stream ID (i) ... 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 Figure 11: GOAWAY frame payload 1641 The GOAWAY frame is always sent on the control stream. It carries a 1642 QUIC Stream ID for a client-initiated bidirectional stream encoded as 1643 a variable-length integer. A client MUST treat receipt of a GOAWAY 1644 frame containing a Stream ID of any other type as a connection error 1645 of type HTTP_MALFORMED_FRAME. 1647 Clients do not need to send GOAWAY to initiate a graceful shutdown; 1648 they simply stop making new requests. A server MUST treat receipt of 1649 a GOAWAY frame on any stream as a connection error (Section 8) of 1650 type HTTP_UNEXPECTED_FRAME. 1652 The GOAWAY frame applies to the connection, not a specific stream. A 1653 client MUST treat a GOAWAY frame on a stream other than the control 1654 stream as a connection error (Section 8) of type HTTP_WRONG_STREAM. 1656 See Section 5.2 for more information on the use of the GOAWAY frame. 1658 7.2.8. MAX_PUSH_ID 1660 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 1661 number of server pushes that the server can initiate. This sets the 1662 maximum value for a Push ID that the server can use in a PUSH_PROMISE 1663 frame. Consequently, this also limits the number of push streams 1664 that the server can initiate in addition to the limit set by the QUIC 1665 MAX_STREAMS frame. 1667 The MAX_PUSH_ID frame is always sent on the control stream. Receipt 1668 of a MAX_PUSH_ID frame on any other stream MUST be treated as a 1669 connection error of type HTTP_WRONG_STREAM. 1671 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1672 receipt of a MAX_PUSH_ID frame as a connection error of type 1673 HTTP_UNEXPECTED_FRAME. 1675 The maximum Push ID is unset when a connection is created, meaning 1676 that a server cannot push until it receives a MAX_PUSH_ID frame. A 1677 client that wishes to manage the number of promised server pushes can 1678 increase the maximum Push ID by sending MAX_PUSH_ID frames as the 1679 server fulfills or cancels server pushes. 1681 0 1 2 3 1682 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 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | Push ID (i) ... 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 Figure 12: MAX_PUSH_ID frame payload 1689 The MAX_PUSH_ID frame carries a single variable-length integer that 1690 identifies the maximum value for a Push ID that the server can use 1691 (see Section 7.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 1692 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 1693 previously received MUST be treated as a connection error of type 1694 HTTP_ID_ERROR. 1696 7.2.9. DUPLICATE_PUSH 1698 The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate 1699 that an existing pushed resource is related to multiple client 1700 requests. 1702 The DUPLICATE_PUSH frame is always sent on a request stream. Receipt 1703 of a DUPLICATE_PUSH frame on any other stream MUST be treated as a 1704 connection error of type HTTP_WRONG_STREAM. 1706 A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat 1707 the receipt of a DUPLICATE_PUSH frame as a connection error of type 1708 HTTP_UNEXPECTED_FRAME. 1710 0 1 2 3 1711 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 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Push ID (i) ... 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 Figure 13: DUPLICATE_PUSH frame payload 1718 The DUPLICATE_PUSH frame carries a single variable-length integer 1719 that identifies the Push ID of a resource that the server has 1720 previously promised (see Section 7.2.6), though that promise might 1721 not be received before this frame. A server MUST NOT use a Push ID 1722 that is larger than the client has provided in a MAX_PUSH_ID frame 1723 (Section 7.2.8). A client MUST treat receipt of a DUPLICATE_PUSH 1724 that contains a larger Push ID than the client has advertised as a 1725 connection error of type HTTP_ID_ERROR. 1727 This frame allows the server to use the same server push in response 1728 to multiple concurrent requests. Referencing the same server push 1729 ensures that a promise can be made in relation to every response in 1730 which server push might be needed without duplicating request headers 1731 or pushed responses. 1733 Allowing duplicate references to the same Push ID is primarily to 1734 reduce duplication caused by concurrent requests. A server SHOULD 1735 avoid reusing a Push ID over a long period. Clients are likely to 1736 consume server push responses and not retain them for reuse over 1737 time. Clients that see a DUPLICATE_PUSH that uses a Push ID that 1738 they have since consumed and discarded are forced to ignore the 1739 DUPLICATE_PUSH. 1741 7.2.10. Reserved Frame Types 1743 Frame types of the format "0x1f * N + 0x21" for integer values of N 1744 are reserved to exercise the requirement that unknown types be 1745 ignored (Section 9). These frames have no semantics, and can be sent 1746 when application-layer padding is desired. They MAY also be sent on 1747 connections where no data is currently being transferred. Endpoints 1748 MUST NOT consider these frames to have any meaning upon receipt. 1750 The payload and length of the frames are selected in any manner the 1751 implementation chooses. 1753 8. Error Handling 1755 QUIC allows the application to abruptly terminate (reset) individual 1756 streams or the entire connection when an error is encountered. These 1757 are referred to as "stream errors" or "connection errors" and are 1758 described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose 1759 to treat a stream error as a connection error. 1761 This section describes HTTP/3-specific error codes which can be used 1762 to express the cause of a connection or stream error. 1764 8.1. HTTP/3 Error Codes 1766 The following error codes are defined for use in QUIC RESET_STREAM 1767 frames, STOP_SENDING frames, and CONNECTION_CLOSE frames when using 1768 HTTP/3. 1770 HTTP_NO_ERROR (0x00): No error. This is used when the connection or 1771 stream needs to be closed, but there is no error to signal. 1773 HTTP_GENERAL_PROTOCOL_ERROR (0x01): Peer violated protocol 1774 requirements in a way which doesn't match a more specific error 1775 code, or endpoint declines to use the more specific error code. 1777 Reserved (0x02): This code is reserved and has no meaning. 1779 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1780 HTTP stack. 1782 Reserved (0x04): This code is reserved and has no meaning. 1784 HTTP_REQUEST_CANCELLED (0x05): The request or its response 1785 (including pushed response) is cancelled. 1787 HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated 1788 without containing a fully-formed request. 1790 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1791 a CONNECT request was reset or abnormally closed. 1793 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1794 exhibiting a behavior that might be generating excessive load. 1796 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1797 served over HTTP/3. The peer should retry over HTTP/1.1. 1799 HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it 1800 is not permitted. 1802 HTTP_ID_ERROR (0x0B): A Stream ID, Push ID, or Placeholder ID was 1803 used incorrectly, such as exceeding a limit, reducing a limit, or 1804 being reused. 1806 Reserved (0x0C): N/A 1808 HTTP_STREAM_CREATION_ERROR (0x0D): The endpoint detected that its 1809 peer created a stream that it will not accept. 1811 Reserved (0x0E): N/A 1812 HTTP_CLOSED_CRITICAL_STREAM (0x0F): A stream required by the 1813 connection was closed or reset. 1815 Reserved (0x0010): N/A 1817 HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request 1818 is not needed to produce a response. For use in STOP_SENDING 1819 only. 1821 HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at 1822 the beginning of the control stream. 1824 HTTP_UNEXPECTED_FRAME (0x0013): A frame was received which was not 1825 permitted in the current state. 1827 HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without 1828 performing any application processing. 1830 HTTP_SETTINGS_ERROR (0x00FF): An endpoint detected an error in the 1831 payload of a SETTINGS frame: a duplicate setting was detected, a 1832 client-only setting was sent by a server, or a server-only setting 1833 by a client. 1835 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1836 If the frame type is "0xfe" or less, the type is included as the 1837 last byte of the error code. For example, an error in a 1838 MAX_PUSH_ID frame would be indicated with the code (0x10D). The 1839 last byte "0xff" is used to indicate any frame type greater than 1840 "0xfe". 1842 9. Extensions to HTTP/3 1844 HTTP/3 permits extension of the protocol. Within the limitations 1845 described in this section, protocol extensions can be used to provide 1846 additional services or alter any aspect of the protocol. Extensions 1847 are effective only within the scope of a single HTTP/3 connection. 1849 This applies to the protocol elements defined in this document. This 1850 does not affect the existing options for extending HTTP, such as 1851 defining new methods, status codes, or header fields. 1853 Extensions are permitted to use new frame types (Section 7.2), new 1854 settings (Section 7.2.5.1), new error codes (Section 8), or new 1855 unidirectional stream types (Section 6.2). Registries are 1856 established for managing these extension points: frame types 1857 (Section 11.3), settings (Section 11.4), error codes (Section 11.5), 1858 and stream types (Section 11.6). 1860 Implementations MUST ignore unknown or unsupported values in all 1861 extensible protocol elements. Implementations MUST discard frames 1862 and unidirectional streams that have unknown or unsupported types. 1863 This means that any of these extension points can be safely used by 1864 extensions without prior arrangement or negotiation. 1866 Extensions that could change the semantics of existing protocol 1867 components MUST be negotiated before being used. For example, an 1868 extension that changes the layout of the HEADERS frame cannot be used 1869 until the peer has given a positive signal that this is acceptable. 1870 In this case, it could also be necessary to coordinate when the 1871 revised layout comes into effect. 1873 This document doesn't mandate a specific method for negotiating the 1874 use of an extension but notes that a setting (Section 7.2.5.1) could 1875 be used for that purpose. If both peers set a value that indicates 1876 willingness to use the extension, then the extension can be used. If 1877 a setting is used for extension negotiation, the default value MUST 1878 be defined in such a fashion that the extension is disabled if the 1879 setting is omitted. 1881 10. Security Considerations 1883 The security considerations of HTTP/3 should be comparable to those 1884 of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames 1885 and Padding fields in other frames to make a connection more 1886 resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames 1887 or employ the reserved frame and stream types discussed in 1888 Section 7.2.10 and Section 6.2.3. 1890 When HTTP Alternative Services is used for discovery for HTTP/3 1891 endpoints, the security considerations of [ALTSVC] also apply. 1893 Several protocol elements contain nested length elements, typically 1894 in the form of frames with an explicit length containing variable- 1895 length integers. This could pose a security risk to an incautious 1896 implementer. An implementation MUST ensure that the length of a 1897 frame exactly matches the length of the fields it contains. 1899 The use of 0-RTT with HTTP/3 creates an exposure to replay attack. 1900 The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when 1901 using HTTP/3 with 0-RTT. 1903 Certain HTTP implementations use the client address for logging or 1904 access-control purposes. Since a QUIC client's address might change 1905 during a connection (and future versions might support simultaneous 1906 use of multiple addresses), such implementations will need to either 1907 actively retrieve the client's current address or addresses when they 1908 are relevant or explicitly accept that the original address might 1909 change. 1911 11. IANA Considerations 1913 11.1. Registration of HTTP/3 Identification String 1915 This document creates a new registration for the identification of 1916 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 1917 IDs" registry established in [RFC7301]. 1919 The "h3" string identifies HTTP/3: 1921 Protocol: HTTP/3 1923 Identification Sequence: 0x68 0x33 ("h3") 1925 Specification: This document 1927 11.2. Registration of QUIC Version Hint Alt-Svc Parameter 1929 This document creates a new registration for version-negotiation 1930 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1931 registry established in [RFC7838]. 1933 Parameter: "quic" 1935 Specification: This document, Section 3.2.1 1937 11.3. Frame Types 1939 This document establishes a registry for HTTP/3 frame type codes. 1940 The "HTTP/3 Frame Type" registry governs a 62-bit space. This space 1941 is split into three spaces that are governed by different policies. 1942 Values between "0x00" and "0x3f" (in hexadecimal) are assigned via 1943 the Standards Action or IESG Review policies [RFC8126]. Values from 1944 "0x40" to "0x3fff" operate on the Specification Required policy 1945 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 1947 While this registry is separate from the "HTTP/2 Frame Type" registry 1948 defined in [HTTP2], it is preferable that the assignments parallel 1949 each other where the code spaces overlap. If an entry is present in 1950 only one registry, every effort SHOULD be made to avoid assigning the 1951 corresponding value to an unrelated operation. 1953 New entries in this registry require the following information: 1955 Frame Type: A name or label for the frame type. 1957 Code: The 62-bit code assigned to the frame type. 1959 Specification: A reference to a specification that includes a 1960 description of the frame layout and its semantics, including any 1961 parts of the frame that are conditionally present. 1963 The entries in the following table are registered by this document. 1965 +----------------+------+---------------+ 1966 | Frame Type | Code | Specification | 1967 +----------------+------+---------------+ 1968 | DATA | 0x0 | Section 7.2.1 | 1969 | | | | 1970 | HEADERS | 0x1 | Section 7.2.2 | 1971 | | | | 1972 | PRIORITY | 0x2 | Section 7.2.3 | 1973 | | | | 1974 | CANCEL_PUSH | 0x3 | Section 7.2.4 | 1975 | | | | 1976 | SETTINGS | 0x4 | Section 7.2.5 | 1977 | | | | 1978 | PUSH_PROMISE | 0x5 | Section 7.2.6 | 1979 | | | | 1980 | Reserved | 0x6 | N/A | 1981 | | | | 1982 | GOAWAY | 0x7 | Section 7.2.7 | 1983 | | | | 1984 | Reserved | 0x8 | N/A | 1985 | | | | 1986 | Reserved | 0x9 | N/A | 1987 | | | | 1988 | MAX_PUSH_ID | 0xD | Section 7.2.8 | 1989 | | | | 1990 | DUPLICATE_PUSH | 0xE | Section 7.2.9 | 1991 +----------------+------+---------------+ 1993 Additionally, each code of the format "0x1f * N + 0x21" for integer 1994 values of N (that is, "0x21", "0x40", ..., through 1995 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 1997 11.4. Settings Parameters 1999 This document establishes a registry for HTTP/3 settings. The 2000 "HTTP/3 Settings" registry governs a 62-bit space. This space is 2001 split into three spaces that are governed by different policies. 2002 Values between "0x00" and "0x3f" (in hexadecimal) are assigned via 2003 the Standards Action or IESG Review policies [RFC8126]. Values from 2004 "0x40" to "0x3fff" operate on the Specification Required policy 2006 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 2007 The designated experts are the same as those for the "HTTP/2 2008 Settings" registry defined in [HTTP2]. 2010 While this registry is separate from the "HTTP/2 Settings" registry 2011 defined in [HTTP2], it is preferable that the assignments parallel 2012 each other. If an entry is present in only one registry, every 2013 effort SHOULD be made to avoid assigning the corresponding value to 2014 an unrelated operation. 2016 New registrations are advised to provide the following information: 2018 Name: A symbolic name for the setting. Specifying a setting name is 2019 optional. 2021 Code: The 62-bit code assigned to the setting. 2023 Specification: An optional reference to a specification that 2024 describes the use of the setting. 2026 The entries in the following table are registered by this document. 2028 +----------------------+------+-----------------+ 2029 | Setting Name | Code | Specification | 2030 +----------------------+------+-----------------+ 2031 | Reserved | 0x2 | N/A | 2032 | | | | 2033 | Reserved | 0x3 | N/A | 2034 | | | | 2035 | Reserved | 0x4 | N/A | 2036 | | | | 2037 | Reserved | 0x5 | N/A | 2038 | | | | 2039 | MAX_HEADER_LIST_SIZE | 0x6 | Section 7.2.5.1 | 2040 | | | | 2041 | NUM_PLACEHOLDERS | 0x9 | Section 7.2.5.1 | 2042 +----------------------+------+-----------------+ 2044 Additionally, each code of the format "0x1f * N + 0x21" for integer 2045 values of N (that is, "0x21", "0x40", ..., through 2046 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 2048 11.5. Error Codes 2050 This document establishes a registry for HTTP/3 error codes. The 2051 "HTTP/3 Error Code" registry manages a 62-bit space. The "HTTP/3 2052 Error Code" registry operates under the "Expert Review" policy 2053 [RFC8126]. 2055 Registrations for error codes are required to include a description 2056 of the error code. An expert reviewer is advised to examine new 2057 registrations for possible duplication with existing error codes. 2058 Use of existing registrations is to be encouraged, but not mandated. 2060 New registrations are advised to provide the following information: 2062 Name: A name for the error code. Specifying an error code name is 2063 optional. 2065 Code: The 62-bit error code value. 2067 Description: A brief description of the error code semantics, longer 2068 if no detailed specification is provided. 2070 Specification: An optional reference for a specification that 2071 defines the error code. 2073 The entries in the following table are registered by this document. 2075 +----------------------------+--------+-------------+---------------+ 2076 | Name | Code | Description | Specification | 2077 +----------------------------+--------+-------------+---------------+ 2078 | HTTP_NO_ERROR | 0x0000 | No error | Section 8.1 | 2079 | | | | | 2080 | HTTP_GENERAL_PROTOCOL_ERRO | 0x0001 | General | Section 8.1 | 2081 | R | | protocol | | 2082 | | | error | | 2083 | | | | | 2084 | Reserved | 0x0002 | N/A | N/A | 2085 | | | | | 2086 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 8.1 | 2087 | | | error | | 2088 | | | | | 2089 | Reserved | 0x0004 | N/A | N/A | 2090 | | | | | 2091 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 8.1 | 2092 | | | longer | | 2093 | | | needed | | 2094 | | | | | 2095 | HTTP_INCOMPLETE_REQUEST | 0x0006 | Stream | Section 8.1 | 2096 | | | terminated | | 2097 | | | early | | 2098 | | | | | 2099 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset | Section 8.1 | 2100 | | | or error on | | 2101 | | | CONNECT | | 2102 | | | request | | 2103 | | | | | 2104 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 8.1 | 2105 | | | generating | | 2106 | | | excessive | | 2107 | | | load | | 2108 | | | | | 2109 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 8.1 | 2110 | | | HTTP/1.1 | | 2111 | | | | | 2112 | HTTP_WRONG_STREAM | 0x000A | A frame was | Section 8.1 | 2113 | | | sent on the | | 2114 | | | wrong | | 2115 | | | stream | | 2116 | | | | | 2117 | HTTP_ID_ERROR | 0x000B | An | Section 8.1 | 2118 | | | identifier | | 2119 | | | was used | | 2120 | | | incorrectly | | 2121 | | | | | 2122 | Reserved | 0x000C | N/A | N/A | 2123 | | | | | 2124 | HTTP_STREAM_CREATION_ERROR | 0x000D | Stream | Section 8.1 | 2125 | | | creation | | 2126 | | | error | | 2127 | | | | | 2128 | Reserved | 0x000E | N/A | N/A | 2129 | | | | | 2130 | HTTP_CLOSED_CRITICAL_STREA | 0x000F | Critical | Section 8.1 | 2131 | M | | stream was | | 2132 | | | closed | | 2133 | | | | | 2134 | Reserved | 0x000E | N/A | N/A | 2135 | | | | | 2136 | HTTP_EARLY_RESPONSE | 0x0011 | Remainder | Section 8.1 | 2137 | | | of request | | 2138 | | | not needed | | 2139 | | | | | 2140 | HTTP_MISSING_SETTINGS | 0x0012 | No SETTINGS | Section 8.1 | 2141 | | | frame | | 2142 | | | received | | 2143 | | | | | 2144 | HTTP_UNEXPECTED_FRAME | 0x0013 | Frame not | Section 8.1 | 2145 | | | permitted | | 2146 | | | in the | | 2147 | | | current | | 2148 | | | state | | 2149 | | | | | 2150 | HTTP_REQUEST_REJECTED | 0x0014 | Request not | Section 8.1 | 2151 | | | processed | | 2152 | | | | | 2153 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 | 2154 | | | frame | | 2155 | | | formatting | | 2156 | | | | | 2157 | HTTP_SETTINGS_ERROR | 0x00FF | SETTINGS | Section 8.1 | 2158 | | | frame | | 2159 | | | contained | | 2160 | | | invalid | | 2161 | | | values | | 2162 +----------------------------+--------+-------------+---------------+ 2164 11.6. Stream Types 2166 This document establishes a registry for HTTP/3 unidirectional stream 2167 types. The "HTTP/3 Stream Type" registry governs a 62-bit space. 2168 This space is split into three spaces that are governed by different 2169 policies. Values between "0x00" and 0x3f (in hexadecimal) are 2170 assigned via the Standards Action or IESG Review policies [RFC8126]. 2171 Values from "0x40" to "0x3fff" operate on the Specification Required 2172 policy [RFC8126]. All other values are assigned to Private Use 2173 [RFC8126]. 2175 New entries in this registry require the following information: 2177 Stream Type: A name or label for the stream type. 2179 Code: The 62-bit code assigned to the stream type. 2181 Specification: A reference to a specification that includes a 2182 description of the stream type, including the layout semantics of 2183 its payload. 2185 Sender: Which endpoint on a connection may initiate a stream of this 2186 type. Values are "Client", "Server", or "Both". 2188 The entries in the following table are registered by this document. 2190 +----------------+------+---------------+--------+ 2191 | Stream Type | Code | Specification | Sender | 2192 +----------------+------+---------------+--------+ 2193 | Control Stream | 0x00 | Section 6.2.1 | Both | 2194 | | | | | 2195 | Push Stream | 0x01 | Section 4.4 | Server | 2196 +----------------+------+---------------+--------+ 2198 Additionally, each code of the format "0x1f * N + 0x21" for integer 2199 values of N (that is, "0x21", "0x40", ..., through 2200 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 2202 12. References 2204 12.1. Normative References 2206 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2207 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2208 April 2016, . 2210 [HTTP-REPLAY] 2211 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 2212 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2213 2018, . 2215 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2216 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2217 DOI 10.17487/RFC7540, May 2015, 2218 . 2220 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 2221 Header Compression for HTTP over QUIC", draft-ietf-quic- 2222 qpack-10 (work in progress), July 2019. 2224 [QUIC-TRANSPORT] 2225 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2226 Multiplexed and Secure Transport", draft-ietf-quic- 2227 transport-22 (work in progress), July 2019. 2229 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2230 RFC 793, DOI 10.17487/RFC0793, September 1981, 2231 . 2233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2234 Requirement Levels", BCP 14, RFC 2119, 2235 DOI 10.17487/RFC2119, March 1997, 2236 . 2238 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2239 Specifications: ABNF", STD 68, RFC 5234, 2240 DOI 10.17487/RFC5234, January 2008, 2241 . 2243 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2244 Extensions: Extension Definitions", RFC 6066, 2245 DOI 10.17487/RFC6066, January 2011, 2246 . 2248 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2249 Protocol (HTTP/1.1): Message Syntax and Routing", 2250 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2251 . 2253 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2254 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2255 DOI 10.17487/RFC7231, June 2014, 2256 . 2258 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2259 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2260 DOI 10.17487/RFC7540, May 2015, 2261 . 2263 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2264 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2265 April 2016, . 2267 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2268 Writing an IANA Considerations Section in RFCs", BCP 26, 2269 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2270 . 2272 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2273 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2274 May 2017, . 2276 12.2. Informative References 2278 [HPACK] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2279 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2280 DOI 10.17487/RFC7231, June 2014, 2281 . 2283 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 2284 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 2285 . 2287 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2288 "Transport Layer Security (TLS) Application-Layer Protocol 2289 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2290 July 2014, . 2292 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2293 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2294 . 2296 12.3. URIs 2298 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 2300 [2] https://github.com/quicwg 2302 [3] https://github.com/quicwg/base-drafts/labels/-http 2304 [4] https://www.iana.org/assignments/message-headers 2306 Appendix A. Considerations for Transitioning from HTTP/2 2308 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 2309 This section describes the approach taken to design HTTP/3, points 2310 out important differences from HTTP/2, and describes how to map 2311 HTTP/2 extensions into HTTP/3. 2313 HTTP/3 begins from the premise that similarity to HTTP/2 is 2314 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 2315 where QUIC differs from TCP, either to take advantage of QUIC 2316 features (like streams) or to accommodate important shortcomings 2317 (such as a lack of total ordering). These differences make HTTP/3 2318 similar to HTTP/2 in key aspects, such as the relationship of 2319 requests and responses to streams. However, the details of the 2320 HTTP/3 design are substantially different than HTTP/2. 2322 These departures are noted in this section. 2324 A.1. Streams 2326 HTTP/3 permits use of a larger number of streams (2^62-1) than 2327 HTTP/2. The considerations about exhaustion of stream identifier 2328 space apply, though the space is significantly larger such that it is 2329 likely that other limits in QUIC are reached first, such as the limit 2330 on the connection flow control window. 2332 A.2. HTTP Frame Types 2334 Many framing concepts from HTTP/2 can be elided on QUIC, because the 2335 transport deals with them. Because frames are already on a stream, 2336 they can omit the stream number. Because frames do not block 2337 multiplexing (QUIC's multiplexing occurs below this layer), the 2338 support for variable-maximum-length packets can be removed. Because 2339 stream termination is handled by QUIC, an END_STREAM flag is not 2340 required. This permits the removal of the Flags field from the 2341 generic frame layout. 2343 Frame payloads are largely drawn from [HTTP2]. However, QUIC 2344 includes many features (e.g., flow control) which are also present in 2345 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 2346 As a result, several HTTP/2 frame types are not required in HTTP/3. 2347 Where an HTTP/2-defined frame is no longer used, the frame ID has 2348 been reserved in order to maximize portability between HTTP/2 and 2349 HTTP/3 implementations. However, even equivalent frames between the 2350 two mappings are not identical. 2352 Many of the differences arise from the fact that HTTP/2 provides an 2353 absolute ordering between frames across all streams, while QUIC 2354 provides this guarantee on each stream only. As a result, if a frame 2355 type makes assumptions that frames from different streams will still 2356 be received in the order sent, HTTP/3 will break them. 2358 Some examples of feature adaptations are described below, as well as 2359 general guidance to extension frame implementors converting an HTTP/2 2360 extension to HTTP/3. 2362 A.2.1. Prioritization Differences 2364 HTTP/2 specifies priority assignments in PRIORITY frames and 2365 (optionally) in HEADERS frames. Implicit in the HTTP/2 2366 prioritization scheme is the notion of in-order delivery of priority 2367 changes (i.e., dependency tree mutations). Since operations on the 2368 dependency tree such as reparenting a subtree are not commutative, 2369 both sender and receiver must apply them in the same order to ensure 2370 that both sides have a consistent view of the stream dependency tree. 2372 To achieve in-order delivery of priority changes in HTTP/3, PRIORITY 2373 frames are sent on the control stream. HTTP/3 permits the 2374 prioritization of requests, pushes and placeholders that each exist 2375 in separate identifier spaces. The HTTP/3 PRIORITY frame replaces 2376 the stream dependency field with fields that can identify the element 2377 of interest and its dependency. 2379 A.2.2. Header Compression Differences 2381 HPACK was designed with the assumption of in-order delivery. A 2382 sequence of encoded header blocks must arrive (and be decoded) at an 2383 endpoint in the same order in which they were encoded. This ensures 2384 that the dynamic state at the two endpoints remains in sync. 2386 Because this total ordering is not provided by QUIC, HTTP/3 uses a 2387 modified version of HPACK, called QPACK. QPACK uses a single 2388 unidirectional stream to make all modifications to the dynamic table, 2389 ensuring a total order of updates. All frames which contain encoded 2390 headers merely reference the table state at a given time without 2391 modifying it. 2393 [QPACK] provides additional details. 2395 A.2.3. Guidance for New Frame Type Definitions 2397 Frame type definitions in HTTP/3 often use the QUIC variable-length 2398 integer encoding. In particular, Stream IDs use this encoding, which 2399 allows for a larger range of possible values than the encoding used 2400 in HTTP/2. Some frames in HTTP/3 use an identifier rather than a 2401 Stream ID (e.g. Push IDs in PRIORITY frames). Redefinition of the 2402 encoding of extension frame types might be necessary if the encoding 2403 includes a Stream ID. 2405 Because the Flags field is not present in generic HTTP/3 frames, 2406 those frames which depend on the presence of flags need to allocate 2407 space for flags as part of their frame payload. 2409 Other than this issue, frame type HTTP/2 extensions are typically 2410 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2411 control stream in HTTP/3. HTTP/3 extensions will not assume 2412 ordering, but would not be harmed by ordering, and would be portable 2413 to HTTP/2 in the same manner. 2415 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types 2417 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2418 Section 7.2.1. 2420 HEADERS (0x1): The PRIORITY region of HEADERS is not defined in 2421 HTTP/3 frames. A separate PRIORITY frame is used in all cases. 2422 Padding is not defined in HTTP/3 frames. See Section 7.2.2. 2424 PRIORITY (0x2): As described above, the PRIORITY frame references a 2425 variety of identifiers. It is sent as the first frame on a 2426 request streams or on the control stream. See Section 7.2.3. 2428 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 2429 provides stream lifecycle management. The same code point is used 2430 for the CANCEL_PUSH frame (Section 7.2.4). 2432 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2433 the connection. See Section 7.2.5 and Appendix A.3. 2435 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 2436 instead the push stream references the PUSH_PROMISE frame using a 2437 Push ID. See Section 7.2.6. 2439 PING (0x6): PING frames do not exist, since QUIC provides equivalent 2440 functionality. 2442 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 2443 contain an error code. See Section 7.2.7. 2445 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 2446 provides flow control. 2448 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 2449 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. 2451 Frame types defined by extensions to HTTP/2 need to be separately 2452 registered for HTTP/3 if still applicable. The IDs of frames defined 2453 in [HTTP2] have been reserved for simplicity. Note that the frame 2454 type space in HTTP/3 is substantially larger (62 bits versus 8 bits), 2455 so many HTTP/3 frame types have no equivalent HTTP/2 code points. 2456 See Section 11.3. 2458 A.3. HTTP/2 SETTINGS Parameters 2460 An important difference from HTTP/2 is that settings are sent once, 2461 at the beginning of the connection, and thereafter cannot change. 2462 This eliminates many corner cases around synchronization of changes. 2464 Some transport-level options that HTTP/2 specifies via the SETTINGS 2465 frame are superseded by QUIC transport parameters in HTTP/3. The 2466 HTTP-level options that are retained in HTTP/3 have the same value as 2467 in HTTP/2. 2469 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2471 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 2473 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 2474 which provides a more granular control over server push. 2476 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 2477 Stream ID as part of its flow control logic. Specifying 2478 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 2480 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 2481 connection flow control window sizes to be specified in the 2482 initial transport handshake. Specifying 2483 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 2485 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. 2486 Specifying it in the SETTINGS frame is an error. 2488 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 7.2.5.1. 2490 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2491 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2492 This will often produce a shorter encoding, but can produce a longer 2493 encoding for settings which use the full 32-bit space. Settings 2494 ported from HTTP/2 might choose to redefine the format of their 2495 settings to avoid using the 62-bit encoding. 2497 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2498 IDs of settings defined in [HTTP2] have been reserved for simplicity. 2499 Note that the settings identifier space in HTTP/3 is substantially 2500 larger (62 bits versus 16 bits), so many HTTP/3 settings have no 2501 equivalent HTTP/2 code point. See Section 11.4. 2503 A.4. HTTP/2 Error Codes 2505 QUIC has the same concepts of "stream" and "connection" errors that 2506 HTTP/2 provides. However, there is no direct portability of HTTP/2 2507 error codes. 2509 The HTTP/2 error codes defined in Section 7 of [HTTP2] map to the 2510 HTTP/3 error codes as follows: 2512 NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1. 2514 PROTOCOL_ERROR (0x1): This is mapped to HTTP_GENERAL_PROTOCOL_ERROR 2515 except in cases where more specific error codes have been defined. 2516 This includes HTTP_MALFORMED_FRAME, HTTP_WRONG_STREAM, 2517 HTTP_UNEXPECTED_FRAME and HTTP_CLOSED_CRITICAL_STREAM defined in 2518 Section 8.1. 2520 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1. 2522 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2523 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 2524 from the QUIC layer. 2526 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2527 SETTINGS is defined. 2529 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2530 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 2531 from the QUIC layer. 2533 FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in 2534 Section 8.1. 2536 REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used 2537 to indicate that a request was not processed. Otherwise, not 2538 applicable because QUIC handles stream management. A 2539 STREAM_ID_ERROR at the QUIC layer is used for streams that are 2540 improperly opened. 2542 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. 2544 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2545 [QPACK]. 2547 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. 2549 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. 2551 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2552 provide sufficient security on all connections. 2554 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1. 2556 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2557 Section 11.5. 2559 Appendix B. Change Log 2561 *RFC Editor's Note:* Please remove this section prior to 2562 publication of a final version of this document. 2564 B.1. Since draft-ietf-quic-http-21 2566 o No changes 2568 B.2. Since draft-ietf-quic-http-20 2570 o Prohibit closing the control stream (#2509, #2666) 2572 o Change default priority to use an orphan node (#2502, #2690) 2574 o Exclusive priorities are restored (#2754, #2781) 2576 o Restrict use of frames when using CONNECT (#2229, #2702) 2577 o Close and maybe reset streams if a connection error occurs for 2578 CONNECT (#2228, #2703) 2580 o Encourage provision of sufficient unidirectional streams for QPACK 2581 (#2100, #2529, #2762) 2583 o Allow extensions to use server-initiated bidirectional streams 2584 (#2711, #2773) 2586 o Clarify use of maximum header list size setting (#2516, #2774) 2588 o Extensive changes to error codes and conditions of their sending 2590 * Require connection errors for more error conditions (#2511, 2591 #2510) 2593 * Updated the error codes for illegal GOAWAY frames (#2714, 2594 #2707) 2596 * Specified error code for HEADERS on control stream (#2708) 2598 * Specified error code for servers receiving PUSH_PROMISE (#2709) 2600 * Specified error code for receiving DATA before HEADERS (#2715) 2602 * Describe malformed messages and their handling (#2410, #2764) 2604 * Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813) 2606 * Refactor Push ID related errors (#2818, #2820) 2608 * Rationalize HTTP/3 stream creation errors (#2821, #2822) 2610 B.3. Since draft-ietf-quic-http-19 2612 o SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530) 2614 o Non-zero bits in the Empty field of the PRIORITY frame MAY be 2615 treated as an error (#2501) 2617 B.4. Since draft-ietf-quic-http-18 2619 o Resetting streams following a GOAWAY is recommended, but not 2620 required (#2256,#2457) 2622 o Use variable-length integers throughout (#2437,#2233,#2253,#2275) 2623 * Variable-length frame types, stream types, and settings 2624 identifiers 2626 * Renumbered stream type assignments 2628 * Modified associated reserved values 2630 o Frame layout switched from Length-Type-Value to Type-Length-Value 2631 (#2395,#2235) 2633 o Specified error code for servers receiving DUPLICATE_PUSH (#2497) 2635 o Use connection error for invalid PRIORITY (#2507, #2508) 2637 B.5. Since draft-ietf-quic-http-17 2639 o HTTP_REQUEST_REJECTED is used to indicate a request can be retried 2640 (#2106, #2325) 2642 o Changed error code for GOAWAY on the wrong stream (#2231, #2343) 2644 B.6. Since draft-ietf-quic-http-16 2646 o Rename "HTTP/QUIC" to "HTTP/3" (#1973) 2648 o Changes to PRIORITY frame (#1865, #2075) 2650 * Permitted as first frame of request streams 2652 * Remove exclusive reprioritization 2654 * Changes to Prioritized Element Type bits 2656 o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 2657 (#2072) 2659 o Set defaults for settings, allow request before receiving SETTINGS 2660 (#1809, #1846, #2038) 2662 o Clarify message processing rules for streams that aren't closed 2663 (#1972, #2003) 2665 o Removed reservation of error code 0 and moved HTTP_NO_ERROR to 2666 this value (#1922) 2668 o Removed prohibition of zero-length DATA frames (#2098) 2670 B.7. Since draft-ietf-quic-http-15 2672 Substantial editorial reorganization; no technical changes. 2674 B.8. Since draft-ietf-quic-http-14 2676 o Recommend sensible values for QUIC transport parameters 2677 (#1720,#1806) 2679 o Define error for missing SETTINGS frame (#1697,#1808) 2681 o Setting values are variable-length integers (#1556,#1807) and do 2682 not have separate maximum values (#1820) 2684 o Expanded discussion of connection closure (#1599,#1717,#1712) 2686 o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 2688 B.9. Since draft-ietf-quic-http-13 2690 o Reserved some frame types for grease (#1333, #1446) 2692 o Unknown unidirectional stream types are tolerated, not errors; 2693 some reserved for grease (#1490, #1525) 2695 o Require settings to be remembered for 0-RTT, prohibit reductions 2696 (#1541, #1641) 2698 o Specify behavior for truncated requests (#1596, #1643) 2700 B.10. Since draft-ietf-quic-http-12 2702 o TLS SNI extension isn't mandatory if an alternative method is used 2703 (#1459, #1462, #1466) 2705 o Removed flags from HTTP/3 frames (#1388, #1398) 2707 o Reserved frame types and settings for use in preserving 2708 extensibility (#1333, #1446) 2710 o Added general error code (#1391, #1397) 2712 o Unidirectional streams carry a type byte and are extensible 2713 (#910,#1359) 2715 o Priority mechanism now uses explicit placeholders to enable 2716 persistent structure in the tree (#441,#1421,#1422) 2718 B.11. Since draft-ietf-quic-http-11 2720 o Moved QPACK table updates and acknowledgments to dedicated streams 2721 (#1121, #1122, #1238) 2723 B.12. Since draft-ietf-quic-http-10 2725 o Settings need to be remembered when attempting and accepting 0-RTT 2726 (#1157, #1207) 2728 B.13. Since draft-ietf-quic-http-09 2730 o Selected QCRAM for header compression (#228, #1117) 2732 o The server_name TLS extension is now mandatory (#296, #495) 2734 o Specified handling of unsupported versions in Alt-Svc (#1093, 2735 #1097) 2737 B.14. Since draft-ietf-quic-http-08 2739 o Clarified connection coalescing rules (#940, #1024) 2741 B.15. Since draft-ietf-quic-http-07 2743 o Changes for integer encodings in QUIC (#595,#905) 2745 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 2747 o Improvement to the description of GOAWAY (#604, #898) 2749 o Improve description of server push usage (#947, #950, #957) 2751 B.16. Since draft-ietf-quic-http-06 2753 o Track changes in QUIC error code usage (#485) 2755 B.17. Since draft-ietf-quic-http-05 2757 o Made push ID sequential, add MAX_PUSH_ID, remove 2758 SETTINGS_ENABLE_PUSH (#709) 2760 o Guidance about keep-alive and QUIC PINGs (#729) 2762 o Expanded text on GOAWAY and cancellation (#757) 2764 B.18. Since draft-ietf-quic-http-04 2766 o Cite RFC 5234 (#404) 2768 o Return to a single stream per request (#245,#557) 2770 o Use separate frame type and settings registries from HTTP/2 (#81) 2772 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 2774 o Restored GOAWAY (#696) 2776 o Identify server push using Push ID rather than a stream ID 2777 (#702,#281) 2779 o DATA frames cannot be empty (#700) 2781 B.19. Since draft-ietf-quic-http-03 2783 None. 2785 B.20. Since draft-ietf-quic-http-02 2787 o Track changes in transport draft 2789 B.21. Since draft-ietf-quic-http-01 2791 o SETTINGS changes (#181): 2793 * SETTINGS can be sent only once at the start of a connection; no 2794 changes thereafter 2796 * SETTINGS_ACK removed 2798 * Settings can only occur in the SETTINGS frame a single time 2800 * Boolean format updated 2802 o Alt-Svc parameter changed from "v" to "quic"; format updated 2803 (#229) 2805 o Closing the connection control stream or any message control 2806 stream is a fatal error (#176) 2808 o HPACK Sequence counter can wrap (#173) 2810 o 0-RTT guidance added 2811 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 2812 added (#127,#242) 2814 B.22. Since draft-ietf-quic-http-00 2816 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 2818 o Changed from using HTTP/2 framing within Stream 3 to new framing 2819 format and two-stream-per-request model (#71,#72,#73) 2821 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 2822 settings-01 2824 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 2825 order (#75) 2827 o Described CONNECT pseudo-method (#95) 2829 o Updated ALPN token and Alt-Svc guidance (#13,#87) 2831 o Application-layer-defined error codes (#19,#74) 2833 B.23. Since draft-shade-quic-http2-mapping-00 2835 o Adopted as base for draft-ietf-quic-http 2837 o Updated authors/editors list 2839 Acknowledgements 2841 The original authors of this specification were Robbie Shade and Mike 2842 Warres. 2844 A substantial portion of Mike's contribution was supported by 2845 Microsoft during his employment there. 2847 Author's Address 2849 Mike Bishop (editor) 2850 Akamai 2852 Email: mbishop@evequefou.be