idnits 2.17.1 draft-ietf-quic-http-17.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 (December 18, 2018) is 1949 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 1935 -- Looks like a reference, but probably isn't: '2' on line 1937 -- Looks like a reference, but probably isn't: '3' on line 1939 -- Looks like a reference, but probably isn't: '4' on line 1941 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-05 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-16 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALTSVC'. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Akamai 4 Intended status: Standards Track December 18, 2018 5 Expires: June 21, 2019 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-17 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 June 21, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 65 2. Connection Setup and Management . . . . . . . . . . . . . . . 5 66 2.1. Draft Version Identification . . . . . . . . . . . . . . 5 67 2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5 68 2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6 69 2.3. Connection Establishment . . . . . . . . . . . . . . . . 6 70 2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7 71 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 72 3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8 73 3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8 74 3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 9 75 3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 9 76 3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 10 77 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10 78 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10 79 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11 80 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12 83 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 14 84 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 15 85 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18 86 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 19 88 4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 20 89 4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 21 90 5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 21 91 5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 21 92 5.1.1. Header Formatting and Compression . . . . . . . . . . 22 93 5.1.2. Request Cancellation . . . . . . . . . . . . . . . . 23 95 5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 24 96 5.3. Request Prioritization . . . . . . . . . . . . . . . . . 25 97 5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 26 98 5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 26 99 5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 27 100 6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 28 101 6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 28 102 6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 29 103 6.3. Immediate Application Closure . . . . . . . . . . . . . . 30 104 6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 30 105 7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 31 106 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 107 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 32 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 110 10.1. Registration of HTTP/3 Identification String . . . . . . 34 111 10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 34 112 10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 34 113 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 36 114 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 37 115 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 39 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 118 11.2. Informative References . . . . . . . . . . . . . . . . . 41 119 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 120 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 42 121 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 42 122 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 42 123 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 44 124 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 45 125 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 46 126 B.1. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 46 127 B.2. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 47 128 B.3. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 47 129 B.4. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 47 130 B.5. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 48 131 B.6. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 48 132 B.7. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 48 133 B.8. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 48 134 B.9. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 48 135 B.10. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 48 136 B.11. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 49 137 B.12. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 49 138 B.13. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 49 139 B.14. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 49 140 B.15. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 49 141 B.16. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 49 142 B.17. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 50 143 B.18. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 50 144 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50 145 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51 147 1. Introduction 149 HTTP semantics are used for a broad range of services on the 150 Internet. These semantics have commonly been used with two different 151 TCP mappings, HTTP/1.1 and HTTP/2. HTTP/2 introduced a framing and 152 multiplexing layer to improve latency without modifying the transport 153 layer. However, TCP's lack of visibility into parallel requests in 154 both mappings limited the possible performance gains. 156 The QUIC transport protocol incorporates stream multiplexing and per- 157 stream flow control, similar to that provided by the HTTP/2 framing 158 layer. By providing reliability at the stream level and congestion 159 control across the entire connection, it has the capability to 160 improve the performance of HTTP compared to a TCP mapping. QUIC also 161 incorporates TLS 1.3 at the transport layer, offering comparable 162 security to running TLS over TCP, but with improved connection setup 163 latency. 165 This document describes a mapping of HTTP semantics over the QUIC 166 transport protocol, drawing heavily on design of HTTP/2. This 167 document identifies HTTP/2 features that are subsumed by QUIC, and 168 describes how the other features can be implemented atop QUIC. 170 QUIC is described in [QUIC-TRANSPORT]. For a full description of 171 HTTP/2, see [RFC7540]. 173 1.1. Notational Conventions 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in BCP 178 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 182 defined in [RFC5234]. 184 This document uses the variable-length integer encoding from 185 [QUIC-TRANSPORT]. 187 Protocol elements called "frames" exist in both this document and 188 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 189 the frame name will be prefaced with "QUIC." For example, "QUIC 190 CONNECTION_CLOSE frames." References without this preface refer to 191 frames defined in Section 4.2. 193 2. Connection Setup and Management 195 2.1. Draft Version Identification 197 *RFC Editor's Note:* Please remove this section prior to 198 publication of a final version of this document. 200 HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc. 201 Only implementations of the final, published RFC can identify 202 themselves as "h3". Until such an RFC exists, implementations MUST 203 NOT identify themselves using this string. 205 Implementations of draft versions of the protocol MUST add the string 206 "-" and the corresponding draft number to the identifier. For 207 example, draft-ietf-quic-http-01 is identified using the string 208 "h3-01". 210 Non-compatible experiments that are based on these draft versions 211 MUST append the string "-" and an experiment name to the identifier. 212 For example, an experimental implementation based on draft-ietf-quic- 213 http-09 which reserves an extra stream for unsolicited transmission 214 of 1980s pop music might identify itself as "h3-09-rickroll". Note 215 that any label MUST conform to the "token" syntax defined in 216 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 217 coordinate their experiments on the quic@ietf.org mailing list. 219 2.2. Discovering an HTTP/3 Endpoint 221 An HTTP origin advertises the availability of an equivalent HTTP/3 222 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 223 ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 2.3. 225 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 226 response that HTTP/3 was available on UDP port 50781 at the same 227 hostname by including the following header field in any response: 229 Alt-Svc: h3=":50781" 231 On receipt of an Alt-Svc record indicating HTTP/3 support, a client 232 MAY attempt to establish a QUIC connection to the indicated host and 233 port and, if successful, send HTTP requests using the mapping 234 described in this document. 236 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 237 connection establishment failure, in which case the client SHOULD 238 continue using the existing connection or try another alternative 239 endpoint offered by the origin. 241 Servers MAY serve HTTP/3 on any UDP port, since an alternative always 242 includes an explicit port. 244 2.2.1. QUIC Version Hints 246 This document defines the "quic" parameter for Alt-Svc, which MAY be 247 used to provide version-negotiation hints to HTTP/3 clients. QUIC 248 versions are four-byte sequences with no additional constraints on 249 format. Leading zeros SHOULD be omitted for brevity. 251 Syntax: 253 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 254 version-number = 1*8HEXDIG; hex-encoded QUIC version 256 Where multiple versions are listed, the order of the values reflects 257 the server's preference (with the first value being the most 258 preferred version). Reserved versions MAY be listed, but unreserved 259 versions which are not supported by the alternative SHOULD NOT be 260 present in the list. Origins MAY omit supported versions for any 261 reason. 263 Clients MUST ignore any included versions which they do not support. 264 The "quic" parameter MUST NOT occur more than once; clients SHOULD 265 process only the first occurrence. 267 For example, suppose a server supported both version 0x00000001 and 268 the version rendered in ASCII as "Q034". If it also opted to include 269 the reserved version (from Section 15 of [QUIC-TRANSPORT]) 270 0x1abadaba, it could specify the following header field: 272 Alt-Svc: h3=":49288";quic="1,1abadaba,51303334" 274 A client acting on this header field would drop the reserved version 275 (not supported), then attempt to connect to the alternative using the 276 first version in the list which it does support, if any. 278 2.3. Connection Establishment 280 HTTP/3 relies on QUIC as the underlying transport. The QUIC version 281 being used MUST use TLS version 1.3 or greater as its handshake 282 protocol. HTTP/3 clients MUST indicate the target domain name during 283 the TLS handshake. This may be done using the Server Name Indication 284 (SNI) [RFC6066] extension to TLS or using some other mechanism. 286 QUIC connections are established as described in [QUIC-TRANSPORT]. 287 During connection establishment, HTTP/3 support is indicated by 288 selecting the ALPN token "hq" in the TLS handshake. Support for 289 other application-layer protocols MAY be offered in the same 290 handshake. 292 While connection-level options pertaining to the core QUIC protocol 293 are set in the initial crypto handshake, HTTP/3-specific settings are 294 conveyed in the SETTINGS frame. After the QUIC connection is 295 established, a SETTINGS frame (Section 4.2.5) MUST be sent by each 296 endpoint as the initial frame of their respective HTTP control stream 297 (see Section 3.2.1). 299 2.4. Connection Reuse 301 Once a connection exists to a server endpoint, this connection MAY be 302 reused for requests with multiple different URI authority components. 303 The client MAY send any requests for which the client considers the 304 server authoritative. 306 An authoritative HTTP/3 endpoint is typically discovered because the 307 client has received an Alt-Svc record from the request's origin which 308 nominates the endpoint as a valid HTTP Alternative Service for that 309 origin. As required by [RFC7838], clients MUST check that the 310 nominated server can present a valid certificate for the origin 311 before considering it authoritative. Clients MUST NOT assume that an 312 HTTP/3 endpoint is authoritative for other origins without an 313 explicit signal. 315 A server that does not wish clients to reuse connections for a 316 particular origin can indicate that it is not authoritative for a 317 request by sending a 421 (Misdirected Request) status code in 318 response to the request (see Section 9.1.2 of [RFC7540]). 320 The considerations discussed in Section 9.1 of [RFC7540] also apply 321 to the management of HTTP/3 connections. 323 3. Stream Mapping and Usage 325 A QUIC stream provides reliable in-order delivery of bytes, but makes 326 no guarantees about order of delivery with regard to bytes on other 327 streams. On the wire, data is framed into QUIC STREAM frames, but 328 this framing is invisible to the HTTP framing layer. The transport 329 layer buffers and orders received QUIC STREAM frames, exposing the 330 data contained within as a reliable byte stream to the application. 332 QUIC streams can be either unidirectional, carrying data only from 333 initiator to receiver, or bidirectional. Streams can be initiated by 334 either the client or the server. For more detail on QUIC streams, 335 see Section 2 of [QUIC-TRANSPORT]. 337 When HTTP headers and data are sent over QUIC, the QUIC layer handles 338 most of the stream management. HTTP does not need to do any separate 339 multiplexing when using QUIC - data sent over a QUIC stream always 340 maps to a particular HTTP transaction or connection context. 342 3.1. Bidirectional Streams 344 All client-initiated bidirectional streams are used for HTTP requests 345 and responses. A bidirectional stream ensures that the response can 346 be readily correlated with the request. This means that the client's 347 first request occurs on QUIC stream 0, with subsequent requests on 348 stream 4, 8, and so on. In order to permit these streams to open, an 349 HTTP/3 client SHOULD send non-zero values for the QUIC transport 350 parameters "initial_max_stream_data_bidi_local". An HTTP/3 server 351 SHOULD send non-zero values for the QUIC transport parameters 352 "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". 353 It is recommended that "initial_max_bidi_streams" be no smaller than 354 100, so as to not unnecessarily limit parallelism. 356 These streams carry frames related to the request/response (see 357 Section 5.1). When a stream terminates cleanly, if the last frame on 358 the stream was truncated, this MUST be treated as a connection error 359 (see HTTP_MALFORMED_FRAME in Section 8.1). Streams which terminate 360 abruptly may be reset at any point in the frame. 362 HTTP/3 does not use server-initiated bidirectional streams; clients 363 MUST omit or specify a value of zero for the QUIC transport parameter 364 "initial_max_bidi_streams". 366 3.2. Unidirectional Streams 368 Unidirectional streams, in either direction, are used for a range of 369 purposes. The purpose is indicated by a stream type, which is sent 370 as a single byte header at the start of the stream. The format and 371 structure of data that follows this header is determined by the 372 stream type. 374 0 1 2 3 4 5 6 7 375 +-+-+-+-+-+-+-+-+ 376 |Stream Type (8)| 377 +-+-+-+-+-+-+-+-+ 379 Figure 1: Unidirectional Stream Header 381 Some stream types are reserved (Section 3.2.3). Two stream types are 382 defined in this document: control streams (Section 3.2.1) and push 383 streams (Section 3.2.2). Other stream types can be defined by 384 extensions to HTTP/3; see Section 7 for more details. 386 Both clients and servers SHOULD send a value of three or greater for 387 the QUIC transport parameter "initial_max_uni_streams". 389 If the stream header indicates a stream type which is not supported 390 by the recipient, the remainder of the stream cannot be consumed as 391 the semantics are unknown. Recipients of unknown stream types MAY 392 trigger a QUIC STOP_SENDING frame with an error code of 393 HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an 394 error of any kind. 396 Implementations MAY send stream types before knowing whether the peer 397 supports them. However, stream types which could modify the state or 398 semantics of existing protocol components, including QPACK or other 399 extensions, MUST NOT be sent until the peer is known to support them. 401 3.2.1. Control Streams 403 A control stream is indicated by a stream type of "0x43" (ASCII 'C'). 404 Data on this stream consists of HTTP/3 frames, as defined in 405 Section 4.2. 407 Each side MUST initiate a single control stream at the beginning of 408 the connection and send its SETTINGS frame as the first frame on this 409 stream. If the first frame of the control stream is any other frame 410 type, this MUST be treated as a connection error of type 411 HTTP_MISSING_SETTINGS. Only one control stream per peer is 412 permitted; receipt of a second stream which claims to be a control 413 stream MUST be treated as a connection error of type 414 HTTP_WRONG_STREAM_COUNT. If the control stream is closed at any 415 point, this MUST be treated as a connection error of type 416 HTTP_CLOSED_CRITICAL_STREAM. 418 A pair of unidirectional streams is used rather than a single 419 bidirectional stream. This allows either peer to send data as soon 420 they are able. Depending on whether 0-RTT is enabled on the 421 connection, either client or server might be able to send stream data 422 first after the cryptographic handshake completes. 424 3.2.2. Push Streams 426 A push stream is indicated by a stream type of "0x50" (ASCII 'P'), 427 followed by the Push ID of the promise that it fulfills, encoded as a 428 variable-length integer. The remaining data on this stream consists 429 of HTTP/3 frames, as defined in Section 4.2, and fulfills a promised 430 server push. Server push and Push IDs are described in Section 5.4. 432 Only servers can push; if a server receives a client-initiated push 433 stream, this MUST be treated as a stream error of type 434 HTTP_WRONG_STREAM_DIRECTION. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |Stream Type (8)| Push ID (i) ... 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Figure 2: Push Stream Header 444 Each Push ID MUST only be used once in a push stream header. If a 445 push stream header includes a Push ID that was used in another push 446 stream header, the client MUST treat this as a connection error of 447 type HTTP_DUPLICATE_PUSH. 449 3.2.3. Reserved Stream Types 451 Stream types of the format "0x1f * N" are reserved to exercise the 452 requirement that unknown types be ignored. These streams have no 453 semantic meaning, and can be sent when application-layer padding is 454 desired. They MAY also be sent on connections where no request data 455 is currently being transferred. Endpoints MUST NOT consider these 456 streams to have any meaning upon receipt. 458 The payload and length of the stream are selected in any manner the 459 implementation chooses. 461 4. HTTP Framing Layer 463 Frames are used on control streams, request streams, and push 464 streams. This section describes HTTP framing in QUIC. For a 465 comparison with HTTP/2 frames, see Appendix A.2. 467 4.1. Frame Layout 469 All frames have the following format: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Length (i) ... 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type (8) | Frame Payload (*) ... 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 3: HTTP/3 frame format 481 A frame includes the following fields: 483 Length: A variable-length integer that describes the length of the 484 Frame Payload. This length does not include the Type field. 486 Type: An 8-bit type for the frame. 488 Frame Payload: A payload, the semantics of which are determined by 489 the Type field. 491 Each frame's payload MUST contain exactly the identified fields. A 492 frame that contains additional bytes after the identified fields or a 493 frame that terminates before the end of the identified fields MUST be 494 treated as a connection error of type HTTP_MALFORMED_FRAME. 496 4.2. Frame Definitions 498 4.2.1. DATA 500 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 501 bytes associated with an HTTP request or response payload. 503 DATA frames MUST be associated with an HTTP request or response. If 504 a DATA frame is received on either control stream, the recipient MUST 505 respond with a connection error (Section 8) of type 506 HTTP_WRONG_STREAM. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Payload (*) ... 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 4: DATA frame payload 516 4.2.2. HEADERS 518 The HEADERS frame (type=0x1) is used to carry a header block, 519 compressed using QPACK. See [QPACK] for more details. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Header Block (*) ... 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 5: HEADERS frame payload 529 HEADERS frames can only be sent on request / push streams. 531 4.2.3. PRIORITY 533 The PRIORITY (type=0x02) frame specifies the client-advised priority 534 of a stream. 536 When opening a new request stream, a PRIORITY frame MAY be sent as 537 the first frame of the stream creating a dependency on an existing 538 element. In order to ensure that prioritization is processed in a 539 consistent order, any subsequent PRIORITY frames MUST be sent on the 540 control stream. A PRIORITY frame received after other frames on a 541 request stream MUST be treated as a stream error of type 542 HTTP_UNEXPECTED_FRAME. 544 If, by the time a new request stream is opened, its priority 545 information has already been received via the control stream, the 546 PRIORITY frame sent on the request stream MUST be ignored. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |PT |DT | Empty | [Prioritized Element ID (i)] ... 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | [Element Dependency ID (i)] ... 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Weight (8) | 556 +-+-+-+-+-+-+-+-+ 558 Figure 6: PRIORITY frame payload 560 The PRIORITY frame payload has the following fields: 562 Prioritized Type: A two-bit field indicating the type of element 563 being prioritized. When sent on a request stream, this MUST be 564 set to "11". When sent on the control stream, this MUST NOT be 565 set to "11". 567 Dependency Type: A two-bit field indicating the type of element 568 being depended on. 570 Empty: A four-bit field which MUST be zero when sent and MUST be 571 ignored on receipt. 573 Prioritized Element ID: A variable-length integer that identifies 574 the element being prioritized. Depending on the value of 575 Prioritized Type, this contains the Stream ID of a request stream, 576 the Push ID of a promised resource, a Placeholder ID of a 577 placeholder, or is absent. 579 Element Dependency ID: A variable-length integer that identifies the 580 element on which a dependency is being expressed. Depending on 581 the value of Dependency Type, this contains the Stream ID of a 582 request stream, the Push ID of a promised resource, the 583 Placeholder ID of a placeholder, or is absent. For details of 584 dependencies, see Section 5.3 and [RFC7540], Section 5.3. 586 Weight: An unsigned 8-bit integer representing a priority weight for 587 the prioritized element (see [RFC7540], Section 5.3). Add one to 588 the value to obtain a weight between 1 and 256. 590 A PRIORITY frame identifies an element to prioritize, and an element 591 upon which it depends. A Prioritized ID or Dependency ID identifies 592 a client-initiated request using the corresponding stream ID, a 593 server push using a Push ID (see Section 4.2.6), or a placeholder 594 using a Placeholder ID (see Section 5.3.1). 596 The values for the Prioritized Element Type and Element Dependency 597 Type imply the interpretation of the associated Element ID fields. 599 +-----------+------------------+---------------------------------+ 600 | Type Bits | Type Description | Prioritized Element ID Contents | 601 +-----------+------------------+---------------------------------+ 602 | 00 | Request stream | Stream ID | 603 | | | | 604 | 01 | Push stream | Push ID | 605 | | | | 606 | 10 | Placeholder | Placeholder ID | 607 | | | | 608 | 11 | Current stream | Absent | 609 +-----------+------------------+---------------------------------+ 610 +-----------+------------------+--------------------------------+ 611 | Type Bits | Type Description | Element Dependency ID Contents | 612 +-----------+------------------+--------------------------------+ 613 | 00 | Request stream | Stream ID | 614 | | | | 615 | 01 | Push stream | Push ID | 616 | | | | 617 | 10 | Placeholder | Placeholder ID | 618 | | | | 619 | 11 | Root of the tree | Absent | 620 +-----------+------------------+--------------------------------+ 622 Note that the root of the tree cannot be referenced using a Stream ID 623 of 0, as in [RFC7540]; QUIC stream 0 carries a valid HTTP request. 624 The root of the tree cannot be reprioritized. A PRIORITY frame sent 625 on a request stream with the Prioritized Element Type set to any 626 value other than "11" or which expresses a dependency on a request 627 with a greater Stream ID than the current stream MUST be treated as a 628 stream error of type HTTP_MALFORMED_FRAME. Likewise, a PRIORITY 629 frame sent on a control stream with the Prioritized Element Type set 630 to "11" MUST be treated as a connection error of type 631 HTTP_MALFORMED_FRAME. 633 When a PRIORITY frame claims to reference a request, the associated 634 ID MUST identify a client-initiated bidirectional stream. A server 635 MUST treat receipt of PRIORITY frame with a Stream ID of any other 636 type as a connection error of type HTTP_MALFORMED_FRAME. 638 A PRIORITY frame that references a non-existent Push ID or a 639 Placeholder ID greater than the server's limit MUST be treated as an 640 HTTP_MALFORMED_FRAME error. 642 A PRIORITY frame received on any stream other than a request or 643 control stream MUST be treated as a connection error of type 644 HTTP_WRONG_STREAM. 646 PRIORITY frames received by a client MUST be treated as a stream 647 error of type HTTP_UNEXPECTED_FRAME. 649 4.2.4. CANCEL_PUSH 651 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 652 server push prior to the push stream being created. The CANCEL_PUSH 653 frame identifies a server push by Push ID (see Section 4.2.6), 654 encoded as a variable-length integer. 656 When a server receives this frame, it aborts sending the response for 657 the identified server push. If the server has not yet started to 658 send the server push, it can use the receipt of a CANCEL_PUSH frame 659 to avoid opening a push stream. If the push stream has been opened 660 by the server, the server SHOULD send a QUIC RESET_STREAM frame on 661 that stream and cease transmission of the response. 663 A server can send this frame to indicate that it will not be 664 fulfilling a promise prior to creation of a push stream. Once the 665 push stream has been created, sending CANCEL_PUSH has no effect on 666 the state of the push stream. A QUIC RESET_STREAM frame SHOULD be 667 used instead to abort transmission of the server push response. 669 A CANCEL_PUSH frame is sent on the control stream. Sending a 670 CANCEL_PUSH frame on a stream other than the control stream MUST be 671 treated as a stream error of type HTTP_WRONG_STREAM. 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Push ID (i) ... 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Figure 7: CANCEL_PUSH frame payload 681 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 682 integer. The Push ID identifies the server push that is being 683 cancelled (see Section 4.2.6). 685 If the client receives a CANCEL_PUSH frame, that frame might identify 686 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 688 An endpoint MUST treat a CANCEL_PUSH frame which does not contain 689 exactly one properly-formatted variable-length integer as a 690 connection error of type HTTP_MALFORMED_FRAME. 692 4.2.5. SETTINGS 694 The SETTINGS frame (type=0x4) conveys configuration parameters that 695 affect how endpoints communicate, such as preferences and constraints 696 on peer behavior. Individually, a SETTINGS parameter can also be 697 referred to as a "setting"; the identifier and value of each setting 698 parameter can be referred to as a "setting identifier" and a "setting 699 value". 701 SETTINGS parameters are not negotiated; they describe characteristics 702 of the sending peer, which can be used by the receiving peer. 703 However, a negotiation can be implied by the use of SETTINGS - each 704 peer uses SETTINGS to advertise a set of supported values. The 705 definition of the setting would describe how each peer combines the 706 two sets to conclude which choice will be used. SETTINGS does not 707 provide a mechanism to identify when the choice takes effect. 709 Different values for the same parameter can be advertised by each 710 peer. For example, a client might be willing to consume a very large 711 response header, while servers are more cautious about request size. 713 Parameters MUST NOT occur more than once. A receiver MAY treat the 714 presence of the same parameter more than once as a connection error 715 of type HTTP_MALFORMED_FRAME. 717 The payload of a SETTINGS frame consists of zero or more parameters, 718 each consisting of an unsigned 16-bit setting identifier and a value 719 which uses the QUIC variable-length integer encoding. 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Identifier (16) | Value (i) ... 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Figure 8: SETTINGS parameter format 729 Each value MUST be compared against the remaining length of the 730 SETTINGS frame. A variable-length integer value which cannot fit 731 within the remaining length of the SETTINGS frame MUST cause the 732 SETTINGS frame to be considered malformed and trigger a connection 733 error of type HTTP_MALFORMED_FRAME. 735 An implementation MUST ignore the contents for any SETTINGS 736 identifier it does not understand. 738 SETTINGS frames always apply to a connection, never a single stream. 739 A SETTINGS frame MUST be sent as the first frame of each control 740 stream (see Section 3.2.1) by each peer, and MUST NOT be sent 741 subsequently or on any other stream. If an endpoint receives a 742 SETTINGS frame on a different stream, the endpoint MUST respond with 743 a connection error of type HTTP_WRONG_STREAM. If an endpoint 744 receives a second SETTINGS frame, the endpoint MUST respond with a 745 connection error of type HTTP_UNEXPECTED_FRAME. 747 The SETTINGS frame affects connection state. A badly formed or 748 incomplete SETTINGS frame MUST be treated as a connection error 749 (Section 8) of type HTTP_MALFORMED_FRAME. 751 4.2.5.1. Defined SETTINGS Parameters 753 The following settings are defined in HTTP/3: 755 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. 756 See Section 5.1.1 for usage. 758 SETTINGS_NUM_PLACEHOLDERS (0x8): The default value is 0. However, 759 this value SHOULD be set to a non-zero value by servers. See 760 Section 5.3.1 for usage. 762 Setting identifiers of the format "0x?a?a" are reserved to exercise 763 the requirement that unknown identifiers be ignored. Such settings 764 have no defined meaning. Endpoints SHOULD include at least one such 765 setting in their SETTINGS frame. Endpoints MUST NOT consider such 766 settings to have any meaning upon receipt. 768 Because the setting has no defined meaning, the value of the setting 769 can be any value the implementation selects. 771 Additional settings can be defined by extensions to HTTP/3; see 772 Section 7 for more details. 774 4.2.5.2. Initialization 776 An HTTP implementation MUST NOT send frames or requests which would 777 be invalid based on its current understanding of the peer's settings. 778 All settings begin at an initial value, and are updated upon receipt 779 of a SETTINGS frame. For servers, the initial value of each client 780 setting is the default value. 782 For clients using a 1-RTT QUIC connection, the initial value of each 783 server setting is the default value. When a 0-RTT QUIC connection is 784 being used, the initial value of each server setting is the value 785 used in the previous session. Clients MUST store the settings the 786 server provided in the session being resumed and MUST comply with 787 stored settings until the current server settings are received. 789 A server can remember the settings that it advertised, or store an 790 integrity-protected copy of the values in the ticket and recover the 791 information when accepting 0-RTT data. A server uses the HTTP/3 792 settings values in determining whether to accept 0-RTT data. 794 A server MAY accept 0-RTT and subsequently provide different settings 795 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 796 SETTINGS frame MUST NOT reduce any limits or alter any values that 797 might be violated by the client with its 0-RTT data. 799 4.2.6. PUSH_PROMISE 801 The PUSH_PROMISE frame (type=0x05) is used to carry a promised 802 request header set from server to client, as in HTTP/2. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Push ID (i) ... 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Header Block (*) ... 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Figure 9: PUSH_PROMISE frame payload 814 The payload consists of: 816 Push ID: A variable-length integer that identifies the server push 817 operation. A Push ID is used in push stream headers 818 (Section 5.4), CANCEL_PUSH frames (Section 4.2.4), DUPLICATE_PUSH 819 frames (Section 4.2.9), and PRIORITY frames (Section 4.2.3). 821 Header Block: QPACK-compressed request header fields for the 822 promised response. See [QPACK] for more details. 824 A server MUST NOT use a Push ID that is larger than the client has 825 provided in a MAX_PUSH_ID frame (Section 4.2.8) and MUST NOT use the 826 same Push ID in multiple PUSH_PROMISE frames. A client MUST treat 827 receipt of a PUSH_PROMISE that contains a larger Push ID than the 828 client has advertised or a Push ID which has already been promised as 829 a connection error of type HTTP_MALFORMED_FRAME. 831 See Section 5.4 for a description of the overall server push 832 mechanism. 834 4.2.7. GOAWAY 836 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 837 a connection by a server. GOAWAY allows a server to stop accepting 838 new requests while still finishing processing of previously received 839 requests. This enables administrative actions, like server 840 maintenance. GOAWAY by itself does not close a connection. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Stream ID (i) ... 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Figure 10: GOAWAY frame payload 850 The GOAWAY frame carries a QUIC Stream ID for a client-initiated 851 bidirectional stream encoded as a variable-length integer. A client 852 MUST treat receipt of a GOAWAY frame containing a Stream ID of any 853 other type as a connection error of type HTTP_MALFORMED_FRAME. 855 Clients do not need to send GOAWAY to initiate a graceful shutdown; 856 they simply stop making new requests. A server MUST treat receipt of 857 a GOAWAY frame on any stream as a connection error (Section 8) of 858 type HTTP_UNEXPECTED_FRAME. 860 The GOAWAY frame applies to the connection, not a specific stream. A 861 client MUST treat a GOAWAY frame on a stream other than the control 862 stream as a connection error (Section 8) of type 863 HTTP_UNEXPECTED_FRAME. 865 See Section 6.2 for more information on the use of the GOAWAY frame. 867 4.2.8. MAX_PUSH_ID 869 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 870 number of server pushes that the server can initiate. This sets the 871 maximum value for a Push ID that the server can use in a PUSH_PROMISE 872 frame. Consequently, this also limits the number of push streams 873 that the server can initiate in addition to the limit set by the QUIC 874 MAX_STREAM_ID frame. 876 The MAX_PUSH_ID frame is always sent on a control stream. Receipt of 877 a MAX_PUSH_ID frame on any other stream MUST be treated as a 878 connection error of type HTTP_WRONG_STREAM. 880 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 881 receipt of a MAX_PUSH_ID frame as a connection error of type 882 HTTP_MALFORMED_FRAME. 884 The maximum Push ID is unset when a connection is created, meaning 885 that a server cannot push until it receives a MAX_PUSH_ID frame. A 886 client that wishes to manage the number of promised server pushes can 887 increase the maximum Push ID by sending MAX_PUSH_ID frames as the 888 server fulfills or cancels server pushes. 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Push ID (i) ... 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Figure 11: MAX_PUSH_ID frame payload 898 The MAX_PUSH_ID frame carries a single variable-length integer that 899 identifies the maximum value for a Push ID that the server can use 900 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 901 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 902 previously received MUST be treated as a connection error of type 903 HTTP_MALFORMED_FRAME. 905 A server MUST treat a MAX_PUSH_ID frame payload that does not contain 906 a single variable-length integer as a connection error of type 907 HTTP_MALFORMED_FRAME. 909 4.2.9. DUPLICATE_PUSH 911 The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate 912 that an existing pushed resource is related to multiple client 913 requests. 915 The DUPLICATE_PUSH frame is always sent on a request stream. Receipt 916 of a DUPLICATE_PUSH frame on any other stream MUST be treated as a 917 connection error of type HTTP_WRONG_STREAM. 919 A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat 920 the receipt of a DUPLICATE_PUSH frame as a connection error of type 921 HTTP_MALFORMED_FRAME. 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Push ID (i) ... 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Figure 12: DUPLICATE_PUSH frame payload 931 The DUPLICATE_PUSH frame carries a single variable-length integer 932 that identifies the Push ID of a resource that the server has 933 previously promised (see Section 4.2.6). A server MUST treat a 934 DUPLICATE_PUSH frame payload that does not contain a single variable- 935 length integer as a connection error of type HTTP_MALFORMED_FRAME. 937 This frame allows the server to use the same server push in response 938 to multiple concurrent requests. Referencing the same server push 939 ensures that a promise can be made in relation to every response in 940 which server push might be needed without duplicating request headers 941 or pushed responses. 943 Allowing duplicate references to the same Push ID is primarily to 944 reduce duplication caused by concurrent requests. A server SHOULD 945 avoid reusing a Push ID over a long period. Clients are likely to 946 consume server push responses and not retain them for reuse over 947 time. Clients that see a DUPLICATE_PUSH that uses a Push ID that 948 they have since consumed and discarded are forced to ignore the 949 DUPLICATE_PUSH. 951 4.2.10. Reserved Frame Types 953 Frame types of the format "0xb + (0x1f * N)" are reserved to exercise 954 the requirement that unknown types be ignored (Section 7). These 955 frames have no semantic value, and can be sent when application-layer 956 padding is desired. They MAY also be sent on connections where no 957 request data is currently being transferred. Endpoints MUST NOT 958 consider these frames to have any meaning upon receipt. 960 The payload and length of the frames are selected in any manner the 961 implementation chooses. 963 5. HTTP Request Lifecycle 965 5.1. HTTP Message Exchanges 967 A client sends an HTTP request on a client-initiated bidirectional 968 QUIC stream. A server sends an HTTP response on the same stream as 969 the request. 971 An HTTP message (request or response) consists of: 973 1. the message header (see [RFC7230], Section 3.2), sent as a single 974 HEADERS frame (see Section 4.2.2), 976 2. the payload body (see [RFC7230], Section 3.3), sent as a series 977 of DATA frames (see Section 4.2.1), 979 3. optionally, one HEADERS frame containing the trailer-part, if 980 present (see [RFC7230], Section 4.1.2). 982 A server MAY interleave one or more PUSH_PROMISE frames (see 983 Section 4.2.6) with the frames of a response message. These 984 PUSH_PROMISE frames are not part of the response; see Section 5.4 for 985 more details. 987 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 988 MUST NOT be used. 990 Trailing header fields are carried in an additional HEADERS frame 991 following the body. Senders MUST send only one HEADERS frame in the 992 trailers section; receivers MUST discard any subsequent HEADERS 993 frames. 995 A response MAY consist of multiple messages when and only when one or 996 more informational responses (1xx, see [RFC7231], Section 6.2) 997 precede a final response to the same request. Non-final responses do 998 not contain a payload body or trailers. 1000 An HTTP request/response exchange fully consumes a bidirectional QUIC 1001 stream. After sending a request, a client MUST close the stream for 1002 sending. Unless using the CONNECT method (see Section 5.2), clients 1003 MUST NOT make stream closure dependent on receiving a response to 1004 their request. After sending a final response, the server MUST close 1005 the stream for sending. At this point, the QUIC stream is fully 1006 closed. 1008 When a stream is closed, this indicates the end of an HTTP message. 1009 Because some messages are large or unbounded, endpoints SHOULD begin 1010 processing partial HTTP messages once enough of the message has been 1011 received to make progress. If a client stream terminates without 1012 enough of the HTTP message to provide a complete response, the server 1013 SHOULD abort its response with the error code 1014 HTTP_INCOMPLETE_REQUEST. 1016 A server can send a complete response prior to the client sending an 1017 entire request if the response does not depend on any portion of the 1018 request that has not been sent and received. When this is true, a 1019 server MAY request that the client abort transmission of a request 1020 without error by triggering a QUIC STOP_SENDING frame with error code 1021 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 1022 its stream. Clients MUST NOT discard complete responses as a result 1023 of having their request terminated abruptly, though clients can 1024 always discard responses at their discretion for other reasons. 1026 5.1.1. Header Formatting and Compression 1028 HTTP message headers carry information as a series of key-value 1029 pairs, called header fields. For a listing of registered HTTP header 1030 fields, see the "Message Header Field" registry maintained at 1031 https://www.iana.org/assignments/message-headers [4]. 1033 Just as in previous versions of HTTP, header field names are strings 1034 of ASCII characters that are compared in a case-insensitive fashion. 1035 Properties of HTTP header field names and values are discussed in 1036 more detail in Section 3.2 of [RFC7230], though the wire rendering in 1037 HTTP/3 differs. As in HTTP/2, header field names MUST be converted 1038 to lowercase prior to their encoding. A request or response 1039 containing uppercase header field names MUST be treated as malformed. 1041 As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with 1042 the ':' character (ASCII 0x3a) to convey the target URI, the method 1043 of the request, and the status code for the response. These pseudo- 1044 header fields are defined in Section 8.1.2.3 and 8.1.2.4 of 1045 [RFC7540]. Pseudo-header fields are not HTTP header fields. 1046 Endpoints MUST NOT generate pseudo-header fields other than those 1047 defined in [RFC7540]. The restrictions on the use of pseudo-header 1048 fields in Section 8.1.2.1 of [RFC7540] also apply to HTTP/3. 1050 HTTP/3 uses QPACK header compression as described in [QPACK], a 1051 variation of HPACK which allows the flexibility to avoid header- 1052 compression-induced head-of-line blocking. See that document for 1053 additional details. 1055 An HTTP/3 implementation MAY impose a limit on the maximum size of 1056 the header it will accept on an individual HTTP message; encountering 1057 a larger message header SHOULD be treated as a stream error of type 1058 "HTTP_EXCESSIVE_LOAD". If an implementation wishes to advise its 1059 peer of this limit, it can be conveyed as a number of bytes in the 1060 "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. The size of a header list 1061 is calculated based on the uncompressed size of header fields, 1062 including the length of the name and value in bytes plus an overhead 1063 of 32 bytes for each header field. 1065 5.1.2. Request Cancellation 1067 Either client or server can cancel requests by aborting the stream 1068 (QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with 1069 an error code of HTTP_REQUEST_CANCELLED (Section 8.1). When the 1070 client cancels a response, it indicates that this response is no 1071 longer of interest. Implementations SHOULD cancel requests by 1072 aborting both directions of a stream. 1074 When the server aborts its response stream using 1075 HTTP_REQUEST_CANCELLED, it indicates that no application processing 1076 was performed. The client can treat requests cancelled by the server 1077 as though they had never been sent at all, thereby allowing them to 1078 be retried later on a new connection. Servers MUST NOT use the 1079 HTTP_REQUEST_CANCELLED status for requests which were partially or 1080 fully processed. 1082 Note: In this context, "processed" means that some data from the 1083 stream was passed to some higher layer of software that might have 1084 taken some action as a result. 1086 If a stream is cancelled after receiving a complete response, the 1087 client MAY ignore the cancellation and use the response. However, if 1088 a stream is cancelled after receiving a partial response, the 1089 response SHOULD NOT be used. Automatically retrying such requests is 1090 not possible, unless this is otherwise permitted (e.g., idempotent 1091 actions like GET, PUT, or DELETE). 1093 5.2. The CONNECT Method 1095 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 1096 used with HTTP proxies to establish a TLS session with an origin 1097 server for the purposes of interacting with "https" resources. In 1098 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 1099 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 1100 establish a tunnel over a single HTTP/2 stream to a remote host for 1101 similar purposes. 1103 A CONNECT request in HTTP/3 functions in the same manner as in 1104 HTTP/2. The request MUST be formatted as described in [RFC7540], 1105 Section 8.3. A CONNECT request that does not conform to these 1106 restrictions is malformed. The request stream MUST NOT be closed at 1107 the end of the request. 1109 A proxy that supports CONNECT establishes a TCP connection 1110 ([RFC0793]) to the server identified in the ":authority" pseudo- 1111 header field. Once this connection is successfully established, the 1112 proxy sends a HEADERS frame containing a 2xx series status code to 1113 the client, as defined in [RFC7231], Section 4.3.6. 1115 All DATA frames on the stream correspond to data sent or received on 1116 the TCP connection. Any DATA frame sent by the client is transmitted 1117 by the proxy to the TCP server; data received from the TCP server is 1118 packaged into DATA frames by the proxy. Note that the size and 1119 number of TCP segments is not guaranteed to map predictably to the 1120 size and number of HTTP DATA or QUIC STREAM frames. 1122 The TCP connection can be closed by either peer. When the client 1123 ends the request stream (that is, the receive stream at the proxy 1124 enters the "Data Recvd" state), the proxy will set the FIN bit on its 1125 connection to the TCP server. When the proxy receives a packet with 1126 the FIN bit set, it will terminate the send stream that it sends to 1127 the client. TCP connections which remain half-closed in a single 1128 direction are not invalid, but are often handled poorly by servers, 1129 so clients SHOULD NOT close a stream for sending while they still 1130 expect to receive data from the target of the CONNECT. 1132 A TCP connection error is signaled with QUIC RESET_STREAM frame. A 1133 proxy treats any error in the TCP connection, which includes 1134 receiving a TCP segment with the RST bit set, as a stream error of 1135 type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, a proxy MUST 1136 send a TCP segment with the RST bit set if it detects an error with 1137 the stream or the QUIC connection. 1139 5.3. Request Prioritization 1141 HTTP/3 uses a priority scheme similar to that described in [RFC7540], 1142 Section 5.3. In this priority scheme, a given stream can be 1143 designated as dependent upon another request, which expresses the 1144 preference that the latter stream (the "parent" request) be allocated 1145 resources before the former stream (the "dependent" request). Taken 1146 together, the dependencies across all requests in a connection form a 1147 dependency tree. 1149 When a client request is first sent, its parent and weight are 1150 determined by the PRIORITY frame (see Section 4.2.3) which begins the 1151 stream, if present. Otherwise, the element is dependent on the root 1152 of the priority tree. Placeholders are also dependent on the root of 1153 the priority tree when first allocated. Pushed streams are initially 1154 dependent on the client request on which the PUSH_PROMISE frame was 1155 sent. In all cases, elements are assigned an initial weight of 16 1156 unless an PRIORITY frame begins the stream. 1158 The structure of the dependency tree changes as PRIORITY frames on 1159 the control stream modify the dependency links between requests. The 1160 PRIORITY frame Section 4.2.3 identifies a prioritized element. The 1161 elements which can be prioritized are: 1163 o Requests, identified by the ID of the request stream 1165 o Pushes, identified by the Push ID of the promised resource 1166 (Section 4.2.6) 1168 o Placeholders, identified by a Placeholder ID 1170 An element can depend on another element or on the root of the tree. 1171 A reference to an element which is no longer in the tree is treated 1172 as a reference to the root of the tree. 1174 Due to reordering between streams, an element can also be prioritized 1175 which is not yet in the tree. Such elements are added to the tree 1176 with the requested priority. 1178 5.3.1. Placeholders 1180 In HTTP/2, certain implementations used closed or unused streams as 1181 placeholders in describing the relative priority of requests. This 1182 created confusion as servers could not reliably identify which 1183 elements of the priority tree could be discarded safely. Clients 1184 could potentially reference closed streams long after the server had 1185 discarded state, leading to disparate views of the prioritization the 1186 client had attempted to express. 1188 In HTTP/3, a number of placeholders are explicitly permitted by the 1189 server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because the 1190 server commits to maintaining these IDs in the tree, clients can use 1191 them with confidence that the server will not have discarded the 1192 state. Clients MUST NOT send the "SETTINGS_NUM_PLACEHOLDERS" 1193 setting; receipt of this setting by a server MUST be treated as a 1194 connection error of type "HTTP_WRONG_SETTING_DIRECTION". 1196 Placeholders are identified by an ID between zero and one less than 1197 the number of placeholders the server has permitted. 1199 Like streams, placeholders have priority information associated with 1200 them. 1202 5.3.2. Priority Tree Maintenance 1204 Servers can aggressively prune inactive regions from the priority 1205 tree, because placeholders will be used to "root" any persistent 1206 structure of the tree which the client cares about retaining. For 1207 prioritization purposes, a node in the tree is considered "inactive" 1208 when the corresponding stream has been closed for at least two round- 1209 trip times (using any reasonable estimate available on the server). 1210 This delay helps mitigate race conditions where the server has pruned 1211 a node the client believed was still active and used as a Stream 1212 Dependency. 1214 Specifically, the server MAY at any time: 1216 o Identify and discard branches of the tree containing only inactive 1217 nodes (i.e. a node with only other inactive nodes as descendants, 1218 along with those descendants) 1220 o Identify and condense interior regions of the tree containing only 1221 inactive nodes, allocating weight appropriately 1222 x x x 1223 | | | 1224 P P P 1225 / \ | | 1226 I I ==> I ==> A 1227 / \ | | 1228 A I A A 1229 | | 1230 A A 1232 Figure 13: Example of Priority Tree Pruning 1234 In the example in Figure 13, "P" represents a Placeholder, "A" 1235 represents an active node, and "I" represents an inactive node. In 1236 the first step, the server discards two inactive branches (each a 1237 single node). In the second step, the server condenses an interior 1238 inactive node. Note that these transformations will result in no 1239 change in the resources allocated to a particular active stream. 1241 Clients SHOULD assume the server is actively performing such pruning 1242 and SHOULD NOT declare a dependency on a stream it knows to have been 1243 closed. 1245 5.4. Server Push 1247 HTTP/3 server push is similar to what is described in HTTP/2 1248 [RFC7540], but uses different mechanisms. 1250 Each server push is identified by a unique Push ID. This Push ID is 1251 used in a single PUSH_PROMISE frame (see Section 4.2.6) which carries 1252 the request headers, possibly included in one or more DUPLICATE_PUSH 1253 frames (see Section 4.2.9), then included with the push stream which 1254 ultimately fulfills those promises. 1256 Server push is only enabled on a connection when a client sends a 1257 MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server 1258 push until it receives a MAX_PUSH_ID frame. A client sends 1259 additional MAX_PUSH_ID frames to control the number of pushes that a 1260 server can promise. A server SHOULD use Push IDs sequentially, 1261 starting at 0. A client MUST treat receipt of a push stream with a 1262 Push ID that is greater than the maximum Push ID as a connection 1263 error of type HTTP_PUSH_LIMIT_EXCEEDED. 1265 The header of the request message is carried by a PUSH_PROMISE frame 1266 (see Section 4.2.6) on the request stream which generated the push. 1267 This allows the server push to be associated with a client request. 1268 Ordering of a PUSH_PROMISE in relation to certain parts of the 1269 response is important (see Section 8.2.1 of [RFC7540]). Promised 1270 requests MUST conform to the requirements in Section 8.2 of 1271 [RFC7540]. 1273 The same server push can be associated with additional client 1274 requests using a DUPLICATE_PUSH frame (see Section 4.2.9). Ordering 1275 of a DUPLICATE_PUSH in relation to certain parts of the response is 1276 similarly important. Due to reordering, DUPLICATE_PUSH frames can 1277 arrive before the corresponding PUSH_PROMISE frame, in which case the 1278 request headers of the push would not be immediately available. 1279 Clients which receive a DUPLICATE_PUSH frame for an as-yet-unknown 1280 Push ID can either delay generating new requests for content 1281 referenced following the DUPLICATE_PUSH frame until the request 1282 headers become available, or can initiate requests for discovered 1283 resources and cancel the requests if the requested resource is 1284 already being pushed. 1286 When a server later fulfills a promise, the server push response is 1287 conveyed on a push stream (see Section 3.2.2). The push stream 1288 identifies the Push ID of the promise that it fulfills, then contains 1289 a response to the promised request using the same format described 1290 for responses in Section 5.1. 1292 If a promised server push is not needed by the client, the client 1293 SHOULD send a CANCEL_PUSH frame. If the push stream is already open 1294 or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING 1295 frame with an appropriate error code can also be used (e.g., 1296 HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This 1297 asks the server not to transfer additional data and indicates that it 1298 will be discarded upon receipt. 1300 6. Connection Closure 1302 Once established, an HTTP/3 connection can be used for many requests 1303 and responses over time until the connection is closed. Connection 1304 closure can happen in any of several different ways. 1306 6.1. Idle Connections 1308 Each QUIC endpoint declares an idle timeout during the handshake. If 1309 the connection remains idle (no packets received) for longer than 1310 this duration, the peer will assume that the connection has been 1311 closed. HTTP/3 implementations will need to open a new connection 1312 for new requests if the existing connection has been idle for longer 1313 than the server's advertised idle timeout, and SHOULD do so if 1314 approaching the idle timeout. 1316 HTTP clients are expected to use QUIC PING frames to keep connections 1317 open while there are responses outstanding for requests or server 1318 pushes. If the client is not expecting a response from the server, 1319 allowing an idle connection to time out is preferred over expending 1320 effort maintaining a connection that might not be needed. A gateway 1321 MAY use PING to maintain connections in anticipation of need rather 1322 than incur the latency cost of connection establishment to servers. 1323 Servers SHOULD NOT use PING frames to keep a connection open. 1325 6.2. Connection Shutdown 1327 Even when a connection is not idle, either endpoint can decide to 1328 stop using the connection and let the connection close gracefully. 1329 Since clients drive request generation, clients perform a connection 1330 shutdown by not sending additional requests on the connection; 1331 responses and pushed responses associated to previous requests will 1332 continue to completion. Servers perform the same function by 1333 communicating with clients. 1335 Servers initiate the shutdown of a connection by sending a GOAWAY 1336 frame (Section 4.2.7). The GOAWAY frame indicates that client- 1337 initiated requests on lower stream IDs were or might be processed in 1338 this connection, while requests on the indicated stream ID and 1339 greater were not accepted. This enables client and server to agree 1340 on which requests were accepted prior to the connection shutdown. 1341 This identifier MAY be lower than the stream limit identified by a 1342 QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were 1343 processed. Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit 1344 after sending a GOAWAY frame. 1346 Once sent, the server MUST cancel requests sent on streams with an 1347 identifier higher than the indicated last Stream ID. Clients MUST 1348 NOT send new requests on the connection after receiving GOAWAY, 1349 although requests might already be in transit. A new connection can 1350 be established for new requests. 1352 If the client has sent requests on streams with a higher Stream ID 1353 than indicated in the GOAWAY frame, those requests are considered 1354 cancelled (Section 5.1.2). Clients SHOULD reset any streams above 1355 this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also 1356 cancel requests on streams below the indicated ID if these requests 1357 were not processed. 1359 Requests on Stream IDs less than the Stream ID in the GOAWAY frame 1360 might have been processed; their status cannot be known until they 1361 are completed successfully, reset individually, or the connection 1362 terminates. 1364 Servers SHOULD send a GOAWAY frame when the closing of a connection 1365 is known in advance, even if the advance notice is small, so that the 1366 remote peer can know whether a stream has been partially processed or 1367 not. For example, if an HTTP client sends a POST at the same time 1368 that a server closes a QUIC connection, the client cannot know if the 1369 server started to process that POST request if the server does not 1370 send a GOAWAY frame to indicate what streams it might have acted on. 1372 A client that is unable to retry requests loses all requests that are 1373 in flight when the server closes the connection. A server MAY send 1374 multiple GOAWAY frames indicating different stream IDs, but MUST NOT 1375 increase the value they send in the last Stream ID, since clients 1376 might already have retried unprocessed requests on another 1377 connection. A server that is attempting to gracefully shut down a 1378 connection SHOULD send an initial GOAWAY frame with the last Stream 1379 ID set to the current value of QUIC's MAX_STREAM_ID and SHOULD NOT 1380 increase the MAX_STREAM_ID thereafter. This signals to the client 1381 that a shutdown is imminent and that initiating further requests is 1382 prohibited. After allowing time for any in-flight requests (at least 1383 one round-trip time), the server MAY send another GOAWAY frame with 1384 an updated last Stream ID. This ensures that a connection can be 1385 cleanly shut down without losing requests. 1387 Once all accepted requests have been processed, the server can permit 1388 the connection to become idle, or MAY initiate an immediate closure 1389 of the connection. An endpoint that completes a graceful shutdown 1390 SHOULD use the HTTP_NO_ERROR code when closing the connection. 1392 6.3. Immediate Application Closure 1394 An HTTP/3 implementation can immediately close the QUIC connection at 1395 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 1396 the peer; the error code in this frame indicates to the peer why the 1397 connection is being closed. See Section 8 for error codes which can 1398 be used when closing a connection. 1400 Before closing the connection, a GOAWAY MAY be sent to allow the 1401 client to retry some requests. Including the GOAWAY frame in the 1402 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 1403 of the frame being received by clients. 1405 6.4. Transport Closure 1407 For various reasons, the QUIC transport could indicate to the 1408 application layer that the connection has terminated. This might be 1409 due to an explicit closure by the peer, a transport-level error, or a 1410 change in network topology which interrupts connectivity. 1412 If a connection terminates without a GOAWAY frame, clients MUST 1413 assume that any request which was sent, whether in whole or in part, 1414 might have been processed. 1416 7. Extensions to HTTP/3 1418 HTTP/3 permits extension of the protocol. Within the limitations 1419 described in this section, protocol extensions can be used to provide 1420 additional services or alter any aspect of the protocol. Extensions 1421 are effective only within the scope of a single HTTP/3 connection. 1423 This applies to the protocol elements defined in this document. This 1424 does not affect the existing options for extending HTTP, such as 1425 defining new methods, status codes, or header fields. 1427 Extensions are permitted to use new frame types (Section 4.2), new 1428 settings (Section 4.2.5.1), new error codes (Section 8), or new 1429 unidirectional stream types (Section 3.2). Registries are 1430 established for managing these extension points: frame types 1431 (Section 10.3), settings (Section 10.4), error codes (Section 10.5), 1432 and stream types (Section 10.6). 1434 Implementations MUST ignore unknown or unsupported values in all 1435 extensible protocol elements. Implementations MUST discard frames 1436 and unidirectional streams that have unknown or unsupported types. 1437 This means that any of these extension points can be safely used by 1438 extensions without prior arrangement or negotiation. 1440 Extensions that could change the semantics of existing protocol 1441 components MUST be negotiated before being used. For example, an 1442 extension that changes the layout of the HEADERS frame cannot be used 1443 until the peer has given a positive signal that this is acceptable. 1444 In this case, it could also be necessary to coordinate when the 1445 revised layout comes into effect. 1447 This document doesn't mandate a specific method for negotiating the 1448 use of an extension but notes that a setting (Section 4.2.5.1) could 1449 be used for that purpose. If both peers set a value that indicates 1450 willingness to use the extension, then the extension can be used. If 1451 a setting is used for extension negotiation, the default value MUST 1452 be defined in such a fashion that the extension is disabled if the 1453 setting is omitted. 1455 8. Error Handling 1457 QUIC allows the application to abruptly terminate (reset) individual 1458 streams or the entire connection when an error is encountered. These 1459 are referred to as "stream errors" or "connection errors" and are 1460 described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose 1461 to treat a stream error as a connection error. 1463 This section describes HTTP/3-specific error codes which can be used 1464 to express the cause of a connection or stream error. 1466 8.1. HTTP/3 Error Codes 1468 The following error codes are defined for use in QUIC RESET_STREAM 1469 frames, STOP_SENDING frames, and CONNECTION_CLOSE frames when using 1470 HTTP/3. 1472 HTTP_NO_ERROR (0x00): No error. This is used when the connection or 1473 stream needs to be closed, but there is no error to signal. 1475 HTTP_WRONG_SETTING_DIRECTION (0x01): A client-only setting was sent 1476 by a server, or a server-only setting by a client. 1478 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1479 which the client will not accept on this connection. 1481 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1482 HTTP stack. 1484 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1485 content which the client has cached. 1487 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1488 requested data. 1490 HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated 1491 without containing a fully-formed request. 1493 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1494 a CONNECT request was reset or abnormally closed. 1496 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1497 exhibiting a behavior that might be generating excessive load. 1499 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1500 served over HTTP/3. The peer should retry over HTTP/1.1. 1502 HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it 1503 is not permitted. 1505 HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current 1506 maximum Push ID was referenced. 1508 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1509 different stream headers. 1511 HTTP_UNKNOWN_STREAM_TYPE (0x0D): A unidirectional stream header 1512 contained an unknown stream type. 1514 HTTP_WRONG_STREAM_COUNT (0x0E): A unidirectional stream type was 1515 used more times than is permitted by that type. 1517 HTTP_CLOSED_CRITICAL_STREAM (0x0F): A stream required by the 1518 connection was closed or reset. 1520 HTTP_WRONG_STREAM_DIRECTION (0x0010): A unidirectional stream type 1521 was used by a peer which is not permitted to do so. 1523 HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request 1524 is not needed to produce a response. For use in STOP_SENDING 1525 only. 1527 HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at 1528 the beginning of the control stream. 1530 HTTP_UNEXPECTED_FRAME (0x0013): A frame was received which was not 1531 permitted in the current state. 1533 HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol 1534 requirements in a way which doesn't match a more specific error 1535 code, or endpoint declines to use the more specific error code. 1537 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1538 The frame type is included as the last byte of the error code. 1539 For example, an error in a MAX_PUSH_ID frame would be indicated 1540 with the code (0x10D). 1542 9. Security Considerations 1544 The security considerations of HTTP/3 should be comparable to those 1545 of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames 1546 and Padding fields in other frames to make a connection more 1547 resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames 1548 or employ the reserved frame and stream types discussed in 1549 Section 4.2.10 and Section 3.2.3. 1551 When HTTP Alternative Services is used for discovery for HTTP/3 1552 endpoints, the security considerations of [ALTSVC] also apply. 1554 Several protocol elements contain nested length elements, typically 1555 in the form of frames with an explicit length containing variable- 1556 length integers. This could pose a security risk to an incautious 1557 implementer. An implementation MUST ensure that the length of a 1558 frame exactly matches the length of the fields it contains. 1560 10. IANA Considerations 1562 10.1. Registration of HTTP/3 Identification String 1564 This document creates a new registration for the identification of 1565 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 1566 IDs" registry established in [RFC7301]. 1568 The "h3" string identifies HTTP/3: 1570 Protocol: HTTP/3 1572 Identification Sequence: 0x68 0x33 ("h3") 1574 Specification: This document 1576 10.2. Registration of QUIC Version Hint Alt-Svc Parameter 1578 This document creates a new registration for version-negotiation 1579 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1580 registry established in [RFC7838]. 1582 Parameter: "quic" 1584 Specification: This document, Section 2.2.1 1586 10.3. Frame Types 1588 This document establishes a registry for HTTP/3 frame type codes. 1589 The "HTTP/3 Frame Type" registry manages an 8-bit space. The "HTTP/3 1590 Frame Type" registry operates under either of the "IETF Review" or 1591 "IESG Approval" policies [RFC8126] for values from 0x00 up to and 1592 including 0xef, with values from 0xf0 up to and including 0xff being 1593 reserved for Experimental Use. 1595 While this registry is separate from the "HTTP/2 Frame Type" registry 1596 defined in [RFC7540], it is preferable that the assignments parallel 1597 each other. If an entry is present in only one registry, every 1598 effort SHOULD be made to avoid assigning the corresponding value to 1599 an unrelated operation. 1601 New entries in this registry require the following information: 1603 Frame Type: A name or label for the frame type. 1605 Code: The 8-bit code assigned to the frame type. 1607 Specification: A reference to a specification that includes a 1608 description of the frame layout and its semantics, including any 1609 parts of the frame that are conditionally present. 1611 The entries in the following table are registered by this document. 1613 +----------------+------+---------------+ 1614 | Frame Type | Code | Specification | 1615 +----------------+------+---------------+ 1616 | DATA | 0x0 | Section 4.2.1 | 1617 | | | | 1618 | HEADERS | 0x1 | Section 4.2.2 | 1619 | | | | 1620 | PRIORITY | 0x2 | Section 4.2.3 | 1621 | | | | 1622 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1623 | | | | 1624 | SETTINGS | 0x4 | Section 4.2.5 | 1625 | | | | 1626 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1627 | | | | 1628 | Reserved | 0x6 | N/A | 1629 | | | | 1630 | GOAWAY | 0x7 | Section 4.2.7 | 1631 | | | | 1632 | Reserved | 0x8 | N/A | 1633 | | | | 1634 | Reserved | 0x9 | N/A | 1635 | | | | 1636 | MAX_PUSH_ID | 0xD | Section 4.2.8 | 1637 | | | | 1638 | DUPLICATE_PUSH | 0xE | Section 4.2.9 | 1639 +----------------+------+---------------+ 1641 Additionally, each code of the format "0xb + (0x1f * N)" for values 1642 of N in the range (0..7) (that is, "0xb", "0x2a", "0x49", "0x68", 1643 "0x87", "0xa6", "0xc5", and "0xe4"), the following values should be 1644 registered: 1646 Frame Type: Reserved - GREASE 1648 Specification: Section 4.2.10 1650 10.4. Settings Parameters 1652 This document establishes a registry for HTTP/3 settings. The 1653 "HTTP/3 Settings" registry manages a 16-bit space. The "HTTP/3 1654 Settings" registry operates under the "Expert Review" policy 1655 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1656 between and 0xf000 and 0xffff being reserved for Experimental Use. 1657 The designated experts are the same as those for the "HTTP/2 1658 Settings" registry defined in [RFC7540]. 1660 While this registry is separate from the "HTTP/2 Settings" registry 1661 defined in [RFC7540], it is preferable that the assignments parallel 1662 each other. If an entry is present in only one registry, every 1663 effort SHOULD be made to avoid assigning the corresponding value to 1664 an unrelated operation. 1666 New registrations are advised to provide the following information: 1668 Name: A symbolic name for the setting. Specifying a setting name is 1669 optional. 1671 Code: The 16-bit code assigned to the setting. 1673 Specification: An optional reference to a specification that 1674 describes the use of the setting. 1676 The entries in the following table are registered by this document. 1678 +----------------------+------+-----------------+ 1679 | Setting Name | Code | Specification | 1680 +----------------------+------+-----------------+ 1681 | Reserved | 0x2 | N/A | 1682 | | | | 1683 | Reserved | 0x3 | N/A | 1684 | | | | 1685 | Reserved | 0x4 | N/A | 1686 | | | | 1687 | Reserved | 0x5 | N/A | 1688 | | | | 1689 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 | 1690 | | | | 1691 | NUM_PLACEHOLDERS | 0x8 | Section 4.2.5.1 | 1692 +----------------------+------+-----------------+ 1694 Additionally, each code of the format "0x?a?a" where each "?" is any 1695 four bits (that is, "0x0a0a", "0x0a1a", etc. through "0xfafa"), the 1696 following values should be registered: 1698 Name: Reserved - GREASE 1700 Specification: Section 4.2.5.1 1702 10.5. Error Codes 1704 This document establishes a registry for HTTP/3 error codes. The 1705 "HTTP/3 Error Code" registry manages a 16-bit space. The "HTTP/3 1706 Error Code" registry operates under the "Expert Review" policy 1707 [RFC8126]. 1709 Registrations for error codes are required to include a description 1710 of the error code. An expert reviewer is advised to examine new 1711 registrations for possible duplication with existing error codes. 1712 Use of existing registrations is to be encouraged, but not mandated. 1714 New registrations are advised to provide the following information: 1716 Name: A name for the error code. Specifying an error code name is 1717 optional. 1719 Code: The 16-bit error code value. 1721 Description: A brief description of the error code semantics, longer 1722 if no detailed specification is provided. 1724 Specification: An optional reference for a specification that 1725 defines the error code. 1727 The entries in the following table are registered by this document. 1729 +---------------------------+--------+---------------+--------------+ 1730 | Name | Code | Description | Specificatio | 1731 | | | | n | 1732 +---------------------------+--------+---------------+--------------+ 1733 | HTTP_NO_ERROR | 0x0000 | No error | Section 8.1 | 1734 | | | | | 1735 | HTTP_WRONG_SETTING_DIRECT | 0x0001 | Setting sent | Section 8.1 | 1736 | ION | | in wrong | | 1737 | | | direction | | 1738 | | | | | 1739 | HTTP_PUSH_REFUSED | 0x0002 | Client | Section 8.1 | 1740 | | | refused | | 1741 | | | pushed | | 1742 | | | content | | 1743 | | | | | 1744 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 8.1 | 1745 | | | error | | 1746 | | | | | 1747 | HTTP_PUSH_ALREADY_IN_CACH | 0x0004 | Pushed | Section 8.1 | 1748 | E | | content | | 1749 | | | already | | 1750 | | | cached | | 1751 | | | | | 1752 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 8.1 | 1753 | | | longer needed | | 1754 | | | | | 1755 | HTTP_INCOMPLETE_REQUEST | 0x0006 | Stream | Section 8.1 | 1756 | | | terminated | | 1757 | | | early | | 1758 | | | | | 1759 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset or | Section 8.1 | 1760 | | | error on | | 1761 | | | CONNECT | | 1762 | | | request | | 1763 | | | | | 1764 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 8.1 | 1765 | | | generating | | 1766 | | | excessive | | 1767 | | | load | | 1768 | | | | | 1769 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 8.1 | 1770 | | | HTTP/1.1 | | 1771 | | | | | 1772 | HTTP_WRONG_STREAM | 0x000A | A frame was | Section 8.1 | 1773 | | | sent on the | | 1774 | | | wrong stream | | 1775 | | | | | 1776 | HTTP_PUSH_LIMIT_EXCEEDED | 0x000B | Maximum Push | Section 8.1 | 1777 | | | ID exceeded | | 1778 | | | | | 1779 | HTTP_DUPLICATE_PUSH | 0x000C | Push ID was | Section 8.1 | 1780 | | | fulfilled | | 1781 | | | multiple | | 1782 | | | times | | 1783 | | | | | 1784 | HTTP_UNKNOWN_STREAM_TYPE | 0x000D | Unknown unidi | Section 8.1 | 1785 | | | rectional | | 1786 | | | stream type | | 1787 | | | | | 1788 | HTTP_WRONG_STREAM_COUNT | 0x000E | Too many unid | Section 8.1 | 1789 | | | irectional | | 1790 | | | streams | | 1791 | | | | | 1792 | HTTP_CLOSED_CRITICAL_STRE | 0x000F | Critical | Section 8.1 | 1793 | AM | | stream was | | 1794 | | | closed | | 1795 | | | | | 1796 | HTTP_WRONG_STREAM_DIRECTI | 0x0010 | Unidirectiona | Section 8.1 | 1797 | ON | | l stream in | | 1798 | | | wrong | | 1799 | | | direction | | 1800 | | | | | 1801 | HTTP_EARLY_RESPONSE | 0x0011 | Remainder of | Section 8.1 | 1802 | | | request not | | 1803 | | | needed | | 1804 | | | | | 1805 | HTTP_MISSING_SETTINGS | 0x0012 | No SETTINGS | Section 8.1 | 1806 | | | frame | | 1807 | | | received | | 1808 | | | | | 1809 | HTTP_UNEXPECTED_FRAME | 0x0013 | Frame not | Section 8.1 | 1810 | | | permitted in | | 1811 | | | the current | | 1812 | | | state | | 1813 | | | | | 1814 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 | 1815 | | | frame | | 1816 | | | formatting | | 1817 +---------------------------+--------+---------------+--------------+ 1819 10.6. Stream Types 1821 This document establishes a registry for HTTP/3 unidirectional stream 1822 types. The "HTTP/3 Stream Type" registry manages an 8-bit space. 1823 The "HTTP/3 Stream Type" registry operates under either of the "IETF 1824 Review" or "IESG Approval" policies [RFC8126] for values from 0x00 up 1825 to and including 0xef, with values from 0xf0 up to and including 0xff 1826 being reserved for Experimental Use. 1828 New entries in this registry require the following information: 1830 Stream Type: A name or label for the stream type. 1832 Code: The 8-bit code assigned to the stream type. 1834 Specification: A reference to a specification that includes a 1835 description of the stream type, including the layout semantics of 1836 its payload. 1838 Sender: Which endpoint on a connection may initiate a stream of this 1839 type. Values are "Client", "Server", or "Both". 1841 The entries in the following table are registered by this document. 1843 +----------------+------+---------------+--------+ 1844 | Stream Type | Code | Specification | Sender | 1845 +----------------+------+---------------+--------+ 1846 | Control Stream | 0x43 | Section 3.2.1 | Both | 1847 | | | | | 1848 | Push Stream | 0x50 | Section 5.4 | Server | 1849 +----------------+------+---------------+--------+ 1851 Additionally, for each code of the format "0x1f * N" for values of N 1852 in the range (0..8) (that is, "0x00", "0x1f", "0x3e", "0x5d", "0x7c", 1853 "0x9b", "0xba", "0xd9", "0xf8"), the following values should be 1854 registered: 1856 Stream Type: Reserved - GREASE 1858 Specification: Section 3.2.3 1860 Sender: Both 1862 11. References 1864 11.1. Normative References 1866 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1867 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1868 April 2016, . 1870 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 1871 Header Compression for HTTP over QUIC", draft-ietf-quic- 1872 qpack-05 (work in progress), December 2018. 1874 [QUIC-TRANSPORT] 1875 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1876 Multiplexed and Secure Transport", draft-ietf-quic- 1877 transport-16 (work in progress), December 2018. 1879 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1880 RFC 793, DOI 10.17487/RFC0793, September 1981, 1881 . 1883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1884 Requirement Levels", BCP 14, RFC 2119, 1885 DOI 10.17487/RFC2119, March 1997, 1886 . 1888 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1889 Specifications: ABNF", STD 68, RFC 5234, 1890 DOI 10.17487/RFC5234, January 2008, 1891 . 1893 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1894 Extensions: Extension Definitions", RFC 6066, 1895 DOI 10.17487/RFC6066, January 2011, 1896 . 1898 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1899 Protocol (HTTP/1.1): Message Syntax and Routing", 1900 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1901 . 1903 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1904 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1905 DOI 10.17487/RFC7231, June 2014, 1906 . 1908 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1909 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1910 DOI 10.17487/RFC7540, May 2015, 1911 . 1913 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1914 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1915 April 2016, . 1917 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1918 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1919 May 2017, . 1921 11.2. Informative References 1923 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1924 "Transport Layer Security (TLS) Application-Layer Protocol 1925 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1926 July 2014, . 1928 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1929 Writing an IANA Considerations Section in RFCs", BCP 26, 1930 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1931 . 1933 11.3. URIs 1935 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1937 [2] https://github.com/quicwg 1939 [3] https://github.com/quicwg/base-drafts/labels/-http 1941 [4] https://www.iana.org/assignments/message-headers 1943 Appendix A. Considerations for Transitioning from HTTP/2 1945 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 1946 This section describes the approach taken to design HTTP/3, points 1947 out important differences from HTTP/2, and describes how to map 1948 HTTP/2 extensions into HTTP/3. 1950 HTTP/3 begins from the premise that similarity to HTTP/2 is 1951 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 1952 primarily where necessary to accommodate the differences in behavior 1953 between QUIC and TCP (lack of ordering, support for streams). We 1954 intend to avoid gratuitous changes which make it difficult or 1955 impossible to build extensions with the same semantics applicable to 1956 both protocols at once. 1958 These departures are noted in this section. 1960 A.1. Streams 1962 HTTP/3 permits use of a larger number of streams (2^62-1) than 1963 HTTP/2. The considerations about exhaustion of stream identifier 1964 space apply, though the space is significantly larger such that it is 1965 likely that other limits in QUIC are reached first, such as the limit 1966 on the connection flow control window. 1968 A.2. HTTP Frame Types 1970 Many framing concepts from HTTP/2 can be elided away on QUIC, because 1971 the transport deals with them. Because frames are already on a 1972 stream, they can omit the stream number. Because frames do not block 1973 multiplexing (QUIC's multiplexing occurs below this layer), the 1974 support for variable-maximum-length packets can be removed. Because 1975 stream termination is handled by QUIC, an END_STREAM flag is not 1976 required. This permits the removal of the Flags field from the 1977 generic frame layout. 1979 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1980 includes many features (e.g. flow control) which are also present in 1981 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 1982 As a result, several HTTP/2 frame types are not required in HTTP/3. 1983 Where an HTTP/2-defined frame is no longer used, the frame ID has 1984 been reserved in order to maximize portability between HTTP/2 and 1985 HTTP/3 implementations. However, even equivalent frames between the 1986 two mappings are not identical. 1988 Many of the differences arise from the fact that HTTP/2 provides an 1989 absolute ordering between frames across all streams, while QUIC 1990 provides this guarantee on each stream only. As a result, if a frame 1991 type makes assumptions that frames from different streams will still 1992 be received in the order sent, HTTP/3 will break them. 1994 For example, implicit in the HTTP/2 prioritization scheme is the 1995 notion of in-order delivery of priority changes (i.e., dependency 1996 tree mutations): since operations on the dependency tree such as 1997 reparenting a subtree are not commutative, both sender and receiver 1998 must apply them in the same order to ensure that both sides have a 1999 consistent view of the stream dependency tree. HTTP/2 specifies 2000 priority assignments in PRIORITY frames and (optionally) in HEADERS 2001 frames. To achieve in-order delivery of priority changes in HTTP/3, 2002 PRIORITY frames are sent on the control stream and exclusive 2003 prioritization has been removed. 2005 Likewise, HPACK was designed with the assumption of in-order 2006 delivery. A sequence of encoded header blocks must arrive (and be 2007 decoded) at an endpoint in the same order in which they were encoded. 2008 This ensures that the dynamic state at the two endpoints remains in 2009 sync. As a result, HTTP/3 uses a modified version of HPACK, 2010 described in [QPACK]. 2012 Frame type definitions in HTTP/3 often use the QUIC variable-length 2013 integer encoding. In particular, Stream IDs use this encoding, which 2014 allow for a larger range of possible values than the encoding used in 2015 HTTP/2. Some frames in HTTP/3 use an identifier rather than a Stream 2016 ID (e.g. Push IDs in PRIORITY frames). Redefinition of the encoding 2017 of extension frame types might be necessary if the encoding includes 2018 a Stream ID. 2020 Because the Flags field is not present in generic HTTP/3 frames, 2021 those frames which depend on the presence of flags need to allocate 2022 space for flags as part of their frame payload. 2024 Other than this issue, frame type HTTP/2 extensions are typically 2025 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2026 control stream in HTTP/3. HTTP/3 extensions will not assume 2027 ordering, but would not be harmed by ordering, and would be portable 2028 to HTTP/2 in the same manner. 2030 Below is a listing of how each HTTP/2 frame type is mapped: 2032 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2033 Section 4.2.1. 2035 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 2036 not supported. A separate PRIORITY frame MUST be used. Padding 2037 is not defined in HTTP/3 frames. See Section 4.2.2. 2039 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 2040 the control stream and can reference a variety of identifiers. 2041 See Section 4.2.3. 2043 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 2044 provides stream lifecycle management. The same code point is used 2045 for the CANCEL_PUSH frame (Section 4.2.4). 2047 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2048 the connection. See Section 4.2.5 and Appendix A.3. 2050 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 2051 instead the push stream references the PUSH_PROMISE frame using a 2052 Push ID. See Section 4.2.6. 2054 PING (0x6): PING frames do not exist, since QUIC provides equivalent 2055 functionality. 2057 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 2058 contain an error code. See Section 4.2.7. 2060 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 2061 provides flow control. 2063 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 2064 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. 2066 Frame types defined by extensions to HTTP/2 need to be separately 2067 registered for HTTP/3 if still applicable. The IDs of frames defined 2068 in [RFC7540] have been reserved for simplicity. See Section 10.3. 2070 A.3. HTTP/2 SETTINGS Parameters 2072 An important difference from HTTP/2 is that settings are sent once, 2073 at the beginning of the connection, and thereafter cannot change. 2074 This eliminates many corner cases around synchronization of changes. 2076 Some transport-level options that HTTP/2 specifies via the SETTINGS 2077 frame are superseded by QUIC transport parameters in HTTP/3. The 2078 HTTP-level options that are retained in HTTP/3 have the same value as 2079 in HTTP/2. 2081 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2083 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 2085 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 2086 which provides a more granular control over server push. 2088 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 2089 Stream ID as part of its flow control logic. Specifying 2090 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 2092 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 2093 connection flow control window sizes to be specified in the 2094 initial transport handshake. Specifying 2095 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 2097 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. 2098 Specifying it in the SETTINGS frame is an error. 2100 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.1. 2102 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2103 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2104 This will often produce a shorter encoding, but can produce a longer 2105 encoding for settings which use the full 32-bit space. Settings 2106 ported from HTTP/2 might choose to redefine the format of their 2107 settings to avoid using the 62-bit encoding. 2109 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2110 IDs of settings defined in [RFC7540] have been reserved for 2111 simplicity. See Section 10.4. 2113 A.4. HTTP/2 Error Codes 2115 QUIC has the same concepts of "stream" and "connection" errors that 2116 HTTP/2 provides. However, there is no direct portability of HTTP/2 2117 error codes. 2119 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 2120 HTTP/3 error codes as follows: 2122 NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1. 2124 PROTOCOL_ERROR (0x1): No single mapping. See new 2125 HTTP_MALFORMED_FRAME error codes defined in Section 8.1. 2127 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1. 2129 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2130 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 2131 from the QUIC layer. 2133 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2134 SETTINGS is defined. 2136 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2137 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 2138 from the QUIC layer. 2140 FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in 2141 Section 8.1. 2143 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 2144 management. Would provoke a STREAM_ID_ERROR from the QUIC layer. 2146 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. 2148 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2149 [QPACK]. 2151 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. 2153 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. 2155 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2156 provide sufficient security on all connections. 2158 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1. 2160 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2161 Section 10.5. 2163 Appendix B. Change Log 2165 *RFC Editor's Note:* Please remove this section prior to 2166 publication of a final version of this document. 2168 B.1. Since draft-ietf-quic-http-16 2170 o Rename "HTTP/QUIC" to "HTTP/3" (#1973) 2172 o Changes to PRIORITY frame (#1865, #2075) 2174 * Permitted as first frame of request streams 2175 * Remove exclusive reprioritization 2177 * Changes to Prioritized Element Type bits 2179 o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 2180 (#2072) 2182 o Set defaults for settings, allow request before receiving SETTINGS 2183 (#1809, #1846, #2038) 2185 o Clarify message processing rules for streams that aren't closed 2186 (#1972, #2003) 2188 o Removed reservation of error code 0 and moved HTTP_NO_ERROR to 2189 this value (#1922) 2191 o Removed prohibition of zero-length DATA frames (#2098) 2193 B.2. Since draft-ietf-quic-http-15 2195 Substantial editorial reorganization; no technical changes. 2197 B.3. Since draft-ietf-quic-http-14 2199 o Recommend sensible values for QUIC transport parameters 2200 (#1720,#1806) 2202 o Define error for missing SETTINGS frame (#1697,#1808) 2204 o Setting values are variable-length integers (#1556,#1807) and do 2205 not have separate maximum values (#1820) 2207 o Expanded discussion of connection closure (#1599,#1717,#1712) 2209 o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 2211 B.4. Since draft-ietf-quic-http-13 2213 o Reserved some frame types for grease (#1333, #1446) 2215 o Unknown unidirectional stream types are tolerated, not errors; 2216 some reserved for grease (#1490, #1525) 2218 o Require settings to be remembered for 0-RTT, prohibit reductions 2219 (#1541, #1641) 2221 o Specify behavior for truncated requests (#1596, #1643) 2223 B.5. Since draft-ietf-quic-http-12 2225 o TLS SNI extension isn't mandatory if an alternative method is used 2226 (#1459, #1462, #1466) 2228 o Removed flags from HTTP/3 frames (#1388, #1398) 2230 o Reserved frame types and settings for use in preserving 2231 extensibility (#1333, #1446) 2233 o Added general error code (#1391, #1397) 2235 o Unidirectional streams carry a type byte and are extensible 2236 (#910,#1359) 2238 o Priority mechanism now uses explicit placeholders to enable 2239 persistent structure in the tree (#441,#1421,#1422) 2241 B.6. Since draft-ietf-quic-http-11 2243 o Moved QPACK table updates and acknowledgments to dedicated streams 2244 (#1121, #1122, #1238) 2246 B.7. Since draft-ietf-quic-http-10 2248 o Settings need to be remembered when attempting and accepting 0-RTT 2249 (#1157, #1207) 2251 B.8. Since draft-ietf-quic-http-09 2253 o Selected QCRAM for header compression (#228, #1117) 2255 o The server_name TLS extension is now mandatory (#296, #495) 2257 o Specified handling of unsupported versions in Alt-Svc (#1093, 2258 #1097) 2260 B.9. Since draft-ietf-quic-http-08 2262 o Clarified connection coalescing rules (#940, #1024) 2264 B.10. Since draft-ietf-quic-http-07 2266 o Changes for integer encodings in QUIC (#595,#905) 2268 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 2270 o Improvement to the description of GOAWAY (#604, #898) 2271 o Improve description of server push usage (#947, #950, #957) 2273 B.11. Since draft-ietf-quic-http-06 2275 o Track changes in QUIC error code usage (#485) 2277 B.12. Since draft-ietf-quic-http-05 2279 o Made push ID sequential, add MAX_PUSH_ID, remove 2280 SETTINGS_ENABLE_PUSH (#709) 2282 o Guidance about keep-alive and QUIC PINGs (#729) 2284 o Expanded text on GOAWAY and cancellation (#757) 2286 B.13. Since draft-ietf-quic-http-04 2288 o Cite RFC 5234 (#404) 2290 o Return to a single stream per request (#245,#557) 2292 o Use separate frame type and settings registries from HTTP/2 (#81) 2294 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 2296 o Restored GOAWAY (#696) 2298 o Identify server push using Push ID rather than a stream ID 2299 (#702,#281) 2301 o DATA frames cannot be empty (#700) 2303 B.14. Since draft-ietf-quic-http-03 2305 None. 2307 B.15. Since draft-ietf-quic-http-02 2309 o Track changes in transport draft 2311 B.16. Since draft-ietf-quic-http-01 2313 o SETTINGS changes (#181): 2315 * SETTINGS can be sent only once at the start of a connection; no 2316 changes thereafter 2318 * SETTINGS_ACK removed 2319 * Settings can only occur in the SETTINGS frame a single time 2321 * Boolean format updated 2323 o Alt-Svc parameter changed from "v" to "quic"; format updated 2324 (#229) 2326 o Closing the connection control stream or any message control 2327 stream is a fatal error (#176) 2329 o HPACK Sequence counter can wrap (#173) 2331 o 0-RTT guidance added 2333 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 2334 added (#127,#242) 2336 B.17. Since draft-ietf-quic-http-00 2338 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 2340 o Changed from using HTTP/2 framing within Stream 3 to new framing 2341 format and two-stream-per-request model (#71,#72,#73) 2343 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 2344 settings-01 2346 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 2347 order (#75) 2349 o Described CONNECT pseudo-method (#95) 2351 o Updated ALPN token and Alt-Svc guidance (#13,#87) 2353 o Application-layer-defined error codes (#19,#74) 2355 B.18. Since draft-shade-quic-http2-mapping-00 2357 o Adopted as base for draft-ietf-quic-http 2359 o Updated authors/editors list 2361 Acknowledgements 2363 The original authors of this specification were Robbie Shade and Mike 2364 Warres. 2366 A substantial portion of Mike's contribution was supported by 2367 Microsoft during his employment there. 2369 Author's Address 2371 Mike Bishop (editor) 2372 Akamai 2374 Email: mbishop@evequefou.be