idnits 2.17.00 (12 Aug 2021) /tmp/idnits54688/draft-ietf-quic-http-15.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 (October 03, 2018) is 1325 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 2022 -- Looks like a reference, but probably isn't: '2' on line 2024 -- Looks like a reference, but probably isn't: '3' on line 2026 -- Looks like a reference, but probably isn't: '4' on line 2028 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-03 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALTSVC'. Summary: 1 error (**), 0 flaws (~~), 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 October 03, 2018 5 Expires: April 6, 2019 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-15 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 QUIC. 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 April 6, 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 . . . . . . . . . . . . . . . 4 66 2.1. Draft Version Identification . . . . . . . . . . . . . . 4 67 2.2. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 5 68 2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 5 69 2.3. Connection Establishment . . . . . . . . . . . . . . . . 6 70 2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7 71 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 72 3.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 8 73 3.1.1. Header Formatting and Compression . . . . . . . . . . 9 74 3.1.2. The CONNECT Method . . . . . . . . . . . . . . . . . 10 75 3.1.3. Request Cancellation . . . . . . . . . . . . . . . . 11 76 3.2. Request Prioritization . . . . . . . . . . . . . . . . . 11 77 3.2.1. Placeholders . . . . . . . . . . . . . . . . . . . . 12 78 3.2.2. Priority Tree Maintenance . . . . . . . . . . . . . . 12 79 3.3. Unidirectional Streams . . . . . . . . . . . . . . . . . 13 80 3.3.1. Reserved Stream Types . . . . . . . . . . . . . . . . 14 81 3.3.2. Control Streams . . . . . . . . . . . . . . . . . . . 14 82 3.3.3. Server Push . . . . . . . . . . . . . . . . . . . . . 15 83 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 16 84 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 16 85 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 17 86 4.2.1. Reserved Frame Types . . . . . . . . . . . . . . . . 17 87 4.2.2. DATA . . . . . . . . . . . . . . . . . . . . . . . . 17 88 4.2.3. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 17 89 4.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 18 90 4.2.5. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 20 91 4.2.6. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 21 92 4.2.7. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 23 93 4.2.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 24 94 4.2.9. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 25 95 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 25 96 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 26 97 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 26 98 5.3. Immediate Application Closure . . . . . . . . . . . . . . 27 99 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 28 100 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 28 101 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 28 102 7. Extensions to HTTP/QUIC . . . . . . . . . . . . . . . . . . . 30 103 8. Considerations for Transitioning from HTTP/2 . . . . . . . . 30 104 8.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 8.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 31 106 8.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 33 107 8.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 34 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 110 10.1. Registration of HTTP/QUIC Identification String . . . . 35 111 10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 36 112 10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 36 113 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 37 114 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 38 115 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 41 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 42 118 11.2. Informative References . . . . . . . . . . . . . . . . . 43 119 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43 120 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 43 121 A.1. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 43 122 A.2. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 44 123 A.3. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 44 124 A.4. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 44 125 A.5. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 44 126 A.6. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 45 127 A.7. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 45 128 A.8. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 45 129 A.9. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 45 130 A.10. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 45 131 A.11. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 45 132 A.12. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 46 133 A.13. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 46 134 A.14. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 46 135 A.15. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 46 136 A.16. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 47 137 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 140 1. Introduction 142 The QUIC transport protocol has several features that are desirable 143 in a transport for HTTP, such as stream multiplexing, per-stream flow 144 control, and low-latency connection establishment. This document 145 describes a mapping of HTTP semantics over QUIC, drawing heavily on 146 the existing TCP mapping, HTTP/2. Specifically, this document 147 identifies HTTP/2 features that are subsumed by QUIC, and describes 148 how the other features can be implemented atop QUIC. 150 QUIC is described in [QUIC-TRANSPORT]. For a full description of 151 HTTP/2, see [RFC7540]. 153 1.1. Notational Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 162 defined in [RFC5234]. 164 This document uses the variable-length integer encoding from 165 [QUIC-TRANSPORT]. 167 Protocol elements called "frames" exist in both this document and 168 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 169 the frame name will be prefaced with "QUIC." For example, "QUIC 170 APPLICATION_CLOSE frames." References without this preface refer to 171 frames defined in Section 4.2. 173 2. Connection Setup and Management 175 2.1. Draft Version Identification 177 *RFC Editor's Note:* Please remove this section prior to 178 publication of a final version of this document. 180 HTTP/QUIC uses the token "hq" to identify itself in ALPN and Alt-Svc. 181 Only implementations of the final, published RFC can identify 182 themselves as "hq". Until such an RFC exists, implementations MUST 183 NOT identify themselves using this string. 185 Implementations of draft versions of the protocol MUST add the string 186 "-" and the corresponding draft number to the identifier. For 187 example, draft-ietf-quic-http-01 is identified using the string "hq- 188 01". 190 Non-compatible experiments that are based on these draft versions 191 MUST append the string "-" and an experiment name to the identifier. 192 For example, an experimental implementation based on draft-ietf-quic- 193 http-09 which reserves an extra stream for unsolicited transmission 194 of 1980s pop music might identify itself as "hq-09-rickroll". Note 195 that any label MUST conform to the "token" syntax defined in 196 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 197 coordinate their experiments on the quic@ietf.org mailing list. 199 2.2. Discovering an HTTP/QUIC Endpoint 201 An HTTP origin advertises the availability of an equivalent HTTP/QUIC 202 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 203 ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 2.3. 205 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 206 response that HTTP/QUIC was available on UDP port 50781 at the same 207 hostname by including the following header field in any response: 209 Alt-Svc: hq=":50781" 211 On receipt of an Alt-Svc record indicating HTTP/QUIC support, a 212 client MAY attempt to establish a QUIC connection to the indicated 213 host and port and, if successful, send HTTP requests using the 214 mapping described in this document. 216 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 217 connection establishment failure, in which case the client SHOULD 218 continue using the existing connection or try another alternative 219 endpoint offered by the origin. 221 Servers MAY serve HTTP/QUIC on any UDP port, since an alternative 222 always includes an explicit port. 224 2.2.1. QUIC Version Hints 226 This document defines the "quic" parameter for Alt-Svc, which MAY be 227 used to provide version-negotiation hints to HTTP/QUIC clients. QUIC 228 versions are four-octet sequences with no additional constraints on 229 format. Leading zeros SHOULD be omitted for brevity. 231 Syntax: 233 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 234 version-number = 1*8HEXDIG; hex-encoded QUIC version 235 Where multiple versions are listed, the order of the values reflects 236 the server's preference (with the first value being the most 237 preferred version). Reserved versions MAY be listed, but unreserved 238 versions which are not supported by the alternative SHOULD NOT be 239 present in the list. Origins MAY omit supported versions for any 240 reason. 242 Clients MUST ignore any included versions which they do not support. 243 The "quic" parameter MUST NOT occur more than once; clients SHOULD 244 process only the first occurrence. 246 For example, suppose a server supported both version 0x00000001 and 247 the version rendered in ASCII as "Q034". If it opted to include the 248 reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and 249 0x1abadaba, it could specify the following header field: 251 Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0" 253 A client acting on this header field would drop the reserved versions 254 (because it does not support them), then attempt to connect to the 255 alternative using the first version in the list which it does 256 support. 258 2.3. Connection Establishment 260 HTTP/QUIC relies on QUIC as the underlying transport. The QUIC 261 version being used MUST use TLS version 1.3 or greater as its 262 handshake protocol. HTTP/QUIC clients MUST indicate the target 263 domain name during the TLS handshake. This may be done using the 264 Server Name Indication (SNI) [RFC6066] extension to TLS or using some 265 other mechanism. 267 QUIC connections are established as described in [QUIC-TRANSPORT]. 268 During connection establishment, HTTP/QUIC support is indicated by 269 selecting the ALPN token "hq" in the TLS handshake. Support for 270 other application-layer protocols MAY be offered in the same 271 handshake. 273 While connection-level options pertaining to the core QUIC protocol 274 are set in the initial crypto handshake, HTTP/QUIC-specific settings 275 are conveyed in the SETTINGS frame. After the QUIC connection is 276 established, a SETTINGS frame (Section 4.2.6) MUST be sent by each 277 endpoint as the initial frame of their respective HTTP control stream 278 (see Section 3.3.2). The server MUST NOT send data on any other 279 stream until the client's SETTINGS frame has been received. 281 2.4. Connection Reuse 283 Once a connection exists to a server endpoint, this connection MAY be 284 reused for requests with multiple different URI authority components. 285 The client MAY send any requests for which the client considers the 286 server authoritative. 288 An authoritative HTTP/QUIC endpoint is typically discovered because 289 the client has received an Alt-Svc record from the request's origin 290 which nominates the endpoint as a valid HTTP Alternative Service for 291 that origin. As required by [RFC7838], clients MUST check that the 292 nominated server can present a valid certificate for the origin 293 before considering it authoritative. Clients MUST NOT assume that an 294 HTTP/QUIC endpoint is authoritative for other origins without an 295 explicit signal. 297 A server that does not wish clients to reuse connections for a 298 particular origin can indicate that it is not authoritative for a 299 request by sending a 421 (Misdirected Request) status code in 300 response to the request (see Section 9.1.2 of [RFC7540]). 302 The considerations discussed in Section 9.1 of [RFC7540] also apply 303 to the management of HTTP/QUIC connections. 305 3. Stream Mapping and Usage 307 A QUIC stream provides reliable in-order delivery of bytes, but makes 308 no guarantees about order of delivery with regard to bytes on other 309 streams. On the wire, data is framed into QUIC STREAM frames, but 310 this framing is invisible to the HTTP framing layer. A QUIC receiver 311 buffers and orders received STREAM frames, exposing the data 312 contained within as a reliable byte stream to the application. 314 When HTTP headers and data are sent over QUIC, the QUIC layer handles 315 most of the stream management. 317 All client-initiated bidirectional streams are used for HTTP requests 318 and responses. A bidirectional stream ensures that the response can 319 be readily correlated with the request. This means that the client's 320 first request occurs on QUIC stream 0, with subsequent requests on 321 stream 4, 8, and so on. In order to permit these streams to open, an 322 HTTP/QUIC client SHOULD send non-zero values for the QUIC transport 323 parameters "initial_max_stream_data_bidi_local". An HTTP/QUIC server 324 SHOULD send non-zero values for the QUIC transport parameters 325 "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". 326 It is recommended that "initial_max_bidi_streams" be no smaller than 327 100, so as to not unnecessarily limit parallelism. 329 These streams carry frames related to the request/response (see 330 Section 4.2). When a stream terminates cleanly, if the last frame on 331 the stream was truncated, this MUST be treated as a connection error 332 (see HTTP_MALFORMED_FRAME in Section 6.1). Streams which terminate 333 abruptly may be reset at any point in the frame. 335 HTTP/QUIC does not use server-initiated bidirectional streams. The 336 use of unidirectional streams is discussed in Section 3.3. Both 337 clients and servers SHOULD send a value of three or greater for the 338 QUIC transport parameter "initial_max_uni_streams". 340 HTTP does not need to do any separate multiplexing when using QUIC - 341 data sent over a QUIC stream always maps to a particular HTTP 342 transaction. Requests and responses are considered complete when the 343 corresponding QUIC stream is closed in the appropriate direction. 345 3.1. HTTP Message Exchanges 347 A client sends an HTTP request on a client-initiated bidirectional 348 QUIC stream. A server sends an HTTP response on the same stream as 349 the request. 351 An HTTP message (request or response) consists of: 353 1. one header block (see Section 4.2.3) containing the message 354 header (see [RFC7230], Section 3.2), 356 2. the payload body (see [RFC7230], Section 3.3), sent as a series 357 of DATA frames (see Section 4.2.2), 359 3. optionally, one header block containing the trailer-part, if 360 present (see [RFC7230], Section 4.1.2). 362 In addition, prior to sending the message header block indicated 363 above, a response may contain zero or more header blocks containing 364 the message headers of informational (1xx) HTTP responses (see 365 [RFC7230], Section 3.2 and [RFC7231], Section 6.2). 367 A server MAY interleave one or more PUSH_PROMISE frames (see 368 Section 4.2.7) with the frames of a response message. These 369 PUSH_PROMISE frames are not part of the response; see Section 3.3.3 370 for more details. 372 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 373 MUST NOT be used. 375 Trailing header fields are carried in an additional header block 376 following the body. Senders MUST send only one header block in the 377 trailers section; receivers MUST discard any subsequent header 378 blocks. 380 An HTTP request/response exchange fully consumes a bidirectional QUIC 381 stream. After sending a request, a client closes the stream for 382 sending; after sending a response, the server closes the stream for 383 sending and the QUIC stream is fully closed. 385 A server can send a complete response prior to the client sending an 386 entire request if the response does not depend on any portion of the 387 request that has not been sent and received. When this is true, a 388 server MAY request that the client abort transmission of a request 389 without error by triggering a QUIC STOP_SENDING with error code 390 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 391 its streams. Clients MUST NOT discard complete responses as a result 392 of having their request terminated abruptly, though clients can 393 always discard responses at their discretion for other reasons. 395 Changes to the state of a request stream, including receiving a 396 RST_STREAM with any error code, do not affect the state of the 397 server's response. Servers do not abort a response in progress 398 solely due to a state change on the request stream. However, if the 399 request stream terminates without containing a usable HTTP request, 400 the server SHOULD abort its response with the error code 401 HTTP_INCOMPLETE_REQUEST. 403 3.1.1. Header Formatting and Compression 405 HTTP header fields carry information as a series of key-value pairs. 406 For a listing of registered HTTP header fields, see the "Message 407 Header Field" registry maintained at 408 https://www.iana.org/assignments/message-headers [4]. 410 Just as in previous versions of HTTP, header field names are strings 411 of ASCII characters that are compared in a case-insensitive fashion. 412 Properties of HTTP header field names and values are discussed in 413 more detail in Section 3.2 of [RFC7230], though the wire rendering in 414 HTTP/QUIC differs. As in HTTP/2, header field names MUST be 415 converted to lowercase prior to their encoding. A request or 416 response containing uppercase header field names MUST be treated as 417 malformed. 419 As in HTTP/2, HTTP/QUIC uses special pseudo-header fields beginning 420 with ':' character (ASCII 0x3a) to convey the target URI, the method 421 of the request, and the status code for the response. These pseudo- 422 header fields are defined in Section 8.1.2.3 and 8.1.2.4 of 423 [RFC7540]. Pseudo-header fields are not HTTP header fields. 424 Endpoints MUST NOT generate pseudo-header fields other than those 425 defined in [RFC7540]. The restrictions on the use of pseudo-header 426 fields in Section 8.1.2.1 of [RFC7540] also apply to HTTP/QUIC. 428 HTTP/QUIC uses QPACK header compression as described in [QPACK], a 429 variation of HPACK which allows the flexibility to avoid header- 430 compression-induced head-of-line blocking. See that document for 431 additional details. 433 3.1.2. The CONNECT Method 435 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 436 used with HTTP proxies to establish a TLS session with an origin 437 server for the purposes of interacting with "https" resources. In 438 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 439 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 440 establish a tunnel over a single HTTP/2 stream to a remote host for 441 similar purposes. 443 A CONNECT request in HTTP/QUIC functions in the same manner as in 444 HTTP/2. The request MUST be formatted as described in [RFC7540], 445 Section 8.3. A CONNECT request that does not conform to these 446 restrictions is malformed. The request stream MUST NOT be half- 447 closed at the end of the request. 449 A proxy that supports CONNECT establishes a TCP connection 450 ([RFC0793]) to the server identified in the ":authority" pseudo- 451 header field. Once this connection is successfully established, the 452 proxy sends a HEADERS frame containing a 2xx series status code to 453 the client, as defined in [RFC7231], Section 4.3.6. 455 All DATA frames on the request stream correspond to data sent on the 456 TCP connection. Any DATA frame sent by the client is transmitted by 457 the proxy to the TCP server; data received from the TCP server is 458 packaged into DATA frames by the proxy. Note that the size and 459 number of TCP segments is not guaranteed to map predictably to the 460 size and number of HTTP DATA or QUIC STREAM frames. 462 The TCP connection can be closed by either peer. When the client 463 ends the request stream (that is, the receive stream at the proxy 464 enters the "Data Recvd" state), the proxy will set the FIN bit on its 465 connection to the TCP server. When the proxy receives a packet with 466 the FIN bit set, it will terminate the send stream that it sends to 467 client. TCP connections which remain half-closed in a single 468 direction are not invalid, but are often handled poorly by servers, 469 so clients SHOULD NOT close a stream for sending while they still 470 expect to receive data from the target of the CONNECT. 472 A TCP connection error is signaled with RST_STREAM. A proxy treats 473 any error in the TCP connection, which includes receiving a TCP 474 segment with the RST bit set, as a stream error of type 475 HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send 476 a TCP segment with the RST bit set if it detects an error with the 477 stream or the QUIC connection. 479 3.1.3. Request Cancellation 481 Either client or server can cancel requests by aborting the stream 482 (QUIC RST_STREAM or STOP_SENDING frames, as appropriate) with an 483 error code of HTTP_REQUEST_CANCELLED (Section 6.1). When the client 484 cancels a response, it indicates that this response is no longer of 485 interest. Clients SHOULD cancel requests by aborting both directions 486 of a stream. 488 When the server cancels its response stream using 489 HTTP_REQUEST_CANCELLED, it indicates that no application processing 490 was performed. The client can treat requests cancelled by the server 491 as though they had never been sent at all, thereby allowing them to 492 be retried later on a new connection. Servers MUST NOT use the 493 HTTP_REQUEST_CANCELLED status for requests which were partially or 494 fully processed. 496 Note: In this context, "processed" means that some data from the 497 stream was passed to some higher layer of software that might have 498 taken some action as a result. 500 If a stream is cancelled after receiving a complete response, the 501 client MAY ignore the cancellation and use the response. However, if 502 a stream is cancelled after receiving a partial response, the 503 response SHOULD NOT be used. Automatically retrying such requests is 504 not possible, unless this is otherwise permitted (e.g., idempotent 505 actions like GET, PUT, or DELETE). 507 3.2. Request Prioritization 509 HTTP/QUIC uses a priority scheme similar to that described in 510 [RFC7540], Section 5.3. In this priority scheme, a given stream can 511 be designated as dependent upon another request, which expresses the 512 preference that the latter stream (the "parent" request) be allocated 513 resources before the former stream (the "dependent" request). Taken 514 together, the dependencies across all requests in a connection form a 515 dependency tree. The structure of the dependency tree changes as 516 PRIORITY frames add, remove, or change the dependency links between 517 requests. 519 The PRIORITY frame Section 4.2.4 identifies a prioritized element. 520 The elements which can be prioritized are: 522 o Requests, identified by the ID of the request stream 524 o Pushes, identified by the Push ID of the promised resource 525 (Section 4.2.7) 527 o Placeholders, identified by a Placeholder ID 529 An element can depend on another element or on the root of the tree. 530 A reference to an element which is no longer in the tree is treated 531 as a reference to the root of the tree. 533 Only a client can send PRIORITY frames. A server MUST NOT send a 534 PRIORITY frame. 536 3.2.1. Placeholders 538 In HTTP/2, certain implementations used closed or unused streams as 539 placeholders in describing the relative priority of requests. 540 However, this created confusion as servers could not reliably 541 identify which elements of the priority tree could safely be 542 discarded. Clients could potentially reference closed streams long 543 after the server had discarded state, leading to disparate views of 544 the prioritization the client had attempted to express. 546 In HTTP/QUIC, a number of placeholders are explicitly permitted by 547 the server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because 548 the server commits to maintain these IDs in the tree, clients can use 549 them with confidence that the server will not have discarded the 550 state. 552 Placeholders are identified by an ID between zero and one less than 553 the number of placeholders the server has permitted. 555 3.2.2. Priority Tree Maintenance 557 Servers can aggressively prune inactive regions from the priority 558 tree, because placeholders will be used to "root" any persistent 559 structure of the tree which the client cares about retaining. For 560 prioritization purposes, a node in the tree is considered "inactive" 561 when the corresponding stream has been closed for at least two round- 562 trip times (using any reasonable estimate available on the server). 563 This delay helps mitigate race conditions where the server has pruned 564 a node the client believed was still active and used as a Stream 565 Dependency. 567 Specifically, the server MAY at any time: 569 o Identify and discard branches of the tree containing only inactive 570 nodes (i.e. a node with only other inactive nodes as descendants, 571 along with those descendants) 573 o Identify and condense interior regions of the tree containing only 574 inactive nodes, allocating weight appropriately 576 x x x 577 | | | 578 P P P 579 / \ | | 580 I I ==> I ==> A 581 / \ | | 582 A I A A 583 | | 584 A A 586 Figure 1: Example of Priority Tree Pruning 588 In the example in Figure 1, "P" represents a Placeholder, "A" 589 represents an active node, and "I" represents an inactive node. In 590 the first step, the server discards two inactive branches (each a 591 single node). In the second step, the server condenses an interior 592 inactive node. Note that these transformations will result in no 593 change in the resources allocated to a particular active stream. 595 Clients SHOULD assume the server is actively performing such pruning 596 and SHOULD NOT declare a dependency on a stream it knows to have been 597 closed. 599 3.3. Unidirectional Streams 601 Unidirectional streams, in either direction, are used for a range of 602 purposes. The purpose is indicated by a stream type, which is sent 603 as a single octet header at the start of the stream. The format and 604 structure of data that follows this header is determined by the 605 stream type. 607 0 1 2 3 4 5 6 7 608 +-+-+-+-+-+-+-+-+ 609 |Stream Type (8)| 610 +-+-+-+-+-+-+-+-+ 612 Figure 2: Unidirectional Stream Header 614 Some stream types are reserved (Section 3.3.1). Two stream types are 615 defined in this document: control streams (Section 3.3.2) and push 616 streams (Section 3.3.3). Other stream types can be defined by 617 extensions to HTTP/QUIC. 619 If the stream header indicates a stream type which is not supported 620 by the recipient, the remainder of the stream cannot be consumed as 621 the semantics are unknown. Recipients of unknown stream types MAY 622 trigger a QUIC STOP_SENDING frame with an error code of 623 HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an 624 error of any kind. 626 Implementations MAY send stream types before knowing whether the peer 627 supports them. However, stream types which could modify the state or 628 semantics of existing protocol components, including QPACK or other 629 extensions, MUST NOT be sent until the peer is known to support them. 631 3.3.1. Reserved Stream Types 633 Stream types of the format "0x1f * N" are reserved to exercise the 634 requirement that unknown types be ignored. These streams have no 635 semantic meaning, and can be sent when application-layer padding is 636 desired. They MAY also be sent on connections where no request data 637 is currently being transferred. Endpoints MUST NOT consider these 638 streams to have any meaning upon receipt. 640 The payload and length of the stream are selected in any manner the 641 implementation chooses. 643 3.3.2. Control Streams 645 The control stream is indicated by a stream type of "0x43" (ASCII 646 'C'). Data on this stream consists of HTTP/QUIC frames, as defined 647 in Section 4.2. 649 Each side MUST initiate a single control stream at the beginning of 650 the connection and send its SETTINGS frame as the first frame on this 651 stream. If the first frame of the control stream is any other frame 652 type, this MUST be treated as a connection error of type 653 HTTP_MISSING_SETTINGS. Only one control stream per peer is 654 permitted; receipt of a second stream which claims to be a control 655 stream MUST be treated as a connection error of type 656 HTTP_WRONG_STREAM_COUNT. If the control stream is closed at any 657 point, this MUST be treated as a connection error of type 658 HTTP_CLOSED_CRITICAL_STREAM. 660 A pair of unidirectional streams is used rather than a single 661 bidirectional stream. This allows either peer to send data as soon 662 they are able. Depending on whether 0-RTT is enabled on the 663 connection, either client or server might be able to send stream data 664 first after the cryptographic handshake completes. 666 3.3.3. Server Push 668 HTTP/QUIC server push is similar to what is described in HTTP/2 669 [RFC7540], but uses different mechanisms. 671 The PUSH_PROMISE frame (Section 4.2.7) is sent on the client- 672 initiated bidirectional stream that carried the request that 673 generated the push. This allows the server push to be associated 674 with a request. Ordering of a PUSH_PROMISE in relation to certain 675 parts of the response is important (see Section 8.2.1 of [RFC7540]). 677 The PUSH_PROMISE frame does not reference a stream; it contains a 678 Push ID that uniquely identifies a server push. This allows a server 679 to fulfill promises in the order that best suits its needs. The same 680 Push ID can be used in multiple PUSH_PROMISE frames (see 681 Section 4.2.7). When a server later fulfills a promise, the server 682 push response is conveyed on a push stream. 684 A push stream is indicated by a stream type of "0x50" (ASCII 'P'), 685 followed by the Push ID of the promise that it fulfills, encoded as a 686 variable-length integer. The remaining data on this stream consists 687 of HTTP/QUIC frames, as defined in Section 4.2, and carries the 688 response side of an HTTP message exchange as described in 689 Section 3.1. The header of the request message is carried by a 690 PUSH_PROMISE frame (see Section 4.2.7) on the request stream which 691 generated the push. Promised requests MUST conform to the 692 requirements in Section 8.2 of [RFC7540]. 694 Only servers can push; if a server receives a client-initiated push 695 stream, this MUST be treated as a stream error of type 696 HTTP_WRONG_STREAM_DIRECTION. 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 |Stream Type (8)| Push ID (i) ... 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Figure 3: Push Stream Header 706 Server push is only enabled on a connection when a client sends a 707 MAX_PUSH_ID frame (see Section 4.2.9). A server cannot use server 708 push until it receives a MAX_PUSH_ID frame. A client sends 709 additional MAX_PUSH_ID frames to control the number of pushes that a 710 server can promise. A server SHOULD use Push IDs sequentially, 711 starting at 0. A client MUST treat receipt of a push stream with a 712 Push ID that is greater than the maximum Push ID as a connection 713 error of type HTTP_PUSH_LIMIT_EXCEEDED. 715 Each Push ID MUST only be used once in a push stream header. If a 716 push stream header includes a Push ID that was used in another push 717 stream header, the client MUST treat this as a connection error of 718 type HTTP_DUPLICATE_PUSH. 720 If a promised server push is not needed by the client, the client 721 SHOULD send a CANCEL_PUSH frame. If the push stream is already open, 722 a QUIC STOP_SENDING frame with an appropriate error code can be used 723 instead (e.g., HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see 724 Section 6). This asks the server not to transfer the data and 725 indicates that it will be discarded upon receipt. 727 4. HTTP Framing Layer 729 Frames are used on the control stream, request streams, and push 730 streams. This section describes HTTP framing in QUIC and highlights 731 some differences from HTTP/2 framing. For more detail on differences 732 from HTTP/2, see Section 8.2. 734 4.1. Frame Layout 736 All frames have the following format: 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Length (i) ... 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type (8) | Frame Payload (*) ... 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Figure 4: HTTP/QUIC frame format 748 A frame includes the following fields: 750 Length: A variable-length integer that describes the length of the 751 Frame Payload. This length does not include the Type field. 753 Type: An 8-bit type for the frame. 755 Frame Payload: A payload, the semantics of which are determined by 756 the Type field. 758 4.2. Frame Definitions 760 4.2.1. Reserved Frame Types 762 Frame types of the format "0xb + (0x1f * N)" are reserved to exercise 763 the requirement that unknown types be ignored. These frames have no 764 semantic meaning, and can be sent when application-layer padding is 765 desired. They MAY also be sent on connections where no request data 766 is currently being transferred. Endpoints MUST NOT consider these 767 frames to have any meaning upon receipt. 769 The payload and length of the frames are selected in any manner the 770 implementation chooses. 772 4.2.2. DATA 774 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 775 octets associated with an HTTP request or response payload. 777 DATA frames MUST be associated with an HTTP request or response. If 778 a DATA frame is received on either control stream, the recipient MUST 779 respond with a connection error (Section 6) of type 780 HTTP_WRONG_STREAM. 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Payload (*) ... 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 Figure 5: DATA frame payload 790 DATA frames MUST contain a non-zero-length payload. If a DATA frame 791 is received with a payload length of zero, the recipient MUST respond 792 with a stream error (Section 6) of type HTTP_MALFORMED_FRAME. 794 4.2.3. HEADERS 796 The HEADERS frame (type=0x1) is used to carry a header block, 797 compressed using QPACK. See [QPACK] for more details. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Header Block (*) ... 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure 6: HEADERS frame payload 807 HEADERS frames can only be sent on request / push streams. 809 4.2.4. PRIORITY 811 The PRIORITY (type=0x02) frame specifies the sender-advised priority 812 of a stream and is substantially different in format from [RFC7540]. 813 In order to ensure that prioritization is processed in a consistent 814 order, PRIORITY frames MUST be sent on the control stream. A 815 PRIORITY frame sent on any other stream MUST be treated as a 816 HTTP_WRONG_STREAM error. 818 The format has been modified to accommodate not being sent on a 819 request stream, to allow for identification of server pushes, and the 820 larger stream ID space of QUIC. The semantics of the Stream 821 Dependency, Weight, and E flag are otherwise the same as in HTTP/2. 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 |PT |DT |Empty|E| 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Prioritized Element ID (i) ... 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Element Dependency ID (i) ... 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Weight (8) | 833 +-+-+-+-+-+-+-+-+ 835 Figure 7: PRIORITY frame payload 837 The PRIORITY frame payload has the following fields: 839 Prioritized Type: A two-bit field indicating the type of element 840 being prioritized. 842 Dependency Type: A two-bit field indicating the type of element 843 being depended on. 845 Empty: A three-bit field which MUST be zero when sent and MUST be 846 ignored on receipt. 848 Exclusive: A flag which indicates that the stream dependency is 849 exclusive (see [RFC7540], Section 5.3). 851 Prioritized Element ID: A variable-length integer that identifies 852 the element being prioritized. Depending on the value of 853 Prioritized Type, this contains the Stream ID of a request stream, 854 the Push ID of a promised resource, or a Placeholder ID of a 855 placeholder. 857 Element Dependency ID: A variable-length integer that identifies the 858 element on which a dependency is being expressed. Depending on 859 the value of Dependency Type, this contains the Stream ID of a 860 request stream, the Push ID of a promised resource, or a 861 Placeholder ID of a placeholder. For details of dependencies, see 862 Section 3.2 and [RFC7540], Section 5.3. 864 Weight: An unsigned 8-bit integer representing a priority weight for 865 the stream (see [RFC7540], Section 5.3). Add one to the value to 866 obtain a weight between 1 and 256. 868 A PRIORITY frame identifies an element to prioritize, and an element 869 upon which it depends. A Prioritized ID or Dependency ID identifies 870 a client-initiated request using the corresponding stream ID, a 871 server push using a Push ID (see Section 4.2.7), or a placeholder 872 using a Placeholder ID (see Section 3.2.1). 874 The values for the Prioritized Element Type and Element Dependency 875 Type imply the interpretation of the associated Element ID fields. 877 +-----------+------------------+---------------------+ 878 | Type Bits | Type Description | Element ID Contents | 879 +-----------+------------------+---------------------+ 880 | 00 | Request stream | Stream ID | 881 | | | | 882 | 01 | Push stream | Push ID | 883 | | | | 884 | 10 | Placeholder | Placeholder ID | 885 | | | | 886 | 11 | Root of the tree | Ignored | 887 +-----------+------------------+---------------------+ 889 Note that the root of the tree cannot be referenced using a Stream ID 890 of 0, as in [RFC7540]; QUIC stream 0 carries a valid HTTP request. 891 The root of the tree cannot be reprioritized. A PRIORITY frame that 892 prioritizes the root of the tree MUST be treated as a connection 893 error of type HTTP_MALFORMED_FRAME. 895 When a PRIORITY frame claims to reference a request, the associated 896 ID MUST identify a client-initiated bidirectional stream. A server 897 MUST treat receipt of PRIORITY frame with a Stream ID of any other 898 type as a connection error of type HTTP_MALFORMED_FRAME. 900 A PRIORITY frame that references a non-existent Push ID or a 901 Placeholder ID greater than the server's limit MUST be treated as a 902 HTTP_MALFORMED_FRAME error. 904 A PRIORITY frame MUST contain only the identified fields. A PRIORITY 905 frame that contains more or fewer fields, or a PRIORITY frame that 906 includes a truncated integer encoding MUST be treated as a connection 907 error of type HTTP_MALFORMED_FRAME. 909 4.2.5. CANCEL_PUSH 911 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of 912 server push prior to the push stream being created. The CANCEL_PUSH 913 frame identifies a server push request by Push ID (see Section 4.2.7) 914 using a variable-length integer. 916 When a server receives this frame, it aborts sending the response for 917 the identified server push. If the server has not yet started to 918 send the server push, it can use the receipt of a CANCEL_PUSH frame 919 to avoid opening a stream. If the push stream has been opened by the 920 server, the server SHOULD send a QUIC RST_STREAM frame on those 921 streams and cease transmission of the response. 923 A server can send this frame to indicate that it won't be sending a 924 response prior to creation of a push stream. Once the push stream 925 has been created, sending CANCEL_PUSH has no effect on the state of 926 the push stream. A QUIC RST_STREAM frame SHOULD be used instead to 927 cancel transmission of the server push response. 929 A CANCEL_PUSH frame is sent on the control stream. Sending a 930 CANCEL_PUSH frame on a stream other than the control stream MUST be 931 treated as a stream error of type HTTP_WRONG_STREAM. 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Push ID (i) ... 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 Figure 8: CANCEL_PUSH frame payload 941 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 942 integer. The Push ID identifies the server push that is being 943 cancelled (see Section 4.2.7). 945 If the client receives a CANCEL_PUSH frame, that frame might identify 946 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 948 An endpoint MUST treat a CANCEL_PUSH frame which does not contain 949 exactly one properly-formatted variable-length integer as a 950 connection error of type HTTP_MALFORMED_FRAME. 952 4.2.6. SETTINGS 954 The SETTINGS frame (type=0x4) conveys configuration parameters that 955 affect how endpoints communicate, such as preferences and constraints 956 on peer behavior, and is different from [RFC7540]. Individually, a 957 SETTINGS parameter can also be referred to as a "setting". 959 SETTINGS parameters are not negotiated; they describe characteristics 960 of the sending peer, which can be used by the receiving peer. 961 However, a negotiation can be implied by the use of SETTINGS - a peer 962 uses SETTINGS to advertise a set of supported values. The recipient 963 can then choose which entries from this list are also acceptable and 964 proceed with the value it has chosen. (This choice could be 965 announced in a field of an extension frame, or in its own value in 966 SETTINGS.) 968 Different values for the same parameter can be advertised by each 969 peer. For example, a client might be willing to consume a very large 970 response header, while servers are more cautious about request size. 972 Parameters MUST NOT occur more than once. A receiver MAY treat the 973 presence of the same parameter more than once as a connection error 974 of type HTTP_MALFORMED_FRAME. 976 The payload of a SETTINGS frame consists of zero or more parameters, 977 each consisting of an unsigned 16-bit setting identifier and a value 978 which uses the QUIC variable-length integer encoding. 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Identifier (16) | Value (i) ... 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 9: SETTINGS value format 988 Each value MUST be compared against the remaining length of the 989 SETTINGS frame. Any value which purports to cross the end of the 990 frame MUST cause the SETTINGS frame to be considered malformed and 991 trigger a connection error of type HTTP_MALFORMED_FRAME. 993 An implementation MUST ignore the contents for any SETTINGS 994 identifier it does not understand. 996 SETTINGS frames always apply to a connection, never a single stream. 997 A SETTINGS frame MUST be sent as the first frame of either control 998 stream (see Section 3) by each peer, and MUST NOT be sent 999 subsequently or on any other stream. If an endpoint receives a 1000 SETTINGS frame on a different stream, the endpoint MUST respond with 1001 a connection error of type HTTP_WRONG_STREAM. If an endpoint 1002 receives a second SETTINGS frame, the endpoint MUST respond with a 1003 connection error of type HTTP_MALFORMED_FRAME. 1005 The SETTINGS frame affects connection state. A badly formed or 1006 incomplete SETTINGS frame MUST be treated as a connection error 1007 (Section 6) of type HTTP_MALFORMED_FRAME. 1009 4.2.6.1. Defined SETTINGS Parameters 1011 The following settings are defined in HTTP/QUIC: 1013 SETTINGS_NUM_PLACEHOLDERS (0x3): This value SHOULD be non-zero. The 1014 default value is 16. 1016 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. 1018 Settings values of the format "0x?a?a" are reserved to exercise the 1019 requirement that unknown parameters be ignored. Such settings have 1020 no defined meaning. Endpoints SHOULD include at least one such 1021 setting in their SETTINGS frame. Endpoints MUST NOT consider such 1022 settings to have any meaning upon receipt. 1024 Because the setting has no defined meaning, the value of the setting 1025 can be any value the implementation selects. 1027 Additional settings MAY be defined by extensions to HTTP/QUIC. 1029 4.2.6.2. Initial SETTINGS Values 1031 When a 0-RTT QUIC connection is being used, the client's initial 1032 requests will be sent before the arrival of the server's SETTINGS 1033 frame. Clients MUST store the settings the server provided in the 1034 session being resumed and MUST comply with stored settings until the 1035 server's current settings are received. Remembered settings apply to 1036 the new connection until the server's SETTINGS frame is received. 1038 A server can remember the settings that it advertised, or store an 1039 integrity-protected copy of the values in the ticket and recover the 1040 information when accepting 0-RTT data. A server uses the HTTP/QUIC 1041 settings values in determining whether to accept 0-RTT data. 1043 A server MAY accept 0-RTT and subsequently provide different settings 1044 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 1045 SETTINGS frame MUST NOT reduce any limits or alter any values that 1046 might be violated by the client with its 0-RTT data. 1048 When a 1-RTT QUIC connection is being used, the client MUST NOT send 1049 requests prior to receiving and processing the server's SETTINGS 1050 frame. 1052 4.2.7. PUSH_PROMISE 1054 The PUSH_PROMISE frame (type=0x05) is used to carry a request header 1055 set from server to client, as in HTTP/2. 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Push ID (i) ... 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Header Block (*) ... 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Figure 10: PUSH_PROMISE frame payload 1067 The payload consists of: 1069 Push ID: A variable-length integer that identifies the server push 1070 request. A push ID is used in push stream header (Section 3.3.3), 1071 CANCEL_PUSH frames (Section 4.2.5), and PRIORITY frames 1072 (Section 4.2.4). 1074 Header Block: QPACK-compressed request header fields for the 1075 promised response. See [QPACK] for more details. 1077 A server MUST NOT use a Push ID that is larger than the client has 1078 provided in a MAX_PUSH_ID frame (Section 4.2.9). A client MUST treat 1079 receipt of a PUSH_PROMISE that contains a larger Push ID than the 1080 client has advertised as a connection error of type 1081 HTTP_MALFORMED_FRAME. 1083 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 1084 This allows the server to use the same server push in response to 1085 multiple concurrent requests. Referencing the same server push 1086 ensures that a PUSH_PROMISE can be made in relation to every response 1087 in which server push might be needed without duplicating pushes. 1089 A server that uses the same Push ID in multiple PUSH_PROMISE frames 1090 MUST include the same header fields each time. The octets of the 1091 header block MAY be different due to differing encoding, but the 1092 header fields and their values MUST be identical. Note that ordering 1093 of header fields is significant. A client MUST treat receipt of a 1094 PUSH_PROMISE with conflicting header field values for the same Push 1095 ID as a connection error of type HTTP_MALFORMED_FRAME. 1097 Allowing duplicate references to the same Push ID is primarily to 1098 reduce duplication caused by concurrent requests. A server SHOULD 1099 avoid reusing a Push ID over a long period. Clients are likely to 1100 consume server push responses and not retain them for reuse over 1101 time. Clients that see a PUSH_PROMISE that uses a Push ID that they 1102 have since consumed and discarded are forced to ignore the 1103 PUSH_PROMISE. 1105 4.2.8. GOAWAY 1107 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 1108 a connection by a server. GOAWAY allows a server to stop accepting 1109 new requests while still finishing processing of previously received 1110 requests. This enables administrative actions, like server 1111 maintenance. GOAWAY by itself does not close a connection. 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Stream ID (i) ... 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 Figure 11: GOAWAY frame payload 1121 The GOAWAY frame carries a QUIC Stream ID for a client-initiated 1122 bidirectional stream encoded as a variable-length integer. A client 1123 MUST treat receipt of a GOAWAY frame containing a Stream ID of any 1124 other type as a connection error of type HTTP_MALFORMED_FRAME. 1126 Clients do not need to send GOAWAY to initiate a graceful shutdown; 1127 they simply stop making new requests. A server MUST treat receipt of 1128 a GOAWAY frame as a connection error (Section 6) of type 1129 HTTP_UNEXPECTED_GOAWAY. 1131 The GOAWAY frame applies to the connection, not a specific stream. 1132 An endpoint MUST treat a GOAWAY frame on a stream other than the 1133 control stream as a connection error (Section 6) of type 1134 HTTP_WRONG_STREAM. 1136 See Section 5.2 for more information on the use of the GOAWAY frame. 1138 4.2.9. MAX_PUSH_ID 1140 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 1141 number of server pushes that the server can initiate. This sets the 1142 maximum value for a Push ID that the server can use in a PUSH_PROMISE 1143 frame. Consequently, this also limits the number of push streams 1144 that the server can initiate in addition to the limit set by the QUIC 1145 MAX_STREAM_ID frame. 1147 The MAX_PUSH_ID frame is always sent on a control stream. Receipt of 1148 a MAX_PUSH_ID frame on any other stream MUST be treated as a 1149 connection error of type HTTP_WRONG_STREAM. 1151 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1152 receipt of a MAX_PUSH_ID frame as a connection error of type 1153 HTTP_MALFORMED_FRAME. 1155 The maximum Push ID is unset when a connection is created, meaning 1156 that a server cannot push until it receives a MAX_PUSH_ID frame. A 1157 client that wishes to manage the number of promised server pushes can 1158 increase the maximum Push ID by sending a MAX_PUSH_ID frame as the 1159 server fulfills or cancels server pushes. 1161 0 1 2 3 1162 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 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Push ID (i) ... 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 Figure 12: MAX_PUSH_ID frame payload 1169 The MAX_PUSH_ID frame carries a single variable-length integer that 1170 identifies the maximum value for a Push ID that the server can use 1171 (see Section 4.2.7). A MAX_PUSH_ID frame cannot reduce the maximum 1172 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 1173 previously received MUST be treated as a connection error of type 1174 HTTP_MALFORMED_FRAME. 1176 A server MUST treat a MAX_PUSH_ID frame payload that does not contain 1177 a single variable-length integer as a connection error of type 1178 HTTP_MALFORMED_FRAME. 1180 5. Connection Closure 1182 Once established, an HTTP/QUIC connection can be used for many 1183 requests and responses over time until the connection is closed. 1184 Connection closure can happen in any of several different ways. 1186 5.1. Idle Connections 1188 Each QUIC endpoint declares an idle timeout during the handshake. If 1189 the connection remains idle (no packets received) for longer than 1190 this duration, the peer will assume that the connection has been 1191 closed. HTTP/QUIC implementations will need to open a new connection 1192 for new requests if the existing connection has been idle for longer 1193 than the server's advertised idle timeout, and SHOULD do so if 1194 approaching the idle timeout. 1196 HTTP clients are expected to use QUIC PING frames to keep connections 1197 open while there are responses outstanding for requests or server 1198 pushes. If the client is not expecting a response from the server, 1199 allowing an idle connection to time out is preferred over expending 1200 effort maintaining a connection that might not be needed. A gateway 1201 MAY use PING to maintain connections in anticipation of need rather 1202 than incur the latency cost of connection establishment to servers. 1203 Servers SHOULD NOT use PING frames to keep a connection open. 1205 5.2. Connection Shutdown 1207 Even when a connection is not idle, either endpoint can decide to 1208 stop using the connection and let the connection close gracefully. 1209 Since clients drive request generation, clients perform a connection 1210 shutdown by not sending additional requests on the connection; 1211 responses and pushed responses associated to previous requests will 1212 continue to completion. Servers perform the same function by 1213 communicating with clients. 1215 Servers initiate the shutdown of a connection by sending a GOAWAY 1216 frame (Section 4.2.8). The GOAWAY frame indicates that client- 1217 initiated requests on lower stream IDs were or might be processed in 1218 this connection, while requests on the indicated stream ID and 1219 greater were not accepted. This enables client and server to agree 1220 on which requests were accepted prior to the connection shutdown. 1221 This identifier MAY be lower than the stream limit identified by a 1222 QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were 1223 processed. Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit 1224 after sending a GOAWAY frame. 1226 Once sent, the server MUST cancel requests sent on streams with an 1227 identifier higher than the indicated last Stream ID. Clients MUST 1228 NOT send new requests on the connection after receiving GOAWAY, 1229 although requests might already be in transit. A new connection can 1230 be established for new requests. 1232 If the client has sent requests on streams with a higher Stream ID 1233 than indicated in the GOAWAY frame, those requests are considered 1234 cancelled (Section 3.1.3). Clients SHOULD reset any streams above 1235 this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also 1236 cancel requests on streams below the indicated ID if these requests 1237 were not processed. 1239 Requests on Stream IDs less than the Stream ID in the GOAWAY frame 1240 might have been processed; their status cannot be known until they 1241 are completed successfully, reset individually, or the connection 1242 terminates. 1244 Servers SHOULD send a GOAWAY frame when the closing of a connection 1245 is known in advance, even if the advance notice is small, so that the 1246 remote peer can know whether a stream has been partially processed or 1247 not. For example, if an HTTP client sends a POST at the same time 1248 that a server closes a QUIC connection, the client cannot know if the 1249 server started to process that POST request if the server does not 1250 send a GOAWAY frame to indicate what streams it might have acted on. 1252 A client that is unable to retry requests loses all requests that are 1253 in flight when the server closes the connection. A server MAY send 1254 multiple GOAWAY frames indicating different stream IDs, but MUST NOT 1255 increase the value they send in the last Stream ID, since clients 1256 might already have retried unprocessed requests on another 1257 connection. A server that is attempting to gracefully shut down a 1258 connection SHOULD send an initial GOAWAY frame with the last Stream 1259 ID set to the current value of QUIC's MAX_STREAM_ID and SHOULD NOT 1260 increase the MAX_STREAM_ID thereafter. This signals to the client 1261 that a shutdown is imminent and that initiating further requests is 1262 prohibited. After allowing time for any in-flight requests (at least 1263 one round-trip time), the server MAY send another GOAWAY frame with 1264 an updated last Stream ID. This ensures that a connection can be 1265 cleanly shut down without losing requests. 1267 Once all accepted requests have been processed, the server can permit 1268 the connection to become idle, or MAY initiate an immediate closure 1269 of the connection. An endpoint that completes a graceful shutdown 1270 SHOULD use the HTTP_NO_ERROR code when closing the connection. 1272 5.3. Immediate Application Closure 1274 An HTTP/QUIC implementation can immediately close the QUIC connection 1275 at any time. This results in sending a QUIC APPLICATION_CLOSE frame 1276 to the peer; the error code in this frame indicates to the peer why 1277 the connection is being closed. See Section 6 for error codes which 1278 can be used when closing a connection. 1280 Before closing the connection, a GOAWAY MAY be sent to allow the 1281 client to retry some requests. Including the GOAWAY frame in the 1282 same packet as the QUIC APPLICATION_CLOSE frame improves the chances 1283 of the frame being received by clients. 1285 5.4. Transport Closure 1287 For various reasons, the QUIC transport could indicate to the 1288 application layer that the connection has terminated. This might be 1289 due to an explicit closure by the peer, a transport-level error, or a 1290 change in network topology which interrupts connectivity. 1292 If a connection terminates without a GOAWAY frame, clients MUST 1293 assume that any request which was sent, whether in whole or in part, 1294 might have been processed. 1296 6. Error Handling 1298 QUIC allows the application to abruptly terminate (reset) individual 1299 streams or the entire connection when an error is encountered. These 1300 are referred to as "stream errors" or "connection errors" and are 1301 described in more detail in [QUIC-TRANSPORT]. 1303 This section describes HTTP/QUIC-specific error codes which can be 1304 used to express the cause of a connection or stream error. 1306 6.1. HTTP/QUIC Error Codes 1308 The following error codes are defined for use in QUIC RST_STREAM, 1309 STOP_SENDING, and APPLICATION_CLOSE frames when using HTTP/QUIC. 1311 STOPPING (0x00): This value is reserved by the transport to be used 1312 in response to QUIC STOP_SENDING frames. 1314 HTTP_NO_ERROR (0x01): No error. This is used when the connection or 1315 stream needs to be closed, but there is no error to signal. 1317 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1318 which the client will not accept on this connection. 1320 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1321 HTTP stack. 1323 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1324 content which the client has cached. 1326 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1327 requested data. 1329 HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated 1330 without containing a fully-formed request. 1332 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1333 a CONNECT request was reset or abnormally closed. 1335 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1336 exhibiting a behavior that might be generating excessive load. 1338 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1339 served over HTTP/QUIC. The peer should retry over HTTP/1.1. 1341 HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it 1342 is not permitted. 1344 HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current 1345 maximum Push ID was referenced. 1347 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1348 different stream headers. 1350 HTTP_UNKNOWN_STREAM_TYPE (0x0D): A unidirectional stream header 1351 contained an unknown stream type. 1353 HTTP_WRONG_STREAM_COUNT (0x0E): A unidirectional stream type was 1354 used more times than is permitted by that type. 1356 HTTP_CLOSED_CRITICAL_STREAM (0x0F): A stream required by the 1357 connection was closed or reset. 1359 HTTP_WRONG_STREAM_DIRECTION (0x0010): A unidirectional stream type 1360 was used by a peer which is not permitted to do so. 1362 HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request 1363 is not needed to produce a response. For use in STOP_SENDING 1364 only. 1366 HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at 1367 the beginning of the control stream. 1369 HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol 1370 requirements in a way which doesn't match a more specific error 1371 code, or endpoint declines to use the more specific error code. 1373 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1374 The frame type is included as the last octet of the error code. 1375 For example, an error in a MAX_PUSH_ID frame would be indicated 1376 with the code (0x10D). 1378 7. Extensions to HTTP/QUIC 1380 HTTP/QUIC permits extension of the protocol. Within the limitations 1381 described in this section, protocol extensions can be used to provide 1382 additional services or alter any aspect of the protocol. Extensions 1383 are effective only within the scope of a single HTTP/QUIC connection. 1385 This applies to the protocol elements defined in this document. This 1386 does not affect the existing options for extending HTTP, such as 1387 defining new methods, status codes, or header fields. 1389 Extensions are permitted to use new frame types (Section 4.2), new 1390 settings (Section 4.2.6.1), new error codes (Section 6), or new 1391 unidirectional stream types (Section 3.3). Registries are 1392 established for managing these extension points: frame types 1393 (Section 10.3), settings (Section 10.4), error codes (Section 10.5), 1394 and stream types (Section 10.6). 1396 Implementations MUST ignore unknown or unsupported values in all 1397 extensible protocol elements. Implementations MUST discard frames 1398 and unidirectional streams that have unknown or unsupported types. 1399 This means that any of these extension points can be safely used by 1400 extensions without prior arrangement or negotiation. 1402 Extensions that could change the semantics of existing protocol 1403 components MUST be negotiated before being used. For example, an 1404 extension that changes the layout of the HEADERS frame cannot be used 1405 until the peer has given a positive signal that this is acceptable. 1406 In this case, it could also be necessary to coordinate when the 1407 revised layout comes into effect. 1409 This document doesn't mandate a specific method for negotiating the 1410 use of an extension but notes that a setting (Section 4.2.6.1) could 1411 be used for that purpose. If both peers set a value that indicates 1412 willingness to use the extension, then the extension can be used. If 1413 a setting is used for extension negotiation, the default value MUST 1414 be defined in such a fashion that the extension is disabled if the 1415 setting is omitted. 1417 8. Considerations for Transitioning from HTTP/2 1419 HTTP/QUIC is strongly informed by HTTP/2, and bears many 1420 similarities. This section describes the approach taken to design 1421 HTTP/QUIC, points out important differences from HTTP/2, and 1422 describes how to map HTTP/2 extensions into HTTP/QUIC. 1424 HTTP/QUIC begins from the premise that HTTP/2 code reuse is a useful 1425 feature, but not a hard requirement. HTTP/QUIC departs from HTTP/2 1426 primarily where necessary to accommodate the differences in behavior 1427 between QUIC and TCP (lack of ordering, support for streams). We 1428 intend to avoid gratuitous changes which make it difficult or 1429 impossible to build extensions with the same semantics applicable to 1430 both protocols at once. 1432 These departures are noted in this section. 1434 8.1. Streams 1436 HTTP/QUIC permits use of a larger number of streams (2^62-1) than 1437 HTTP/2. The considerations about exhaustion of stream identifier 1438 space apply, though the space is significantly larger such that it is 1439 likely that other limits in QUIC are reached first, such as the limit 1440 on the connection flow control window. 1442 8.2. HTTP Frame Types 1444 Many framing concepts from HTTP/2 can be elided away on QUIC, because 1445 the transport deals with them. Because frames are already on a 1446 stream, they can omit the stream number. Because frames do not block 1447 multiplexing (QUIC's multiplexing occurs below this layer), the 1448 support for variable-maximum-length packets can be removed. Because 1449 stream termination is handled by QUIC, an END_STREAM flag is not 1450 required. This permits the removal of the Flags field from the 1451 generic frame layout. 1453 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1454 includes many features (e.g. flow control) which are also present in 1455 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 1456 As a result, several HTTP/2 frame types are not required in HTTP/ 1457 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 1458 has been reserved in order to maximize portability between HTTP/2 and 1459 HTTP/QUIC implementations. However, even equivalent frames between 1460 the two mappings are not identical. 1462 Many of the differences arise from the fact that HTTP/2 provides an 1463 absolute ordering between frames across all streams, while QUIC 1464 provides this guarantee on each stream only. As a result, if a frame 1465 type makes assumptions that frames from different streams will still 1466 be received in the order sent, HTTP/QUIC will break them. 1468 For example, implicit in the HTTP/2 prioritization scheme is the 1469 notion of in-order delivery of priority changes (i.e., dependency 1470 tree mutations): since operations on the dependency tree such as 1471 reparenting a subtree are not commutative, both sender and receiver 1472 must apply them in the same order to ensure that both sides have a 1473 consistent view of the stream dependency tree. HTTP/2 specifies 1474 priority assignments in PRIORITY frames and (optionally) in HEADERS 1475 frames. To achieve in-order delivery of priority changes in HTTP/ 1476 QUIC, PRIORITY frames are sent on the control stream and the PRIORITY 1477 section is removed from the HEADERS frame. 1479 Likewise, HPACK was designed with the assumption of in-order 1480 delivery. A sequence of encoded header blocks must arrive (and be 1481 decoded) at an endpoint in the same order in which they were encoded. 1482 This ensures that the dynamic state at the two endpoints remains in 1483 sync. As a result, HTTP/QUIC uses a modified version of HPACK, 1484 described in [QPACK]. 1486 Frame type definitions in HTTP/QUIC often use the QUIC variable- 1487 length integer encoding. In particular, Stream IDs use this 1488 encoding, which allow for a larger range of possible values than the 1489 encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier 1490 rather than a Stream ID (e.g. Push IDs in PRIORITY frames). 1491 Redefinition of the encoding of extension frame types might be 1492 necessary if the encoding includes a Stream ID. 1494 Because the Flags field is not present in generic HTTP/QUIC frames, 1495 those frames which depend on the presence of flags need to allocate 1496 space for flags as part of their frame payload. 1498 Other than this issue, frame type HTTP/2 extensions are typically 1499 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 1500 control stream in HTTP/QUIC. HTTP/QUIC extensions will not assume 1501 ordering, but would not be harmed by ordering, and would be portable 1502 to HTTP/2 in the same manner. 1504 Below is a listing of how each HTTP/2 frame type is mapped: 1506 DATA (0x0): Padding is not defined in HTTP/QUIC frames. See 1507 Section 4.2.2. 1509 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 1510 not supported. A separate PRIORITY frame MUST be used. Padding 1511 is not defined in HTTP/QUIC frames. See Section 4.2.3. 1513 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 1514 the control stream and can reference either a Stream ID or a Push 1515 ID. See Section 4.2.4. 1517 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 1518 provides stream lifecycle management. The same code point is used 1519 for the CANCEL_PUSH frame (Section 4.2.5). 1521 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 1522 the connection. See Section 4.2.6 and Section 8.3. 1524 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 1525 instead the push stream references the PUSH_PROMISE frame using a 1526 Push ID. See Section 4.2.7. 1528 PING (0x6): PING frames do not exist, since QUIC provides equivalent 1529 functionality. 1531 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 1532 contain an error code. See Section 4.2.8. 1534 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 1535 provides flow control. 1537 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 1538 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted, and 1539 HEADERS frames can be used in series. 1541 Frame types defined by extensions to HTTP/2 need to be separately 1542 registered for HTTP/QUIC if still applicable. The IDs of frames 1543 defined in [RFC7540] have been reserved for simplicity. See 1544 Section 10.3. 1546 8.3. HTTP/2 SETTINGS Parameters 1548 An important difference from HTTP/2 is that settings are sent once, 1549 at the beginning of the connection, and thereafter cannot change. 1550 This eliminates many corner cases around synchronization of changes. 1552 Some transport-level options that HTTP/2 specifies via the SETTINGS 1553 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 1554 HTTP-level options that are retained in HTTP/QUIC have the same value 1555 as in HTTP/2. 1557 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 1559 SETTINGS_HEADER_TABLE_SIZE: See Section 4.2.6.1. 1561 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 1562 which provides a more granular control over server push. 1564 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 1565 Stream ID as part of its flow control logic. Specifying 1566 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 1568 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 1569 connection flow control window sizes to be specified in the 1570 initial transport handshake. Specifying 1571 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 1573 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 1574 QUIC. Specifying it in the SETTINGS frame is an error. 1576 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.6.1. 1578 In HTTP/QUIC, setting values are variable-length integers (6, 14, 30, 1579 or 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 1580 This will often produce a shorter encoding, but can produce a longer 1581 encoding for settings which use the full 32-bit space. Settings 1582 ported from HTTP/2 might choose to redefine the format of their 1583 settings to avoid using the 62-bit encoding. 1585 Settings need to be defined separately for HTTP/2 and HTTP/QUIC. The 1586 IDs of settings defined in [RFC7540] have been reserved for 1587 simplicity. See Section 10.4. 1589 8.4. HTTP/2 Error Codes 1591 QUIC has the same concepts of "stream" and "connection" errors that 1592 HTTP/2 provides. However, because the error code space is shared 1593 between multiple components, there is no direct portability of HTTP/2 1594 error codes. 1596 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 1597 HTTP/QUIC error codes as follows: 1599 NO_ERROR (0x0): HTTP_NO_ERROR in Section 6.1. 1601 PROTOCOL_ERROR (0x1): No single mapping. See new 1602 HTTP_MALFORMED_FRAME error codes defined in Section 6.1. 1604 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 6.1. 1606 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 1607 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 1608 from the QUIC layer. 1610 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 1611 SETTINGS is defined. 1613 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 1614 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 1615 from the QUIC layer. 1617 FRAME_SIZE_ERROR (0x6): No single mapping. See new error codes 1618 defined in Section 6.1. 1620 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 1621 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 1622 QUIC layer. 1624 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 1626 COMPRESSION_ERROR (0x9): HTTP_QPACK_DECOMPRESSION_FAILED in [QPACK]. 1628 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 1630 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 1632 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 1633 provide sufficient security on all connections. 1635 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 1637 Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. 1638 See Section 10.5. 1640 9. Security Considerations 1642 The security considerations of HTTP/QUIC should be comparable to 1643 those of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING 1644 frames to make a connection more resistant to traffic analysis, HTTP/ 1645 QUIC can rely on QUIC's own PADDING frames or employ the reserved 1646 frame and stream types discussed in Section 4.2.1 and Section 3.3.1. 1648 When HTTP Alternative Services is used for discovery for HTTP/QUIC 1649 endpoints, the security considerations of [ALTSVC] also apply. 1651 The modified SETTINGS format contains nested length elements, which 1652 could pose a security risk to an incautious implementer. A SETTINGS 1653 frame parser MUST ensure that the length of the frame exactly matches 1654 the length of the settings it contains. 1656 10. IANA Considerations 1658 10.1. Registration of HTTP/QUIC Identification String 1660 This document creates a new registration for the identification of 1661 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 1662 Protocol IDs" registry established in [RFC7301]. 1664 The "hq" string identifies HTTP/QUIC: 1666 Protocol: HTTP/QUIC 1668 Identification Sequence: 0x68 0x71 ("hq") 1670 Specification: This document 1672 10.2. Registration of QUIC Version Hint Alt-Svc Parameter 1674 This document creates a new registration for version-negotiation 1675 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1676 registry established in [RFC7838]. 1678 Parameter: "quic" 1680 Specification: This document, Section 2.2.1 1682 10.3. Frame Types 1684 This document establishes a registry for HTTP/QUIC frame type codes. 1685 The "HTTP/QUIC Frame Type" registry manages an 8-bit space. The 1686 "HTTP/QUIC Frame Type" registry operates under either of the "IETF 1687 Review" or "IESG Approval" policies [RFC8126] for values from 0x00 up 1688 to and including 0xef, with values from 0xf0 up to and including 0xff 1689 being reserved for Experimental Use. 1691 While this registry is separate from the "HTTP/2 Frame Type" registry 1692 defined in [RFC7540], it is preferable that the assignments parallel 1693 each other. If an entry is present in only one registry, every 1694 effort SHOULD be made to avoid assigning the corresponding value to 1695 an unrelated operation. 1697 New entries in this registry require the following information: 1699 Frame Type: A name or label for the frame type. 1701 Code: The 8-bit code assigned to the frame type. 1703 Specification: A reference to a specification that includes a 1704 description of the frame layout and its semantics, including any 1705 parts of the frame that are conditionally present. 1707 The entries in the following table are registered by this document. 1709 +--------------+------+---------------+ 1710 | Frame Type | Code | Specification | 1711 +--------------+------+---------------+ 1712 | DATA | 0x0 | Section 4.2.2 | 1713 | | | | 1714 | HEADERS | 0x1 | Section 4.2.3 | 1715 | | | | 1716 | PRIORITY | 0x2 | Section 4.2.4 | 1717 | | | | 1718 | CANCEL_PUSH | 0x3 | Section 4.2.5 | 1719 | | | | 1720 | SETTINGS | 0x4 | Section 4.2.6 | 1721 | | | | 1722 | PUSH_PROMISE | 0x5 | Section 4.2.7 | 1723 | | | | 1724 | Reserved | 0x6 | N/A | 1725 | | | | 1726 | GOAWAY | 0x7 | Section 4.2.8 | 1727 | | | | 1728 | Reserved | 0x8 | N/A | 1729 | | | | 1730 | Reserved | 0x9 | N/A | 1731 | | | | 1732 | MAX_PUSH_ID | 0xD | Section 4.2.9 | 1733 +--------------+------+---------------+ 1735 Additionally, each code of the format "0xb + (0x1f * N)" for values 1736 of N in the range (0..7) (that is, "0xb", "0x2a", "0x49", "0x68", 1737 "0x87", "0xa6", "0xc5", and "0xe4"), the following values should be 1738 registered: 1740 Frame Type: Reserved - GREASE 1742 Specification: Section 4.2.1 1744 10.4. Settings Parameters 1746 This document establishes a registry for HTTP/QUIC settings. The 1747 "HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC 1748 Settings" registry operates under the "Expert Review" policy 1749 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1750 between and 0xf000 and 0xffff being reserved for Experimental Use. 1751 The designated experts are the same as those for the "HTTP/2 1752 Settings" registry defined in [RFC7540]. 1754 While this registry is separate from the "HTTP/2 Settings" registry 1755 defined in [RFC7540], it is preferable that the assignments parallel 1756 each other. If an entry is present in only one registry, every 1757 effort SHOULD be made to avoid assigning the corresponding value to 1758 an unrelated operation. 1760 New registrations are advised to provide the following information: 1762 Name: A symbolic name for the setting. Specifying a setting name is 1763 optional. 1765 Code: The 16-bit code assigned to the setting. 1767 Specification: An optional reference to a specification that 1768 describes the use of the setting. 1770 The entries in the following table are registered by this document. 1772 +----------------------+------+-----------------+ 1773 | Setting Name | Code | Specification | 1774 +----------------------+------+-----------------+ 1775 | Reserved | 0x2 | N/A | 1776 | | | | 1777 | NUM_PLACEHOLDERS | 0x3 | Section 4.2.6.1 | 1778 | | | | 1779 | Reserved | 0x4 | N/A | 1780 | | | | 1781 | Reserved | 0x5 | N/A | 1782 | | | | 1783 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.6.1 | 1784 +----------------------+------+-----------------+ 1786 Additionally, each code of the format "0x?a?a" where each "?" is any 1787 four bits (that is, "0x0a0a", "0x0a1a", etc. through "0xfafa"), the 1788 following values should be registered: 1790 Name: Reserved - GREASE 1792 Specification: Section 4.2.6.1 1794 10.5. Error Codes 1796 This document establishes a registry for HTTP/QUIC error codes. The 1797 "HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/ 1798 QUIC Error Code" registry operates under the "Expert Review" policy 1799 [RFC8126]. 1801 Registrations for error codes are required to include a description 1802 of the error code. An expert reviewer is advised to examine new 1803 registrations for possible duplication with existing error codes. 1804 Use of existing registrations is to be encouraged, but not mandated. 1806 New registrations are advised to provide the following information: 1808 Name: A name for the error code. Specifying an error code name is 1809 optional. 1811 Code: The 16-bit error code value. 1813 Description: A brief description of the error code semantics, longer 1814 if no detailed specification is provided. 1816 Specification: An optional reference for a specification that 1817 defines the error code. 1819 The entries in the following table are registered by this document. 1821 +-------------------------+-------+---------------+-----------------+ 1822 | Name | Code | Description | Specification | 1823 +-------------------------+-------+---------------+-----------------+ 1824 | STOPPING | 0x000 | Reserved by | [QUIC-TRANSPORT | 1825 | | 0 | QUIC | ] | 1826 | | | | | 1827 | HTTP_NO_ERROR | 0x000 | No error | Section 6.1 | 1828 | | 1 | | | 1829 | | | | | 1830 | HTTP_PUSH_REFUSED | 0x000 | Client | Section 6.1 | 1831 | | 2 | refused | | 1832 | | | pushed | | 1833 | | | content | | 1834 | | | | | 1835 | HTTP_INTERNAL_ERROR | 0x000 | Internal | Section 6.1 | 1836 | | 3 | error | | 1837 | | | | | 1838 | HTTP_PUSH_ALREADY_IN_CA | 0x000 | Pushed | Section 6.1 | 1839 | CHE | 4 | content | | 1840 | | | already | | 1841 | | | cached | | 1842 | | | | | 1843 | HTTP_REQUEST_CANCELLED | 0x000 | Data no | Section 6.1 | 1844 | | 5 | longer needed | | 1845 | | | | | 1846 | HTTP_INCOMPLETE_REQUEST | 0x000 | Stream | Section 6.1 | 1847 | | 6 | terminated | | 1848 | | | early | | 1849 | | | | | 1850 | HTTP_CONNECT_ERROR | 0x000 | TCP reset or | Section 6.1 | 1851 | | 7 | error on | | 1852 | | | CONNECT | | 1853 | | | request | | 1854 | | | | | 1855 | HTTP_EXCESSIVE_LOAD | 0x000 | Peer | Section 6.1 | 1856 | | 8 | generating | | 1857 | | | excessive | | 1858 | | | load | | 1859 | | | | | 1860 | HTTP_VERSION_FALLBACK | 0x000 | Retry over | Section 6.1 | 1861 | | 9 | HTTP/1.1 | | 1862 | | | | | 1863 | HTTP_WRONG_STREAM | 0x000 | A frame was | Section 6.1 | 1864 | | A | sent on the | | 1865 | | | wrong stream | | 1866 | | | | | 1867 | HTTP_PUSH_LIMIT_EXCEEDE | 0x000 | Maximum Push | Section 6.1 | 1868 | D | B | ID exceeded | | 1869 | | | | | 1870 | HTTP_DUPLICATE_PUSH | 0x000 | Push ID was | Section 6.1 | 1871 | | C | fulfilled | | 1872 | | | multiple | | 1873 | | | times | | 1874 | | | | | 1875 | HTTP_UNKNOWN_STREAM_TYP | 0x000 | Unknown unidi | Section 6.1 | 1876 | E | D | rectional | | 1877 | | | stream type | | 1878 | | | | | 1879 | HTTP_WRONG_STREAM_COUNT | 0x000 | Too many unid | Section 6.1 | 1880 | | E | irectional | | 1881 | | | streams | | 1882 | | | | | 1883 | HTTP_CLOSED_CRITICAL_ST | 0x000 | Critical | Section 6.1 | 1884 | REAM | F | stream was | | 1885 | | | closed | | 1886 | | | | | 1887 | HTTP_WRONG_STREAM_DIREC | 0x001 | Unidirectiona | Section 6.1 | 1888 | TION | 0 | l stream in | | 1889 | | | wrong | | 1890 | | | direction | | 1891 | | | | | 1892 | HTTP_EARLY_RESPONSE | 0x001 | Remainder of | Section 6.1 | 1893 | | 1 | request not | | 1894 | | | needed | | 1895 | | | | | 1896 | HTTP_MISSING_SETTINGS | 0x001 | No SETTINGS | Section 6.1 | 1897 | | 2 | frame | | 1898 | | | received | | 1899 | | | | | 1900 | HTTP_MALFORMED_FRAME | 0x01X | Error in | Section 6.1 | 1901 | | X | frame | | 1902 | | | formatting or | | 1903 | | | use | | 1904 +-------------------------+-------+---------------+-----------------+ 1906 10.6. Stream Types 1908 This document establishes a registry for HTTP/QUIC unidirectional 1909 stream types. The "HTTP/QUIC Stream Type" registry manages an 8-bit 1910 space. The "HTTP/QUIC Stream Type" registry operates under either of 1911 the "IETF Review" or "IESG Approval" policies [RFC8126] for values 1912 from 0x00 up to and including 0xef, with values from 0xf0 up to and 1913 including 0xff being reserved for Experimental Use. 1915 New entries in this registry require the following information: 1917 Stream Type: A name or label for the stream type. 1919 Code: The 8-bit code assigned to the stream type. 1921 Specification: A reference to a specification that includes a 1922 description of the stream type, including the layout semantics of 1923 its payload. 1925 Sender: Which endpoint on a connection may initiate a stream of this 1926 type. Values are "Client", "Server", or "Both". 1928 The entries in the following table are registered by this document. 1930 +----------------+------+---------------+--------+ 1931 | Stream Type | Code | Specification | Sender | 1932 +----------------+------+---------------+--------+ 1933 | Control Stream | 0x43 | Section 3.3.2 | Both | 1934 | | | | | 1935 | Push Stream | 0x50 | Section 3.3.3 | Server | 1936 +----------------+------+---------------+--------+ 1938 Additionally, for each code of the format "0x1f * N" for values of N 1939 in the range (0..8) (that is, "0x00", "0x1f", "0x3e", "0x5d", "0x7c", 1940 "0x9b", "0xba", "0xd9", "0xf8"), the following values should be 1941 registered: 1943 Stream Type: Reserved - GREASE 1945 Specification: Section 3.3.1 1947 Sender: Both 1949 11. References 1951 11.1. Normative References 1953 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1954 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1955 April 2016, . 1957 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 1958 Header Compression for HTTP over QUIC", draft-ietf-quic- 1959 qpack-03 (work in progress), October 2018. 1961 [QUIC-TRANSPORT] 1962 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1963 Multiplexed and Secure Transport", draft-ietf-quic- 1964 transport-14 (work in progress), October 2018. 1966 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1967 RFC 793, DOI 10.17487/RFC0793, September 1981, 1968 . 1970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1971 Requirement Levels", BCP 14, RFC 2119, 1972 DOI 10.17487/RFC2119, March 1997, 1973 . 1975 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1976 Specifications: ABNF", STD 68, RFC 5234, 1977 DOI 10.17487/RFC5234, January 2008, 1978 . 1980 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1981 Extensions: Extension Definitions", RFC 6066, 1982 DOI 10.17487/RFC6066, January 2011, 1983 . 1985 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1986 Protocol (HTTP/1.1): Message Syntax and Routing", 1987 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1988 . 1990 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1991 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1992 DOI 10.17487/RFC7231, June 2014, 1993 . 1995 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1996 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1997 DOI 10.17487/RFC7540, May 2015, 1998 . 2000 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2001 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2002 April 2016, . 2004 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2005 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2006 May 2017, . 2008 11.2. Informative References 2010 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2011 "Transport Layer Security (TLS) Application-Layer Protocol 2012 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2013 July 2014, . 2015 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2016 Writing an IANA Considerations Section in RFCs", BCP 26, 2017 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2018 . 2020 11.3. URIs 2022 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 2024 [2] https://github.com/quicwg 2026 [3] https://github.com/quicwg/base-drafts/labels/-http 2028 [4] https://www.iana.org/assignments/message-headers 2030 Appendix A. Change Log 2032 *RFC Editor's Note:* Please remove this section prior to 2033 publication of a final version of this document. 2035 A.1. Since draft-ietf-quic-http-14 2037 o Recommend sensible values for QUIC transport parameters 2038 (#1720,#1806) 2040 o Define error for missing SETTINGS frame (#1697,#1808) 2041 o Setting values are variable-length integers (#1556,#1807) and do 2042 not have separate maximum values (#1820) 2044 o Expanded discussion of connection closure (#1599,#1717,#1712) 2046 o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 2048 A.2. Since draft-ietf-quic-http-13 2050 o Reserved some frame types for grease (#1333, #1446) 2052 o Unknown unidirectional stream types are tolerated, not errors; 2053 some reserved for grease (#1490, #1525) 2055 o Require settings to be remembered for 0-RTT, prohibit reductions 2056 (#1541, #1641) 2058 o Specify behavior for truncated requests (#1596, #1643) 2060 A.3. Since draft-ietf-quic-http-12 2062 o TLS SNI extension isn't mandatory if an alternative method is used 2063 (#1459, #1462, #1466) 2065 o Removed flags from HTTP/QUIC frames (#1388, #1398) 2067 o Reserved frame types and settings for use in preserving 2068 extensibility (#1333, #1446) 2070 o Added general error code (#1391, #1397) 2072 o Unidirectional streams carry a type byte and are extensible 2073 (#910,#1359) 2075 o Priority mechanism now uses explicit placeholders to enable 2076 persistent structure in the tree (#441,#1421,#1422) 2078 A.4. Since draft-ietf-quic-http-11 2080 o Moved QPACK table updates and acknowledgments to dedicated streams 2081 (#1121, #1122, #1238) 2083 A.5. Since draft-ietf-quic-http-10 2085 o Settings need to be remembered when attempting and accepting 0-RTT 2086 (#1157, #1207) 2088 A.6. Since draft-ietf-quic-http-09 2090 o Selected QCRAM for header compression (#228, #1117) 2092 o The server_name TLS extension is now mandatory (#296, #495) 2094 o Specified handling of unsupported versions in Alt-Svc (#1093, 2095 #1097) 2097 A.7. Since draft-ietf-quic-http-08 2099 o Clarified connection coalescing rules (#940, #1024) 2101 A.8. Since draft-ietf-quic-http-07 2103 o Changes for integer encodings in QUIC (#595,#905) 2105 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 2107 o Improvement to the description of GOAWAY (#604, #898) 2109 o Improve description of server push usage (#947, #950, #957) 2111 A.9. Since draft-ietf-quic-http-06 2113 o Track changes in QUIC error code usage (#485) 2115 A.10. Since draft-ietf-quic-http-05 2117 o Made push ID sequential, add MAX_PUSH_ID, remove 2118 SETTINGS_ENABLE_PUSH (#709) 2120 o Guidance about keep-alive and QUIC PINGs (#729) 2122 o Expanded text on GOAWAY and cancellation (#757) 2124 A.11. Since draft-ietf-quic-http-04 2126 o Cite RFC 5234 (#404) 2128 o Return to a single stream per request (#245,#557) 2130 o Use separate frame type and settings registries from HTTP/2 (#81) 2132 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 2134 o Restored GOAWAY (#696) 2135 o Identify server push using Push ID rather than a stream ID 2136 (#702,#281) 2138 o DATA frames cannot be empty (#700) 2140 A.12. Since draft-ietf-quic-http-03 2142 None. 2144 A.13. Since draft-ietf-quic-http-02 2146 o Track changes in transport draft 2148 A.14. Since draft-ietf-quic-http-01 2150 o SETTINGS changes (#181): 2152 * SETTINGS can be sent only once at the start of a connection; no 2153 changes thereafter 2155 * SETTINGS_ACK removed 2157 * Settings can only occur in the SETTINGS frame a single time 2159 * Boolean format updated 2161 o Alt-Svc parameter changed from "v" to "quic"; format updated 2162 (#229) 2164 o Closing the connection control stream or any message control 2165 stream is a fatal error (#176) 2167 o HPACK Sequence counter can wrap (#173) 2169 o 0-RTT guidance added 2171 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 2172 added (#127,#242) 2174 A.15. Since draft-ietf-quic-http-00 2176 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 2178 o Changed from using HTTP/2 framing within Stream 3 to new framing 2179 format and two-stream-per-request model (#71,#72,#73) 2181 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 2182 settings-01 2184 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 2185 order (#75) 2187 o Described CONNECT pseudo-method (#95) 2189 o Updated ALPN token and Alt-Svc guidance (#13,#87) 2191 o Application-layer-defined error codes (#19,#74) 2193 A.16. Since draft-shade-quic-http2-mapping-00 2195 o Adopted as base for draft-ietf-quic-http 2197 o Updated authors/editors list 2199 Acknowledgements 2201 The original authors of this specification were Robbie Shade and Mike 2202 Warres. 2204 A substantial portion of Mike's contribution was supported by 2205 Microsoft during his employment there. 2207 Author's Address 2209 Mike Bishop (editor) 2210 Akamai 2212 Email: mbishop@evequefou.be