idnits 2.17.00 (12 Aug 2021) /tmp/idnits53167/draft-ietf-quic-http-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2018) is 1573 days in the past. Is this intentional? 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 1597 -- Looks like a reference, but probably isn't: '2' on line 1599 -- Looks like a reference, but probably isn't: '3' on line 1601 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Akamai 4 Intended status: Standards Track January 28, 2018 5 Expires: August 1, 2018 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-09 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 August 1, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 65 2. Connection Setup and Management . . . . . . . . . . . . . . . 4 66 2.1. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 4 67 2.1.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 4 68 2.2. Connection Establishment . . . . . . . . . . . . . . . . 5 69 2.2.1. Draft Version Identification . . . . . . . . . . . . 5 70 2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6 71 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 6 72 3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 7 74 3.2.1. Header Compression . . . . . . . . . . . . . . . . . 9 75 3.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 9 76 3.3. Request Prioritization . . . . . . . . . . . . . . . . . 10 77 3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10 78 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11 79 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12 80 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 12 81 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 13 84 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 15 85 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 15 86 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18 87 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 19 88 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 21 89 5. Connection Management . . . . . . . . . . . . . . . . . . . . 22 90 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22 91 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 23 92 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 24 93 7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 24 95 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 26 96 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 27 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 9.1. Registration of HTTP/QUIC Identification String . . . . . 28 100 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 28 101 9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 29 102 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 30 103 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 31 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 106 10.2. Informative References . . . . . . . . . . . . . . . . . 34 107 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 109 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 110 B.1. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 35 111 B.2. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 35 112 B.3. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 35 113 B.4. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 35 114 B.5. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 35 115 B.6. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 36 116 B.7. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 36 117 B.8. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 36 118 B.9. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 36 119 B.10. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 37 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 122 1. Introduction 124 The QUIC transport protocol has several features that are desirable 125 in a transport for HTTP, such as stream multiplexing, per-stream flow 126 control, and low-latency connection establishment. This document 127 describes a mapping of HTTP semantics over QUIC, drawing heavily on 128 the existing TCP mapping, HTTP/2. Specifically, this document 129 identifies HTTP/2 features that are subsumed by QUIC, and describes 130 how the other features can be implemented atop QUIC. 132 QUIC is described in [QUIC-TRANSPORT]. For a full description of 133 HTTP/2, see [RFC7540]. 135 1.1. Notational Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 144 defined in [RFC5234]. 146 This document uses the variable-length integer encoding from 147 [QUIC-TRANSPORT]. 149 Protocol elements called "frames" exist in both this document and 150 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 151 the frame name will be prefaced with "QUIC." For example, "QUIC 152 APPLICATION_CLOSE frames." References without this preface refer to 153 frames defined in Section 4.2. 155 2. Connection Setup and Management 157 2.1. Discovering an HTTP/QUIC Endpoint 159 An HTTP origin advertises the availability of an equivalent HTTP/QUIC 160 endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC 161 frame ([RFC7838]), using the ALPN token defined in Section 2.2. 163 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 164 response that HTTP/QUIC was available on UDP port 50781 at the same 165 hostname by including the following header in any response: 167 Alt-Svc: hq=":50781" 169 On receipt of an Alt-Svc header indicating HTTP/QUIC support, a 170 client MAY attempt to establish a QUIC connection to the indicated 171 host and port and, if successful, send HTTP requests using the 172 mapping described in this document. 174 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 175 connection establishment failure, in which case the client SHOULD 176 continue using the existing connection or try another alternative 177 endpoint offered by the origin. 179 Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the 180 same port across all IP addresses that serve a single domain, and 181 SHOULD NOT change this port. 183 2.1.1. QUIC Version Hints 185 This document defines the "quic" parameter for Alt-Svc, which MAY be 186 used to provide version-negotiation hints to HTTP/QUIC clients. QUIC 187 versions are four-octet sequences with no additional constraints on 188 format. Syntax: 190 quic = version-number 191 version-number = 1*8HEXDIG; hex-encoded QUIC version 193 Leading zeros SHOULD be omitted for brevity. When multiple versions 194 are supported, the "quic" parameter MAY be repeated multiple times in 195 a single Alt-Svc entry. For example, if a server supported both 196 version 0x00000001 and the version rendered in ASCII as "Q034", it 197 could specify the following header: 199 Alt-Svc: hq=":49288";quic=1;quic=51303334 201 Where multiple versions are listed, the order of the values reflects 202 the server's preference (with the first value being the most 203 preferred version). Origins SHOULD list only versions which are 204 supported by the alternative, but MAY omit supported versions for any 205 reason. 207 2.2. Connection Establishment 209 HTTP/QUIC relies on QUIC as the underlying transport. The QUIC 210 version being used MUST use TLS version 1.3 or greater as its 211 handshake protocol. The Server Name Indication (SNI) extension 212 [RFC6066] MUST be included in the TLS handshake. 214 QUIC connections are established as described in [QUIC-TRANSPORT]. 215 During connection establishment, HTTP/QUIC support is indicated by 216 selecting the ALPN token "hq" in the TLS handshake. Support for 217 other application-layer protocols MAY be offered in the same 218 handshake. 220 While connection-level options pertaining to the core QUIC protocol 221 are set in the initial crypto handshake, HTTP-specific settings are 222 conveyed in the SETTINGS frame. After the QUIC connection is 223 established, a SETTINGS frame (Section 4.2.5) MUST be sent by each 224 endpoint as the initial frame of their respective HTTP control stream 225 (Stream ID 2 or 3, see Section 3). The server MUST NOT send data on 226 any other stream until the client's SETTINGS frame has been received. 228 2.2.1. Draft Version Identification 230 *RFC Editor's Note:* Please remove this section prior to 231 publication of a final version of this document. 233 Only implementations of the final, published RFC can identify 234 themselves as "hq". Until such an RFC exists, implementations MUST 235 NOT identify themselves using this string. 237 Implementations of draft versions of the protocol MUST add the string 238 "-" and the corresponding draft number to the identifier. For 239 example, draft-ietf-quic-http-01 is identified using the string "hq- 240 01". 242 Non-compatible experiments that are based on these draft versions 243 MUST append the string "-" and an experiment name to the identifier. 244 For example, an experimental implementation based on draft-ietf-quic- 245 http-09 which reserves an extra stream for unsolicited transmission 246 of 1980s pop music might identify itself as "hq-09-rickroll". Note 247 that any label MUST conform to the "token" syntax defined in 248 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 249 coordinate their experiments on the quic@ietf.org mailing list. 251 2.3. Connection Reuse 253 Once a connection exists to a server endpoint, this connection MAY be 254 reused for requests with multiple different URI authority components. 255 The client MAY send any requests for which the client considers the 256 server authoritative. 258 An authoritative HTTP/QUIC endpoint is typically discovered because 259 the client has received an Alt-Svc record from the request's origin 260 which nominates the endpoint as a valid HTTP Alternative Service for 261 that origin. As required by [RFC7838], clients MUST check that the 262 nominated server can present a valid certificate for the origin 263 before considering it authoritative. Clients MUST NOT assume that an 264 HTTP/QUIC endpoint is authoritative for other origins without an 265 explicit signal. 267 A server that does not wish clients to reuse connections for a 268 particular origin can indicate that it is not authoritative for a 269 request by sending a 421 (Misdirected Request) status code in 270 response to the request (see Section 9.1.2 of [RFC7540]). 272 3. Stream Mapping and Usage 274 A QUIC stream provides reliable in-order delivery of bytes, but makes 275 no guarantees about order of delivery with regard to bytes on other 276 streams. On the wire, data is framed into QUIC STREAM frames, but 277 this framing is invisible to the HTTP framing layer. A QUIC receiver 278 buffers and orders received STREAM frames, exposing the data 279 contained within as a reliable byte stream to the application. 281 QUIC reserves the first client-initiated, bidirectional stream 282 (Stream 0) for cryptographic operations. HTTP over QUIC reserves the 283 first unidirectional stream sent by either peer (Streams 2 and 3) for 284 sending and receiving HTTP control frames. This pair of 285 unidirectional streams is analogous to HTTP/2's Stream 0. The data 286 sent on these streams is critical to the HTTP connection. If either 287 control stream is closed for any reason, this MUST be treated as a 288 connection error of type QUIC_CLOSED_CRITICAL_STREAM. 290 When HTTP headers and data are sent over QUIC, the QUIC layer handles 291 most of the stream management. 293 An HTTP request/response consumes a single client-initiated, 294 bidirectional stream. A bidirectional stream ensures that the 295 response can be readily correlated with the request. This means that 296 the client's first request occurs on QUIC stream 4, with subsequent 297 requests on stream 8, 12, and so on. 299 Server push uses server-initiated, unidirectional streams. Thus, the 300 server's first push consumes stream 7 and subsequent pushes use 301 stream 11, 15, and so on. 303 These streams carry frames related to the request/response (see 304 Section 4.2). When a stream terminates cleanly, if the last frame on 305 the stream was truncated, this MUST be treated as a connection error 306 (see HTTP_MALFORMED_FRAME in Section 6.1). Streams which terminate 307 abruptly may be reset at any point in the frame. 309 Streams SHOULD be used sequentially, with no gaps. 311 HTTP does not need to do any separate multiplexing when using QUIC - 312 data sent over a QUIC stream always maps to a particular HTTP 313 transaction. Requests and responses are considered complete when the 314 corresponding QUIC stream is closed in the appropriate direction. 316 3.1. Control Streams 318 Since most connection-level concerns will be managed by QUIC, the 319 primary use of Streams 2 and 3 will be for the SETTINGS frame when 320 the connection opens and for PRIORITY frames subsequently. 322 A pair of unidirectional streams is used rather than a single 323 bidirectional stream. This allows either peer to send data as soon 324 they are able. Depending on whether 0-RTT is enabled on the 325 connection, either client or server might be able to send stream data 326 first after the cryptographic handshake completes. 328 3.2. HTTP Message Exchanges 330 A client sends an HTTP request on a client-initiated, bidirectional 331 QUIC stream. A server sends an HTTP response on the same stream as 332 the request. 334 An HTTP message (request or response) consists of: 336 1. one header block (see Section 4.2.2) containing the message 337 headers (see [RFC7230], Section 3.2), 339 2. the payload body (see [RFC7230], Section 3.3), sent as a series 340 of DATA frames (see Section 4.2.1), 342 3. optionally, one header block containing the trailer-part, if 343 present (see [RFC7230], Section 4.1.2). 345 In addition, prior to sending the message header block indicated 346 above, a response may contain zero or more header blocks containing 347 the message headers of informational (1xx) HTTP responses (see 348 [RFC7230], Section 3.2 and [RFC7231], Section 6.2). 350 PUSH_PROMISE frames MAY be interleaved with the frames of a response 351 message indicating a pushed resource related to the response. These 352 PUSH_PROMISE frames are not part of the response, but carry the 353 headers of a separate HTTP request message. See Section 3.4 for more 354 details. 356 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 357 MUST NOT be used. 359 Trailing header fields are carried in an additional header block 360 following the body. Such a header block is a sequence of HEADERS 361 frames with End Header Block set on the last frame. Senders MUST 362 send only one header block in the trailers section; receivers MUST 363 discard any subsequent header blocks. 365 An HTTP request/response exchange fully consumes a QUIC stream. 366 After sending a request, a client closes the stream for sending; 367 after sending a response, the server closes the stream for sending 368 and the QUIC stream is fully closed. 370 A server can send a complete response prior to the client sending an 371 entire request if the response does not depend on any portion of the 372 request that has not been sent and received. When this is true, a 373 server MAY request that the client abort transmission of a request 374 without error by triggering a QUIC STOP_SENDING with error code 375 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 376 its streams. Clients MUST NOT discard complete responses as a result 377 of having their request terminated abruptly, though clients can 378 always discard responses at their discretion for other reasons. 379 Servers MUST NOT abort a response in progress as a result of 380 receiving a solicited RST_STREAM. 382 3.2.1. Header Compression 384 HTTP/QUIC uses HPACK header compression as described in [RFC7541]. 385 HPACK was designed for HTTP/2 with the assumption of in-order 386 delivery such as that provided by TCP. A sequence of encoded header 387 blocks must arrive (and be decoded) at an endpoint in the same order 388 in which they were encoded. This ensures that the dynamic state at 389 the two endpoints remains in sync. 391 QUIC streams provide in-order delivery of data sent on those streams, 392 but there are no guarantees about order of delivery between streams. 393 QUIC anticipates moving to a modified version of HPACK without this 394 assumption. In the meantime, by fixing the size of the dynamic table 395 at zero, HPACK can be used in an unordered environment. 397 3.2.2. The CONNECT Method 399 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 400 used with HTTP proxies to establish a TLS session with an origin 401 server for the purposes of interacting with "https" resources. In 402 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 403 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 404 establish a tunnel over a single HTTP/2 stream to a remote host for 405 similar purposes. 407 A CONNECT request in HTTP/QUIC functions in the same manner as in 408 HTTP/2. The request MUST be formatted as described in [RFC7540], 409 Section 8.3. A CONNECT request that does not conform to these 410 restrictions is malformed. The request stream MUST NOT be half- 411 closed at the end of the request. 413 A proxy that supports CONNECT establishes a TCP connection 414 ([RFC0793]) to the server identified in the ":authority" pseudo- 415 header field. Once this connection is successfully established, the 416 proxy sends a HEADERS frame containing a 2xx series status code to 417 the client, as defined in [RFC7231], Section 4.3.6. 419 All DATA frames on the request stream correspond to data sent on the 420 TCP connection. Any DATA frame sent by the client is transmitted by 421 the proxy to the TCP server; data received from the TCP server is 422 packaged into DATA frames by the proxy. Note that the size and 423 number of TCP segments is not guaranteed to map predictably to the 424 size and number of HTTP DATA or QUIC STREAM frames. 426 The TCP connection can be closed by either peer. When the client 427 ends the request stream (that is, the receive stream at the proxy 428 enters the "Data Recvd" state), the proxy will set the FIN bit on its 429 connection to the TCP server. When the proxy receives a packet with 430 the FIN bit set, it will terminate the send stream that it sends to 431 client. TCP connections which remain half-closed in a single 432 direction are not invalid, but are often handled poorly by servers, 433 so clients SHOULD NOT cause send a STREAM frame with a FIN bit for 434 connections on which they are still expecting data. 436 A TCP connection error is signaled with RST_STREAM. A proxy treats 437 any error in the TCP connection, which includes receiving a TCP 438 segment with the RST bit set, as a stream error of type 439 HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send 440 a TCP segment with the RST bit set if it detects an error with the 441 stream or the QUIC connection. 443 3.3. Request Prioritization 445 HTTP/QUIC uses the priority scheme described in [RFC7540], 446 Section 5.3. In this priority scheme, a given request can be 447 designated as dependent upon another request, which expresses the 448 preference that the latter stream (the "parent" request) be allocated 449 resources before the former stream (the "dependent" request). Taken 450 together, the dependencies across all requests in a connection form a 451 dependency tree. The structure of the dependency tree changes as 452 PRIORITY frames add, remove, or change the dependency links between 453 requests. 455 The PRIORITY frame Section 4.2.3 identifies a request either by 456 identifying the stream that carries a request or by using a Push ID 457 (Section 4.2.6). 459 Only a client can send PRIORITY frames. A server MUST NOT send a 460 PRIORITY frame. 462 3.4. Server Push 464 HTTP/QUIC supports server push as described in [RFC7540]. During 465 connection establishment, the client enables server push by sending a 466 MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server 467 push until it receives a MAX_PUSH_ID frame. 469 As with server push for HTTP/2, the server initiates a server push by 470 sending a PUSH_PROMISE frame that includes request header fields 471 attributed to the request. The PUSH_PROMISE frame is sent on the 472 client-initiated, bidirectional stream that carried the request that 473 generated the push. This allows the server push to be associated 474 with a request. Ordering of a PUSH_PROMISE in relation to certain 475 parts of the response is important (see Section 8.2.1 of [RFC7540]). 477 Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it 478 contains a Push ID. The Push ID uniquely identifies a server push 479 (see Section 4.2.6). This allows a server to fulfill promises in the 480 order that best suits its needs. 482 When a server later fulfills a promise, the server push response is 483 conveyed on a push stream. A push stream is a server-initiated, 484 unidirectional stream. A push stream always begins with a header 485 (see Figure 1) that identifies the Push ID of the promise that it 486 fulfills, encoded as a variable-length integer. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Push ID (i) ... 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 1: Push Stream Header 496 A server SHOULD use Push IDs sequentially, starting at 0. A client 497 uses the MAX_PUSH_ID frame (Section 4.2.8) to limit the number of 498 pushes that a server can promise. A client MUST treat receipt of a 499 push stream with a Push ID that is greater than the maximum Push ID 500 as a connection error of type HTTP_PUSH_LIMIT_EXCEEDED. 502 Each Push ID MUST only be used once in a push stream header. If a 503 push stream header includes a Push ID that was used in another push 504 stream header, the client MUST treat this as a connection error of 505 type HTTP_DUPLICATE_PUSH. The same Push ID can be used in multiple 506 PUSH_PROMISE frames (see Section 4.2.6). 508 After the push stream header, a push contains a response 509 (Section 3.2), with response headers, a response body (if any) 510 carried by DATA frames, then trailers (if any) carried by HEADERS 511 frames. 513 If a promised server push is not needed by the client, the client 514 SHOULD send a CANCEL_PUSH frame; if the push stream is already open, 515 a QUIC STOP_SENDING frame with an appropriate error code can be used 516 instead (e.g., HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see 517 Section 6). This asks the server not to transfer the data and 518 indicates that it will be discarded upon receipt. 520 4. HTTP Framing Layer 522 Frames are used on each stream. This section describes HTTP framing 523 in QUIC and highlights some differences from HTTP/2 framing. For 524 more detail on differences from HTTP/2, see Section 7.2. 526 4.1. Frame Layout 528 All frames have the following format: 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Length (i) ... 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type (8) | Flags (8) | Frame Payload (*) ... 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 2: HTTP/QUIC frame format 540 A frame includes the following fields: 542 Length: A variable-length integer that describes the length of the 543 Frame Payload. This length does not include the frame header. 545 Type: An 8-bit type for the frame. 547 Flags: An 8-bit field containing flags. The Type field determines 548 the semantics of flags. 550 Frame Payload: A payload, the semantics of which are determined by 551 the Type field. 553 4.2. Frame Definitions 555 4.2.1. DATA 557 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 558 octets associated with an HTTP request or response payload. 560 The DATA frame defines no flags. 562 DATA frames MUST be associated with an HTTP request or response. If 563 a DATA frame is received on either control stream, the recipient MUST 564 respond with a connection error (Section 6) of type 565 HTTP_WRONG_STREAM. 567 DATA frames MUST contain a non-zero-length payload. If a DATA frame 568 is received with a payload length of zero, the recipient MUST respond 569 with a stream error (Section 6) of type HTTP_MALFORMED_FRAME. 571 4.2.2. HEADERS 573 The HEADERS frame (type=0x1) is used to carry a header block, 574 compressed using HPACK Section 3.2.1. 576 No flags are defined for the HEADERS frame. 578 A HEADERS frame with any flags set MUST be treated as a connection 579 error of type HTTP_MALFORMED_FRAME. 581 4.2.3. PRIORITY 583 The PRIORITY (type=0x02) frame specifies the sender-advised priority 584 of a stream and is substantially different in format from [RFC7540]. 585 In order to ensure that prioritization is processed in a consistent 586 order, PRIORITY frames MUST be sent on the control stream. A 587 PRIORITY frame sent on any other stream MUST be treated as a 588 HTTP_WRONG_STREAM error. 590 The format has been modified to accommodate not being sent on a 591 request stream, to allow for identification of server pushes, and the 592 larger stream ID space of QUIC. The semantics of the Stream 593 Dependency, Weight, and E flag are otherwise the same as in HTTP/2. 595 The flags defined are: 597 PUSH_PRIORITIZED (0x04): Indicates that the Prioritized Stream is a 598 server push rather than a request. 600 PUSH_DEPENDENT (0x02): Indicates a dependency on a server push. 602 E (0x01): Indicates that the stream dependency is exclusive (see 603 [RFC7540], Section 5.3). 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Prioritized Request ID (i) | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Stream Dependency ID (i) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Weight (8) | 613 +-+-+-+-+-+-+-+-+ 615 Figure 3: PRIORITY frame payload 617 The PRIORITY frame payload has the following fields: 619 Prioritized Request ID: A variable-length integer that identifies a 620 request. This contains the Stream ID of a request stream when the 621 PUSH_PRIORITIZED flag is clear, or a Push ID when the 622 PUSH_PRIORITIZED flag is set. 624 Stream Dependency ID: A variable-length integer that identifies a 625 dependent request. This contains the Stream ID of a request 626 stream when the PUSH_DEPENDENT flag is clear, or a Push ID when 627 the PUSH_DEPENDENT flag is set. A request Stream ID of 0 628 indicates a dependency on the root stream. For details of 629 dependencies, see Section 3.3 and [RFC7540], Section 5.3. 631 Weight: An unsigned 8-bit integer representing a priority weight for 632 the stream (see [RFC7540], Section 5.3). Add one to the value to 633 obtain a weight between 1 and 256. 635 A PRIORITY frame identifies a request to prioritize, and a request 636 upon which that request is dependent. A Prioritized Request ID or 637 Stream Dependency ID identifies a client-initiated request using the 638 corresponding stream ID when the corresponding PUSH_PRIORITIZED or 639 PUSH_DEPENDENT flag is not set. Setting the PUSH_PRIORITIZED or 640 PUSH_DEPENDENT flag causes the Prioritized Request ID or Stream 641 Dependency ID (respectively) to identify a server push using a Push 642 ID (see Section 4.2.6 for details). 644 A PRIORITY frame MAY identify a Stream Dependency ID using a Stream 645 ID of 0; as in [RFC7540], this makes the request dependent on the 646 root of the dependency tree. 648 A PRIORITY frame MUST identify a client-initiated, bidirectional 649 stream. A server MUST treat receipt of PRIORITY frame with a Stream 650 ID of any other type as a connection error of type 651 HTTP_MALFORMED_FRAME. 653 Stream ID 0 cannot be reprioritized. A Prioritized Request ID that 654 identifies Stream 0 MUST be treated as a connection error of type 655 HTTP_MALFORMED_FRAME. 657 A PRIORITY frame that does not reference a request MUST be treated as 658 a HTTP_MALFORMED_FRAME error, unless it references Stream ID 0. A 659 PRIORITY that sets a PUSH_PRIORITIZED or PUSH_DEPENDENT flag, but 660 then references a non-existent Push ID MUST be treated as a 661 HTTP_MALFORMED_FRAME error. 663 A PRIORITY frame MUST contain only the identified fields. A PRIORITY 664 frame that contains more or fewer fields, or a PRIORITY frame that 665 includes a truncated integer encoding MUST be treated as a connection 666 error of type HTTP_MALFORMED_FRAME. 668 4.2.4. CANCEL_PUSH 670 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of 671 server push prior to the push stream being created. The CANCEL_PUSH 672 frame identifies a server push request by Push ID (see Section 4.2.6) 673 using a variable-length integer. 675 When a server receives this frame, it aborts sending the response for 676 the identified server push. If the server has not yet started to 677 send the server push, it can use the receipt of a CANCEL_PUSH frame 678 to avoid opening a stream. If the push stream has been opened by the 679 server, the server SHOULD sent a QUIC RST_STREAM frame on those 680 streams and cease transmission of the response. 682 A server can send this frame to indicate that it won't be sending a 683 response prior to creation of a push stream. Once the push stream 684 has been created, sending CANCEL_PUSH has no effect on the state of 685 the push stream. A QUIC RST_STREAM frame SHOULD be used instead to 686 cancel transmission of the server push response. 688 A CANCEL_PUSH frame is sent on the control stream. Sending a 689 CANCEL_PUSH frame on a stream other than the control stream MUST be 690 treated as a stream error of type HTTP_WRONG_STREAM. 692 The CANCEL_PUSH frame has no defined flags. 694 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 695 integer. The Push ID identifies the server push that is being 696 cancelled (see Section 4.2.6). 698 If the client receives a CANCEL_PUSH frame, that frame might identify 699 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 701 An endpoint MUST treat a CANCEL_PUSH frame which does not contain 702 exactly one properly-formatted variable-length integer as a 703 connection error of type HTTP_MALFORMED_FRAME. 705 4.2.5. SETTINGS 707 The SETTINGS frame (type=0x4) conveys configuration parameters that 708 affect how endpoints communicate, such as preferences and constraints 709 on peer behavior, and is different from [RFC7540]. Individually, a 710 SETTINGS parameter can also be referred to as a "setting". 712 SETTINGS parameters are not negotiated; they describe characteristics 713 of the sending peer, which can be used by the receiving peer. 714 However, a negotiation can be implied by the use of SETTINGS - a peer 715 uses SETTINGS to advertise a set of supported values. The recipient 716 can then choose which entries from this list are also acceptable and 717 proceed with the value it has chosen. (This choice could be 718 announced in a field of an extension frame, or in its own value in 719 SETTINGS.) 721 Different values for the same parameter can be advertised by each 722 peer. For example, a client might be willing to consume very large 723 response headers, while servers are more cautious about request size. 725 Parameters MUST NOT occur more than once. A receiver MAY treat the 726 presence of the same parameter more than once as a connection error 727 of type HTTP_MALFORMED_FRAME. 729 The SETTINGS frame defines no flags. 731 The payload of a SETTINGS frame consists of zero or more parameters, 732 each consisting of an unsigned 16-bit setting identifier and a 733 length-prefixed binary value. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Identifier (16) | Length (i) ... 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Contents (?) ... 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 Figure 4: SETTINGS value format 745 A zero-length content indicates that the setting value is a Boolean 746 and true. False is indicated by the absence of the setting. 748 Non-zero-length values MUST be compared against the remaining length 749 of the SETTINGS frame. Any value which purports to cross the end of 750 the frame MUST cause the SETTINGS frame to be considered malformed 751 and trigger a connection error of type HTTP_MALFORMED_FRAME. 753 An implementation MUST ignore the contents for any SETTINGS 754 identifier it does not understand. 756 SETTINGS frames always apply to a connection, never a single stream. 757 A SETTINGS frame MUST be sent as the first frame of either control 758 stream (see Section 3) by each peer, and MUST NOT be sent 759 subsequently or on any other stream. If an endpoint receives an 760 SETTINGS frame on a different stream, the endpoint MUST respond with 761 a connection error of type HTTP_WRONG_STREAM. If an endpoint 762 receives a second SETTINGS frame, the endpoint MUST respond with a 763 connection error of type HTTP_MALFORMED_FRAME. 765 The SETTINGS frame affects connection state. A badly formed or 766 incomplete SETTINGS frame MUST be treated as a connection error 767 (Section 6) of type HTTP_MALFORMED_FRAME. 769 4.2.5.1. Integer encoding 771 Settings which are integers use the QUIC variable-length integer 772 encoding. 774 4.2.5.2. Defined SETTINGS Parameters 776 The following settings are defined in HTTP/QUIC: 778 SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of 779 2^30 - 1. This value MUST be zero. 781 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value 782 of 2^30 - 1 784 4.2.5.3. Usage in 0-RTT 786 When a 0-RTT QUIC connection is being used, the client's initial 787 requests will be sent before the arrival of the server's SETTINGS 788 frame. Clients SHOULD cache at least the following settings about 789 servers: 791 o SETTINGS_HEADER_TABLE_SIZE 793 o SETTINGS_MAX_HEADER_LIST_SIZE 795 Clients MUST comply with cached settings until the server's current 796 settings are received. If a client does not have cached values, it 797 SHOULD assume the following values: 799 o SETTINGS_HEADER_TABLE_SIZE: 0 octets 801 o SETTINGS_MAX_HEADER_LIST_SIZE: 16,384 octets 803 Servers MAY continue processing data from clients which exceed its 804 current configuration during the initial flight. In this case, the 805 client MUST apply the new settings immediately upon receipt. 807 If the connection is closed because these or other constraints were 808 violated during the 0-RTT flight (e.g. with 809 HTTP_HPACK_DECOMPRESSION_FAILED), clients MAY establish a new 810 connection and retry any 0-RTT requests using the settings sent by 811 the server on the closed connection. (This assumes that only 812 requests that are safe to retry are sent in 0-RTT.) If the 813 connection was closed before the SETTINGS frame was received, clients 814 SHOULD discard any cached values and use the defaults above on the 815 next connection. 817 4.2.6. PUSH_PROMISE 819 The PUSH_PROMISE frame (type=0x05) is used to carry a request header 820 set from server to client, as in HTTP/2. The PUSH_PROMISE frame 821 defines no flags. 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 | Push ID (i) ... 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Header Block (*) ... 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Figure 5: PUSH_PROMISE frame payload 833 The payload consists of: 835 Push ID: A variable-length integer that identifies the server push 836 request. A push ID is used in push stream header (Section 3.4), 837 CANCEL_PUSH frames (Section 4.2.4), and PRIORITY frames 838 (Section 4.2.3). 840 Header Block: HPACK-compressed request headers for the promised 841 response. 843 A server MUST NOT use a Push ID that is larger than the client has 844 provided in a MAX_PUSH_ID frame (Section 4.2.8). A client MUST treat 845 receipt of a PUSH_PROMISE that contains a larger Push ID than the 846 client has advertised as a connection error of type 847 HTTP_MALFORMED_FRAME. 849 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 850 This allows the server to use the same server push in response to 851 multiple concurrent requests. Referencing the same server push 852 ensures that a PUSH_PROMISE can be made in relation to every response 853 in which server push might be needed without duplicating pushes. 855 A server that uses the same Push ID in multiple PUSH_PROMISE frames 856 MUST include the same header fields each time. The octets of the 857 header block MAY be different due to differing encoding, but the 858 header fields and their values MUST be identical. Note that ordering 859 of header fields is significant. A client MUST treat receipt of a 860 PUSH_PROMISE with conflicting header field values for the same Push 861 ID as a connection error of type HTTP_MALFORMED_FRAME. 863 Allowing duplicate references to the same Push ID is primarily to 864 reduce duplication caused by concurrent requests. A server SHOULD 865 avoid reusing a Push ID over a long period. Clients are likely to 866 consume server push responses and not retain them for reuse over 867 time. Clients that see a PUSH_PROMISE that uses a Push ID that they 868 have since consumed and discarded are forced to ignore the 869 PUSH_PROMISE. 871 4.2.7. GOAWAY 873 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 874 a connection by a server. GOAWAY allows a server to stop accepting 875 new requests while still finishing processing of previously received 876 requests. This enables administrative actions, like server 877 maintenance. GOAWAY by itself does not close a connection. 879 The GOAWAY frame does not define any flags, and the payload is a QUIC 880 Stream ID for a client-initiated, bidirectional stream encoded as a 881 variable-length integer. 883 Clients do not need to send GOAWAY to initiate a graceful shutdown; 884 they simply stop making new requests. A server MUST treat receipt of 885 a GOAWAY frame as a connection error (Section 6) of type 886 HTTP_UNEXPECTED_GOAWAY. 888 A client MUST treat receipt of a GOAWAY frame containing a Stream ID 889 of any other type as a connection error of type HTTP_MALFORMED_FRAME. 891 The GOAWAY frame applies to the connection, not a specific stream. 892 An endpoint MUST treat a GOAWAY frame on a stream other than the 893 control stream as a connection error (Section 6) of type 894 HTTP_WRONG_STREAM. 896 New client requests might already have been sent before the client 897 receives the server's GOAWAY frame. The GOAWAY frame contains the 898 Stream ID of the last client-initiated request that was or might be 899 processed in this connection, which enables client and server to 900 agree on which requests were accepted prior to the connection 901 shutdown. This identifier MAY be lower than the stream limit 902 identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no 903 requests were processed. Servers SHOULD NOT increase the 904 MAX_STREAM_ID limit after sending a GOAWAY frame. 906 Note: In this context, "processed" means that some data from the 907 stream was passed to some higher layer of software that might have 908 taken some action as a result. 910 Once sent, the server will refuse requests sent on streams with an 911 identifier higher than the included last Stream ID. Clients MUST NOT 912 send new requests on the connection after receiving GOAWAY, although 913 requests might already be in transit. A new connection can be 914 established for new requests. 916 If the client has sent requests on streams with a higher Stream ID 917 than indicated in the GOAWAY frame, those requests were not and will 918 not be processed. Endpoints SHOULD reset any streams above this ID 919 with the error code HTTP_REQUEST_CANCELLED. Servers MAY also reset 920 streams below the indicated ID with HTTP_REQUEST_CANCELLED if the 921 associated requests were not processed. Servers MUST NOT use the 922 HTTP_REQUEST_CANCELLED status for requests which were partially or 923 fully processed. 925 The client can treat requests cancelled by the server as though they 926 had never been sent at all, thereby allowing them to be retried later 927 on a new connection. If a stream is cancelled after receiving a 928 complete response, the client MAY ignore the cancellation and use the 929 response. However, if a stream is cancelled after receiving a 930 partial response, the response SHOULD NOT be used. Automatically 931 retrying such requests is not possible, unless this is otherwise 932 permitted (e.g., idempotent actions like GET, PUT, or DELETE). 933 Requests on Stream IDs less than or equal to the Stream ID in the 934 GOAWAY frame might have been processed; their status cannot be known 935 until they are completed successfully, reset individually, or the 936 connection terminates. 938 Servers SHOULD send a GOAWAY frame when the closing of a connection 939 is known in advance, even if the advance notice is small, so that the 940 remote peer can know whether a stream has been partially processed or 941 not. For example, if an HTTP client sends a POST at the same time 942 that a server closes a QUIC connection, the client cannot know if the 943 server started to process that POST request if the server does not 944 send a GOAWAY frame to indicate what streams it might have acted on. 946 For unexpected closures caused by error conditions, a QUIC 947 CONNECTION_CLOSE or APPLICATION_CLOSE frame MUST be used. However, a 948 GOAWAY MAY be sent first to provide additional detail to clients and 949 to allow the client to retry requests. Including the GOAWAY frame in 950 the same packet as the QUIC CONNECTION_CLOSE or APPLICATION_CLOSE 951 frame improves the chances of the frame being received by clients. 953 If a connection terminates without a GOAWAY frame, the last Stream ID 954 is effectively the highest possible Stream ID (as determined by 955 QUIC's MAX_STREAM_ID). 957 An endpoint MAY send multiple GOAWAY frames if circumstances change. 958 For instance, an endpoint that sends GOAWAY without an error code 959 during graceful shutdown could subsequently encounter an error 960 condition. The last stream identifier from the last GOAWAY frame 961 received indicates which streams could have been acted upon. A 962 server MUST NOT increase the value they send in the last Stream ID, 963 since clients might already have retried unprocessed requests on 964 another connection. 966 A client that is unable to retry requests loses all requests that are 967 in flight when the server closes the connection. A server that is 968 attempting to gracefully shut down a connection SHOULD send an 969 initial GOAWAY frame with the last Stream ID set to the current value 970 of QUIC's MAX_STREAM_ID and SHOULD NOT increase the MAX_STREAM_ID 971 thereafter. This signals to the client that a shutdown is imminent 972 and that initiating further requests is prohibited. After allowing 973 time for any in-flight requests (at least one round-trip time), the 974 server MAY send another GOAWAY frame with an updated last Stream ID. 975 This ensures that a connection can be cleanly shut down without 976 losing requests. 978 Once all requests on streams at or below the identified stream number 979 have been completed or cancelled, and all promised server push 980 responses associated with those requests have been completed or 981 cancelled, the connection can be closed using an Immediate Close (see 982 [QUIC-TRANSPORT]). An endpoint that completes a graceful shutdown 983 SHOULD use the QUIC APPLICATION_CLOSE frame with the HTTP_NO_ERROR 984 code. 986 4.2.8. MAX_PUSH_ID 988 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 989 number of server pushes that the server can initiate. This sets the 990 maximum value for a Push ID that the server can use in a PUSH_PROMISE 991 frame. Consequently, this also limits the number of push streams 992 that the server can initiate in addition to the limit set by the QUIC 993 MAX_STREAM_ID frame. 995 The MAX_PUSH_ID frame is always sent on a control stream. Receipt of 996 a MAX_PUSH_ID frame on any other stream MUST be treated as a 997 connection error of type HTTP_WRONG_STREAM. 999 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1000 receipt of a MAX_PUSH_ID frame as a connection error of type 1001 HTTP_MALFORMED_FRAME. 1003 The maximum Push ID is unset when a connection is created, meaning 1004 that a server cannot push until it receives a MAX_PUSH_ID frame. A 1005 client that wishes to manage the number of promised server pushes can 1006 increase the maximum Push ID by sending a MAX_PUSH_ID frame as the 1007 server fulfills or cancels server pushes. 1009 The MAX_PUSH_ID frame has no defined flags. 1011 The MAX_PUSH_ID frame carries a single variable-length integer that 1012 identifies the maximum value for a Push ID that the server can use 1013 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 1014 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 1015 previously received MUST be treated as a connection error of type 1016 HTTP_MALFORMED_FRAME. 1018 A server MUST treat a MAX_PUSH_ID frame payload that does not contain 1019 a single variable-length integer as a connection error of type 1020 HTTP_MALFORMED_FRAME. 1022 5. Connection Management 1024 QUIC connections are persistent. All of the considerations in 1025 Section 9.1 of [RFC7540] apply to the management of QUIC connections. 1027 HTTP clients are expected to use QUIC PING frames to keep connections 1028 open. Servers SHOULD NOT use PING frames to keep a connection open. 1029 A client SHOULD NOT use PING frames for this purpose unless there are 1030 responses outstanding for requests or server pushes. If the client 1031 is not expecting a response from the server, allowing an idle 1032 connection to time out (based on the idle_timeout transport 1033 parameter) is preferred over expending effort maintaining a 1034 connection that might not be needed. A gateway MAY use PING to 1035 maintain connections in anticipation of need rather than incur the 1036 latency cost of connection establishment to servers. 1038 6. Error Handling 1040 QUIC allows the application to abruptly terminate (reset) individual 1041 streams or the entire connection when an error is encountered. These 1042 are referred to as "stream errors" or "connection errors" and are 1043 described in more detail in [QUIC-TRANSPORT]. 1045 This section describes HTTP-specific error codes which can be used to 1046 express the cause of a connection or stream error. 1048 6.1. HTTP/QUIC Error Codes 1050 The following error codes are defined for use in QUIC RST_STREAM, 1051 STOP_SENDING, and CONNECTION_CLOSE frames when using HTTP/QUIC. 1053 STOPPING (0x00): This value is reserved by the transport to be used 1054 in response to QUIC STOP_SENDING frames. 1056 HTTP_NO_ERROR (0x01): No error. This is used when the connection or 1057 stream needs to be closed, but there is no error to signal. 1059 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1060 which the client will not accept on this connection. 1062 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1063 HTTP stack. 1065 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1066 content which the client has cached. 1068 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1069 requested data. 1071 HTTP_HPACK_DECOMPRESSION_FAILED (0x06): HPACK failed to decompress a 1072 frame and cannot continue. 1074 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1075 a CONNECT request was reset or abnormally closed. 1077 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1078 exhibiting a behavior that might be generating excessive load. 1080 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1081 served over HTTP/QUIC. The peer should retry over HTTP/2. 1083 HTTP_WRONG_STREAM (0x0A): A frame was received on stream where it is 1084 not permitted. 1086 HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current 1087 maximum Push ID was referenced. 1089 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1090 different stream headers. 1092 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1093 The frame type is included as the last octet of the error code. 1094 For example, an error in a MAX_PUSH_ID frame would be indicated 1095 with the code (0x10D). 1097 7. Considerations for Transitioning from HTTP/2 1099 HTTP/QUIC is strongly informed by HTTP/2, and bears many 1100 similarities. This section describes the approach taken to design 1101 HTTP/QUIC, points out important differences from HTTP/2, and 1102 describes how to map HTTP/2 extensions into HTTP/QUIC. 1104 HTTP/QUIC begins from the premise that HTTP/2 code reuse is a useful 1105 feature, but not a hard requirement. HTTP/QUIC departs from HTTP/2 1106 primarily where necessary to accommodate the differences in behavior 1107 between QUIC and TCP (lack of ordering, support for streams). We 1108 intend to avoid gratuitous changes which make it difficult or 1109 impossible to build extensions with the same semantics applicable to 1110 both protocols at once. 1112 These departures are noted in this section. 1114 7.1. Streams 1116 HTTP/QUIC permits use of a larger number of streams (2^62-1) than 1117 HTTP/2. The considerations about exhaustion of stream identifier 1118 space apply, though the space is significantly larger such that it is 1119 likely that other limits in QUIC are reached first, such as the limit 1120 on the connection flow control window. 1122 7.2. HTTP Frame Types 1124 Many framing concepts from HTTP/2 can be elided away on QUIC, because 1125 the transport deals with them. Because frames are already on a 1126 stream, they can omit the stream number. Because frames do not block 1127 multiplexing (QUIC's multiplexing occurs below this layer), the 1128 support for variable-maximum-length packets can be removed. Because 1129 stream termination is handled by QUIC, an END_STREAM flag is not 1130 required. 1132 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1133 includes many features (e.g. flow control) which are also present in 1134 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 1135 As a result, several HTTP/2 frame types are not required in HTTP/ 1136 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 1137 has been reserved in order to maximize portability between HTTP/2 and 1138 HTTP/QUIC implementations. However, even equivalent frames between 1139 the two mappings are not identical. 1141 Many of the differences arise from the fact that HTTP/2 provides an 1142 absolute ordering between frames across all streams, while QUIC 1143 provides this guarantee on each stream only. As a result, if a frame 1144 type makes assumptions that frames from different streams will still 1145 be received in the order sent, HTTP/QUIC will break them. 1147 For example, implicit in the HTTP/2 prioritization scheme is the 1148 notion of in-order delivery of priority changes (i.e., dependency 1149 tree mutations): since operations on the dependency tree such as 1150 reparenting a subtree are not commutative, both sender and receiver 1151 must apply them in the same order to ensure that both sides have a 1152 consistent view of the stream dependency tree. HTTP/2 specifies 1153 priority assignments in PRIORITY frames and (optionally) in HEADERS 1154 frames. To achieve in-order delivery of priority changes in HTTP/ 1155 QUIC, PRIORITY frames are sent on the control stream and the PRIORITY 1156 section is removed from the HEADERS frame. 1158 Frame type definitions in HTTP/QUIC often use the QUIC variable- 1159 length integer encoding. In particular, Stream IDs use this 1160 encoding, which allow for a larger range of possible values than the 1161 encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier 1162 rather than a Stream ID (e.g. Push IDs in PRIORITY frames). 1163 Redefinition of the encoding of extension frame types might be 1164 necessary if the encoding includes a Stream ID. 1166 Other than this issue, frame type HTTP/2 extensions are typically 1167 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 2 1168 or 3 in HTTP/QUIC. HTTP/QUIC extensions will not assume ordering, 1169 but would not be harmed by ordering, and would be portable to HTTP/2 1170 in the same manner. 1172 Below is a listing of how each HTTP/2 frame type is mapped: 1174 DATA (0x0): Padding is not defined in HTTP/QUIC frames. See 1175 Section 4.2.1. 1177 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 1178 not supported. A separate PRIORITY frame MUST be used. Padding 1179 is not defined in HTTP/QUIC frames. See Section 4.2.2. 1181 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 1182 the control stream and can reference either a Stream ID or a Push 1183 ID. See Section 4.2.3. 1185 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 1186 provides stream lifecycle management. The same code point is used 1187 for the CANCEL_PUSH frame (Section 4.2.4). 1189 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 1190 the connection. See Section 4.2.5 and Section 7.3. 1192 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 1193 instead the push stream references the PUSH_PROMISE frame using a 1194 Push ID. See Section 4.2.6. 1196 PING (0x6): PING frames do not exist, since QUIC provides equivalent 1197 functionality. 1199 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 1200 contain an error code. See Section 4.2.7. 1202 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 1203 provides flow control. 1205 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 1206 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted, and 1207 HEADERS frames can be used in series. 1209 Frame types defined by extensions to HTTP/2 need to be separately 1210 registered for HTTP/QUIC if still applicable. The IDs of frames 1211 defined in [RFC7540] have been reserved for simplicity. See 1212 Section 9.3. 1214 7.3. HTTP/2 SETTINGS Parameters 1216 An important difference from HTTP/2 is that settings are sent once, 1217 at the beginning of the connection, and thereafter cannot change. 1218 This eliminates many corner cases around synchronization of changes. 1220 Some transport-level options that HTTP/2 specifies via the SETTINGS 1221 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 1222 HTTP-level options that are retained in HTTP/QUIC have the same value 1223 as in HTTP/2. 1225 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 1227 SETTINGS_HEADER_TABLE_SIZE: See Section 4.2.5.2. 1229 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 1230 which provides a more granular control over server push. 1232 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 1233 Stream ID as part of its flow control logic. Specifying 1234 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 1236 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 1237 connection flow control window sizes to be specified in the 1238 initial transport handshake. Specifying 1239 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 1241 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 1242 QUIC. Specifying it in the SETTINGS frame is an error. 1244 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.2. 1246 Settings need to be defined separately for HTTP/2 and HTTP/QUIC. The 1247 IDs of settings defined in [RFC7540] have been reserved for 1248 simplicity. See Section 9.4. 1250 7.4. HTTP/2 Error Codes 1252 QUIC has the same concepts of "stream" and "connection" errors that 1253 HTTP/2 provides. However, because the error code space is shared 1254 between multiple components, there is no direct portability of HTTP/2 1255 error codes. 1257 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 1258 HTTP over QUIC error codes as follows: 1260 NO_ERROR (0x0): HTTP_NO_ERROR in Section 6.1. 1262 PROTOCOL_ERROR (0x1): No single mapping. See new 1263 HTTP_MALFORMED_FRAME error codes defined in Section 6.1. 1265 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 6.1. 1267 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 1268 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 1269 from the QUIC layer. 1271 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 1272 SETTINGS is defined. 1274 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 1275 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 1276 from the QUIC layer. 1278 FRAME_SIZE_ERROR (0x6) No single mapping. See new error codes 1279 defined in Section 6.1. 1281 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 1282 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 1283 QUIC layer. 1285 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 1287 COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in 1288 Section 6.1. 1290 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 1292 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 1294 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 1295 provide sufficient security on all connections. 1297 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 1299 Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. 1300 See Section 9.5. 1302 8. Security Considerations 1304 The security considerations of HTTP over QUIC should be comparable to 1305 those of HTTP/2. 1307 The modified SETTINGS format contains nested length elements, which 1308 could pose a security risk to an uncautious implementer. A SETTINGS 1309 frame parser MUST ensure that the length of the frame exactly matches 1310 the length of the settings it contains. 1312 9. IANA Considerations 1314 9.1. Registration of HTTP/QUIC Identification String 1316 This document creates a new registration for the identification of 1317 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 1318 Protocol IDs" registry established in [RFC7301]. 1320 The "hq" string identifies HTTP/QUIC: 1322 Protocol: HTTP over QUIC 1324 Identification Sequence: 0x68 0x71 ("hq") 1326 Specification: This document 1328 9.2. Registration of QUIC Version Hint Alt-Svc Parameter 1330 This document creates a new registration for version-negotiation 1331 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1332 registry established in [RFC7838]. 1334 Parameter: "quic" 1336 Specification: This document, Section 2.1.1 1338 9.3. Frame Types 1340 This document establishes a registry for HTTP/QUIC frame type codes. 1341 The "HTTP/QUIC Frame Type" registry manages an 8-bit space. The 1342 "HTTP/QUIC Frame Type" registry operates under either of the "IETF 1343 Review" or "IESG Approval" policies [RFC8126] for values between 0x00 1344 and 0xef, with values between 0xf0 and 0xff being reserved for 1345 Experimental Use. 1347 While this registry is separate from the "HTTP/2 Frame Type" registry 1348 defined in [RFC7540], it is preferable that the assignments parallel 1349 each other. If an entry is present in only one registry, every 1350 effort SHOULD be made to avoid assigning the corresponding value to 1351 an unrelated operation. 1353 New entries in this registry require the following information: 1355 Frame Type: A name or label for the frame type. 1357 Code: The 8-bit code assigned to the frame type. 1359 Specification: A reference to a specification that includes a 1360 description of the frame layout, its semantics, and flags that the 1361 frame type uses, including any parts of the frame that are 1362 conditionally present based on the value of flags. 1364 The entries in the following table are registered by this document. 1366 +--------------+------+---------------+ 1367 | Frame Type | Code | Specification | 1368 +--------------+------+---------------+ 1369 | DATA | 0x0 | Section 4.2.1 | 1370 | | | | 1371 | HEADERS | 0x1 | Section 4.2.2 | 1372 | | | | 1373 | PRIORITY | 0x2 | Section 4.2.3 | 1374 | | | | 1375 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1376 | | | | 1377 | SETTINGS | 0x4 | Section 4.2.5 | 1378 | | | | 1379 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1380 | | | | 1381 | Reserved | 0x6 | N/A | 1382 | | | | 1383 | GOAWAY | 0x7 | Section 4.2.7 | 1384 | | | | 1385 | Reserved | 0x8 | N/A | 1386 | | | | 1387 | Reserved | 0x9 | N/A | 1388 | | | | 1389 | MAX_PUSH_ID | 0xD | Section 4.2.8 | 1390 +--------------+------+---------------+ 1392 9.4. Settings Parameters 1394 This document establishes a registry for HTTP/QUIC settings. The 1395 "HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC 1396 Settings" registry operates under the "Expert Review" policy 1397 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1398 between and 0xf000 and 0xffff being reserved for Experimental Use. 1399 The designated experts are the same as those for the "HTTP/2 1400 Settings" registry defined in [RFC7540]. 1402 While this registry is separate from the "HTTP/2 Settings" registry 1403 defined in [RFC7540], it is preferable that the assignments parallel 1404 each other. If an entry is present in only one registry, every 1405 effort SHOULD be made to avoid assigning the corresponding value to 1406 an unrelated operation. 1408 New registrations are advised to provide the following information: 1410 Name: A symbolic name for the setting. Specifying a setting name is 1411 optional. 1413 Code: The 16-bit code assigned to the setting. 1415 Specification: An optional reference to a specification that 1416 describes the use of the setting. 1418 The entries in the following table are registered by this document. 1420 +----------------------+------+-----------------+ 1421 | Setting Name | Code | Specification | 1422 +----------------------+------+-----------------+ 1423 | HEADER_TABLE_SIZE | 0x1 | Section 4.2.5.2 | 1424 | | | | 1425 | Reserved | 0x2 | N/A | 1426 | | | | 1427 | Reserved | 0x3 | N/A | 1428 | | | | 1429 | Reserved | 0x4 | N/A | 1430 | | | | 1431 | Reserved | 0x5 | N/A | 1432 | | | | 1433 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.2 | 1434 +----------------------+------+-----------------+ 1436 9.5. Error Codes 1438 This document establishes a registry for HTTP/QUIC error codes. The 1439 "HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/ 1440 QUIC Error Code" registry operates under the "Expert Review" policy 1441 [RFC8126]. 1443 Registrations for error codes are required to include a description 1444 of the error code. An expert reviewer is advised to examine new 1445 registrations for possible duplication with existing error codes. 1446 Use of existing registrations is to be encouraged, but not mandated. 1448 New registrations are advised to provide the following information: 1450 Name: A name for the error code. Specifying an error code name is 1451 optional. 1453 Code: The 16-bit error code value. 1455 Description: A brief description of the error code semantics, longer 1456 if no detailed specification is provided. 1458 Specification: An optional reference for a specification that 1459 defines the error code. 1461 The entries in the following table are registered by this document. 1463 +----------------------------+--------+------------+----------------+ 1464 | Name | Code | Descriptio | Specification | 1465 | | | n | | 1466 +----------------------------+--------+------------+----------------+ 1467 | STOPPING | 0x0000 | Reserved | [QUIC-TRANSPOR | 1468 | | | by QUIC | T] | 1469 | | | | | 1470 | HTTP_NO_ERROR | 0x0001 | No error | Section 6.1 | 1471 | | | | | 1472 | HTTP_PUSH_REFUSED | 0x0002 | Client | Section 6.1 | 1473 | | | refused | | 1474 | | | pushed | | 1475 | | | content | | 1476 | | | | | 1477 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 6.1 | 1478 | | | error | | 1479 | | | | | 1480 | HTTP_PUSH_ALREADY_IN_CACHE | 0x0004 | Pushed | Section 6.1 | 1481 | | | content | | 1482 | | | already | | 1483 | | | cached | | 1484 | | | | | 1485 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 6.1 | 1486 | | | longer | | 1487 | | | needed | | 1488 | | | | | 1489 | HTTP_HPACK_DECOMPRESSION_F | 0x0006 | HPACK | Section 6.1 | 1490 | AILED | | cannot | | 1491 | | | continue | | 1492 | | | | | 1493 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset | Section 6.1 | 1494 | | | or error | | 1495 | | | on CONNECT | | 1496 | | | request | | 1497 | | | | | 1498 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 6.1 | 1499 | | | generating | | 1500 | | | excessive | | 1501 | | | load | | 1502 | | | | | 1503 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 6.1 | 1504 | | | HTTP/2 | | 1505 | | | | | 1506 | HTTP_WRONG_STREAM | 0x000A | A frame | Section 6.1 | 1507 | | | was sent | | 1508 | | | on the | | 1509 | | | wrong | | 1510 | | | stream | | 1511 | | | | | 1512 | HTTP_PUSH_LIMIT_EXCEEDED | 0x000B | Maximum | Section 6.1 | 1513 | | | Push ID | | 1514 | | | exceeded | | 1515 | | | | | 1516 | HTTP_DUPLICATE_PUSH | 0x000C | Push ID | Section 6.1 | 1517 | | | was | | 1518 | | | fulfilled | | 1519 | | | multiple | | 1520 | | | times | | 1521 | | | | | 1522 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 6.1 | 1523 | | | frame | | 1524 | | | formatting | | 1525 | | | or use | | 1526 +----------------------------+--------+------------+----------------+ 1528 10. References 1530 10.1. Normative References 1532 [QUIC-TRANSPORT] 1533 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1534 Multiplexed and Secure Transport", draft-ietf-quic- 1535 transport-09 (work in progress), January 2018. 1537 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1538 RFC 793, DOI 10.17487/RFC0793, September 1981, 1539 . 1541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1542 Requirement Levels", BCP 14, RFC 2119, 1543 DOI 10.17487/RFC2119, March 1997, 1544 . 1546 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1547 Specifications: ABNF", STD 68, RFC 5234, 1548 DOI 10.17487/RFC5234, January 2008, 1549 . 1551 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1552 Extensions: Extension Definitions", RFC 6066, 1553 DOI 10.17487/RFC6066, January 2011, 1554 . 1556 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1557 Protocol (HTTP/1.1): Message Syntax and Routing", 1558 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1559 . 1561 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1562 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1563 DOI 10.17487/RFC7231, June 2014, 1564 . 1566 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1567 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1568 DOI 10.17487/RFC7540, May 2015, 1569 . 1571 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1572 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1573 . 1575 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1576 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1577 April 2016, . 1579 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1580 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1581 May 2017, . 1583 10.2. Informative References 1585 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1586 "Transport Layer Security (TLS) Application-Layer Protocol 1587 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1588 July 2014, . 1590 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1591 Writing an IANA Considerations Section in RFCs", BCP 26, 1592 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1593 . 1595 10.3. URIs 1597 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1599 [2] https://github.com/quicwg 1601 [3] https://github.com/quicwg/base-drafts/labels/-http 1603 Appendix A. Contributors 1605 The original authors of this specification were Robbie Shade and Mike 1606 Warres. 1608 A substantial portion of Mike's contribution was supported by 1609 Microsoft during his employment there. 1611 Appendix B. Change Log 1613 *RFC Editor's Note:* Please remove this section prior to 1614 publication of a final version of this document. 1616 B.1. Since draft-ietf-quic-http-08 1618 o Clarified connection coalescing rules (#940, #1024) 1620 B.2. Since draft-ietf-quic-http-07 1622 o Changes for integer encodings in QUIC (#595,#905) 1624 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 1626 o Improvement to the description of GOAWAY (#604, #898) 1628 o Improve description of server push usage (#947, #950, #957) 1630 B.3. Since draft-ietf-quic-http-06 1632 o Track changes in QUIC error code usage (#485) 1634 B.4. Since draft-ietf-quic-http-05 1636 o Made push ID sequential, add MAX_PUSH_ID, remove 1637 SETTINGS_ENABLE_PUSH (#709) 1639 o Guidance about keep-alive and QUIC PINGs (#729) 1641 o Expanded text on GOAWAY and cancellation (#757) 1643 B.5. Since draft-ietf-quic-http-04 1645 o Cite RFC 5234 (#404) 1647 o Return to a single stream per request (#245,#557) 1649 o Use separate frame type and settings registries from HTTP/2 (#81) 1650 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 1652 o Restored GOAWAY (#696) 1654 o Identify server push using Push ID rather than a stream ID 1655 (#702,#281) 1657 o DATA frames cannot be empty (#700) 1659 B.6. Since draft-ietf-quic-http-03 1661 None. 1663 B.7. Since draft-ietf-quic-http-02 1665 o Track changes in transport draft 1667 B.8. Since draft-ietf-quic-http-01 1669 o SETTINGS changes (#181): 1671 * SETTINGS can be sent only once at the start of a connection; no 1672 changes thereafter 1674 * SETTINGS_ACK removed 1676 * Settings can only occur in the SETTINGS frame a single time 1678 * Boolean format updated 1680 o Alt-Svc parameter changed from "v" to "quic"; format updated 1681 (#229) 1683 o Closing the connection control stream or any message control 1684 stream is a fatal error (#176) 1686 o HPACK Sequence counter can wrap (#173) 1688 o 0-RTT guidance added 1690 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 1691 added (#127,#242) 1693 B.9. Since draft-ietf-quic-http-00 1695 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 1696 o Changed from using HTTP/2 framing within Stream 3 to new framing 1697 format and two-stream-per-request model (#71,#72,#73) 1699 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 1700 settings-01 1702 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 1703 order (#75) 1705 o Described CONNECT pseudo-method (#95) 1707 o Updated ALPN token and Alt-Svc guidance (#13,#87) 1709 o Application-layer-defined error codes (#19,#74) 1711 B.10. Since draft-shade-quic-http2-mapping-00 1713 o Adopted as base for draft-ietf-quic-http 1715 o Updated authors/editors list 1717 Author's Address 1719 Mike Bishop (editor) 1720 Akamai 1722 Email: mbishop@evequefou.be