idnits 2.17.1 draft-ietf-quic-http-18.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 (January 23, 2019) is 1913 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 1954 -- Looks like a reference, but probably isn't: '2' on line 1956 -- Looks like a reference, but probably isn't: '3' on line 1958 -- Looks like a reference, but probably isn't: '4' on line 1960 == Unused Reference: 'RFC7413' is defined on line 1943, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-17 ** 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) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALTSVC'. Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Akamai 4 Intended status: Standards Track January 23, 2019 5 Expires: July 27, 2019 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-18 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 July 27, 2019. 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. Notational Conventions . . . . . . . . . . . . . . . . . 4 65 2. Connection Setup and Management . . . . . . . . . . . . . . . 5 66 2.1. Draft Version Identification . . . . . . . . . . . . . . 5 67 2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5 68 2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6 69 2.3. Connection Establishment . . . . . . . . . . . . . . . . 6 70 2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7 71 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 72 3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8 73 3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8 74 3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 9 75 3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 10 76 3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 10 77 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10 78 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 11 79 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11 80 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12 83 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 15 84 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16 85 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18 86 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 19 88 4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 20 89 4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 21 90 5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 21 91 5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 21 92 5.1.1. Header Formatting and Compression . . . . . . . . . . 22 93 5.1.2. Request Cancellation and Rejection . . . . . . . . . 23 95 5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 24 96 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 25 97 5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 26 98 5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 26 99 5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 27 100 6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 28 101 6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 28 102 6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 29 103 6.3. Immediate Application Closure . . . . . . . . . . . . . . 30 104 6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 30 105 7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 31 106 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 107 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 32 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 110 10.1. Registration of HTTP/3 Identification String . . . . . . 34 111 10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 34 112 10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 34 113 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 36 114 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 37 115 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 39 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 118 11.2. Informative References . . . . . . . . . . . . . . . . . 41 119 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 120 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 42 121 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 42 122 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 42 123 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 45 124 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 45 125 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47 126 B.1. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 47 127 B.2. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 47 128 B.3. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 47 129 B.4. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 47 130 B.5. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 48 131 B.6. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 48 132 B.7. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 48 133 B.8. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 48 134 B.9. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 49 135 B.10. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 49 136 B.11. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 49 137 B.12. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 49 138 B.13. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 49 139 B.14. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 49 140 B.15. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 50 141 B.16. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 50 142 B.17. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 50 143 B.18. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 50 144 B.19. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 51 145 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51 146 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51 148 1. Introduction 150 HTTP semantics are used for a broad range of services on the 151 Internet. These semantics have commonly been used with two different 152 TCP mappings, HTTP/1.1 and HTTP/2. HTTP/2 introduced a framing and 153 multiplexing layer to improve latency without modifying the transport 154 layer. However, TCP's lack of visibility into parallel requests in 155 both mappings limited the possible performance gains. 157 The QUIC transport protocol incorporates stream multiplexing and per- 158 stream flow control, similar to that provided by the HTTP/2 framing 159 layer. By providing reliability at the stream level and congestion 160 control across the entire connection, it has the capability to 161 improve the performance of HTTP compared to a TCP mapping. QUIC also 162 incorporates TLS 1.3 at the transport layer, offering comparable 163 security to running TLS over TCP, but with improved connection setup 164 latency (unless TCP Fast Open [RFC7413]} is used). 166 This document defines a mapping of HTTP semantics over the QUIC 167 transport protocol, drawing heavily on the design of HTTP/2. This 168 document identifies HTTP/2 features that are subsumed by QUIC, and 169 describes how the other features can be implemented atop QUIC. 171 QUIC is described in [QUIC-TRANSPORT]. For a full description of 172 HTTP/2, see [RFC7540]. 174 1.1. Notational Conventions 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 183 defined in [RFC5234]. 185 This document uses the variable-length integer encoding from 186 [QUIC-TRANSPORT]. 188 Protocol elements called "frames" exist in both this document and 189 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 190 the frame name will be prefaced with "QUIC." For example, "QUIC 191 CONNECTION_CLOSE frames." References without this preface refer to 192 frames defined in Section 4.2. 194 2. Connection Setup and Management 196 2.1. Draft Version Identification 198 *RFC Editor's Note:* Please remove this section prior to 199 publication of a final version of this document. 201 HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc. 202 Only implementations of the final, published RFC can identify 203 themselves as "h3". Until such an RFC exists, implementations MUST 204 NOT identify themselves using this string. 206 Implementations of draft versions of the protocol MUST add the string 207 "-" and the corresponding draft number to the identifier. For 208 example, draft-ietf-quic-http-01 is identified using the string 209 "h3-01". 211 Non-compatible experiments that are based on these draft versions 212 MUST append the string "-" and an experiment name to the identifier. 213 For example, an experimental implementation based on draft-ietf-quic- 214 http-09 which reserves an extra stream for unsolicited transmission 215 of 1980s pop music might identify itself as "h3-09-rickroll". Note 216 that any label MUST conform to the "token" syntax defined in 217 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 218 coordinate their experiments on the quic@ietf.org mailing list. 220 2.2. Discovering an HTTP/3 Endpoint 222 An HTTP origin advertises the availability of an equivalent HTTP/3 223 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 224 ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 2.3. 226 For example, an origin could indicate in an HTTP response that HTTP/3 227 was available on UDP port 50781 at the same hostname by including the 228 following header field: 230 Alt-Svc: h3=":50781" 232 On receipt of an Alt-Svc record indicating HTTP/3 support, a client 233 MAY attempt to establish a QUIC connection to the indicated host and 234 port and, if successful, send HTTP requests using the mapping 235 described in this document. 237 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 238 connection establishment failure, in which case the client SHOULD 239 continue using the existing connection or try another alternative 240 endpoint offered by the origin. 242 Servers MAY serve HTTP/3 on any UDP port, since an alternative always 243 includes an explicit port. 245 2.2.1. QUIC Version Hints 247 This document defines the "quic" parameter for Alt-Svc, which MAY be 248 used to provide version-negotiation hints to HTTP/3 clients. QUIC 249 versions are four-byte sequences with no additional constraints on 250 format. Leading zeros SHOULD be omitted for brevity. 252 Syntax: 254 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 255 version-number = 1*8HEXDIG; hex-encoded QUIC version 257 Where multiple versions are listed, the order of the values reflects 258 the server's preference (with the first value being the most 259 preferred version). Reserved versions MAY be listed, but unreserved 260 versions which are not supported by the alternative SHOULD NOT be 261 present in the list. Origins MAY omit supported versions for any 262 reason. 264 Clients MUST ignore any included versions which they do not support. 265 The "quic" parameter MUST NOT occur more than once; clients SHOULD 266 process only the first occurrence. 268 For example, suppose a server supported both version 0x00000001 and 269 the version rendered in ASCII as "Q034". If it also opted to include 270 the reserved version (from Section 15 of [QUIC-TRANSPORT]) 271 0x1abadaba, it could specify the following header field: 273 Alt-Svc: h3=":49288";quic="1,1abadaba,51303334" 275 A client acting on this header field would drop the reserved version 276 (not supported), then attempt to connect to the alternative using the 277 first version in the list which it does support, if any. 279 2.3. Connection Establishment 281 HTTP/3 relies on QUIC as the underlying transport. The QUIC version 282 being used MUST use TLS version 1.3 or greater as its handshake 283 protocol. HTTP/3 clients MUST indicate the target domain name during 284 the TLS handshake. This may be done using the Server Name Indication 285 (SNI) [RFC6066] extension to TLS or using some other mechanism. 287 QUIC connections are established as described in [QUIC-TRANSPORT]. 288 During connection establishment, HTTP/3 support is indicated by 289 selecting the ALPN token "h3" in the TLS handshake. Support for 290 other application-layer protocols MAY be offered in the same 291 handshake. 293 While connection-level options pertaining to the core QUIC protocol 294 are set in the initial crypto handshake, HTTP/3-specific settings are 295 conveyed in the SETTINGS frame. After the QUIC connection is 296 established, a SETTINGS frame (Section 4.2.5) MUST be sent by each 297 endpoint as the initial frame of their respective HTTP control stream 298 (see Section 3.2.1). 300 2.4. Connection Reuse 302 Once a connection exists to a server endpoint, this connection MAY be 303 reused for requests with multiple different URI authority components. 304 The client MAY send any requests for which the client considers the 305 server authoritative. 307 An authoritative HTTP/3 endpoint is typically discovered because the 308 client has received an Alt-Svc record from the request's origin which 309 nominates the endpoint as a valid HTTP Alternative Service for that 310 origin. As required by [RFC7838], clients MUST check that the 311 nominated server can present a valid certificate for the origin 312 before considering it authoritative. Clients MUST NOT assume that an 313 HTTP/3 endpoint is authoritative for other origins without an 314 explicit signal. 316 A server that does not wish clients to reuse connections for a 317 particular origin can indicate that it is not authoritative for a 318 request by sending a 421 (Misdirected Request) status code in 319 response to the request (see Section 9.1.2 of [RFC7540]). 321 The considerations discussed in Section 9.1 of [RFC7540] also apply 322 to the management of HTTP/3 connections. 324 3. Stream Mapping and Usage 326 A QUIC stream provides reliable in-order delivery of bytes, but makes 327 no guarantees about order of delivery with regard to bytes on other 328 streams. On the wire, data is framed into QUIC STREAM frames, but 329 this framing is invisible to the HTTP framing layer. The transport 330 layer buffers and orders received QUIC STREAM frames, exposing the 331 data contained within as a reliable byte stream to the application. 332 Although QUIC permits out-of-order delivery within a stream HTTP/3 333 does not make use of this feature. 335 QUIC streams can be either unidirectional, carrying data only from 336 initiator to receiver, or bidirectional. Streams can be initiated by 337 either the client or the server. For more detail on QUIC streams, 338 see Section 2 of [QUIC-TRANSPORT]. 340 When HTTP headers and data are sent over QUIC, the QUIC layer handles 341 most of the stream management. HTTP does not need to do any separate 342 multiplexing when using QUIC - data sent over a QUIC stream always 343 maps to a particular HTTP transaction or connection context. 345 3.1. Bidirectional Streams 347 All client-initiated bidirectional streams are used for HTTP requests 348 and responses. A bidirectional stream ensures that the response can 349 be readily correlated with the request. This means that the client's 350 first request occurs on QUIC stream 0, with subsequent requests on 351 stream 4, 8, and so on. In order to permit these streams to open, an 352 HTTP/3 client SHOULD send non-zero values for the QUIC transport 353 parameters "initial_max_stream_data_bidi_local". An HTTP/3 server 354 SHOULD send non-zero values for the QUIC transport parameters 355 "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". 356 It is recommended that "initial_max_bidi_streams" be no smaller than 357 100, so as to not unnecessarily limit parallelism. 359 These streams carry frames related to the request/response (see 360 Section 5.1). When a stream terminates cleanly, if the last frame on 361 the stream was truncated, this MUST be treated as a connection error 362 (see HTTP_MALFORMED_FRAME in Section 8.1). Streams which terminate 363 abruptly may be reset at any point in the frame. 365 HTTP/3 does not use server-initiated bidirectional streams; clients 366 MUST omit or specify a value of zero for the QUIC transport parameter 367 "initial_max_bidi_streams". 369 3.2. Unidirectional Streams 371 Unidirectional streams, in either direction, are used for a range of 372 purposes. The purpose is indicated by a stream type, which is sent 373 as a single byte header at the start of the stream. The format and 374 structure of data that follows this header is determined by the 375 stream type. 377 0 1 2 3 4 5 6 7 378 +-+-+-+-+-+-+-+-+ 379 |Stream Type (8)| 380 +-+-+-+-+-+-+-+-+ 382 Figure 1: Unidirectional Stream Header 384 Some stream types are reserved (Section 3.2.3). Two stream types are 385 defined in this document: control streams (Section 3.2.1) and push 386 streams (Section 3.2.2). Other stream types can be defined by 387 extensions to HTTP/3; see Section 7 for more details. 389 Both clients and servers SHOULD send a value of three or greater for 390 the QUIC transport parameter "initial_max_uni_streams". 392 If the stream header indicates a stream type which is not supported 393 by the recipient, the remainder of the stream cannot be consumed as 394 the semantics are unknown. Recipients of unknown stream types MAY 395 trigger a QUIC STOP_SENDING frame with an error code of 396 HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an 397 error of any kind. 399 Implementations MAY send stream types before knowing whether the peer 400 supports them. However, stream types which could modify the state or 401 semantics of existing protocol components, including QPACK or other 402 extensions, MUST NOT be sent until the peer is known to support them. 404 A sender can close or reset a unidirectional stream unless otherwise 405 specified. A receiver MUST tolerate unidirectional streams being 406 closed or reset prior to the reception of the unidirectional stream 407 header. 409 3.2.1. Control Streams 411 A control stream is indicated by a stream type of "0x43" (ASCII 'C'). 412 Data on this stream consists of HTTP/3 frames, as defined in 413 Section 4.2. 415 Each side MUST initiate a single control stream at the beginning of 416 the connection and send its SETTINGS frame as the first frame on this 417 stream. If the first frame of the control stream is any other frame 418 type, this MUST be treated as a connection error of type 419 HTTP_MISSING_SETTINGS. Only one control stream per peer is 420 permitted; receipt of a second stream which claims to be a control 421 stream MUST be treated as a connection error of type 422 HTTP_WRONG_STREAM_COUNT. The sender MUST NOT close the control 423 stream. If the control stream is closed at any point, this MUST be 424 treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. 426 A pair of unidirectional streams is used rather than a single 427 bidirectional stream. This allows either peer to send data as soon 428 they are able. Depending on whether 0-RTT is enabled on the 429 connection, either client or server might be able to send stream data 430 first after the cryptographic handshake completes. 432 3.2.2. Push Streams 434 A push stream is indicated by a stream type of "0x50" (ASCII 'P'), 435 followed by the Push ID of the promise that it fulfills, encoded as a 436 variable-length integer. The remaining data on this stream consists 437 of HTTP/3 frames, as defined in Section 4.2, and fulfills a promised 438 server push. Server push and Push IDs are described in Section 5.4. 440 Only servers can push; if a server receives a client-initiated push 441 stream, this MUST be treated as a stream error of type 442 HTTP_WRONG_STREAM_DIRECTION. 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |Stream Type (8)| Push ID (i) ... 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 2: Push Stream Header 452 Each Push ID MUST only be used once in a push stream header. If a 453 push stream header includes a Push ID that was used in another push 454 stream header, the client MUST treat this as a connection error of 455 type HTTP_DUPLICATE_PUSH. 457 3.2.3. Reserved Stream Types 459 Stream types of the format "0x1f * N" are reserved to exercise the 460 requirement that unknown types be ignored. These streams have no 461 semantic meaning, and can be sent when application-layer padding is 462 desired. They MAY also be sent on connections where no request data 463 is currently being transferred. Endpoints MUST NOT consider these 464 streams to have any meaning upon receipt. 466 The payload and length of the stream are selected in any manner the 467 implementation chooses. 469 4. HTTP Framing Layer 471 As discussed above, frames are carried on QUIC streams and used on 472 control streams, request streams, and push streams. This section 473 describes HTTP framing in QUIC. For a comparison with HTTP/2 frames, 474 see Appendix A.2. 476 4.1. Frame Layout 478 All frames have the following format: 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Length (i) ... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type (8) | Frame Payload (*) ... 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 3: HTTP/3 frame format 490 A frame includes the following fields: 492 Length: A variable-length integer that describes the length of the 493 Frame Payload. This length does not include the Type field. 495 Type: An 8-bit type for the frame. 497 Frame Payload: A payload, the semantics of which are determined by 498 the Type field. 500 Each frame's payload MUST contain exactly the fields identified in 501 its description. A frame payload that contains additional bytes 502 after the identified fields or a frame payload that terminates before 503 the end of the identified fields MUST be treated as a connection 504 error of type HTTP_MALFORMED_FRAME. 506 4.2. Frame Definitions 508 4.2.1. DATA 510 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 511 bytes associated with an HTTP request or response payload. 513 DATA frames MUST be associated with an HTTP request or response. If 514 a DATA frame is received on either control stream, the recipient MUST 515 respond with a connection error (Section 8) of type 516 HTTP_WRONG_STREAM. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Payload (*) ... 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 4: DATA frame payload 526 4.2.2. HEADERS 528 The HEADERS frame (type=0x1) is used to carry a header block, 529 compressed using QPACK. See [QPACK] for more details. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Header Block (*) ... 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 5: HEADERS frame payload 539 HEADERS frames can only be sent on request / push streams. 541 4.2.3. PRIORITY 543 The PRIORITY (type=0x02) frame specifies the client-advised priority 544 of a request, server push or placeholder. 546 A PRIORITY frame identifies an element to prioritize, and an element 547 upon which it depends. A Prioritized ID or Dependency ID identifies 548 a client-initiated request using the corresponding stream ID, a 549 server push using a Push ID (see Section 4.2.6), or a placeholder 550 using a Placeholder ID (see Section 5.3.1). 552 When a client initiates a request, a PRIORITY frame MAY be sent as 553 the first frame of the stream, creating a dependency on an existing 554 element. In order to ensure that prioritization is processed in a 555 consistent order, any subsequent PRIORITY frames for that request 556 MUST be sent on the control stream. A PRIORITY frame received after 557 other frames on a request stream MUST be treated as a stream error of 558 type HTTP_UNEXPECTED_FRAME. 560 If, by the time a new request stream is opened, its priority 561 information has already been received via the control stream, the 562 PRIORITY frame sent on the request stream MUST be ignored. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 |PT |DT | Empty | [Prioritized Element ID (i)] ... 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | [Element Dependency ID (i)] ... 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Weight (8) | 572 +-+-+-+-+-+-+-+-+ 574 Figure 6: PRIORITY frame payload 576 The PRIORITY frame payload has the following fields: 578 PT (Prioritized Element Type): A two-bit field indicating the type 579 of element being prioritized (see Table 1). When sent on a 580 request stream, this MUST be set to "11". When sent on the 581 control stream, this MUST NOT be set to "11". 583 DT (Element Dependency Type): A two-bit field indicating the type of 584 element being depended on (see Table 2). 586 Empty: A four-bit field which MUST be zero when sent and MUST be 587 ignored on receipt. 589 Prioritized Element ID: A variable-length integer that identifies 590 the element being prioritized. Depending on the value of 591 Prioritized Type, this contains the Stream ID of a request stream, 592 the Push ID of a promised resource, a Placeholder ID of a 593 placeholder, or is absent. 595 Element Dependency ID: A variable-length integer that identifies the 596 element on which a dependency is being expressed. Depending on 597 the value of Dependency Type, this contains the Stream ID of a 598 request stream, the Push ID of a promised resource, the 599 Placeholder ID of a placeholder, or is absent. For details of 600 dependencies, see Section 5.3 and [RFC7540], Section 5.3. 602 Weight: An unsigned 8-bit integer representing a priority weight for 603 the prioritized element (see [RFC7540], Section 5.3). Add one to 604 the value to obtain a weight between 1 and 256. 606 The values for the Prioritized Element Type (Table 1) and Element 607 Dependency Type (Table 2) imply the interpretation of the associated 608 Element ID fields. 610 +---------+------------------+---------------------------------+ 611 | PT Bits | Type Description | Prioritized Element ID Contents | 612 +---------+------------------+---------------------------------+ 613 | 00 | Request stream | Stream ID | 614 | | | | 615 | 01 | Push stream | Push ID | 616 | | | | 617 | 10 | Placeholder | Placeholder ID | 618 | | | | 619 | 11 | Current stream | Absent | 620 +---------+------------------+---------------------------------+ 622 Table 1: Prioritized Element Types 624 +---------+------------------+--------------------------------+ 625 | DT Bits | Type Description | Element Dependency ID Contents | 626 +---------+------------------+--------------------------------+ 627 | 00 | Request stream | Stream ID | 628 | | | | 629 | 01 | Push stream | Push ID | 630 | | | | 631 | 10 | Placeholder | Placeholder ID | 632 | | | | 633 | 11 | Root of the tree | Absent | 634 +---------+------------------+--------------------------------+ 636 Table 2: Element Dependency Types 638 Note that unlike in [RFC7540], the root of the tree cannot be 639 referenced using a Stream ID of 0, as in QUIC stream 0 carries a 640 valid HTTP request. The root of the tree cannot be reprioritized. A 641 PRIORITY frame sent on a request stream with the Prioritized Element 642 Type set to any value other than "11" or which expresses a dependency 643 on a request with a greater Stream ID than the current stream MUST be 644 treated as a stream error of type HTTP_MALFORMED_FRAME. Likewise, a 645 PRIORITY frame sent on a control stream with the Prioritized Element 646 Type set to "11" MUST be treated as a connection error of type 647 HTTP_MALFORMED_FRAME. 649 When a PRIORITY frame claims to reference a request, the associated 650 ID MUST identify a client-initiated bidirectional stream. A server 651 MUST treat receipt of a PRIORITY frame identifying a stream of any 652 other type as a connection error of type HTTP_MALFORMED_FRAME. 654 A PRIORITY frame that references a non-existent Push ID, a 655 Placeholder ID greater than the server's limit, or a Stream ID the 656 client is not yet permitted to open MUST be treated as an 657 HTTP_LIMIT_EXCEEDED error. 659 A PRIORITY frame received on any stream other than a request or 660 control stream MUST be treated as a connection error of type 661 HTTP_WRONG_STREAM. 663 PRIORITY frames received by a client MUST be treated as a stream 664 error of type HTTP_UNEXPECTED_FRAME. 666 4.2.4. CANCEL_PUSH 668 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 669 server push prior to the push stream being received. The CANCEL_PUSH 670 frame identifies a server push by Push ID (see Section 4.2.6), 671 encoded as a variable-length integer. 673 When a server receives this frame, it aborts sending the response for 674 the identified server push. If the server has not yet started to 675 send the server push, it can use the receipt of a CANCEL_PUSH frame 676 to avoid opening a push stream. If the push stream has been opened 677 by the server, the server SHOULD send a QUIC RESET_STREAM frame on 678 that stream and cease transmission of the response. 680 A server can send the CANCEL_PUSH frame to indicate that it will not 681 be fulfilling a promise prior to creation of a push stream. Once the 682 push stream has been created, sending CANCEL_PUSH has no effect on 683 the state of the push stream. A QUIC RESET_STREAM frame SHOULD be 684 used instead to abort transmission of the server push response. 686 A CANCEL_PUSH frame is sent on the control stream. Receiving a 687 CANCEL_PUSH frame on a stream other than the control stream MUST be 688 treated as a stream error of type HTTP_WRONG_STREAM. 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Push ID (i) ... 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Figure 7: CANCEL_PUSH frame payload 698 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 699 integer. The Push ID identifies the server push that is being 700 cancelled (see Section 4.2.6). 702 If the client receives a CANCEL_PUSH frame, that frame might identify 703 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 705 4.2.5. SETTINGS 707 The SETTINGS frame (type=0x4) conveys configuration parameters that 708 affect how endpoints communicate, such as preferences and constraints 709 on peer behavior. Individually, a SETTINGS parameter can also be 710 referred to as a "setting"; the identifier and value of each setting 711 parameter can be referred to as a "setting identifier" and a "setting 712 value". 714 SETTINGS frames always apply to a connection, never a single stream. 715 A SETTINGS frame MUST be sent as the first frame of each control 716 stream (see Section 3.2.1) by each peer, and MUST NOT be sent 717 subsequently or on any other stream. If an endpoint receives a 718 SETTINGS frame on a different stream, the endpoint MUST respond with 719 a connection error of type HTTP_WRONG_STREAM. If an endpoint 720 receives a second SETTINGS frame, the endpoint MUST respond with a 721 connection error of type HTTP_UNEXPECTED_FRAME. 723 SETTINGS parameters are not negotiated; they describe characteristics 724 of the sending peer, which can be used by the receiving peer. 725 However, a negotiation can be implied by the use of SETTINGS - each 726 peer uses SETTINGS to advertise a set of supported values. The 727 definition of the setting would describe how each peer combines the 728 two sets to conclude which choice will be used. SETTINGS does not 729 provide a mechanism to identify when the choice takes effect. 731 Different values for the same parameter can be advertised by each 732 peer. For example, a client might be willing to consume a very large 733 response header, while servers are more cautious about request size. 735 Parameters MUST NOT occur more than once in the SETTINGS frame. A 736 receiver MAY treat the presence of the same parameter more than once 737 as a connection error of type HTTP_MALFORMED_FRAME. 739 The payload of a SETTINGS frame consists of zero or more parameters, 740 each consisting of an unsigned 16-bit setting identifier and a value 741 which uses the QUIC variable-length integer encoding. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Identifier (16) | Value (i) ... 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Figure 8: SETTINGS parameter format 751 An implementation MUST ignore the contents for any SETTINGS 752 identifier it does not understand. 754 4.2.5.1. Defined SETTINGS Parameters 756 The following settings are defined in HTTP/3: 758 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. 759 See Section 5.1.1 for usage. 761 SETTINGS_NUM_PLACEHOLDERS (0x8): The default value is 0. However, 762 this value SHOULD be set to a non-zero value by servers. See 763 Section 5.3.1 for usage. 765 Setting identifiers of the format "0x?a?a" are reserved to exercise 766 the requirement that unknown identifiers be ignored. Such settings 767 have no defined meaning. Endpoints SHOULD include at least one such 768 setting in their SETTINGS frame. Endpoints MUST NOT consider such 769 settings to have any meaning upon receipt. 771 Because the setting has no defined meaning, the value of the setting 772 can be any value the implementation selects. 774 Additional settings can be defined by extensions to HTTP/3; see 775 Section 7 for more details. 777 4.2.5.2. Initialization 779 An HTTP implementation MUST NOT send frames or requests which would 780 be invalid based on its current understanding of the peer's settings. 781 All settings begin at an initial value, and are updated upon receipt 782 of a SETTINGS frame. For servers, the initial value of each client 783 setting is the default value. 785 For clients using a 1-RTT QUIC connection, the initial value of each 786 server setting is the default value. When a 0-RTT QUIC connection is 787 being used, the initial value of each server setting is the value 788 used in the previous session. Clients MUST store the settings the 789 server provided in the session being resumed and MUST comply with 790 stored settings until the current server settings are received. 792 A server can remember the settings that it advertised, or store an 793 integrity-protected copy of the values in the ticket and recover the 794 information when accepting 0-RTT data. A server uses the HTTP/3 795 settings values in determining whether to accept 0-RTT data. 797 A server MAY accept 0-RTT and subsequently provide different settings 798 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 799 SETTINGS frame MUST NOT reduce any limits or alter any values that 800 might be violated by the client with its 0-RTT data. 802 4.2.6. PUSH_PROMISE 804 The PUSH_PROMISE frame (type=0x05) is used to carry a promised 805 request header set from server to client on a request stream, as in 806 HTTP/2. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Push ID (i) ... 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Header Block (*) ... 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Figure 9: PUSH_PROMISE frame payload 818 The payload consists of: 820 Push ID: A variable-length integer that identifies the server push 821 operation. A Push ID is used in push stream headers 822 (Section 5.4), CANCEL_PUSH frames (Section 4.2.4), DUPLICATE_PUSH 823 frames (Section 4.2.9), and PRIORITY frames (Section 4.2.3). 825 Header Block: QPACK-compressed request header fields for the 826 promised response. See [QPACK] for more details. 828 A server MUST NOT use a Push ID that is larger than the client has 829 provided in a MAX_PUSH_ID frame (Section 4.2.8) and MUST NOT use the 830 same Push ID in multiple PUSH_PROMISE frames. A client MUST treat 831 receipt of a PUSH_PROMISE that contains a larger Push ID than the 832 client has advertised or a Push ID which has already been promised as 833 a connection error of type HTTP_MALFORMED_FRAME. 835 If a PUSH_PROMISE frame is received on either control stream, the 836 recipient MUST respond with a connection error (Section 8) of type 837 HTTP_WRONG_STREAM. 839 See Section 5.4 for a description of the overall server push 840 mechanism. 842 4.2.7. GOAWAY 844 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 845 a connection by a server. GOAWAY allows a server to stop accepting 846 new requests while still finishing processing of previously received 847 requests. This enables administrative actions, like server 848 maintenance. GOAWAY by itself does not close a connection. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Stream ID (i) ... 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Figure 10: GOAWAY frame payload 858 The GOAWAY frame is always sent on the control stream. It carries a 859 QUIC Stream ID for a client-initiated bidirectional stream encoded as 860 a variable-length integer. A client MUST treat receipt of a GOAWAY 861 frame containing a Stream ID of any other type as a connection error 862 of type HTTP_WRONG_STREAM. 864 Clients do not need to send GOAWAY to initiate a graceful shutdown; 865 they simply stop making new requests. A server MUST treat receipt of 866 a GOAWAY frame on any stream as a connection error (Section 8) of 867 type HTTP_UNEXPECTED_FRAME. 869 The GOAWAY frame applies to the connection, not a specific stream. A 870 client MUST treat a GOAWAY frame on a stream other than the control 871 stream as a connection error (Section 8) of type 872 HTTP_UNEXPECTED_FRAME. 874 See Section 6.2 for more information on the use of the GOAWAY frame. 876 4.2.8. MAX_PUSH_ID 878 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 879 number of server pushes that the server can initiate. This sets the 880 maximum value for a Push ID that the server can use in a PUSH_PROMISE 881 frame. Consequently, this also limits the number of push streams 882 that the server can initiate in addition to the limit set by the QUIC 883 MAX_STREAM_ID frame. 885 The MAX_PUSH_ID frame is always sent on the control stream. Receipt 886 of a MAX_PUSH_ID frame on any other stream MUST be treated as a 887 connection error of type HTTP_WRONG_STREAM. 889 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 890 receipt of a MAX_PUSH_ID frame as a connection error of type 891 HTTP_UNEXPECTED_FRAME. 893 The maximum Push ID is unset when a connection is created, meaning 894 that a server cannot push until it receives a MAX_PUSH_ID frame. A 895 client that wishes to manage the number of promised server pushes can 896 increase the maximum Push ID by sending MAX_PUSH_ID frames as the 897 server fulfills or cancels server pushes. 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Push ID (i) ... 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Figure 11: MAX_PUSH_ID frame payload 907 The MAX_PUSH_ID frame carries a single variable-length integer that 908 identifies the maximum value for a Push ID that the server can use 909 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 910 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 911 previously received MUST be treated as a connection error of type 912 HTTP_MALFORMED_FRAME. 914 4.2.9. DUPLICATE_PUSH 916 The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate 917 that an existing pushed resource is related to multiple client 918 requests. 920 The DUPLICATE_PUSH frame is always sent on a request stream. Receipt 921 of a DUPLICATE_PUSH frame on any other stream MUST be treated as a 922 connection error of type HTTP_WRONG_STREAM. 924 A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat 925 the receipt of a DUPLICATE_PUSH frame as a connection error of type 926 HTTP_MALFORMED_FRAME. 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Push ID (i) ... 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Figure 12: DUPLICATE_PUSH frame payload 936 The DUPLICATE_PUSH frame carries a single variable-length integer 937 that identifies the Push ID of a resource that the server has 938 previously promised (see Section 4.2.6). 940 This frame allows the server to use the same server push in response 941 to multiple concurrent requests. Referencing the same server push 942 ensures that a promise can be made in relation to every response in 943 which server push might be needed without duplicating request headers 944 or pushed responses. 946 Allowing duplicate references to the same Push ID is primarily to 947 reduce duplication caused by concurrent requests. A server SHOULD 948 avoid reusing a Push ID over a long period. Clients are likely to 949 consume server push responses and not retain them for reuse over 950 time. Clients that see a DUPLICATE_PUSH that uses a Push ID that 951 they have since consumed and discarded are forced to ignore the 952 DUPLICATE_PUSH. 954 4.2.10. Reserved Frame Types 956 Frame types of the format "0xb + (0x1f * N)" are reserved to exercise 957 the requirement that unknown types be ignored (Section 7). These 958 frames have no semantic value, and can be sent when application-layer 959 padding is desired. They MAY also be sent on connections where no 960 request data is currently being transferred. Endpoints MUST NOT 961 consider these frames to have any meaning upon receipt. 963 The payload and length of the frames are selected in any manner the 964 implementation chooses. 966 5. HTTP Request Lifecycle 968 5.1. HTTP Message Exchanges 970 A client sends an HTTP request on a client-initiated bidirectional 971 QUIC stream. A client MUST send only a single request on a given 972 stream. A server sends one or more HTTP responses on the same stream 973 as the request, as detailed below. 975 An HTTP message (request or response) consists of: 977 1. the message header (see [RFC7230], Section 3.2), sent as a single 978 HEADERS frame (see Section 4.2.2), 980 2. the payload body (see [RFC7230], Section 3.3), sent as a series 981 of DATA frames (see Section 4.2.1), 983 3. optionally, one HEADERS frame containing the trailer-part, if 984 present (see [RFC7230], Section 4.1.2). 986 A server MAY interleave one or more PUSH_PROMISE frames (see 987 Section 4.2.6) with the frames of a response message. These 988 PUSH_PROMISE frames are not part of the response; see Section 5.4 for 989 more details. 991 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 992 MUST NOT be used. 994 Trailing header fields are carried in an additional HEADERS frame 995 following the body. Senders MUST send only one HEADERS frame in the 996 trailers section; receivers MUST discard any subsequent HEADERS 997 frames. 999 A response MAY consist of multiple messages when and only when one or 1000 more informational responses (1xx, see [RFC7231], Section 6.2) 1001 precede a final response to the same request. Non-final responses do 1002 not contain a payload body or trailers. 1004 An HTTP request/response exchange fully consumes a bidirectional QUIC 1005 stream. After sending a request, a client MUST close the stream for 1006 sending. Unless using the CONNECT method (see Section 5.2), clients 1007 MUST NOT make stream closure dependent on receiving a response to 1008 their request. After sending a final response, the server MUST close 1009 the stream for sending. At this point, the QUIC stream is fully 1010 closed. 1012 When a stream is closed, this indicates the end of an HTTP message. 1013 Because some messages are large or unbounded, endpoints SHOULD begin 1014 processing partial HTTP messages once enough of the message has been 1015 received to make progress. If a client stream terminates without 1016 enough of the HTTP message to provide a complete response, the server 1017 SHOULD abort its response with the error code 1018 HTTP_INCOMPLETE_REQUEST. 1020 A server can send a complete response prior to the client sending an 1021 entire request if the response does not depend on any portion of the 1022 request that has not been sent and received. When this is true, a 1023 server MAY request that the client abort transmission of a request 1024 without error by triggering a QUIC STOP_SENDING frame with error code 1025 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 1026 its stream. Clients MUST NOT discard complete responses as a result 1027 of having their request terminated abruptly, though clients can 1028 always discard responses at their discretion for other reasons. 1030 5.1.1. Header Formatting and Compression 1032 HTTP message headers carry information as a series of key-value 1033 pairs, called header fields. For a listing of registered HTTP header 1034 fields, see the "Message Header Field" registry maintained at 1035 https://www.iana.org/assignments/message-headers [4]. 1037 Just as in previous versions of HTTP, header field names are strings 1038 of ASCII characters that are compared in a case-insensitive fashion. 1039 Properties of HTTP header field names and values are discussed in 1040 more detail in Section 3.2 of [RFC7230], though the wire rendering in 1041 HTTP/3 differs. As in HTTP/2, header field names MUST be converted 1042 to lowercase prior to their encoding. A request or response 1043 containing uppercase header field names MUST be treated as malformed. 1045 As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with 1046 the ':' character (ASCII 0x3a) to convey the target URI, the method 1047 of the request, and the status code for the response. These pseudo- 1048 header fields are defined in Section 8.1.2.3 and 8.1.2.4 of 1049 [RFC7540]. Pseudo-header fields are not HTTP header fields. 1050 Endpoints MUST NOT generate pseudo-header fields other than those 1051 defined in [RFC7540]. The restrictions on the use of pseudo-header 1052 fields in Section 8.1.2.1 of [RFC7540] also apply to HTTP/3. 1054 HTTP/3 uses QPACK header compression as described in [QPACK], a 1055 variation of HPACK which allows the flexibility to avoid header- 1056 compression-induced head-of-line blocking. See that document for 1057 additional details. 1059 An HTTP/3 implementation MAY impose a limit on the maximum size of 1060 the header it will accept on an individual HTTP message; encountering 1061 a larger message header SHOULD be treated as a stream error of type 1062 "HTTP_EXCESSIVE_LOAD". If an implementation wishes to advise its 1063 peer of this limit, it can be conveyed as a number of bytes in the 1064 "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. The size of a header list 1065 is calculated based on the uncompressed size of header fields, 1066 including the length of the name and value in bytes plus an overhead 1067 of 32 bytes for each header field. 1069 5.1.2. Request Cancellation and Rejection 1071 Clients can cancel requests by aborting the stream (QUIC RESET_STREAM 1072 and/or STOP_SENDING frames, as appropriate) with an error code of 1073 HTTP_REQUEST_CANCELLED (Section 8.1). When the client cancels a 1074 response, it indicates that this response is no longer of interest. 1075 Implementations SHOULD cancel requests by aborting both directions of 1076 a stream. 1078 When the server rejects a request without performing any application 1079 processing, it SHOULD abort its response stream with the error code 1080 HTTP_REQUEST_REJECTED. In this context, "processed" means that some 1081 data from the stream was passed to some higher layer of software that 1082 might have taken some action as a result. The client can treat 1083 requests rejected by the server as though they had never been sent at 1084 all, thereby allowing them to be retried later on a new connection. 1085 Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for 1086 requests which were partially or fully processed. When a client 1087 sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY 1088 indicate the error code HTTP_REQUEST_REJECTED in the corresponding 1089 RESET_STREAM if no processing was performed. Clients MUST NOT reset 1090 streams with the HTTP_REQUEST_REJECTED error code except in response 1091 to a QUIC STOP_SENDING frame. 1093 If a stream is cancelled after receiving a complete response, the 1094 client MAY ignore the cancellation and use the response. However, if 1095 a stream is cancelled after receiving a partial response, the 1096 response SHOULD NOT be used. Automatically retrying such requests is 1097 not possible, unless this is otherwise permitted (e.g., idempotent 1098 actions like GET, PUT, or DELETE). 1100 5.2. The CONNECT Method 1102 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 1103 used with HTTP proxies to establish a TLS session with an origin 1104 server for the purposes of interacting with "https" resources. In 1105 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 1106 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 1107 establish a tunnel over a single HTTP/2 stream to a remote host for 1108 similar purposes. 1110 A CONNECT request in HTTP/3 functions in the same manner as in 1111 HTTP/2. The request MUST be formatted as described in [RFC7540], 1112 Section 8.3. A CONNECT request that does not conform to these 1113 restrictions is malformed. The request stream MUST NOT be closed at 1114 the end of the request. 1116 A proxy that supports CONNECT establishes a TCP connection 1117 ([RFC0793]) to the server identified in the ":authority" pseudo- 1118 header field. Once this connection is successfully established, the 1119 proxy sends a HEADERS frame containing a 2xx series status code to 1120 the client, as defined in [RFC7231], Section 4.3.6. 1122 All DATA frames on the stream correspond to data sent or received on 1123 the TCP connection. Any DATA frame sent by the client is transmitted 1124 by the proxy to the TCP server; data received from the TCP server is 1125 packaged into DATA frames by the proxy. Note that the size and 1126 number of TCP segments is not guaranteed to map predictably to the 1127 size and number of HTTP DATA or QUIC STREAM frames. 1129 The TCP connection can be closed by either peer. When the client 1130 ends the request stream (that is, the receive stream at the proxy 1131 enters the "Data Recvd" state), the proxy will set the FIN bit on its 1132 connection to the TCP server. When the proxy receives a packet with 1133 the FIN bit set, it will terminate the send stream that it sends to 1134 the client. TCP connections which remain half-closed in a single 1135 direction are not invalid, but are often handled poorly by servers, 1136 so clients SHOULD NOT close a stream for sending while they still 1137 expect to receive data from the target of the CONNECT. 1139 A TCP connection error is signaled with QUIC RESET_STREAM frame. A 1140 proxy treats any error in the TCP connection, which includes 1141 receiving a TCP segment with the RST bit set, as a stream error of 1142 type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, a proxy MUST 1143 send a TCP segment with the RST bit set if it detects an error with 1144 the stream or the QUIC connection. 1146 5.3. Prioritization 1148 HTTP/3 uses a priority scheme similar to that described in [RFC7540], 1149 Section 5.3. In this priority scheme, a given element can be 1150 designated as dependent upon another element. This information is 1151 expressed in the PRIORITY frame Section 4.2.3 which identifies the 1152 element and the dependency. The elements that can be prioritized 1153 are: 1155 o Requests, identified by the ID of the request stream 1157 o Pushes, identified by the Push ID of the promised resource 1158 (Section 4.2.6) 1160 o Placeholders, identified by a Placeholder ID 1162 Taken together, the dependencies across all prioritized elements in a 1163 connection form a dependency tree. An element can depend on another 1164 element or on the root of the tree. A reference to an element which 1165 is no longer in the tree is treated as a reference to the root of the 1166 tree. The structure of the dependency tree changes as PRIORITY 1167 frames modify the dependency links between prioritized elements. 1169 Due to reordering between streams, an element can also be prioritized 1170 which is not yet in the tree. Such elements are added to the tree 1171 with the requested priority. 1173 When a prioritized element is first created, it has a default initial 1174 weight of 16 and a default dependency. Requests and placeholders are 1175 dependent on the root of the priority tree; pushes are dependent on 1176 the client request on which the PUSH_PROMISE frame was sent. 1178 Requests may override the default intial values by including a 1179 PRIORTIY frame (see Section 4.2.3) at the beginning of the stream. 1180 These priorities can be updated by sending a PRIORITY frame on the 1181 control stream. 1183 5.3.1. Placeholders 1185 In HTTP/2, certain implementations used closed or unused streams as 1186 placeholders in describing the relative priority of requests. This 1187 created confusion as servers could not reliably identify which 1188 elements of the priority tree could be discarded safely. Clients 1189 could potentially reference closed streams long after the server had 1190 discarded state, leading to disparate views of the prioritization the 1191 client had attempted to express. 1193 In HTTP/3, a number of placeholders are explicitly permitted by the 1194 server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because the 1195 server commits to maintaining these placeholders in the 1196 prioritization tree, clients can use them with confidence that the 1197 server will not have discarded the state. Clients MUST NOT send the 1198 "SETTINGS_NUM_PLACEHOLDERS" setting; receipt of this setting by a 1199 server MUST be treated as a connection error of type 1200 "HTTP_WRONG_SETTING_DIRECTION". 1202 Placeholders are identified by an ID between zero and one less than 1203 the number of placeholders the server has permitted. 1205 Like streams, placeholders have priority information associated with 1206 them. 1208 5.3.2. Priority Tree Maintenance 1210 Because placeholders will be used to "root" any persistent structure 1211 of the tree which the client cares about retaining, servers can 1212 aggressively prune inactive regions from the priority tree. For 1213 prioritization purposes, a node in the tree is considered "inactive" 1214 when the corresponding stream has been closed for at least two round- 1215 trip times (using any reasonable estimate available on the server). 1216 This delay helps mitigate race conditions where the server has pruned 1217 a node the client believed was still active and used as a Stream 1218 Dependency. 1220 Specifically, the server MAY at any time: 1222 o Identify and discard branches of the tree containing only inactive 1223 nodes (i.e. a node with only other inactive nodes as descendants, 1224 along with those descendants) 1226 o Identify and condense interior regions of the tree containing only 1227 inactive nodes, allocating weight appropriately 1228 x x x 1229 | | | 1230 P P P 1231 / \ | | 1232 I I ==> I ==> A 1233 / \ | | 1234 A I A A 1235 | | 1236 A A 1238 Figure 13: Example of Priority Tree Pruning 1240 In the example in Figure 13, "P" represents a Placeholder, "A" 1241 represents an active node, and "I" represents an inactive node. In 1242 the first step, the server discards two inactive branches (each a 1243 single node). In the second step, the server condenses an interior 1244 inactive node. Note that these transformations will result in no 1245 change in the resources allocated to a particular active stream. 1247 Clients SHOULD assume the server is actively performing such pruning 1248 and SHOULD NOT declare a dependency on a stream it knows to have been 1249 closed. 1251 5.4. Server Push 1253 HTTP/3 server push is similar to what is described in HTTP/2 1254 [RFC7540], but uses different mechanisms. 1256 Each server push is identified by a unique Push ID. This Push ID is 1257 used in a single PUSH_PROMISE frame (see Section 4.2.6) which carries 1258 the request headers, possibly included in one or more DUPLICATE_PUSH 1259 frames (see Section 4.2.9), then included with the push stream which 1260 ultimately fulfills those promises. 1262 Server push is only enabled on a connection when a client sends a 1263 MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server 1264 push until it receives a MAX_PUSH_ID frame. A client sends 1265 additional MAX_PUSH_ID frames to control the number of pushes that a 1266 server can promise. A server SHOULD use Push IDs sequentially, 1267 starting at 0. A client MUST treat receipt of a push stream with a 1268 Push ID that is greater than the maximum Push ID as a connection 1269 error of type HTTP_LIMIT_EXCEEDED. 1271 The header of the request message is carried by a PUSH_PROMISE frame 1272 (see Section 4.2.6) on the request stream which generated the push. 1273 This allows the server push to be associated with a client request. 1274 Ordering of a PUSH_PROMISE in relation to certain parts of the 1275 response is important (see Section 8.2.1 of [RFC7540]). Promised 1276 requests MUST conform to the requirements in Section 8.2 of 1277 [RFC7540]. 1279 The same server push can be associated with additional client 1280 requests using a DUPLICATE_PUSH frame (see Section 4.2.9). Ordering 1281 of a DUPLICATE_PUSH in relation to certain parts of the response is 1282 similarly important. Due to reordering, DUPLICATE_PUSH frames can 1283 arrive before the corresponding PUSH_PROMISE frame, in which case the 1284 request headers of the push would not be immediately available. 1285 Clients which receive a DUPLICATE_PUSH frame for an as-yet-unknown 1286 Push ID can either delay generating new requests for content 1287 referenced following the DUPLICATE_PUSH frame until the request 1288 headers become available, or can initiate requests for discovered 1289 resources and cancel the requests if the requested resource is 1290 already being pushed. 1292 When a server later fulfills a promise, the server push response is 1293 conveyed on a push stream (see Section 3.2.2). The push stream 1294 identifies the Push ID of the promise that it fulfills, then contains 1295 a response to the promised request using the same format described 1296 for responses in Section 5.1. 1298 If a promised server push is not needed by the client, the client 1299 SHOULD send a CANCEL_PUSH frame. If the push stream is already open 1300 or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING 1301 frame with an appropriate error code can also be used (e.g., 1302 HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This 1303 asks the server not to transfer additional data and indicates that it 1304 will be discarded upon receipt. 1306 6. Connection Closure 1308 Once established, an HTTP/3 connection can be used for many requests 1309 and responses over time until the connection is closed. Connection 1310 closure can happen in any of several different ways. 1312 6.1. Idle Connections 1314 Each QUIC endpoint declares an idle timeout during the handshake. If 1315 the connection remains idle (no packets received) for longer than 1316 this duration, the peer will assume that the connection has been 1317 closed. HTTP/3 implementations will need to open a new connection 1318 for new requests if the existing connection has been idle for longer 1319 than the server's advertised idle timeout, and SHOULD do so if 1320 approaching the idle timeout. 1322 HTTP clients are expected to request that the transport keep 1323 connections open while there are responses outstanding for requests 1324 or server pushes, as described in Section 19.2 of [QUIC-TRANSPORT]. 1325 If the client is not expecting a response from the server, allowing 1326 an idle connection to time out is preferred over expending effort 1327 maintaining a connection that might not be needed. A gateway MAY 1328 maintain connections in anticipation of need rather than incur the 1329 latency cost of connection establishment to servers. Servers SHOULD 1330 NOT actively keep connections open. 1332 6.2. Connection Shutdown 1334 Even when a connection is not idle, either endpoint can decide to 1335 stop using the connection and let the connection close gracefully. 1336 Since clients drive request generation, clients perform a connection 1337 shutdown by not sending additional requests on the connection; 1338 responses and pushed responses associated to previous requests will 1339 continue to completion. Servers perform the same function by 1340 communicating with clients. 1342 Servers initiate the shutdown of a connection by sending a GOAWAY 1343 frame (Section 4.2.7). The GOAWAY frame indicates that client- 1344 initiated requests on lower stream IDs were or might be processed in 1345 this connection, while requests on the indicated stream ID and 1346 greater were rejected. This enables client and server to agree on 1347 which requests were accepted prior to the connection shutdown. This 1348 identifier MAY be lower than the stream limit identified by a QUIC 1349 MAX_STREAM_ID frame, and MAY be zero if no requests were processed. 1350 Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after 1351 sending a GOAWAY frame. 1353 Once GOAWAY is sent, the server MUST reject requests sent on streams 1354 with an identifier greater than or equal to the indicated last Stream 1355 ID. Clients MUST NOT send new requests on the connection after 1356 receiving GOAWAY, although requests might already be in transit. A 1357 new connection can be established for new requests. 1359 If the client has sent requests on streams with a Stream ID greater 1360 than or equal to that indicated in the GOAWAY frame, those requests 1361 are considered rejected (Section 5.1.2). Clients SHOULD cancel any 1362 requests on streams above this ID. Servers MAY also reject requests 1363 on streams below the indicated ID if these requests were not 1364 processed. 1366 Requests on Stream IDs less than the Stream ID in the GOAWAY frame 1367 might have been processed; their status cannot be known until they 1368 are completed successfully, reset individually, or the connection 1369 terminates. 1371 Servers SHOULD send a GOAWAY frame when the closing of a connection 1372 is known in advance, even if the advance notice is small, so that the 1373 remote peer can know whether a request has been partially processed 1374 or not. For example, if an HTTP client sends a POST at the same time 1375 that a server closes a QUIC connection, the client cannot know if the 1376 server started to process that POST request if the server does not 1377 send a GOAWAY frame to indicate what streams it might have acted on. 1379 A client that is unable to retry requests loses all requests that are 1380 in flight when the server closes the connection. A server MAY send 1381 multiple GOAWAY frames indicating different stream IDs, but MUST NOT 1382 increase the value they send in the last Stream ID, since clients 1383 might already have retried unprocessed requests on another 1384 connection. A server that is attempting to gracefully shut down a 1385 connection SHOULD send an initial GOAWAY frame with the last Stream 1386 ID set to the current value of QUIC's MAX_STREAM_ID and SHOULD NOT 1387 increase the MAX_STREAM_ID thereafter. This signals to the client 1388 that a shutdown is imminent and that initiating further requests is 1389 prohibited. After allowing time for any in-flight requests (at least 1390 one round-trip time), the server MAY send another GOAWAY frame with 1391 an updated last Stream ID. This ensures that a connection can be 1392 cleanly shut down without losing requests. 1394 Once all accepted requests have been processed, the server can permit 1395 the connection to become idle, or MAY initiate an immediate closure 1396 of the connection. An endpoint that completes a graceful shutdown 1397 SHOULD use the HTTP_NO_ERROR code when closing the connection. 1399 6.3. Immediate Application Closure 1401 An HTTP/3 implementation can immediately close the QUIC connection at 1402 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 1403 the peer; the error code in this frame indicates to the peer why the 1404 connection is being closed. See Section 8 for error codes which can 1405 be used when closing a connection. 1407 Before closing the connection, a GOAWAY MAY be sent to allow the 1408 client to retry some requests. Including the GOAWAY frame in the 1409 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 1410 of the frame being received by clients. 1412 6.4. Transport Closure 1414 For various reasons, the QUIC transport could indicate to the 1415 application layer that the connection has terminated. This might be 1416 due to an explicit closure by the peer, a transport-level error, or a 1417 change in network topology which interrupts connectivity. 1419 If a connection terminates without a GOAWAY frame, clients MUST 1420 assume that any request which was sent, whether in whole or in part, 1421 might have been processed. 1423 7. Extensions to HTTP/3 1425 HTTP/3 permits extension of the protocol. Within the limitations 1426 described in this section, protocol extensions can be used to provide 1427 additional services or alter any aspect of the protocol. Extensions 1428 are effective only within the scope of a single HTTP/3 connection. 1430 This applies to the protocol elements defined in this document. This 1431 does not affect the existing options for extending HTTP, such as 1432 defining new methods, status codes, or header fields. 1434 Extensions are permitted to use new frame types (Section 4.2), new 1435 settings (Section 4.2.5.1), new error codes (Section 8), or new 1436 unidirectional stream types (Section 3.2). Registries are 1437 established for managing these extension points: frame types 1438 (Section 10.3), settings (Section 10.4), error codes (Section 10.5), 1439 and stream types (Section 10.6). 1441 Implementations MUST ignore unknown or unsupported values in all 1442 extensible protocol elements. Implementations MUST discard frames 1443 and unidirectional streams that have unknown or unsupported types. 1444 This means that any of these extension points can be safely used by 1445 extensions without prior arrangement or negotiation. 1447 Extensions that could change the semantics of existing protocol 1448 components MUST be negotiated before being used. For example, an 1449 extension that changes the layout of the HEADERS frame cannot be used 1450 until the peer has given a positive signal that this is acceptable. 1451 In this case, it could also be necessary to coordinate when the 1452 revised layout comes into effect. 1454 This document doesn't mandate a specific method for negotiating the 1455 use of an extension but notes that a setting (Section 4.2.5.1) could 1456 be used for that purpose. If both peers set a value that indicates 1457 willingness to use the extension, then the extension can be used. If 1458 a setting is used for extension negotiation, the default value MUST 1459 be defined in such a fashion that the extension is disabled if the 1460 setting is omitted. 1462 8. Error Handling 1464 QUIC allows the application to abruptly terminate (reset) individual 1465 streams or the entire connection when an error is encountered. These 1466 are referred to as "stream errors" or "connection errors" and are 1467 described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose 1468 to treat a stream error as a connection error. 1470 This section describes HTTP/3-specific error codes which can be used 1471 to express the cause of a connection or stream error. 1473 8.1. HTTP/3 Error Codes 1475 The following error codes are defined for use in QUIC RESET_STREAM 1476 frames, STOP_SENDING frames, and CONNECTION_CLOSE frames when using 1477 HTTP/3. 1479 HTTP_NO_ERROR (0x00): No error. This is used when the connection or 1480 stream needs to be closed, but there is no error to signal. 1482 HTTP_WRONG_SETTING_DIRECTION (0x01): A client-only setting was sent 1483 by a server, or a server-only setting by a client. 1485 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1486 which the client will not accept on this connection. 1488 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1489 HTTP stack. 1491 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1492 content which the client has cached. 1494 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1495 requested data. 1497 HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated 1498 without containing a fully-formed request. 1500 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1501 a CONNECT request was reset or abnormally closed. 1503 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1504 exhibiting a behavior that might be generating excessive load. 1506 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1507 served over HTTP/3. The peer should retry over HTTP/1.1. 1509 HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it 1510 is not permitted. 1512 HTTP_LIMIT_EXCEEDED (0x0B): A Stream ID, Push ID, or Placeholder ID 1513 greater than the current maximum for that identifier was 1514 referenced. 1516 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1517 different stream headers. 1519 HTTP_UNKNOWN_STREAM_TYPE (0x0D): A unidirectional stream header 1520 contained an unknown stream type. 1522 HTTP_WRONG_STREAM_COUNT (0x0E): A unidirectional stream type was 1523 used more times than is permitted by that type. 1525 HTTP_CLOSED_CRITICAL_STREAM (0x0F): A stream required by the 1526 connection was closed or reset. 1528 HTTP_WRONG_STREAM_DIRECTION (0x0010): A unidirectional stream type 1529 was used by a peer which is not permitted to do so. 1531 HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request 1532 is not needed to produce a response. For use in STOP_SENDING 1533 only. 1535 HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at 1536 the beginning of the control stream. 1538 HTTP_UNEXPECTED_FRAME (0x0013): A frame was received which was not 1539 permitted in the current state. 1541 HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without 1542 performing any application processing. 1544 HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol 1545 requirements in a way which doesn't match a more specific error 1546 code, or endpoint declines to use the more specific error code. 1548 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1549 The frame type is included as the last byte of the error code. 1550 For example, an error in a MAX_PUSH_ID frame would be indicated 1551 with the code (0x10D). 1553 9. Security Considerations 1555 The security considerations of HTTP/3 should be comparable to those 1556 of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames 1557 and Padding fields in other frames to make a connection more 1558 resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames 1559 or employ the reserved frame and stream types discussed in 1560 Section 4.2.10 and Section 3.2.3. 1562 When HTTP Alternative Services is used for discovery for HTTP/3 1563 endpoints, the security considerations of [ALTSVC] also apply. 1565 Several protocol elements contain nested length elements, typically 1566 in the form of frames with an explicit length containing variable- 1567 length integers. This could pose a security risk to an incautious 1568 implementer. An implementation MUST ensure that the length of a 1569 frame exactly matches the length of the fields it contains. 1571 10. IANA Considerations 1573 10.1. Registration of HTTP/3 Identification String 1575 This document creates a new registration for the identification of 1576 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 1577 IDs" registry established in [RFC7301]. 1579 The "h3" string identifies HTTP/3: 1581 Protocol: HTTP/3 1583 Identification Sequence: 0x68 0x33 ("h3") 1585 Specification: This document 1587 10.2. Registration of QUIC Version Hint Alt-Svc Parameter 1589 This document creates a new registration for version-negotiation 1590 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1591 registry established in [RFC7838]. 1593 Parameter: "quic" 1595 Specification: This document, Section 2.2.1 1597 10.3. Frame Types 1599 This document establishes a registry for HTTP/3 frame type codes. 1600 The "HTTP/3 Frame Type" registry manages an 8-bit space. The "HTTP/3 1601 Frame Type" registry operates under either of the "IETF Review" or 1602 "IESG Approval" policies [RFC8126] for values from 0x00 up to and 1603 including 0xef, with values from 0xf0 up to and including 0xff being 1604 reserved for Experimental Use. 1606 While this registry is separate from the "HTTP/2 Frame Type" registry 1607 defined in [RFC7540], it is preferable that the assignments parallel 1608 each other. If an entry is present in only one registry, every 1609 effort SHOULD be made to avoid assigning the corresponding value to 1610 an unrelated operation. 1612 New entries in this registry require the following information: 1614 Frame Type: A name or label for the frame type. 1616 Code: The 8-bit code assigned to the frame type. 1618 Specification: A reference to a specification that includes a 1619 description of the frame layout and its semantics, including any 1620 parts of the frame that are conditionally present. 1622 The entries in the following table are registered by this document. 1624 +----------------+------+---------------+ 1625 | Frame Type | Code | Specification | 1626 +----------------+------+---------------+ 1627 | DATA | 0x0 | Section 4.2.1 | 1628 | | | | 1629 | HEADERS | 0x1 | Section 4.2.2 | 1630 | | | | 1631 | PRIORITY | 0x2 | Section 4.2.3 | 1632 | | | | 1633 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1634 | | | | 1635 | SETTINGS | 0x4 | Section 4.2.5 | 1636 | | | | 1637 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1638 | | | | 1639 | Reserved | 0x6 | N/A | 1640 | | | | 1641 | GOAWAY | 0x7 | Section 4.2.7 | 1642 | | | | 1643 | Reserved | 0x8 | N/A | 1644 | | | | 1645 | Reserved | 0x9 | N/A | 1646 | | | | 1647 | MAX_PUSH_ID | 0xD | Section 4.2.8 | 1648 | | | | 1649 | DUPLICATE_PUSH | 0xE | Section 4.2.9 | 1650 +----------------+------+---------------+ 1652 Additionally, each code of the format "0xb + (0x1f * N)" for values 1653 of N in the range (0..7) (that is, "0xb", "0x2a", "0x49", "0x68", 1654 "0x87", "0xa6", "0xc5", and "0xe4"), the following values should be 1655 registered: 1657 Frame Type: Reserved - GREASE 1659 Specification: Section 4.2.10 1661 10.4. Settings Parameters 1663 This document establishes a registry for HTTP/3 settings. The 1664 "HTTP/3 Settings" registry manages a 16-bit space. The "HTTP/3 1665 Settings" registry operates under the "Expert Review" policy 1666 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1667 between and 0xf000 and 0xffff being reserved for Experimental Use. 1668 The designated experts are the same as those for the "HTTP/2 1669 Settings" registry defined in [RFC7540]. 1671 While this registry is separate from the "HTTP/2 Settings" registry 1672 defined in [RFC7540], it is preferable that the assignments parallel 1673 each other. If an entry is present in only one registry, every 1674 effort SHOULD be made to avoid assigning the corresponding value to 1675 an unrelated operation. 1677 New registrations are advised to provide the following information: 1679 Name: A symbolic name for the setting. Specifying a setting name is 1680 optional. 1682 Code: The 16-bit code assigned to the setting. 1684 Specification: An optional reference to a specification that 1685 describes the use of the setting. 1687 The entries in the following table are registered by this document. 1689 +----------------------+------+-----------------+ 1690 | Setting Name | Code | Specification | 1691 +----------------------+------+-----------------+ 1692 | Reserved | 0x2 | N/A | 1693 | | | | 1694 | Reserved | 0x3 | N/A | 1695 | | | | 1696 | Reserved | 0x4 | N/A | 1697 | | | | 1698 | Reserved | 0x5 | N/A | 1699 | | | | 1700 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 | 1701 | | | | 1702 | NUM_PLACEHOLDERS | 0x8 | Section 4.2.5.1 | 1703 +----------------------+------+-----------------+ 1705 Additionally, each code of the format "0x?a?a" where each "?" is any 1706 four bits (that is, "0x0a0a", "0x0a1a", etc. through "0xfafa"), the 1707 following values should be registered: 1709 Name: Reserved - GREASE 1711 Specification: Section 4.2.5.1 1713 10.5. Error Codes 1715 This document establishes a registry for HTTP/3 error codes. The 1716 "HTTP/3 Error Code" registry manages a 16-bit space. The "HTTP/3 1717 Error Code" registry operates under the "Expert Review" policy 1718 [RFC8126]. 1720 Registrations for error codes are required to include a description 1721 of the error code. An expert reviewer is advised to examine new 1722 registrations for possible duplication with existing error codes. 1723 Use of existing registrations is to be encouraged, but not mandated. 1725 New registrations are advised to provide the following information: 1727 Name: A name for the error code. Specifying an error code name is 1728 optional. 1730 Code: The 16-bit error code value. 1732 Description: A brief description of the error code semantics, longer 1733 if no detailed specification is provided. 1735 Specification: An optional reference for a specification that 1736 defines the error code. 1738 The entries in the following table are registered by this document. 1740 +---------------------------+--------+---------------+--------------+ 1741 | Name | Code | Description | Specificatio | 1742 | | | | n | 1743 +---------------------------+--------+---------------+--------------+ 1744 | HTTP_NO_ERROR | 0x0000 | No error | Section 8.1 | 1745 | | | | | 1746 | HTTP_WRONG_SETTING_DIRECT | 0x0001 | Setting sent | Section 8.1 | 1747 | ION | | in wrong | | 1748 | | | direction | | 1749 | | | | | 1750 | HTTP_PUSH_REFUSED | 0x0002 | Client | Section 8.1 | 1751 | | | refused | | 1752 | | | pushed | | 1753 | | | content | | 1754 | | | | | 1755 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 8.1 | 1756 | | | error | | 1757 | | | | | 1758 | HTTP_PUSH_ALREADY_IN_CACH | 0x0004 | Pushed | Section 8.1 | 1759 | E | | content | | 1760 | | | already | | 1761 | | | cached | | 1762 | | | | | 1763 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 8.1 | 1764 | | | longer needed | | 1765 | | | | | 1766 | HTTP_INCOMPLETE_REQUEST | 0x0006 | Stream | Section 8.1 | 1767 | | | terminated | | 1768 | | | early | | 1769 | | | | | 1770 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset or | Section 8.1 | 1771 | | | error on | | 1772 | | | CONNECT | | 1773 | | | request | | 1774 | | | | | 1775 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 8.1 | 1776 | | | generating | | 1777 | | | excessive | | 1778 | | | load | | 1779 | | | | | 1780 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 8.1 | 1781 | | | HTTP/1.1 | | 1782 | | | | | 1783 | HTTP_WRONG_STREAM | 0x000A | A frame was | Section 8.1 | 1784 | | | sent on the | | 1785 | | | wrong stream | | 1786 | | | | | 1787 | HTTP_LIMIT_EXCEEDED | 0x000B | An identifier | Section 8.1 | 1788 | | | limit was | | 1789 | | | exceeded | | 1790 | | | | | 1791 | HTTP_DUPLICATE_PUSH | 0x000C | Push ID was | Section 8.1 | 1792 | | | fulfilled | | 1793 | | | multiple | | 1794 | | | times | | 1795 | | | | | 1796 | HTTP_UNKNOWN_STREAM_TYPE | 0x000D | Unknown unidi | Section 8.1 | 1797 | | | rectional | | 1798 | | | stream type | | 1799 | | | | | 1800 | HTTP_WRONG_STREAM_COUNT | 0x000E | Too many unid | Section 8.1 | 1801 | | | irectional | | 1802 | | | streams | | 1803 | | | | | 1804 | HTTP_CLOSED_CRITICAL_STRE | 0x000F | Critical | Section 8.1 | 1805 | AM | | stream was | | 1806 | | | closed | | 1807 | | | | | 1808 | HTTP_WRONG_STREAM_DIRECTI | 0x0010 | Unidirectiona | Section 8.1 | 1809 | ON | | l stream in | | 1810 | | | wrong | | 1811 | | | direction | | 1812 | | | | | 1813 | HTTP_EARLY_RESPONSE | 0x0011 | Remainder of | Section 8.1 | 1814 | | | request not | | 1815 | | | needed | | 1816 | | | | | 1817 | HTTP_MISSING_SETTINGS | 0x0012 | No SETTINGS | Section 8.1 | 1818 | | | frame | | 1819 | | | received | | 1820 | | | | | 1821 | HTTP_UNEXPECTED_FRAME | 0x0013 | Frame not | Section 8.1 | 1822 | | | permitted in | | 1823 | | | the current | | 1824 | | | state | | 1825 | | | | | 1826 | HTTP_REQUEST_REJECTED | 0x0014 | Request not | Section 8.1 | 1827 | | | processed | | 1828 | | | | | 1829 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 | 1830 | | | frame | | 1831 | | | formatting | | 1832 +---------------------------+--------+---------------+--------------+ 1834 10.6. Stream Types 1836 This document establishes a registry for HTTP/3 unidirectional stream 1837 types. The "HTTP/3 Stream Type" registry manages an 8-bit space. 1838 The "HTTP/3 Stream Type" registry operates under either of the "IETF 1839 Review" or "IESG Approval" policies [RFC8126] for values from 0x00 up 1840 to and including 0xef, with values from 0xf0 up to and including 0xff 1841 being reserved for Experimental Use. 1843 New entries in this registry require the following information: 1845 Stream Type: A name or label for the stream type. 1847 Code: The 8-bit code assigned to the stream type. 1849 Specification: A reference to a specification that includes a 1850 description of the stream type, including the layout semantics of 1851 its payload. 1853 Sender: Which endpoint on a connection may initiate a stream of this 1854 type. Values are "Client", "Server", or "Both". 1856 The entries in the following table are registered by this document. 1858 +----------------+------+---------------+--------+ 1859 | Stream Type | Code | Specification | Sender | 1860 +----------------+------+---------------+--------+ 1861 | Control Stream | 0x43 | Section 3.2.1 | Both | 1862 | | | | | 1863 | Push Stream | 0x50 | Section 5.4 | Server | 1864 +----------------+------+---------------+--------+ 1866 Additionally, for each code of the format "0x1f * N" for values of N 1867 in the range (0..8) (that is, "0x00", "0x1f", "0x3e", "0x5d", "0x7c", 1868 "0x9b", "0xba", "0xd9", "0xf8"), the following values should be 1869 registered: 1871 Stream Type: Reserved - GREASE 1873 Specification: Section 3.2.3 1875 Sender: Both 1877 11. References 1879 11.1. Normative References 1881 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1882 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1883 April 2016, . 1885 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 1886 Header Compression for HTTP over QUIC", draft-ietf-quic- 1887 qpack-06 (work in progress), January 2019. 1889 [QUIC-TRANSPORT] 1890 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1891 Multiplexed and Secure Transport", draft-ietf-quic- 1892 transport-17 (work in progress), January 2019. 1894 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1895 RFC 793, DOI 10.17487/RFC0793, September 1981, 1896 . 1898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1899 Requirement Levels", BCP 14, RFC 2119, 1900 DOI 10.17487/RFC2119, March 1997, 1901 . 1903 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1904 Specifications: ABNF", STD 68, RFC 5234, 1905 DOI 10.17487/RFC5234, January 2008, 1906 . 1908 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1909 Extensions: Extension Definitions", RFC 6066, 1910 DOI 10.17487/RFC6066, January 2011, 1911 . 1913 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1914 Protocol (HTTP/1.1): Message Syntax and Routing", 1915 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1916 . 1918 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1919 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1920 DOI 10.17487/RFC7231, June 2014, 1921 . 1923 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1924 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1925 DOI 10.17487/RFC7540, May 2015, 1926 . 1928 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1929 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1930 April 2016, . 1932 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1933 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1934 May 2017, . 1936 11.2. Informative References 1938 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1939 "Transport Layer Security (TLS) Application-Layer Protocol 1940 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1941 July 2014, . 1943 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1944 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1945 . 1947 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1948 Writing an IANA Considerations Section in RFCs", BCP 26, 1949 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1950 . 1952 11.3. URIs 1954 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1956 [2] https://github.com/quicwg 1958 [3] https://github.com/quicwg/base-drafts/labels/-http 1960 [4] https://www.iana.org/assignments/message-headers 1962 Appendix A. Considerations for Transitioning from HTTP/2 1964 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 1965 This section describes the approach taken to design HTTP/3, points 1966 out important differences from HTTP/2, and describes how to map 1967 HTTP/2 extensions into HTTP/3. 1969 HTTP/3 begins from the premise that similarity to HTTP/2 is 1970 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 1971 primarily where necessary to accommodate the differences in behavior 1972 between QUIC and TCP (lack of ordering, support for streams). We 1973 intend to avoid gratuitous changes which make it difficult or 1974 impossible to build extensions with the same semantics applicable to 1975 both protocols at once. 1977 These departures are noted in this section. 1979 A.1. Streams 1981 HTTP/3 permits use of a larger number of streams (2^62-1) than 1982 HTTP/2. The considerations about exhaustion of stream identifier 1983 space apply, though the space is significantly larger such that it is 1984 likely that other limits in QUIC are reached first, such as the limit 1985 on the connection flow control window. 1987 A.2. HTTP Frame Types 1989 Many framing concepts from HTTP/2 can be elided on QUIC, because the 1990 transport deals with them. Because frames are already on a stream, 1991 they can omit the stream number. Because frames do not block 1992 multiplexing (QUIC's multiplexing occurs below this layer), the 1993 support for variable-maximum-length packets can be removed. Because 1994 stream termination is handled by QUIC, an END_STREAM flag is not 1995 required. This permits the removal of the Flags field from the 1996 generic frame layout. 1998 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1999 includes many features (e.g., flow control) which are also present in 2000 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 2001 As a result, several HTTP/2 frame types are not required in HTTP/3. 2002 Where an HTTP/2-defined frame is no longer used, the frame ID has 2003 been reserved in order to maximize portability between HTTP/2 and 2004 HTTP/3 implementations. However, even equivalent frames between the 2005 two mappings are not identical. 2007 Many of the differences arise from the fact that HTTP/2 provides an 2008 absolute ordering between frames across all streams, while QUIC 2009 provides this guarantee on each stream only. As a result, if a frame 2010 type makes assumptions that frames from different streams will still 2011 be received in the order sent, HTTP/3 will break them. 2013 For example, implicit in the HTTP/2 prioritization scheme is the 2014 notion of in-order delivery of priority changes (i.e., dependency 2015 tree mutations): since operations on the dependency tree such as 2016 reparenting a subtree are not commutative, both sender and receiver 2017 must apply them in the same order to ensure that both sides have a 2018 consistent view of the stream dependency tree. HTTP/2 specifies 2019 priority assignments in PRIORITY frames and (optionally) in HEADERS 2020 frames. To achieve in-order delivery of priority changes in HTTP/3, 2021 PRIORITY frames are sent on the control stream and exclusive 2022 prioritization has been removed. 2024 Likewise, HPACK was designed with the assumption of in-order 2025 delivery. A sequence of encoded header blocks must arrive (and be 2026 decoded) at an endpoint in the same order in which they were encoded. 2027 This ensures that the dynamic state at the two endpoints remains in 2028 sync. As a result, HTTP/3 uses a modified version of HPACK, 2029 described in [QPACK]. 2031 Frame type definitions in HTTP/3 often use the QUIC variable-length 2032 integer encoding. In particular, Stream IDs use this encoding, which 2033 allow for a larger range of possible values than the encoding used in 2034 HTTP/2. Some frames in HTTP/3 use an identifier rather than a Stream 2035 ID (e.g. Push IDs in PRIORITY frames). Redefinition of the encoding 2036 of extension frame types might be necessary if the encoding includes 2037 a Stream ID. 2039 Because the Flags field is not present in generic HTTP/3 frames, 2040 those frames which depend on the presence of flags need to allocate 2041 space for flags as part of their frame payload. 2043 Other than this issue, frame type HTTP/2 extensions are typically 2044 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2045 control stream in HTTP/3. HTTP/3 extensions will not assume 2046 ordering, but would not be harmed by ordering, and would be portable 2047 to HTTP/2 in the same manner. 2049 Below is a listing of how each HTTP/2 frame type is mapped: 2051 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2052 Section 4.2.1. 2054 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 2055 not supported. A separate PRIORITY frame MUST be used. Padding 2056 is not defined in HTTP/3 frames. See Section 4.2.2. 2058 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 2059 the control stream and can reference a variety of identifiers. 2060 See Section 4.2.3. 2062 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 2063 provides stream lifecycle management. The same code point is used 2064 for the CANCEL_PUSH frame (Section 4.2.4). 2066 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2067 the connection. See Section 4.2.5 and Appendix A.3. 2069 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 2070 instead the push stream references the PUSH_PROMISE frame using a 2071 Push ID. See Section 4.2.6. 2073 PING (0x6): PING frames do not exist, since QUIC provides equivalent 2074 functionality. 2076 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 2077 contain an error code. See Section 4.2.7. 2079 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 2080 provides flow control. 2082 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 2083 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. 2085 Frame types defined by extensions to HTTP/2 need to be separately 2086 registered for HTTP/3 if still applicable. The IDs of frames defined 2087 in [RFC7540] have been reserved for simplicity. See Section 10.3. 2089 A.3. HTTP/2 SETTINGS Parameters 2091 An important difference from HTTP/2 is that settings are sent once, 2092 at the beginning of the connection, and thereafter cannot change. 2093 This eliminates many corner cases around synchronization of changes. 2095 Some transport-level options that HTTP/2 specifies via the SETTINGS 2096 frame are superseded by QUIC transport parameters in HTTP/3. The 2097 HTTP-level options that are retained in HTTP/3 have the same value as 2098 in HTTP/2. 2100 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2102 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 2104 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 2105 which provides a more granular control over server push. 2107 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 2108 Stream ID as part of its flow control logic. Specifying 2109 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 2111 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 2112 connection flow control window sizes to be specified in the 2113 initial transport handshake. Specifying 2114 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 2116 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. 2117 Specifying it in the SETTINGS frame is an error. 2119 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.1. 2121 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2122 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2123 This will often produce a shorter encoding, but can produce a longer 2124 encoding for settings which use the full 32-bit space. Settings 2125 ported from HTTP/2 might choose to redefine the format of their 2126 settings to avoid using the 62-bit encoding. 2128 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2129 IDs of settings defined in [RFC7540] have been reserved for 2130 simplicity. See Section 10.4. 2132 A.4. HTTP/2 Error Codes 2134 QUIC has the same concepts of "stream" and "connection" errors that 2135 HTTP/2 provides. However, there is no direct portability of HTTP/2 2136 error codes. 2138 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 2139 HTTP/3 error codes as follows: 2141 NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1. 2143 PROTOCOL_ERROR (0x1): No single mapping. See new 2144 HTTP_MALFORMED_FRAME error codes defined in Section 8.1. 2146 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1. 2148 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2149 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 2150 from the QUIC layer. 2152 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2153 SETTINGS is defined. 2155 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2156 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 2157 from the QUIC layer. 2159 FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in 2160 Section 8.1. 2162 REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used 2163 to indicate that a request was not processed. Otherwise, not 2164 applicable because QUIC handles stream management. A 2165 STREAM_ID_ERROR at the QUIC layer is used for streams that are 2166 improperly opened. 2168 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. 2170 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2171 [QPACK]. 2173 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. 2175 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. 2177 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2178 provide sufficient security on all connections. 2180 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1. 2182 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2183 Section 10.5. 2185 Appendix B. Change Log 2187 *RFC Editor's Note:* Please remove this section prior to 2188 publication of a final version of this document. 2190 B.1. Since draft-ietf-quic-http-17 2192 o HTTP_REQUEST_REJECTED is used to indicate a request can be retried 2193 (#2106, #2325) 2195 o Changed error code for GOAWAY on the wrong stream (#2231, #2343) 2197 B.2. Since draft-ietf-quic-http-16 2199 o Rename "HTTP/QUIC" to "HTTP/3" (#1973) 2201 o Changes to PRIORITY frame (#1865, #2075) 2203 * Permitted as first frame of request streams 2205 * Remove exclusive reprioritization 2207 * Changes to Prioritized Element Type bits 2209 o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 2210 (#2072) 2212 o Set defaults for settings, allow request before receiving SETTINGS 2213 (#1809, #1846, #2038) 2215 o Clarify message processing rules for streams that aren't closed 2216 (#1972, #2003) 2218 o Removed reservation of error code 0 and moved HTTP_NO_ERROR to 2219 this value (#1922) 2221 o Removed prohibition of zero-length DATA frames (#2098) 2223 B.3. Since draft-ietf-quic-http-15 2225 Substantial editorial reorganization; no technical changes. 2227 B.4. Since draft-ietf-quic-http-14 2229 o Recommend sensible values for QUIC transport parameters 2230 (#1720,#1806) 2232 o Define error for missing SETTINGS frame (#1697,#1808) 2233 o Setting values are variable-length integers (#1556,#1807) and do 2234 not have separate maximum values (#1820) 2236 o Expanded discussion of connection closure (#1599,#1717,#1712) 2238 o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 2240 B.5. Since draft-ietf-quic-http-13 2242 o Reserved some frame types for grease (#1333, #1446) 2244 o Unknown unidirectional stream types are tolerated, not errors; 2245 some reserved for grease (#1490, #1525) 2247 o Require settings to be remembered for 0-RTT, prohibit reductions 2248 (#1541, #1641) 2250 o Specify behavior for truncated requests (#1596, #1643) 2252 B.6. Since draft-ietf-quic-http-12 2254 o TLS SNI extension isn't mandatory if an alternative method is used 2255 (#1459, #1462, #1466) 2257 o Removed flags from HTTP/3 frames (#1388, #1398) 2259 o Reserved frame types and settings for use in preserving 2260 extensibility (#1333, #1446) 2262 o Added general error code (#1391, #1397) 2264 o Unidirectional streams carry a type byte and are extensible 2265 (#910,#1359) 2267 o Priority mechanism now uses explicit placeholders to enable 2268 persistent structure in the tree (#441,#1421,#1422) 2270 B.7. Since draft-ietf-quic-http-11 2272 o Moved QPACK table updates and acknowledgments to dedicated streams 2273 (#1121, #1122, #1238) 2275 B.8. Since draft-ietf-quic-http-10 2277 o Settings need to be remembered when attempting and accepting 0-RTT 2278 (#1157, #1207) 2280 B.9. Since draft-ietf-quic-http-09 2282 o Selected QCRAM for header compression (#228, #1117) 2284 o The server_name TLS extension is now mandatory (#296, #495) 2286 o Specified handling of unsupported versions in Alt-Svc (#1093, 2287 #1097) 2289 B.10. Since draft-ietf-quic-http-08 2291 o Clarified connection coalescing rules (#940, #1024) 2293 B.11. Since draft-ietf-quic-http-07 2295 o Changes for integer encodings in QUIC (#595,#905) 2297 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 2299 o Improvement to the description of GOAWAY (#604, #898) 2301 o Improve description of server push usage (#947, #950, #957) 2303 B.12. Since draft-ietf-quic-http-06 2305 o Track changes in QUIC error code usage (#485) 2307 B.13. Since draft-ietf-quic-http-05 2309 o Made push ID sequential, add MAX_PUSH_ID, remove 2310 SETTINGS_ENABLE_PUSH (#709) 2312 o Guidance about keep-alive and QUIC PINGs (#729) 2314 o Expanded text on GOAWAY and cancellation (#757) 2316 B.14. Since draft-ietf-quic-http-04 2318 o Cite RFC 5234 (#404) 2320 o Return to a single stream per request (#245,#557) 2322 o Use separate frame type and settings registries from HTTP/2 (#81) 2324 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 2326 o Restored GOAWAY (#696) 2327 o Identify server push using Push ID rather than a stream ID 2328 (#702,#281) 2330 o DATA frames cannot be empty (#700) 2332 B.15. Since draft-ietf-quic-http-03 2334 None. 2336 B.16. Since draft-ietf-quic-http-02 2338 o Track changes in transport draft 2340 B.17. Since draft-ietf-quic-http-01 2342 o SETTINGS changes (#181): 2344 * SETTINGS can be sent only once at the start of a connection; no 2345 changes thereafter 2347 * SETTINGS_ACK removed 2349 * Settings can only occur in the SETTINGS frame a single time 2351 * Boolean format updated 2353 o Alt-Svc parameter changed from "v" to "quic"; format updated 2354 (#229) 2356 o Closing the connection control stream or any message control 2357 stream is a fatal error (#176) 2359 o HPACK Sequence counter can wrap (#173) 2361 o 0-RTT guidance added 2363 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 2364 added (#127,#242) 2366 B.18. Since draft-ietf-quic-http-00 2368 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 2370 o Changed from using HTTP/2 framing within Stream 3 to new framing 2371 format and two-stream-per-request model (#71,#72,#73) 2373 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 2374 settings-01 2376 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 2377 order (#75) 2379 o Described CONNECT pseudo-method (#95) 2381 o Updated ALPN token and Alt-Svc guidance (#13,#87) 2383 o Application-layer-defined error codes (#19,#74) 2385 B.19. Since draft-shade-quic-http2-mapping-00 2387 o Adopted as base for draft-ietf-quic-http 2389 o Updated authors/editors list 2391 Acknowledgements 2393 The original authors of this specification were Robbie Shade and Mike 2394 Warres. 2396 A substantial portion of Mike's contribution was supported by 2397 Microsoft during his employment there. 2399 Author's Address 2401 Mike Bishop (editor) 2402 Akamai 2404 Email: mbishop@evequefou.be