idnits 2.17.00 (12 Aug 2021) /tmp/idnits34119/draft-ietf-quic-http-20.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 (April 23, 2019) is 1123 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 2041 -- Looks like a reference, but probably isn't: '2' on line 2043 -- Looks like a reference, but probably isn't: '3' on line 2045 -- Looks like a reference, but probably isn't: '4' on line 2047 == Unused Reference: 'RFC7413' is defined on line 2035, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-08 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALTSVC'. Summary: 1 error (**), 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 April 23, 2019 5 Expires: October 25, 2019 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-20 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 October 25, 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 . . . . . . . . . . . . . . . . . . . 10 75 3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 10 76 3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 11 77 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11 78 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12 79 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13 80 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14 83 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 17 84 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 18 85 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 20 86 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 21 87 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 21 88 4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 22 89 4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 23 90 5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 23 91 5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 23 92 5.1.1. Header Formatting and Compression . . . . . . . . . . 25 93 5.1.2. Request Cancellation and Rejection . . . . . . . . . 25 95 5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 26 96 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 27 97 5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 28 98 5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 28 99 5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 29 100 6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 31 101 6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 31 102 6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 31 103 6.3. Immediate Application Closure . . . . . . . . . . . . . . 33 104 6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 33 105 7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 33 106 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 34 107 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 110 10.1. Registration of HTTP/3 Identification String . . . . . . 37 111 10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 37 112 10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37 113 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 38 114 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 39 115 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 42 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 43 118 11.2. Informative References . . . . . . . . . . . . . . . . . 44 119 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 120 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45 121 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45 122 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45 123 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48 124 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49 125 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50 126 B.1. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 50 127 B.2. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 50 128 B.3. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 50 129 B.4. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 51 130 B.5. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 51 131 B.6. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 51 132 B.7. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 52 133 B.8. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 52 134 B.9. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 52 135 B.10. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 52 136 B.11. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 52 137 B.12. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 53 138 B.13. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 53 139 B.14. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 53 140 B.15. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 53 141 B.16. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 53 142 B.17. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 54 143 B.18. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 54 144 B.19. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 54 145 B.20. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 54 146 B.21. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 55 147 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55 148 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55 150 1. Introduction 152 HTTP semantics are used for a broad range of services on the 153 Internet. These semantics have commonly been used with two different 154 TCP mappings, HTTP/1.1 and HTTP/2. HTTP/2 introduced a framing and 155 multiplexing layer to improve latency without modifying the transport 156 layer. However, TCP's lack of visibility into parallel requests in 157 both mappings limited the possible performance gains. 159 The QUIC transport protocol incorporates stream multiplexing and per- 160 stream flow control, similar to that provided by the HTTP/2 framing 161 layer. By providing reliability at the stream level and congestion 162 control across the entire connection, it has the capability to 163 improve the performance of HTTP compared to a TCP mapping. QUIC also 164 incorporates TLS 1.3 at the transport layer, offering comparable 165 security to running TLS over TCP, but with improved connection setup 166 latency (unless TCP Fast Open [RFC7413]} is used). 168 This document defines a mapping of HTTP semantics over the QUIC 169 transport protocol, drawing heavily on the design of HTTP/2. This 170 document identifies HTTP/2 features that are subsumed by QUIC, and 171 describes how the other features can be implemented atop QUIC. 173 QUIC is described in [QUIC-TRANSPORT]. For a full description of 174 HTTP/2, see [RFC7540]. 176 1.1. Notational Conventions 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 185 defined in [RFC5234]. 187 This document uses the variable-length integer encoding from 188 [QUIC-TRANSPORT]. 190 Protocol elements called "frames" exist in both this document and 191 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 192 the frame name will be prefaced with "QUIC." For example, "QUIC 193 CONNECTION_CLOSE frames." References without this preface refer to 194 frames defined in Section 4.2. 196 2. Connection Setup and Management 198 2.1. Draft Version Identification 200 *RFC Editor's Note:* Please remove this section prior to 201 publication of a final version of this document. 203 HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc. 204 Only implementations of the final, published RFC can identify 205 themselves as "h3". Until such an RFC exists, implementations MUST 206 NOT identify themselves using this string. 208 Implementations of draft versions of the protocol MUST add the string 209 "-" and the corresponding draft number to the identifier. For 210 example, draft-ietf-quic-http-01 is identified using the string 211 "h3-01". 213 Non-compatible experiments that are based on these draft versions 214 MUST append the string "-" and an experiment name to the identifier. 215 For example, an experimental implementation based on draft-ietf-quic- 216 http-09 which reserves an extra stream for unsolicited transmission 217 of 1980s pop music might identify itself as "h3-09-rickroll". Note 218 that any label MUST conform to the "token" syntax defined in 219 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 220 coordinate their experiments on the quic@ietf.org mailing list. 222 2.2. Discovering an HTTP/3 Endpoint 224 An HTTP origin advertises the availability of an equivalent HTTP/3 225 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 226 ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 2.3. 228 For example, an origin could indicate in an HTTP response that HTTP/3 229 was available on UDP port 50781 at the same hostname by including the 230 following header field: 232 Alt-Svc: h3=":50781" 234 On receipt of an Alt-Svc record indicating HTTP/3 support, a client 235 MAY attempt to establish a QUIC connection to the indicated host and 236 port and, if successful, send HTTP requests using the mapping 237 described in this document. 239 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 240 connection establishment failure, in which case the client SHOULD 241 continue using the existing connection or try another alternative 242 endpoint offered by the origin. 244 Servers MAY serve HTTP/3 on any UDP port, since an alternative always 245 includes an explicit port. 247 2.2.1. QUIC Version Hints 249 This document defines the "quic" parameter for Alt-Svc, which MAY be 250 used to provide version-negotiation hints to HTTP/3 clients. QUIC 251 versions are four-byte sequences with no additional constraints on 252 format. Leading zeros SHOULD be omitted for brevity. 254 Syntax: 256 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 257 version-number = 1*8HEXDIG; hex-encoded QUIC version 259 Where multiple versions are listed, the order of the values reflects 260 the server's preference (with the first value being the most 261 preferred version). Reserved versions MAY be listed, but unreserved 262 versions which are not supported by the alternative SHOULD NOT be 263 present in the list. Origins MAY omit supported versions for any 264 reason. 266 Clients MUST ignore any included versions which they do not support. 267 The "quic" parameter MUST NOT occur more than once; clients SHOULD 268 process only the first occurrence. 270 For example, suppose a server supported both version 0x00000001 and 271 the version rendered in ASCII as "Q034". If it also opted to include 272 the reserved version (from Section 15 of [QUIC-TRANSPORT]) 273 0x1abadaba, it could specify the following header field: 275 Alt-Svc: h3=":49288";quic="1,1abadaba,51303334" 277 A client acting on this header field would drop the reserved version 278 (not supported), then attempt to connect to the alternative using the 279 first version in the list which it does support, if any. 281 2.3. Connection Establishment 283 HTTP/3 relies on QUIC as the underlying transport. The QUIC version 284 being used MUST use TLS version 1.3 or greater as its handshake 285 protocol. HTTP/3 clients MUST indicate the target domain name during 286 the TLS handshake. This may be done using the Server Name Indication 287 (SNI) [RFC6066] extension to TLS or using some other mechanism. 289 QUIC connections are established as described in [QUIC-TRANSPORT]. 290 During connection establishment, HTTP/3 support is indicated by 291 selecting the ALPN token "h3" in the TLS handshake. Support for 292 other application-layer protocols MAY be offered in the same 293 handshake. 295 While connection-level options pertaining to the core QUIC protocol 296 are set in the initial crypto handshake, HTTP/3-specific settings are 297 conveyed in the SETTINGS frame. After the QUIC connection is 298 established, a SETTINGS frame (Section 4.2.5) MUST be sent by each 299 endpoint as the initial frame of their respective HTTP control stream 300 (see Section 3.2.1). 302 2.4. Connection Reuse 304 Once a connection exists to a server endpoint, this connection MAY be 305 reused for requests with multiple different URI authority components. 306 The client MAY send any requests for which the client considers the 307 server authoritative. 309 An authoritative HTTP/3 endpoint is typically discovered because the 310 client has received an Alt-Svc record from the request's origin which 311 nominates the endpoint as a valid HTTP Alternative Service for that 312 origin. As required by [RFC7838], clients MUST check that the 313 nominated server can present a valid certificate for the origin 314 before considering it authoritative. Clients MUST NOT assume that an 315 HTTP/3 endpoint is authoritative for other origins without an 316 explicit signal. 318 A server that does not wish clients to reuse connections for a 319 particular origin can indicate that it is not authoritative for a 320 request by sending a 421 (Misdirected Request) status code in 321 response to the request (see Section 9.1.2 of [RFC7540]). 323 The considerations discussed in Section 9.1 of [RFC7540] also apply 324 to the management of HTTP/3 connections. 326 3. Stream Mapping and Usage 328 A QUIC stream provides reliable in-order delivery of bytes, but makes 329 no guarantees about order of delivery with regard to bytes on other 330 streams. On the wire, data is framed into QUIC STREAM frames, but 331 this framing is invisible to the HTTP framing layer. The transport 332 layer buffers and orders received QUIC STREAM frames, exposing the 333 data contained within as a reliable byte stream to the application. 335 Although QUIC permits out-of-order delivery within a stream HTTP/3 336 does not make use of this feature. 338 QUIC streams can be either unidirectional, carrying data only from 339 initiator to receiver, or bidirectional. Streams can be initiated by 340 either the client or the server. For more detail on QUIC streams, 341 see Section 2 of [QUIC-TRANSPORT]. 343 When HTTP headers and data are sent over QUIC, the QUIC layer handles 344 most of the stream management. HTTP does not need to do any separate 345 multiplexing when using QUIC - data sent over a QUIC stream always 346 maps to a particular HTTP transaction or connection context. 348 3.1. Bidirectional Streams 350 All client-initiated bidirectional streams are used for HTTP requests 351 and responses. A bidirectional stream ensures that the response can 352 be readily correlated with the request. This means that the client's 353 first request occurs on QUIC stream 0, with subsequent requests on 354 stream 4, 8, and so on. In order to permit these streams to open, an 355 HTTP/3 client SHOULD send non-zero values for the QUIC transport 356 parameters "initial_max_stream_data_bidi_local". An HTTP/3 server 357 SHOULD send non-zero values for the QUIC transport parameters 358 "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". 359 It is recommended that "initial_max_bidi_streams" be no smaller than 360 100, so as to not unnecessarily limit parallelism. 362 These streams carry frames related to the request/response (see 363 Section 5.1). When a stream terminates cleanly, if the last frame on 364 the stream was truncated, this MUST be treated as a connection error 365 (see HTTP_MALFORMED_FRAME in Section 8.1). Streams which terminate 366 abruptly may be reset at any point in the frame. 368 HTTP/3 does not use server-initiated bidirectional streams; clients 369 MUST omit or specify a value of zero for the QUIC transport parameter 370 "initial_max_bidi_streams". 372 3.2. Unidirectional Streams 374 Unidirectional streams, in either direction, are used for a range of 375 purposes. The purpose is indicated by a stream type, which is sent 376 as a variable-length integer at the start of the stream. The format 377 and structure of data that follows this integer is determined by the 378 stream type. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Stream Type (i) ... 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 1: Unidirectional Stream Header 388 Some stream types are reserved (Section 3.2.3). Two stream types are 389 defined in this document: control streams (Section 3.2.1) and push 390 streams (Section 3.2.2). Other stream types can be defined by 391 extensions to HTTP/3; see Section 7 for more details. 393 The performance of HTTP/3 connections in the early phase of their 394 lifetime is sensitive to the creation and exchange of data on 395 unidirectional streams. Endpoints that set low values for the QUIC 396 transport parameters "initial_max_uni_streams" and 397 "initial_max_stream_data_uni" will increase the chance that the 398 remote peer reaches the limit early and becomes blocked. In 399 particular, the value chosen for "initial_max_uni_streams" should 400 consider that remote peers may wish to exercise reserved stream 401 behaviour (Section 3.2.3). To reduce the likelihood of blocking, 402 both clients and servers SHOULD send a value of three or greater for 403 the QUIC transport parameter "initial_max_uni_streams", and a value 404 of 1,024 or greater for the QUIC transport parameter 405 "initial_max_stream_data_uni". 407 If the stream header indicates a stream type which is not supported 408 by the recipient, the remainder of the stream cannot be consumed as 409 the semantics are unknown. Recipients of unknown stream types MAY 410 trigger a QUIC STOP_SENDING frame with an error code of 411 HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an 412 error of any kind. 414 Implementations MAY send stream types before knowing whether the peer 415 supports them. However, stream types which could modify the state or 416 semantics of existing protocol components, including QPACK or other 417 extensions, MUST NOT be sent until the peer is known to support them. 419 A sender can close or reset a unidirectional stream unless otherwise 420 specified. A receiver MUST tolerate unidirectional streams being 421 closed or reset prior to the reception of the unidirectional stream 422 header. 424 3.2.1. Control Streams 426 A control stream is indicated by a stream type of "0x00". Data on 427 this stream consists of HTTP/3 frames, as defined in Section 4.2. 429 Each side MUST initiate a single control stream at the beginning of 430 the connection and send its SETTINGS frame as the first frame on this 431 stream. If the first frame of the control stream is any other frame 432 type, this MUST be treated as a connection error of type 433 HTTP_MISSING_SETTINGS. Only one control stream per peer is 434 permitted; receipt of a second stream which claims to be a control 435 stream MUST be treated as a connection error of type 436 HTTP_WRONG_STREAM_COUNT. The sender MUST NOT close the control 437 stream. If the control stream is closed at any point, this MUST be 438 treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. 440 A pair of unidirectional streams is used rather than a single 441 bidirectional stream. This allows either peer to send data as soon 442 they are able. Depending on whether 0-RTT is enabled on the 443 connection, either client or server might be able to send stream data 444 first after the cryptographic handshake completes. 446 3.2.2. Push Streams 448 A push stream is indicated by a stream type of "0x01", followed by 449 the Push ID of the promise that it fulfills, encoded as a variable- 450 length integer. The remaining data on this stream consists of HTTP/3 451 frames, as defined in Section 4.2, and fulfills a promised server 452 push. Server push and Push IDs are described in Section 5.4. 454 Only servers can push; if a server receives a client-initiated push 455 stream, this MUST be treated as a stream error of type 456 HTTP_WRONG_STREAM_DIRECTION. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | 0x01 (i) ... 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Push ID (i) ... 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 2: Push Stream Header 468 Each Push ID MUST only be used once in a push stream header. If a 469 push stream header includes a Push ID that was used in another push 470 stream header, the client MUST treat this as a connection error of 471 type HTTP_DUPLICATE_PUSH. 473 3.2.3. Reserved Stream Types 475 Stream types of the format "0x1f * N + 0x21" for integer values of N 476 are reserved to exercise the requirement that unknown types be 477 ignored. These streams have no semantics, and can be sent when 478 application-layer padding is desired. They MAY also be sent on 479 connections where no data is currently being transferred. Endpoints 480 MUST NOT consider these streams to have any meaning upon receipt. 482 The payload and length of the stream are selected in any manner the 483 implementation chooses. 485 4. HTTP Framing Layer 487 HTTP frames are carried on QUIC streams, as described in Section 3. 488 HTTP/3 defines three stream types: control stream, request stream, 489 and push stream. This section describes HTTP/3 frame formats and the 490 streams types on which they are permitted; see Table 1 for an 491 overiew. A comparison between HTTP/2 and HTTP/3 frames is provided 492 in Appendix A.2. 494 +----------------+------------+------------+-----------+------------+ 495 | Frame | Control | Request | Push | Section | 496 | | Stream | Stream | Stream | | 497 +----------------+------------+------------+-----------+------------+ 498 | DATA | No | Yes | Yes | Section | 499 | | | | | 4.2.1 | 500 | | | | | | 501 | HEADERS | No | Yes | Yes | Section | 502 | | | | | 4.2.2 | 503 | | | | | | 504 | PRIORITY | Yes | Yes (1) | No | Section | 505 | | | | | 4.2.3 | 506 | | | | | | 507 | CANCEL_PUSH | Yes | No | No | Section | 508 | | | | | 4.2.4 | 509 | | | | | | 510 | SETTINGS | Yes (1) | No | No | Section | 511 | | | | | 4.2.5 | 512 | | | | | | 513 | PUSH_PROMISE | No | Yes | No | Section | 514 | | | | | 4.2.6 | 515 | | | | | | 516 | GOAWAY | Yes | No | No | Section | 517 | | | | | 4.2.7 | 518 | | | | | | 519 | MAX_PUSH_ID | Yes | No | No | Section | 520 | | | | | 4.2.8 | 521 | | | | | | 522 | DUPLICATE_PUSH | No | Yes | No | Section | 523 | | | | | 4.2.9 | 524 +----------------+------------+------------+-----------+------------+ 526 Table 1: HTTP/3 frames and stream type overview 528 Certain frames can only occur as the first frame of a particular 529 stream type; these are indicated in Table 1 with a (1). Specific 530 guidance is provided in the relevant section. 532 4.1. Frame Layout 534 All frames have the following format: 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type (i) ... 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Length (i) ... 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Frame Payload (*) ... 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 3: HTTP/3 frame format 548 A frame includes the following fields: 550 Type: A variable-length integer that identifies the frame type. 552 Length: A variable-length integer that describes the length of the 553 Frame Payload. 555 Frame Payload: A payload, the semantics of which are determined by 556 the Type field. 558 Each frame's payload MUST contain exactly the fields identified in 559 its description. A frame payload that contains additional bytes 560 after the identified fields or a frame payload that terminates before 561 the end of the identified fields MUST be treated as a connection 562 error of type HTTP_MALFORMED_FRAME. 564 4.2. Frame Definitions 566 4.2.1. DATA 568 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 569 bytes associated with an HTTP request or response payload. 571 DATA frames MUST be associated with an HTTP request or response. If 572 a DATA frame is received on either control stream, the recipient MUST 573 respond with a connection error (Section 8) of type 574 HTTP_WRONG_STREAM. 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Payload (*) ... 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 4: DATA frame payload 584 4.2.2. HEADERS 586 The HEADERS frame (type=0x1) is used to carry a header block, 587 compressed using QPACK. See [QPACK] for more details. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Header Block (*) ... 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 5: HEADERS frame payload 597 HEADERS frames can only be sent on request / push streams. 599 4.2.3. PRIORITY 601 The PRIORITY (type=0x2) frame specifies the client-advised priority 602 of a request, server push or placeholder. 604 A PRIORITY frame identifies an element to prioritize, and an element 605 upon which it depends. A Prioritized ID or Dependency ID identifies 606 a client-initiated request using the corresponding stream ID, a 607 server push using a Push ID (see Section 4.2.6), or a placeholder 608 using a Placeholder ID (see Section 5.3.1). 610 When a client initiates a request, a PRIORITY frame MAY be sent as 611 the first frame of the stream, creating a dependency on an existing 612 element. In order to ensure that prioritization is processed in a 613 consistent order, any subsequent PRIORITY frames for that request 614 MUST be sent on the control stream. A PRIORITY frame received after 615 other frames on a request stream MUST be treated as a stream error of 616 type HTTP_UNEXPECTED_FRAME. 618 If, by the time a new request stream is opened, its priority 619 information has already been received via the control stream, the 620 PRIORITY frame sent on the request stream MUST be ignored. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |PT |DT | Empty | [Prioritized Element ID (i)] ... 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | [Element Dependency ID (i)] ... 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Weight (8) | 630 +-+-+-+-+-+-+-+-+ 632 Figure 6: PRIORITY frame payload 634 The PRIORITY frame payload has the following fields: 636 PT (Prioritized Element Type): A two-bit field indicating the type 637 of element being prioritized (see Table 2). When sent on a 638 request stream, this MUST be set to "11". When sent on the 639 control stream, this MUST NOT be set to "11". 641 DT (Element Dependency Type): A two-bit field indicating the type of 642 element being depended on (see Table 3). 644 Empty: A four-bit field which MUST be zero when sent and has no 645 semantic value on receipt. 647 Prioritized Element ID: A variable-length integer that identifies 648 the element being prioritized. Depending on the value of 649 Prioritized Type, this contains the Stream ID of a request stream, 650 the Push ID of a promised resource, a Placeholder ID of a 651 placeholder, or is absent. 653 Element Dependency ID: A variable-length integer that identifies the 654 element on which a dependency is being expressed. Depending on 655 the value of Dependency Type, this contains the Stream ID of a 656 request stream, the Push ID of a promised resource, the 657 Placeholder ID of a placeholder, or is absent. For details of 658 dependencies, see Section 5.3 and [RFC7540], Section 5.3. 660 Weight: An unsigned 8-bit integer representing a priority weight for 661 the prioritized element (see [RFC7540], Section 5.3). Add one to 662 the value to obtain a weight between 1 and 256. 664 The values for the Prioritized Element Type (Table 2) and Element 665 Dependency Type (Table 3) imply the interpretation of the associated 666 Element ID fields. 668 +---------+------------------+---------------------------------+ 669 | PT Bits | Type Description | Prioritized Element ID Contents | 670 +---------+------------------+---------------------------------+ 671 | 00 | Request stream | Stream ID | 672 | | | | 673 | 01 | Push stream | Push ID | 674 | | | | 675 | 10 | Placeholder | Placeholder ID | 676 | | | | 677 | 11 | Current stream | Absent | 678 +---------+------------------+---------------------------------+ 680 Table 2: Prioritized Element Types 682 +---------+------------------+--------------------------------+ 683 | DT Bits | Type Description | Element Dependency ID Contents | 684 +---------+------------------+--------------------------------+ 685 | 00 | Request stream | Stream ID | 686 | | | | 687 | 01 | Push stream | Push ID | 688 | | | | 689 | 10 | Placeholder | Placeholder ID | 690 | | | | 691 | 11 | Root of the tree | Absent | 692 +---------+------------------+--------------------------------+ 694 Table 3: Element Dependency Types 696 Note that unlike in [RFC7540], the root of the tree cannot be 697 referenced using a Stream ID of 0, as in QUIC stream 0 carries a 698 valid HTTP request. The root of the tree cannot be reprioritized. A 699 PRIORITY frame sent on a request stream with the Prioritized Element 700 Type set to any value other than "11" or which expresses a dependency 701 on a request with a greater Stream ID than the current stream MUST be 702 treated as a stream error of type HTTP_MALFORMED_FRAME. Likewise, a 703 PRIORITY frame sent on a control stream with the Prioritized Element 704 Type set to "11" MUST be treated as a connection error of type 705 HTTP_MALFORMED_FRAME. A PRIORITY frame with Empty bits not set to 706 zero MAY be treated as a connection error of type 707 HTTP_MALFORMED_FRAME. 709 When a PRIORITY frame claims to reference a request, the associated 710 ID MUST identify a client-initiated bidirectional stream. A server 711 MUST treat receipt of a PRIORITY frame identifying a stream of any 712 other type as a connection error of type HTTP_MALFORMED_FRAME. 714 A PRIORITY frame that references a non-existent Push ID, a 715 Placeholder ID greater than the server's limit, or a Stream ID the 716 client is not yet permitted to open MUST be treated as an 717 HTTP_LIMIT_EXCEEDED error. 719 A PRIORITY frame received on any stream other than a request or 720 control stream MUST be treated as a connection error of type 721 HTTP_WRONG_STREAM. 723 PRIORITY frames received by a client MUST be treated as a connection 724 error of type HTTP_UNEXPECTED_FRAME. 726 4.2.4. CANCEL_PUSH 728 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 729 server push prior to the push stream being received. The CANCEL_PUSH 730 frame identifies a server push by Push ID (see Section 4.2.6), 731 encoded as a variable-length integer. 733 When a server receives this frame, it aborts sending the response for 734 the identified server push. If the server has not yet started to 735 send the server push, it can use the receipt of a CANCEL_PUSH frame 736 to avoid opening a push stream. If the push stream has been opened 737 by the server, the server SHOULD send a QUIC RESET_STREAM frame on 738 that stream and cease transmission of the response. 740 A server can send the CANCEL_PUSH frame to indicate that it will not 741 be fulfilling a promise prior to creation of a push stream. Once the 742 push stream has been created, sending CANCEL_PUSH has no effect on 743 the state of the push stream. A QUIC RESET_STREAM frame SHOULD be 744 used instead to abort transmission of the server push response. 746 A CANCEL_PUSH frame is sent on the control stream. Receiving a 747 CANCEL_PUSH frame on a stream other than the control stream MUST be 748 treated as a stream error of type HTTP_WRONG_STREAM. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Push ID (i) ... 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Figure 7: CANCEL_PUSH frame payload 758 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 759 integer. The Push ID identifies the server push that is being 760 cancelled (see Section 4.2.6). 762 If the client receives a CANCEL_PUSH frame, that frame might identify 763 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 765 4.2.5. SETTINGS 767 The SETTINGS frame (type=0x4) conveys configuration parameters that 768 affect how endpoints communicate, such as preferences and constraints 769 on peer behavior. Individually, a SETTINGS parameter can also be 770 referred to as a "setting"; the identifier and value of each setting 771 parameter can be referred to as a "setting identifier" and a "setting 772 value". 774 SETTINGS frames always apply to a connection, never a single stream. 775 A SETTINGS frame MUST be sent as the first frame of each control 776 stream (see Section 3.2.1) by each peer, and MUST NOT be sent 777 subsequently or on any other stream. If an endpoint receives a 778 SETTINGS frame on a different stream, the endpoint MUST respond with 779 a connection error of type HTTP_WRONG_STREAM. If an endpoint 780 receives a second SETTINGS frame, the endpoint MUST respond with a 781 connection error of type HTTP_UNEXPECTED_FRAME. 783 SETTINGS parameters are not negotiated; they describe characteristics 784 of the sending peer, which can be used by the receiving peer. 785 However, a negotiation can be implied by the use of SETTINGS - each 786 peer uses SETTINGS to advertise a set of supported values. The 787 definition of the setting would describe how each peer combines the 788 two sets to conclude which choice will be used. SETTINGS does not 789 provide a mechanism to identify when the choice takes effect. 791 Different values for the same parameter can be advertised by each 792 peer. For example, a client might be willing to consume a very large 793 response header, while servers are more cautious about request size. 795 Parameters MUST NOT occur more than once in the SETTINGS frame. A 796 receiver MAY treat the presence of the same parameter more than once 797 as a connection error of type HTTP_MALFORMED_FRAME. 799 The payload of a SETTINGS frame consists of zero or more parameters. 800 Each parameter consists of a setting identifier and a value, both 801 encoded as QUIC variable-length integers. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Identifier (i) ... 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Value (i) ... 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 Figure 8: SETTINGS parameter format 813 An implementation MUST ignore the contents for any SETTINGS 814 identifier it does not understand. 816 4.2.5.1. Defined SETTINGS Parameters 818 The following settings are defined in HTTP/3: 820 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. 821 See Section 5.1.1 for usage. 823 SETTINGS_NUM_PLACEHOLDERS (0x9): The default value is 0. However, 824 this value SHOULD be set to a non-zero value by servers. See 825 Section 5.3.1 for usage. 827 Setting identifiers of the format "0x1f * N + 0x21" for integer 828 values of N are reserved to exercise the requirement that unknown 829 identifiers be ignored. Such settings have no defined meaning. 830 Endpoints SHOULD include at least one such setting in their SETTINGS 831 frame. Endpoints MUST NOT consider such settings to have any meaning 832 upon receipt. 834 Because the setting has no defined meaning, the value of the setting 835 can be any value the implementation selects. 837 Additional settings can be defined by extensions to HTTP/3; see 838 Section 7 for more details. 840 4.2.5.2. Initialization 842 An HTTP implementation MUST NOT send frames or requests which would 843 be invalid based on its current understanding of the peer's settings. 844 All settings begin at an initial value, and are updated upon receipt 845 of a SETTINGS frame. For servers, the initial value of each client 846 setting is the default value. 848 For clients using a 1-RTT QUIC connection, the initial value of each 849 server setting is the default value. When a 0-RTT QUIC connection is 850 being used, the initial value of each server setting is the value 851 used in the previous session. Clients MUST store the settings the 852 server provided in the session being resumed and MUST comply with 853 stored settings until the current server settings are received. 855 A server can remember the settings that it advertised, or store an 856 integrity-protected copy of the values in the ticket and recover the 857 information when accepting 0-RTT data. A server uses the HTTP/3 858 settings values in determining whether to accept 0-RTT data. 860 A server MAY accept 0-RTT and subsequently provide different settings 861 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 862 SETTINGS frame MUST NOT reduce any limits or alter any values that 863 might be violated by the client with its 0-RTT data. 865 4.2.6. PUSH_PROMISE 867 The PUSH_PROMISE frame (type=0x5) is used to carry a promised request 868 header set from server to client on a request stream, as in HTTP/2. 870 0 1 2 3 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Push ID (i) ... 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Header Block (*) ... 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Figure 9: PUSH_PROMISE frame payload 880 The payload consists of: 882 Push ID: A variable-length integer that identifies the server push 883 operation. A Push ID is used in push stream headers 884 (Section 5.4), CANCEL_PUSH frames (Section 4.2.4), DUPLICATE_PUSH 885 frames (Section 4.2.9), and PRIORITY frames (Section 4.2.3). 887 Header Block: QPACK-compressed request header fields for the 888 promised response. See [QPACK] for more details. 890 A server MUST NOT use a Push ID that is larger than the client has 891 provided in a MAX_PUSH_ID frame (Section 4.2.8) and MUST NOT use the 892 same Push ID in multiple PUSH_PROMISE frames. A client MUST treat 893 receipt of a PUSH_PROMISE that contains a larger Push ID than the 894 client has advertised or a Push ID which has already been promised as 895 a connection error of type HTTP_MALFORMED_FRAME. 897 If a PUSH_PROMISE frame is received on either control stream, the 898 recipient MUST respond with a connection error (Section 8) of type 899 HTTP_WRONG_STREAM. 901 See Section 5.4 for a description of the overall server push 902 mechanism. 904 4.2.7. GOAWAY 906 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 907 a connection by a server. GOAWAY allows a server to stop accepting 908 new requests while still finishing processing of previously received 909 requests. This enables administrative actions, like server 910 maintenance. GOAWAY by itself does not close a connection. 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Stream ID (i) ... 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Figure 10: GOAWAY frame payload 920 The GOAWAY frame is always sent on the control stream. It carries a 921 QUIC Stream ID for a client-initiated bidirectional stream encoded as 922 a variable-length integer. A client MUST treat receipt of a GOAWAY 923 frame containing a Stream ID of any other type as a connection error 924 of type HTTP_WRONG_STREAM. 926 Clients do not need to send GOAWAY to initiate a graceful shutdown; 927 they simply stop making new requests. A server MUST treat receipt of 928 a GOAWAY frame on any stream as a connection error (Section 8) of 929 type HTTP_UNEXPECTED_FRAME. 931 The GOAWAY frame applies to the connection, not a specific stream. A 932 client MUST treat a GOAWAY frame on a stream other than the control 933 stream as a connection error (Section 8) of type 934 HTTP_UNEXPECTED_FRAME. 936 See Section 6.2 for more information on the use of the GOAWAY frame. 938 4.2.8. MAX_PUSH_ID 940 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 941 number of server pushes that the server can initiate. This sets the 942 maximum value for a Push ID that the server can use in a PUSH_PROMISE 943 frame. Consequently, this also limits the number of push streams 944 that the server can initiate in addition to the limit set by the QUIC 945 MAX_STREAMS frame. 947 The MAX_PUSH_ID frame is always sent on the control stream. Receipt 948 of a MAX_PUSH_ID frame on any other stream MUST be treated as a 949 connection error of type HTTP_WRONG_STREAM. 951 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 952 receipt of a MAX_PUSH_ID frame as a connection error of type 953 HTTP_UNEXPECTED_FRAME. 955 The maximum Push ID is unset when a connection is created, meaning 956 that a server cannot push until it receives a MAX_PUSH_ID frame. A 957 client that wishes to manage the number of promised server pushes can 958 increase the maximum Push ID by sending MAX_PUSH_ID frames as the 959 server fulfills or cancels server pushes. 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Push ID (i) ... 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 11: MAX_PUSH_ID frame payload 969 The MAX_PUSH_ID frame carries a single variable-length integer that 970 identifies the maximum value for a Push ID that the server can use 971 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 972 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 973 previously received MUST be treated as a connection error of type 974 HTTP_MALFORMED_FRAME. 976 4.2.9. DUPLICATE_PUSH 978 The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate 979 that an existing pushed resource is related to multiple client 980 requests. 982 The DUPLICATE_PUSH frame is always sent on a request stream. Receipt 983 of a DUPLICATE_PUSH frame on any other stream MUST be treated as a 984 connection error of type HTTP_WRONG_STREAM. 986 A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat 987 the receipt of a DUPLICATE_PUSH frame as a connection error of type 988 HTTP_UNEXPECTED_FRAME. 990 0 1 2 3 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Push ID (i) ... 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Figure 12: DUPLICATE_PUSH frame payload 998 The DUPLICATE_PUSH frame carries a single variable-length integer 999 that identifies the Push ID of a resource that the server has 1000 previously promised (see Section 4.2.6). 1002 This frame allows the server to use the same server push in response 1003 to multiple concurrent requests. Referencing the same server push 1004 ensures that a promise can be made in relation to every response in 1005 which server push might be needed without duplicating request headers 1006 or pushed responses. 1008 Allowing duplicate references to the same Push ID is primarily to 1009 reduce duplication caused by concurrent requests. A server SHOULD 1010 avoid reusing a Push ID over a long period. Clients are likely to 1011 consume server push responses and not retain them for reuse over 1012 time. Clients that see a DUPLICATE_PUSH that uses a Push ID that 1013 they have since consumed and discarded are forced to ignore the 1014 DUPLICATE_PUSH. 1016 4.2.10. Reserved Frame Types 1018 Frame types of the format "0x1f * N + 0x21" for integer values of N 1019 are reserved to exercise the requirement that unknown types be 1020 ignored (Section 7). These frames have no semantics, and can be sent 1021 when application-layer padding is desired. They MAY also be sent on 1022 connections where no data is currently being transferred. Endpoints 1023 MUST NOT consider these frames to have any meaning upon receipt. 1025 The payload and length of the frames are selected in any manner the 1026 implementation chooses. 1028 5. HTTP Request Lifecycle 1030 5.1. HTTP Message Exchanges 1032 A client sends an HTTP request on a client-initiated bidirectional 1033 QUIC stream. A client MUST send only a single request on a given 1034 stream. A server sends one or more HTTP responses on the same stream 1035 as the request, as detailed below. 1037 An HTTP message (request or response) consists of: 1039 1. the message header (see [RFC7230], Section 3.2), sent as a single 1040 HEADERS frame (see Section 4.2.2), 1042 2. the payload body (see [RFC7230], Section 3.3), sent as a series 1043 of DATA frames (see Section 4.2.1), 1045 3. optionally, one HEADERS frame containing the trailer-part, if 1046 present (see [RFC7230], Section 4.1.2). 1048 A server MAY interleave one or more PUSH_PROMISE frames (see 1049 Section 4.2.6) with the frames of a response message. These 1050 PUSH_PROMISE frames are not part of the response; see Section 5.4 for 1051 more details. 1053 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 1054 MUST NOT be used. 1056 Trailing header fields are carried in an additional HEADERS frame 1057 following the body. Senders MUST send only one HEADERS frame in the 1058 trailers section; receivers MUST discard any subsequent HEADERS 1059 frames. 1061 A response MAY consist of multiple messages when and only when one or 1062 more informational responses (1xx, see [RFC7231], Section 6.2) 1063 precede a final response to the same request. Non-final responses do 1064 not contain a payload body or trailers. 1066 An HTTP request/response exchange fully consumes a bidirectional QUIC 1067 stream. After sending a request, a client MUST close the stream for 1068 sending. Unless using the CONNECT method (see Section 5.2), clients 1069 MUST NOT make stream closure dependent on receiving a response to 1070 their request. After sending a final response, the server MUST close 1071 the stream for sending. At this point, the QUIC stream is fully 1072 closed. 1074 When a stream is closed, this indicates the end of an HTTP message. 1075 Because some messages are large or unbounded, endpoints SHOULD begin 1076 processing partial HTTP messages once enough of the message has been 1077 received to make progress. If a client stream terminates without 1078 enough of the HTTP message to provide a complete response, the server 1079 SHOULD abort its response with the error code 1080 HTTP_INCOMPLETE_REQUEST. 1082 A server can send a complete response prior to the client sending an 1083 entire request if the response does not depend on any portion of the 1084 request that has not been sent and received. When this is true, a 1085 server MAY request that the client abort transmission of a request 1086 without error by triggering a QUIC STOP_SENDING frame with error code 1087 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 1088 its stream. Clients MUST NOT discard complete responses as a result 1089 of having their request terminated abruptly, though clients can 1090 always discard responses at their discretion for other reasons. 1092 5.1.1. Header Formatting and Compression 1094 HTTP message headers carry information as a series of key-value 1095 pairs, called header fields. For a listing of registered HTTP header 1096 fields, see the "Message Header Field" registry maintained at 1097 https://www.iana.org/assignments/message-headers [4]. 1099 Just as in previous versions of HTTP, header field names are strings 1100 of ASCII characters that are compared in a case-insensitive fashion. 1101 Properties of HTTP header field names and values are discussed in 1102 more detail in Section 3.2 of [RFC7230], though the wire rendering in 1103 HTTP/3 differs. As in HTTP/2, header field names MUST be converted 1104 to lowercase prior to their encoding. A request or response 1105 containing uppercase header field names MUST be treated as malformed. 1107 As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with 1108 the ':' character (ASCII 0x3a) to convey the target URI, the method 1109 of the request, and the status code for the response. These pseudo- 1110 header fields are defined in Section 8.1.2.3 and 8.1.2.4 of 1111 [RFC7540]. Pseudo-header fields are not HTTP header fields. 1112 Endpoints MUST NOT generate pseudo-header fields other than those 1113 defined in [RFC7540]. The restrictions on the use of pseudo-header 1114 fields in Section 8.1.2.1 of [RFC7540] also apply to HTTP/3. 1116 HTTP/3 uses QPACK header compression as described in [QPACK], a 1117 variation of HPACK which allows the flexibility to avoid header- 1118 compression-induced head-of-line blocking. See that document for 1119 additional details. 1121 An HTTP/3 implementation MAY impose a limit on the maximum size of 1122 the header it will accept on an individual HTTP message; encountering 1123 a larger message header SHOULD be treated as a stream error of type 1124 "HTTP_EXCESSIVE_LOAD". If an implementation wishes to advise its 1125 peer of this limit, it can be conveyed as a number of bytes in the 1126 "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. The size of a header list 1127 is calculated based on the uncompressed size of header fields, 1128 including the length of the name and value in bytes plus an overhead 1129 of 32 bytes for each header field. 1131 5.1.2. Request Cancellation and Rejection 1133 Clients can cancel requests by aborting the stream (QUIC RESET_STREAM 1134 and/or STOP_SENDING frames, as appropriate) with an error code of 1135 HTTP_REQUEST_CANCELLED (Section 8.1). When the client cancels a 1136 response, it indicates that this response is no longer of interest. 1137 Implementations SHOULD cancel requests by aborting both directions of 1138 a stream. 1140 When the server rejects a request without performing any application 1141 processing, it SHOULD abort its response stream with the error code 1142 HTTP_REQUEST_REJECTED. In this context, "processed" means that some 1143 data from the stream was passed to some higher layer of software that 1144 might have taken some action as a result. The client can treat 1145 requests rejected by the server as though they had never been sent at 1146 all, thereby allowing them to be retried later on a new connection. 1147 Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for 1148 requests which were partially or fully processed. When a server 1149 abandons a response after partial processing, it SHOULD abort its 1150 response stream with the error code HTTP_REQUEST_CANCELLED. 1152 When a client sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a 1153 server MAY send the error code HTTP_REQUEST_REJECTED in the 1154 corresponding RESET_STREAM if no processing was performed. Clients 1155 MUST NOT reset streams with the HTTP_REQUEST_REJECTED error code 1156 except in response to a QUIC STOP_SENDING frame that contains the 1157 same code. 1159 If a stream is cancelled after receiving a complete response, the 1160 client MAY ignore the cancellation and use the response. However, if 1161 a stream is cancelled after receiving a partial response, the 1162 response SHOULD NOT be used. Automatically retrying such requests is 1163 not possible, unless this is otherwise permitted (e.g., idempotent 1164 actions like GET, PUT, or DELETE). 1166 5.2. The CONNECT Method 1168 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 1169 used with HTTP proxies to establish a TLS session with an origin 1170 server for the purposes of interacting with "https" resources. In 1171 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 1172 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 1173 establish a tunnel over a single HTTP/2 stream to a remote host for 1174 similar purposes. 1176 A CONNECT request in HTTP/3 functions in the same manner as in 1177 HTTP/2. The request MUST be formatted as described in [RFC7540], 1178 Section 8.3. A CONNECT request that does not conform to these 1179 restrictions is malformed. The request stream MUST NOT be closed at 1180 the end of the request. 1182 A proxy that supports CONNECT establishes a TCP connection 1183 ([RFC0793]) to the server identified in the ":authority" pseudo- 1184 header field. Once this connection is successfully established, the 1185 proxy sends a HEADERS frame containing a 2xx series status code to 1186 the client, as defined in [RFC7231], Section 4.3.6. 1188 All DATA frames on the stream correspond to data sent or received on 1189 the TCP connection. Any DATA frame sent by the client is transmitted 1190 by the proxy to the TCP server; data received from the TCP server is 1191 packaged into DATA frames by the proxy. Note that the size and 1192 number of TCP segments is not guaranteed to map predictably to the 1193 size and number of HTTP DATA or QUIC STREAM frames. 1195 The TCP connection can be closed by either peer. When the client 1196 ends the request stream (that is, the receive stream at the proxy 1197 enters the "Data Recvd" state), the proxy will set the FIN bit on its 1198 connection to the TCP server. When the proxy receives a packet with 1199 the FIN bit set, it will terminate the send stream that it sends to 1200 the client. TCP connections which remain half-closed in a single 1201 direction are not invalid, but are often handled poorly by servers, 1202 so clients SHOULD NOT close a stream for sending while they still 1203 expect to receive data from the target of the CONNECT. 1205 A TCP connection error is signaled with QUIC RESET_STREAM frame. A 1206 proxy treats any error in the TCP connection, which includes 1207 receiving a TCP segment with the RST bit set, as a stream error of 1208 type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, a proxy MUST 1209 send a TCP segment with the RST bit set if it detects an error with 1210 the stream or the QUIC connection. 1212 5.3. Prioritization 1214 HTTP/3 uses a priority scheme similar to that described in [RFC7540], 1215 Section 5.3. In this priority scheme, a given element can be 1216 designated as dependent upon another element. This information is 1217 expressed in the PRIORITY frame Section 4.2.3 which identifies the 1218 element and the dependency. The elements that can be prioritized 1219 are: 1221 o Requests, identified by the ID of the request stream 1223 o Pushes, identified by the Push ID of the promised resource 1224 (Section 4.2.6) 1226 o Placeholders, identified by a Placeholder ID 1228 Taken together, the dependencies across all prioritized elements in a 1229 connection form a dependency tree. An element can depend on another 1230 element or on the root of the tree. A reference to an element which 1231 is no longer in the tree is treated as a reference to the root of the 1232 tree. The structure of the dependency tree changes as PRIORITY 1233 frames modify the dependency links between prioritized elements. 1235 Due to reordering between streams, an element can also be prioritized 1236 which is not yet in the tree. Such elements are added to the tree 1237 with the requested priority. 1239 When a prioritized element is first created, it has a default initial 1240 weight of 16 and a default dependency. Requests and placeholders are 1241 dependent on the root of the priority tree; pushes are dependent on 1242 the client request on which the PUSH_PROMISE frame was sent. 1244 Requests may override the default initial values by including a 1245 PRIORTIY frame (see Section 4.2.3) at the beginning of the stream. 1246 These priorities can be updated by sending a PRIORITY frame on the 1247 control stream. 1249 5.3.1. Placeholders 1251 In HTTP/2, certain implementations used closed or unused streams as 1252 placeholders in describing the relative priority of requests. This 1253 created confusion as servers could not reliably identify which 1254 elements of the priority tree could be discarded safely. Clients 1255 could potentially reference closed streams long after the server had 1256 discarded state, leading to disparate views of the prioritization the 1257 client had attempted to express. 1259 In HTTP/3, a number of placeholders are explicitly permitted by the 1260 server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because the 1261 server commits to maintaining these placeholders in the 1262 prioritization tree, clients can use them with confidence that the 1263 server will not have discarded the state. Clients MUST NOT send the 1264 "SETTINGS_NUM_PLACEHOLDERS" setting; receipt of this setting by a 1265 server MUST be treated as a connection error of type 1266 "HTTP_WRONG_SETTING_DIRECTION". 1268 Placeholders are identified by an ID between zero and one less than 1269 the number of placeholders the server has permitted. 1271 Like streams, placeholders have priority information associated with 1272 them. 1274 5.3.2. Priority Tree Maintenance 1276 Because placeholders will be used to "root" any persistent structure 1277 of the tree which the client cares about retaining, servers can 1278 aggressively prune inactive regions from the priority tree. For 1279 prioritization purposes, a node in the tree is considered "inactive" 1280 when the corresponding stream has been closed for at least two round- 1281 trip times (using any reasonable estimate available on the server). 1282 This delay helps mitigate race conditions where the server has pruned 1283 a node the client believed was still active and used as a Stream 1284 Dependency. 1286 Specifically, the server MAY at any time: 1288 o Identify and discard branches of the tree containing only inactive 1289 nodes (i.e. a node with only other inactive nodes as descendants, 1290 along with those descendants) 1292 o Identify and condense interior regions of the tree containing only 1293 inactive nodes, allocating weight appropriately 1295 x x x 1296 | | | 1297 P P P 1298 / \ | | 1299 I I ==> I ==> A 1300 / \ | | 1301 A I A A 1302 | | 1303 A A 1305 Figure 13: Example of Priority Tree Pruning 1307 In the example in Figure 13, "P" represents a Placeholder, "A" 1308 represents an active node, and "I" represents an inactive node. In 1309 the first step, the server discards two inactive branches (each a 1310 single node). In the second step, the server condenses an interior 1311 inactive node. Note that these transformations will result in no 1312 change in the resources allocated to a particular active stream. 1314 Clients SHOULD assume the server is actively performing such pruning 1315 and SHOULD NOT declare a dependency on a stream it knows to have been 1316 closed. 1318 5.4. Server Push 1320 HTTP/3 server push is similar to what is described in HTTP/2 1321 [RFC7540], but uses different mechanisms. 1323 Each server push is identified by a unique Push ID. This Push ID is 1324 used in a single PUSH_PROMISE frame (see Section 4.2.6) which carries 1325 the request headers, possibly included in one or more DUPLICATE_PUSH 1326 frames (see Section 4.2.9), then included with the push stream which 1327 ultimately fulfills those promises. 1329 Server push is only enabled on a connection when a client sends a 1330 MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server 1331 push until it receives a MAX_PUSH_ID frame. A client sends 1332 additional MAX_PUSH_ID frames to control the number of pushes that a 1333 server can promise. A server SHOULD use Push IDs sequentially, 1334 starting at 0. A client MUST treat receipt of a push stream with a 1335 Push ID that is greater than the maximum Push ID as a connection 1336 error of type HTTP_LIMIT_EXCEEDED. 1338 The header of the request message is carried by a PUSH_PROMISE frame 1339 (see Section 4.2.6) on the request stream which generated the push. 1340 This allows the server push to be associated with a client request. 1341 Ordering of a PUSH_PROMISE in relation to certain parts of the 1342 response is important (see Section 8.2.1 of [RFC7540]). Promised 1343 requests MUST conform to the requirements in Section 8.2 of 1344 [RFC7540]. 1346 The same server push can be associated with additional client 1347 requests using a DUPLICATE_PUSH frame (see Section 4.2.9). Ordering 1348 of a DUPLICATE_PUSH in relation to certain parts of the response is 1349 similarly important. 1351 When a server later fulfills a promise, the server push response is 1352 conveyed on a push stream (see Section 3.2.2). The push stream 1353 identifies the Push ID of the promise that it fulfills, then contains 1354 a response to the promised request using the same format described 1355 for responses in Section 5.1. 1357 Due to reordering, DUPLICATE_PUSH frames or push stream data can 1358 arrive before the corresponding PUSH_PROMISE frame. When a client 1359 receives a DUPLICATE_PUSH frame for an as-yet-unknown Push ID, the 1360 request headers of the push are not immediately available. The 1361 client can either delay generating new requests for content 1362 referenced following the DUPLICATE_PUSH frame until the request 1363 headers become available, or can initiate requests for discovered 1364 resources and cancel the requests if the requested resource is 1365 already being pushed. When a client receives a new push stream with 1366 an as-yet-unknown Push ID, both the associated client request and the 1367 pushed request headers are unknown. The client can buffer the stream 1368 data in expectation of the matching PUSH_PROMISE. The client can use 1369 stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit 1370 the amount of data a server may commit to the pushed stream. 1372 If a promised server push is not needed by the client, the client 1373 SHOULD send a CANCEL_PUSH frame. If the push stream is already open 1374 or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING 1375 frame with an appropriate error code can also be used (e.g., 1376 HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This 1377 asks the server not to transfer additional data and indicates that it 1378 will be discarded upon receipt. 1380 6. Connection Closure 1382 Once established, an HTTP/3 connection can be used for many requests 1383 and responses over time until the connection is closed. Connection 1384 closure can happen in any of several different ways. 1386 6.1. Idle Connections 1388 Each QUIC endpoint declares an idle timeout during the handshake. If 1389 the connection remains idle (no packets received) for longer than 1390 this duration, the peer will assume that the connection has been 1391 closed. HTTP/3 implementations will need to open a new connection 1392 for new requests if the existing connection has been idle for longer 1393 than the server's advertised idle timeout, and SHOULD do so if 1394 approaching the idle timeout. 1396 HTTP clients are expected to request that the transport keep 1397 connections open while there are responses outstanding for requests 1398 or server pushes, as described in Section 19.2 of [QUIC-TRANSPORT]. 1399 If the client is not expecting a response from the server, allowing 1400 an idle connection to time out is preferred over expending effort 1401 maintaining a connection that might not be needed. A gateway MAY 1402 maintain connections in anticipation of need rather than incur the 1403 latency cost of connection establishment to servers. Servers SHOULD 1404 NOT actively keep connections open. 1406 6.2. Connection Shutdown 1408 Even when a connection is not idle, either endpoint can decide to 1409 stop using the connection and let the connection close gracefully. 1410 Since clients drive request generation, clients perform a connection 1411 shutdown by not sending additional requests on the connection; 1412 responses and pushed responses associated to previous requests will 1413 continue to completion. Servers perform the same function by 1414 communicating with clients. 1416 Servers initiate the shutdown of a connection by sending a GOAWAY 1417 frame (Section 4.2.7). The GOAWAY frame indicates that client- 1418 initiated requests on lower stream IDs were or might be processed in 1419 this connection, while requests on the indicated stream ID and 1420 greater were rejected. This enables client and server to agree on 1421 which requests were accepted prior to the connection shutdown. This 1422 identifier MAY be lower than the stream limit identified by a QUIC 1423 MAX_STREAM_ID frame, and MAY be zero if no requests were processed. 1424 Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after 1425 sending a GOAWAY frame. 1427 Clients MUST NOT send new requests on the connection after receiving 1428 GOAWAY; a new connection MAY be established to send additional 1429 requests. 1431 Some requests might already be in transit. If the client has already 1432 sent requests on streams with a Stream ID greater than or equal to 1433 that indicated in the GOAWAY frame, those requests will not be 1434 processed and MAY be retried by the client on a different connection. 1435 The client MAY cancel these requests. It is RECOMMENDED that the 1436 server explicitly reject such requests (see Section 5.1.2) in order 1437 to clean up transport state for the affected streams. 1439 Requests on Stream IDs less than the Stream ID in the GOAWAY frame 1440 might have been processed; their status cannot be known until a 1441 response is received, the stream is reset individually, or the 1442 connection terminates. Servers MAY reject individual requests on 1443 streams below the indicated ID if these requests were not processed. 1445 Servers SHOULD send a GOAWAY frame when the closing of a connection 1446 is known in advance, even if the advance notice is small, so that the 1447 remote peer can know whether a request has been partially processed 1448 or not. For example, if an HTTP client sends a POST at the same time 1449 that a server closes a QUIC connection, the client cannot know if the 1450 server started to process that POST request if the server does not 1451 send a GOAWAY frame to indicate what streams it might have acted on. 1453 A client that is unable to retry requests loses all requests that are 1454 in flight when the server closes the connection. A server MAY send 1455 multiple GOAWAY frames indicating different stream IDs, but MUST NOT 1456 increase the value they send in the last Stream ID, since clients 1457 might already have retried unprocessed requests on another 1458 connection. A server that is attempting to gracefully shut down a 1459 connection SHOULD send an initial GOAWAY frame with the last Stream 1460 ID set to the current value of QUIC's MAX_STREAM_ID and SHOULD NOT 1461 increase the MAX_STREAM_ID thereafter. This signals to the client 1462 that a shutdown is imminent and that initiating further requests is 1463 prohibited. After allowing time for any in-flight requests (at least 1464 one round-trip time), the server MAY send another GOAWAY frame with 1465 an updated last Stream ID. This ensures that a connection can be 1466 cleanly shut down without losing requests. 1468 Once all accepted requests have been processed, the server can permit 1469 the connection to become idle, or MAY initiate an immediate closure 1470 of the connection. An endpoint that completes a graceful shutdown 1471 SHOULD use the HTTP_NO_ERROR code when closing the connection. 1473 If a client has consumed all available bidirectional stream IDs with 1474 requests, the server need not send a GOAWAY frame, since the client 1475 is unable to make further requests. 1477 6.3. Immediate Application Closure 1479 An HTTP/3 implementation can immediately close the QUIC connection at 1480 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 1481 the peer; the error code in this frame indicates to the peer why the 1482 connection is being closed. See Section 8 for error codes which can 1483 be used when closing a connection. 1485 Before closing the connection, a GOAWAY MAY be sent to allow the 1486 client to retry some requests. Including the GOAWAY frame in the 1487 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 1488 of the frame being received by clients. 1490 6.4. Transport Closure 1492 For various reasons, the QUIC transport could indicate to the 1493 application layer that the connection has terminated. This might be 1494 due to an explicit closure by the peer, a transport-level error, or a 1495 change in network topology which interrupts connectivity. 1497 If a connection terminates without a GOAWAY frame, clients MUST 1498 assume that any request which was sent, whether in whole or in part, 1499 might have been processed. 1501 7. Extensions to HTTP/3 1503 HTTP/3 permits extension of the protocol. Within the limitations 1504 described in this section, protocol extensions can be used to provide 1505 additional services or alter any aspect of the protocol. Extensions 1506 are effective only within the scope of a single HTTP/3 connection. 1508 This applies to the protocol elements defined in this document. This 1509 does not affect the existing options for extending HTTP, such as 1510 defining new methods, status codes, or header fields. 1512 Extensions are permitted to use new frame types (Section 4.2), new 1513 settings (Section 4.2.5.1), new error codes (Section 8), or new 1514 unidirectional stream types (Section 3.2). Registries are 1515 established for managing these extension points: frame types 1516 (Section 10.3), settings (Section 10.4), error codes (Section 10.5), 1517 and stream types (Section 10.6). 1519 Implementations MUST ignore unknown or unsupported values in all 1520 extensible protocol elements. Implementations MUST discard frames 1521 and unidirectional streams that have unknown or unsupported types. 1522 This means that any of these extension points can be safely used by 1523 extensions without prior arrangement or negotiation. 1525 Extensions that could change the semantics of existing protocol 1526 components MUST be negotiated before being used. For example, an 1527 extension that changes the layout of the HEADERS frame cannot be used 1528 until the peer has given a positive signal that this is acceptable. 1529 In this case, it could also be necessary to coordinate when the 1530 revised layout comes into effect. 1532 This document doesn't mandate a specific method for negotiating the 1533 use of an extension but notes that a setting (Section 4.2.5.1) could 1534 be used for that purpose. If both peers set a value that indicates 1535 willingness to use the extension, then the extension can be used. If 1536 a setting is used for extension negotiation, the default value MUST 1537 be defined in such a fashion that the extension is disabled if the 1538 setting is omitted. 1540 8. Error Handling 1542 QUIC allows the application to abruptly terminate (reset) individual 1543 streams or the entire connection when an error is encountered. These 1544 are referred to as "stream errors" or "connection errors" and are 1545 described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose 1546 to treat a stream error as a connection error. 1548 This section describes HTTP/3-specific error codes which can be used 1549 to express the cause of a connection or stream error. 1551 8.1. HTTP/3 Error Codes 1553 The following error codes are defined for use in QUIC RESET_STREAM 1554 frames, STOP_SENDING frames, and CONNECTION_CLOSE frames when using 1555 HTTP/3. 1557 HTTP_NO_ERROR (0x00): No error. This is used when the connection or 1558 stream needs to be closed, but there is no error to signal. 1560 HTTP_WRONG_SETTING_DIRECTION (0x01): A client-only setting was sent 1561 by a server, or a server-only setting by a client. 1563 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1564 which the client will not accept on this connection. 1566 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1567 HTTP stack. 1569 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1570 content which the client has cached. 1572 HTTP_REQUEST_CANCELLED (0x05): The request or its response is 1573 cancelled. 1575 HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated 1576 without containing a fully-formed request. 1578 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1579 a CONNECT request was reset or abnormally closed. 1581 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1582 exhibiting a behavior that might be generating excessive load. 1584 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1585 served over HTTP/3. The peer should retry over HTTP/1.1. 1587 HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it 1588 is not permitted. 1590 HTTP_LIMIT_EXCEEDED (0x0B): A Stream ID, Push ID, or Placeholder ID 1591 greater than the current maximum for that identifier was 1592 referenced. 1594 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1595 different stream headers. 1597 HTTP_UNKNOWN_STREAM_TYPE (0x0D): A unidirectional stream header 1598 contained an unknown stream type. 1600 HTTP_WRONG_STREAM_COUNT (0x0E): A unidirectional stream type was 1601 used more times than is permitted by that type. 1603 HTTP_CLOSED_CRITICAL_STREAM (0x0F): A stream required by the 1604 connection was closed or reset. 1606 HTTP_WRONG_STREAM_DIRECTION (0x0010): A unidirectional stream type 1607 was used by a peer which is not permitted to do so. 1609 HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request 1610 is not needed to produce a response. For use in STOP_SENDING 1611 only. 1613 HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at 1614 the beginning of the control stream. 1616 HTTP_UNEXPECTED_FRAME (0x0013): A frame was received which was not 1617 permitted in the current state. 1619 HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without 1620 performing any application processing. 1622 HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol 1623 requirements in a way which doesn't match a more specific error 1624 code, or endpoint declines to use the more specific error code. 1626 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1627 If the frame type is "0xfe" or less, the type is included as the 1628 last byte of the error code. For example, an error in a 1629 MAX_PUSH_ID frame would be indicated with the code (0x10D). The 1630 last byte "0xff" is used to indicate any frame type greater than 1631 "0xfe". 1633 9. Security Considerations 1635 The security considerations of HTTP/3 should be comparable to those 1636 of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames 1637 and Padding fields in other frames to make a connection more 1638 resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames 1639 or employ the reserved frame and stream types discussed in 1640 Section 4.2.10 and Section 3.2.3. 1642 When HTTP Alternative Services is used for discovery for HTTP/3 1643 endpoints, the security considerations of [ALTSVC] also apply. 1645 Several protocol elements contain nested length elements, typically 1646 in the form of frames with an explicit length containing variable- 1647 length integers. This could pose a security risk to an incautious 1648 implementer. An implementation MUST ensure that the length of a 1649 frame exactly matches the length of the fields it contains. 1651 The use of 0-RTT with HTTP/3 creates an exposure to replay attack. 1652 The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when 1653 using HTTP/3 with 0-RTT. 1655 Certain HTTP implementations use the client address for logging or 1656 access-control purposes. Since a QUIC client's address might change 1657 during a connection (and future versions might support simultaneous 1658 use of multiple addresses), such implementations will need to either 1659 actively retrieve the client's current address or addresses when they 1660 are relevant or explicitly accept that the original address might 1661 change. 1663 10. IANA Considerations 1665 10.1. Registration of HTTP/3 Identification String 1667 This document creates a new registration for the identification of 1668 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 1669 IDs" registry established in [RFC7301]. 1671 The "h3" string identifies HTTP/3: 1673 Protocol: HTTP/3 1675 Identification Sequence: 0x68 0x33 ("h3") 1677 Specification: This document 1679 10.2. Registration of QUIC Version Hint Alt-Svc Parameter 1681 This document creates a new registration for version-negotiation 1682 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1683 registry established in [RFC7838]. 1685 Parameter: "quic" 1687 Specification: This document, Section 2.2.1 1689 10.3. Frame Types 1691 This document establishes a registry for HTTP/3 frame type codes. 1692 The "HTTP/3 Frame Type" registry governs a 62-bit space. This space 1693 is split into three spaces that are governed by different policies. 1694 Values between "0x00" and "0x3f" (in hexadecimal) are assigned via 1695 the Standards Action or IESG Review policies [RFC8126]. Values from 1696 "0x40" to "0x3fff" operate on the Specification Required policy 1697 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 1699 While this registry is separate from the "HTTP/2 Frame Type" registry 1700 defined in [RFC7540], it is preferable that the assignments parallel 1701 each other where the code spaces overlap. If an entry is present in 1702 only one registry, every effort SHOULD be made to avoid assigning the 1703 corresponding value to an unrelated operation. 1705 New entries in this registry require the following information: 1707 Frame Type: A name or label for the frame type. 1709 Code: The 62-bit code assigned to the frame type. 1711 Specification: A reference to a specification that includes a 1712 description of the frame layout and its semantics, including any 1713 parts of the frame that are conditionally present. 1715 The entries in the following table are registered by this document. 1717 +----------------+------+---------------+ 1718 | Frame Type | Code | Specification | 1719 +----------------+------+---------------+ 1720 | DATA | 0x0 | Section 4.2.1 | 1721 | | | | 1722 | HEADERS | 0x1 | Section 4.2.2 | 1723 | | | | 1724 | PRIORITY | 0x2 | Section 4.2.3 | 1725 | | | | 1726 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1727 | | | | 1728 | SETTINGS | 0x4 | Section 4.2.5 | 1729 | | | | 1730 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1731 | | | | 1732 | Reserved | 0x6 | N/A | 1733 | | | | 1734 | GOAWAY | 0x7 | Section 4.2.7 | 1735 | | | | 1736 | Reserved | 0x8 | N/A | 1737 | | | | 1738 | Reserved | 0x9 | N/A | 1739 | | | | 1740 | MAX_PUSH_ID | 0xD | Section 4.2.8 | 1741 | | | | 1742 | DUPLICATE_PUSH | 0xE | Section 4.2.9 | 1743 +----------------+------+---------------+ 1745 Additionally, each code of the format "0x1f * N + 0x21" for integer 1746 values of N (that is, "0x21", "0x40", ..., through 1747 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 1749 10.4. Settings Parameters 1751 This document establishes a registry for HTTP/3 settings. The 1752 "HTTP/3 Settings" registry governs a 62-bit space. This space is 1753 split into three spaces that are governed by different policies. 1754 Values between "0x00" and "0x3f" (in hexadecimal) are assigned via 1755 the Standards Action or IESG Review policies [RFC8126]. Values from 1756 "0x40" to "0x3fff" operate on the Specification Required policy 1757 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 1759 The designated experts are the same as those for the "HTTP/2 1760 Settings" registry defined in [RFC7540]. 1762 While this registry is separate from the "HTTP/2 Settings" registry 1763 defined in [RFC7540], it is preferable that the assignments parallel 1764 each other. If an entry is present in only one registry, every 1765 effort SHOULD be made to avoid assigning the corresponding value to 1766 an unrelated operation. 1768 New registrations are advised to provide the following information: 1770 Name: A symbolic name for the setting. Specifying a setting name is 1771 optional. 1773 Code: The 62-bit code assigned to the setting. 1775 Specification: An optional reference to a specification that 1776 describes the use of the setting. 1778 The entries in the following table are registered by this document. 1780 +----------------------+------+-----------------+ 1781 | Setting Name | Code | Specification | 1782 +----------------------+------+-----------------+ 1783 | Reserved | 0x2 | N/A | 1784 | | | | 1785 | Reserved | 0x3 | N/A | 1786 | | | | 1787 | Reserved | 0x4 | N/A | 1788 | | | | 1789 | Reserved | 0x5 | N/A | 1790 | | | | 1791 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 | 1792 | | | | 1793 | NUM_PLACEHOLDERS | 0x9 | Section 4.2.5.1 | 1794 +----------------------+------+-----------------+ 1796 Additionally, each code of the format "0x1f * N + 0x21" for integer 1797 values of N (that is, "0x21", "0x40", ..., through 1798 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 1800 10.5. Error Codes 1802 This document establishes a registry for HTTP/3 error codes. The 1803 "HTTP/3 Error Code" registry manages a 16-bit space. The "HTTP/3 1804 Error Code" registry operates under the "Expert Review" policy 1805 [RFC8126]. 1807 Registrations for error codes are required to include a description 1808 of the error code. An expert reviewer is advised to examine new 1809 registrations for possible duplication with existing error codes. 1810 Use of existing registrations is to be encouraged, but not mandated. 1812 New registrations are advised to provide the following information: 1814 Name: A name for the error code. Specifying an error code name is 1815 optional. 1817 Code: The 16-bit error code value. 1819 Description: A brief description of the error code semantics, longer 1820 if no detailed specification is provided. 1822 Specification: An optional reference for a specification that 1823 defines the error code. 1825 The entries in the following table are registered by this document. 1827 +---------------------------+--------+---------------+--------------+ 1828 | Name | Code | Description | Specificatio | 1829 | | | | n | 1830 +---------------------------+--------+---------------+--------------+ 1831 | HTTP_NO_ERROR | 0x0000 | No error | Section 8.1 | 1832 | | | | | 1833 | HTTP_WRONG_SETTING_DIRECT | 0x0001 | Setting sent | Section 8.1 | 1834 | ION | | in wrong | | 1835 | | | direction | | 1836 | | | | | 1837 | HTTP_PUSH_REFUSED | 0x0002 | Client | Section 8.1 | 1838 | | | refused | | 1839 | | | pushed | | 1840 | | | content | | 1841 | | | | | 1842 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 8.1 | 1843 | | | error | | 1844 | | | | | 1845 | HTTP_PUSH_ALREADY_IN_CACH | 0x0004 | Pushed | Section 8.1 | 1846 | E | | content | | 1847 | | | already | | 1848 | | | cached | | 1849 | | | | | 1850 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 8.1 | 1851 | | | longer needed | | 1852 | | | | | 1853 | HTTP_INCOMPLETE_REQUEST | 0x0006 | Stream | Section 8.1 | 1854 | | | terminated | | 1855 | | | early | | 1856 | | | | | 1857 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset or | Section 8.1 | 1858 | | | error on | | 1859 | | | CONNECT | | 1860 | | | request | | 1861 | | | | | 1862 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 8.1 | 1863 | | | generating | | 1864 | | | excessive | | 1865 | | | load | | 1866 | | | | | 1867 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 8.1 | 1868 | | | HTTP/1.1 | | 1869 | | | | | 1870 | HTTP_WRONG_STREAM | 0x000A | A frame was | Section 8.1 | 1871 | | | sent on the | | 1872 | | | wrong stream | | 1873 | | | | | 1874 | HTTP_LIMIT_EXCEEDED | 0x000B | An identifier | Section 8.1 | 1875 | | | limit was | | 1876 | | | exceeded | | 1877 | | | | | 1878 | HTTP_DUPLICATE_PUSH | 0x000C | Push ID was | Section 8.1 | 1879 | | | fulfilled | | 1880 | | | multiple | | 1881 | | | times | | 1882 | | | | | 1883 | HTTP_UNKNOWN_STREAM_TYPE | 0x000D | Unknown unidi | Section 8.1 | 1884 | | | rectional | | 1885 | | | stream type | | 1886 | | | | | 1887 | HTTP_WRONG_STREAM_COUNT | 0x000E | Too many unid | Section 8.1 | 1888 | | | irectional | | 1889 | | | streams | | 1890 | | | | | 1891 | HTTP_CLOSED_CRITICAL_STRE | 0x000F | Critical | Section 8.1 | 1892 | AM | | stream was | | 1893 | | | closed | | 1894 | | | | | 1895 | HTTP_WRONG_STREAM_DIRECTI | 0x0010 | Unidirectiona | Section 8.1 | 1896 | ON | | l stream in | | 1897 | | | wrong | | 1898 | | | direction | | 1899 | | | | | 1900 | HTTP_EARLY_RESPONSE | 0x0011 | Remainder of | Section 8.1 | 1901 | | | request not | | 1902 | | | needed | | 1903 | | | | | 1904 | HTTP_MISSING_SETTINGS | 0x0012 | No SETTINGS | Section 8.1 | 1905 | | | frame | | 1906 | | | received | | 1907 | | | | | 1908 | HTTP_UNEXPECTED_FRAME | 0x0013 | Frame not | Section 8.1 | 1909 | | | permitted in | | 1910 | | | the current | | 1911 | | | state | | 1912 | | | | | 1913 | HTTP_REQUEST_REJECTED | 0x0014 | Request not | Section 8.1 | 1914 | | | processed | | 1915 | | | | | 1916 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 | 1917 | | | frame | | 1918 | | | formatting | | 1919 +---------------------------+--------+---------------+--------------+ 1921 10.6. Stream Types 1923 This document establishes a registry for HTTP/3 unidirectional stream 1924 types. The "HTTP/3 Stream Type" registry governs a 62-bit space. 1925 This space is split into three spaces that are governed by different 1926 policies. Values between "0x00" and 0x3f (in hexadecimal) are 1927 assigned via the Standards Action or IESG Review policies [RFC8126]. 1928 Values from "0x40" to "0x3fff" operate on the Specification Required 1929 policy [RFC8126]. All other values are assigned to Private Use 1930 [RFC8126]. 1932 New entries in this registry require the following information: 1934 Stream Type: A name or label for the stream type. 1936 Code: The 62-bit code assigned to the stream type. 1938 Specification: A reference to a specification that includes a 1939 description of the stream type, including the layout semantics of 1940 its payload. 1942 Sender: Which endpoint on a connection may initiate a stream of this 1943 type. Values are "Client", "Server", or "Both". 1945 The entries in the following table are registered by this document. 1947 +----------------+------+---------------+--------+ 1948 | Stream Type | Code | Specification | Sender | 1949 +----------------+------+---------------+--------+ 1950 | Control Stream | 0x00 | Section 3.2.1 | Both | 1951 | | | | | 1952 | Push Stream | 0x01 | Section 5.4 | Server | 1953 +----------------+------+---------------+--------+ 1955 Additionally, each code of the format "0x1f * N + 0x21" for integer 1956 values of N (that is, "0x21", "0x40", ..., through 1957 "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 1959 11. References 1961 11.1. Normative References 1963 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1964 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1965 April 2016, . 1967 [HTTP-REPLAY] 1968 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1969 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1970 2018, . 1972 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 1973 Header Compression for HTTP over QUIC", draft-ietf-quic- 1974 qpack-08 (work in progress), April 2019. 1976 [QUIC-TRANSPORT] 1977 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1978 Multiplexed and Secure Transport", draft-ietf-quic- 1979 transport-18 (work in progress), April 2019. 1981 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1982 RFC 793, DOI 10.17487/RFC0793, September 1981, 1983 . 1985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1986 Requirement Levels", BCP 14, RFC 2119, 1987 DOI 10.17487/RFC2119, March 1997, 1988 . 1990 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1991 Specifications: ABNF", STD 68, RFC 5234, 1992 DOI 10.17487/RFC5234, January 2008, 1993 . 1995 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1996 Extensions: Extension Definitions", RFC 6066, 1997 DOI 10.17487/RFC6066, January 2011, 1998 . 2000 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2001 Protocol (HTTP/1.1): Message Syntax and Routing", 2002 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2003 . 2005 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2006 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2007 DOI 10.17487/RFC7231, June 2014, 2008 . 2010 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2011 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2012 DOI 10.17487/RFC7540, May 2015, 2013 . 2015 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2016 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2017 April 2016, . 2019 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2020 Writing an IANA Considerations Section in RFCs", BCP 26, 2021 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2022 . 2024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2025 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2026 May 2017, . 2028 11.2. Informative References 2030 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2031 "Transport Layer Security (TLS) Application-Layer Protocol 2032 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2033 July 2014, . 2035 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2036 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2037 . 2039 11.3. URIs 2041 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 2043 [2] https://github.com/quicwg 2045 [3] https://github.com/quicwg/base-drafts/labels/-http 2047 [4] https://www.iana.org/assignments/message-headers 2049 Appendix A. Considerations for Transitioning from HTTP/2 2051 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 2052 This section describes the approach taken to design HTTP/3, points 2053 out important differences from HTTP/2, and describes how to map 2054 HTTP/2 extensions into HTTP/3. 2056 HTTP/3 begins from the premise that similarity to HTTP/2 is 2057 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 2058 primarily where necessary to accommodate the differences in behavior 2059 between QUIC and TCP (lack of ordering, support for streams). We 2060 intend to avoid gratuitous changes which make it difficult or 2061 impossible to build extensions with the same semantics applicable to 2062 both protocols at once. 2064 These departures are noted in this section. 2066 A.1. Streams 2068 HTTP/3 permits use of a larger number of streams (2^62-1) than 2069 HTTP/2. The considerations about exhaustion of stream identifier 2070 space apply, though the space is significantly larger such that it is 2071 likely that other limits in QUIC are reached first, such as the limit 2072 on the connection flow control window. 2074 A.2. HTTP Frame Types 2076 Many framing concepts from HTTP/2 can be elided on QUIC, because the 2077 transport deals with them. Because frames are already on a stream, 2078 they can omit the stream number. Because frames do not block 2079 multiplexing (QUIC's multiplexing occurs below this layer), the 2080 support for variable-maximum-length packets can be removed. Because 2081 stream termination is handled by QUIC, an END_STREAM flag is not 2082 required. This permits the removal of the Flags field from the 2083 generic frame layout. 2085 Frame payloads are largely drawn from [RFC7540]. However, QUIC 2086 includes many features (e.g., flow control) which are also present in 2087 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 2088 As a result, several HTTP/2 frame types are not required in HTTP/3. 2089 Where an HTTP/2-defined frame is no longer used, the frame ID has 2090 been reserved in order to maximize portability between HTTP/2 and 2091 HTTP/3 implementations. However, even equivalent frames between the 2092 two mappings are not identical. 2094 Many of the differences arise from the fact that HTTP/2 provides an 2095 absolute ordering between frames across all streams, while QUIC 2096 provides this guarantee on each stream only. As a result, if a frame 2097 type makes assumptions that frames from different streams will still 2098 be received in the order sent, HTTP/3 will break them. 2100 For example, implicit in the HTTP/2 prioritization scheme is the 2101 notion of in-order delivery of priority changes (i.e., dependency 2102 tree mutations): since operations on the dependency tree such as 2103 reparenting a subtree are not commutative, both sender and receiver 2104 must apply them in the same order to ensure that both sides have a 2105 consistent view of the stream dependency tree. HTTP/2 specifies 2106 priority assignments in PRIORITY frames and (optionally) in HEADERS 2107 frames. To achieve in-order delivery of priority changes in HTTP/3, 2108 PRIORITY frames are sent as the first frame on a request stream or on 2109 the control stream and exclusive prioritization has been removed. 2110 HTTP/3 permits the prioritisation of requests, pushes and 2111 placeholders that each exist in separate identifier spaces. The 2112 HTTP/3 PRIORITY frame replaces the stream dependency field with 2113 fields that can identify the element of interest and its dependency. 2115 Likewise, HPACK was designed with the assumption of in-order 2116 delivery. A sequence of encoded header blocks must arrive (and be 2117 decoded) at an endpoint in the same order in which they were encoded. 2118 This ensures that the dynamic state at the two endpoints remains in 2119 sync. As a result, HTTP/3 uses a modified version of HPACK, 2120 described in [QPACK]. 2122 Frame type definitions in HTTP/3 often use the QUIC variable-length 2123 integer encoding. In particular, Stream IDs use this encoding, which 2124 allow for a larger range of possible values than the encoding used in 2125 HTTP/2. Some frames in HTTP/3 use an identifier rather than a Stream 2126 ID (e.g. Push IDs in PRIORITY frames). Redefinition of the encoding 2127 of extension frame types might be necessary if the encoding includes 2128 a Stream ID. 2130 Because the Flags field is not present in generic HTTP/3 frames, 2131 those frames which depend on the presence of flags need to allocate 2132 space for flags as part of their frame payload. 2134 Other than this issue, frame type HTTP/2 extensions are typically 2135 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2136 control stream in HTTP/3. HTTP/3 extensions will not assume 2137 ordering, but would not be harmed by ordering, and would be portable 2138 to HTTP/2 in the same manner. 2140 Below is a listing of how each HTTP/2 frame type is mapped: 2142 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2143 Section 4.2.1. 2145 HEADERS (0x1): The PRIORITY region of HEADERS is not defined in 2146 HTTP/3 frames. A separate PRIORITY frame is used in all cases. 2147 Padding is not defined in HTTP/3 frames. See Section 4.2.2. 2149 PRIORITY (0x2): As described above, the PRIORITY frame references a 2150 variety of identifiers. It is sent as the first frame on a 2151 request streams or on the control stream. See Section 4.2.3. 2153 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 2154 provides stream lifecycle management. The same code point is used 2155 for the CANCEL_PUSH frame (Section 4.2.4). 2157 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2158 the connection. See Section 4.2.5 and Appendix A.3. 2160 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 2161 instead the push stream references the PUSH_PROMISE frame using a 2162 Push ID. See Section 4.2.6. 2164 PING (0x6): PING frames do not exist, since QUIC provides equivalent 2165 functionality. 2167 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 2168 contain an error code. See Section 4.2.7. 2170 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 2171 provides flow control. 2173 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 2174 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. 2176 Frame types defined by extensions to HTTP/2 need to be separately 2177 registered for HTTP/3 if still applicable. The IDs of frames defined 2178 in [RFC7540] have been reserved for simplicity. Note that the frame 2179 type space in HTTP/3 is substantially larger (62 bits versus 8 bits), 2180 so many HTTP/3 frame types have no equivalent HTTP/2 code points. 2181 See Section 10.3. 2183 A.3. HTTP/2 SETTINGS Parameters 2185 An important difference from HTTP/2 is that settings are sent once, 2186 at the beginning of the connection, and thereafter cannot change. 2187 This eliminates many corner cases around synchronization of changes. 2189 Some transport-level options that HTTP/2 specifies via the SETTINGS 2190 frame are superseded by QUIC transport parameters in HTTP/3. The 2191 HTTP-level options that are retained in HTTP/3 have the same value as 2192 in HTTP/2. 2194 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2196 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 2198 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 2199 which provides a more granular control over server push. 2201 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 2202 Stream ID as part of its flow control logic. Specifying 2203 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 2205 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 2206 connection flow control window sizes to be specified in the 2207 initial transport handshake. Specifying 2208 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 2210 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. 2211 Specifying it in the SETTINGS frame is an error. 2213 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.1. 2215 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2216 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2217 This will often produce a shorter encoding, but can produce a longer 2218 encoding for settings which use the full 32-bit space. Settings 2219 ported from HTTP/2 might choose to redefine the format of their 2220 settings to avoid using the 62-bit encoding. 2222 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2223 IDs of settings defined in [RFC7540] have been reserved for 2224 simplicity. Note that the settings identifier space in HTTP/3 is 2225 substantially larger (62 bits versus 16 bits), so many HTTP/3 2226 settings have no equivalent HTTP/2 code point. See Section 10.4. 2228 A.4. HTTP/2 Error Codes 2230 QUIC has the same concepts of "stream" and "connection" errors that 2231 HTTP/2 provides. However, there is no direct portability of HTTP/2 2232 error codes. 2234 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 2235 HTTP/3 error codes as follows: 2237 NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1. 2239 PROTOCOL_ERROR (0x1): No single mapping. See new 2240 HTTP_MALFORMED_FRAME error codes defined in Section 8.1. 2242 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1. 2244 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2245 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 2246 from the QUIC layer. 2248 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2249 SETTINGS is defined. 2251 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2252 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 2253 from the QUIC layer. 2255 FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in 2256 Section 8.1. 2258 REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used 2259 to indicate that a request was not processed. Otherwise, not 2260 applicable because QUIC handles stream management. A 2261 STREAM_ID_ERROR at the QUIC layer is used for streams that are 2262 improperly opened. 2264 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. 2266 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2267 [QPACK]. 2269 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. 2271 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. 2273 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2274 provide sufficient security on all connections. 2276 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1. 2278 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2279 Section 10.5. 2281 Appendix B. Change Log 2283 *RFC Editor's Note:* Please remove this section prior to 2284 publication of a final version of this document. 2286 B.1. Since draft-ietf-quic-http-19 2288 o SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530) 2290 o Non-zero bits in the Empty field of the PRIORITY frame MAY be 2291 treated as an error (#2501) 2293 B.2. Since draft-ietf-quic-http-18 2295 o Resetting streams following a GOAWAY is recommended, but not 2296 required (#2256,#2457) 2298 o Use variable-length integers throughout (#2437,#2233,#2253,#2275) 2300 * Variable-length frame types, stream types, and settings 2301 identifiers 2303 * Renumbered stream type assignments 2305 * Modified associated reserved values 2307 o Frame layout switched from Length-Type-Value to Type-Length-Value 2308 (#2395,#2235) 2310 o Specified error code for servers receiving DUPLICATE_PUSH (#2497) 2312 o Use connection error for invalid PRIORITY (#2507, #2508) 2314 B.3. Since draft-ietf-quic-http-17 2316 o HTTP_REQUEST_REJECTED is used to indicate a request can be retried 2317 (#2106, #2325) 2319 o Changed error code for GOAWAY on the wrong stream (#2231, #2343) 2321 B.4. Since draft-ietf-quic-http-16 2323 o Rename "HTTP/QUIC" to "HTTP/3" (#1973) 2325 o Changes to PRIORITY frame (#1865, #2075) 2327 * Permitted as first frame of request streams 2329 * Remove exclusive reprioritization 2331 * Changes to Prioritized Element Type bits 2333 o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 2334 (#2072) 2336 o Set defaults for settings, allow request before receiving SETTINGS 2337 (#1809, #1846, #2038) 2339 o Clarify message processing rules for streams that aren't closed 2340 (#1972, #2003) 2342 o Removed reservation of error code 0 and moved HTTP_NO_ERROR to 2343 this value (#1922) 2345 o Removed prohibition of zero-length DATA frames (#2098) 2347 B.5. Since draft-ietf-quic-http-15 2349 Substantial editorial reorganization; no technical changes. 2351 B.6. Since draft-ietf-quic-http-14 2353 o Recommend sensible values for QUIC transport parameters 2354 (#1720,#1806) 2356 o Define error for missing SETTINGS frame (#1697,#1808) 2358 o Setting values are variable-length integers (#1556,#1807) and do 2359 not have separate maximum values (#1820) 2361 o Expanded discussion of connection closure (#1599,#1717,#1712) 2363 o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 2365 B.7. Since draft-ietf-quic-http-13 2367 o Reserved some frame types for grease (#1333, #1446) 2369 o Unknown unidirectional stream types are tolerated, not errors; 2370 some reserved for grease (#1490, #1525) 2372 o Require settings to be remembered for 0-RTT, prohibit reductions 2373 (#1541, #1641) 2375 o Specify behavior for truncated requests (#1596, #1643) 2377 B.8. Since draft-ietf-quic-http-12 2379 o TLS SNI extension isn't mandatory if an alternative method is used 2380 (#1459, #1462, #1466) 2382 o Removed flags from HTTP/3 frames (#1388, #1398) 2384 o Reserved frame types and settings for use in preserving 2385 extensibility (#1333, #1446) 2387 o Added general error code (#1391, #1397) 2389 o Unidirectional streams carry a type byte and are extensible 2390 (#910,#1359) 2392 o Priority mechanism now uses explicit placeholders to enable 2393 persistent structure in the tree (#441,#1421,#1422) 2395 B.9. Since draft-ietf-quic-http-11 2397 o Moved QPACK table updates and acknowledgments to dedicated streams 2398 (#1121, #1122, #1238) 2400 B.10. Since draft-ietf-quic-http-10 2402 o Settings need to be remembered when attempting and accepting 0-RTT 2403 (#1157, #1207) 2405 B.11. Since draft-ietf-quic-http-09 2407 o Selected QCRAM for header compression (#228, #1117) 2409 o The server_name TLS extension is now mandatory (#296, #495) 2411 o Specified handling of unsupported versions in Alt-Svc (#1093, 2412 #1097) 2414 B.12. Since draft-ietf-quic-http-08 2416 o Clarified connection coalescing rules (#940, #1024) 2418 B.13. Since draft-ietf-quic-http-07 2420 o Changes for integer encodings in QUIC (#595,#905) 2422 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 2424 o Improvement to the description of GOAWAY (#604, #898) 2426 o Improve description of server push usage (#947, #950, #957) 2428 B.14. Since draft-ietf-quic-http-06 2430 o Track changes in QUIC error code usage (#485) 2432 B.15. Since draft-ietf-quic-http-05 2434 o Made push ID sequential, add MAX_PUSH_ID, remove 2435 SETTINGS_ENABLE_PUSH (#709) 2437 o Guidance about keep-alive and QUIC PINGs (#729) 2439 o Expanded text on GOAWAY and cancellation (#757) 2441 B.16. Since draft-ietf-quic-http-04 2443 o Cite RFC 5234 (#404) 2445 o Return to a single stream per request (#245,#557) 2447 o Use separate frame type and settings registries from HTTP/2 (#81) 2449 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 2451 o Restored GOAWAY (#696) 2453 o Identify server push using Push ID rather than a stream ID 2454 (#702,#281) 2456 o DATA frames cannot be empty (#700) 2458 B.17. Since draft-ietf-quic-http-03 2460 None. 2462 B.18. Since draft-ietf-quic-http-02 2464 o Track changes in transport draft 2466 B.19. Since draft-ietf-quic-http-01 2468 o SETTINGS changes (#181): 2470 * SETTINGS can be sent only once at the start of a connection; no 2471 changes thereafter 2473 * SETTINGS_ACK removed 2475 * Settings can only occur in the SETTINGS frame a single time 2477 * Boolean format updated 2479 o Alt-Svc parameter changed from "v" to "quic"; format updated 2480 (#229) 2482 o Closing the connection control stream or any message control 2483 stream is a fatal error (#176) 2485 o HPACK Sequence counter can wrap (#173) 2487 o 0-RTT guidance added 2489 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 2490 added (#127,#242) 2492 B.20. Since draft-ietf-quic-http-00 2494 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 2496 o Changed from using HTTP/2 framing within Stream 3 to new framing 2497 format and two-stream-per-request model (#71,#72,#73) 2499 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 2500 settings-01 2502 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 2503 order (#75) 2505 o Described CONNECT pseudo-method (#95) 2506 o Updated ALPN token and Alt-Svc guidance (#13,#87) 2508 o Application-layer-defined error codes (#19,#74) 2510 B.21. Since draft-shade-quic-http2-mapping-00 2512 o Adopted as base for draft-ietf-quic-http 2514 o Updated authors/editors list 2516 Acknowledgements 2518 The original authors of this specification were Robbie Shade and Mike 2519 Warres. 2521 A substantial portion of Mike's contribution was supported by 2522 Microsoft during his employment there. 2524 Author's Address 2526 Mike Bishop (editor) 2527 Akamai 2529 Email: mbishop@evequefou.be