idnits 2.17.00 (12 Aug 2021) /tmp/idnits6282/draft-ietf-quic-http-10.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 (March 05, 2018) is 1537 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 1668 -- Looks like a reference, but probably isn't: '2' on line 1670 -- Looks like a reference, but probably isn't: '3' on line 1672 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 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 March 05, 2018 5 Expires: September 6, 2018 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-10 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 September 6, 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 . . . . . . . . . . . . . . . . . 4 65 2. Connection Setup and Management . . . . . . . . . . . . . . . 4 66 2.1. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 4 67 2.1.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 5 68 2.2. Connection Establishment . . . . . . . . . . . . . . . . 5 69 2.2.1. Draft Version Identification . . . . . . . . . . . . 6 70 2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6 71 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 72 3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 8 73 3.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 8 74 3.2.1. Header Compression . . . . . . . . . . . . . . . . . 9 75 3.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 9 76 3.2.3. Request Cancellation . . . . . . . . . . . . . . . . 10 77 3.3. Request Prioritization . . . . . . . . . . . . . . . . . 11 78 3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 11 79 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 12 80 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12 81 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13 82 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13 84 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14 85 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16 86 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16 87 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19 88 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20 89 4.2.8. HEADER_ACK . . . . . . . . . . . . . . . . . . . . . 22 90 4.2.9. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 23 91 5. Connection Management . . . . . . . . . . . . . . . . . . . . 24 92 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24 93 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 24 95 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 25 96 7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 26 98 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 28 99 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 28 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 102 9.1. Registration of HTTP/QUIC Identification String . . . . . 30 103 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 30 104 9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 30 105 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 31 106 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 32 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 109 10.2. Informative References . . . . . . . . . . . . . . . . . 35 110 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 111 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 112 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 113 B.1. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 36 114 B.2. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 36 115 B.3. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 36 116 B.4. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37 117 B.5. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37 118 B.6. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 37 119 B.7. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 37 120 B.8. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 37 121 B.9. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 37 122 B.10. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 38 123 B.11. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 38 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 126 1. Introduction 128 The QUIC transport protocol has several features that are desirable 129 in a transport for HTTP, such as stream multiplexing, per-stream flow 130 control, and low-latency connection establishment. This document 131 describes a mapping of HTTP semantics over QUIC, drawing heavily on 132 the existing TCP mapping, HTTP/2. Specifically, this document 133 identifies HTTP/2 features that are subsumed by QUIC, and describes 134 how the other features can be implemented atop QUIC. 136 QUIC is described in [QUIC-TRANSPORT]. For a full description of 137 HTTP/2, see [RFC7540]. 139 1.1. Notational Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 148 defined in [RFC5234]. 150 This document uses the variable-length integer encoding from 151 [QUIC-TRANSPORT]. 153 Protocol elements called "frames" exist in both this document and 154 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 155 the frame name will be prefaced with "QUIC." For example, "QUIC 156 APPLICATION_CLOSE frames." References without this preface refer to 157 frames defined in Section 4.2. 159 2. Connection Setup and Management 161 2.1. Discovering an HTTP/QUIC Endpoint 163 An HTTP origin advertises the availability of an equivalent HTTP/QUIC 164 endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC 165 frame ([RFC7838]), using the ALPN token defined in Section 2.2. 167 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 168 response that HTTP/QUIC was available on UDP port 50781 at the same 169 hostname by including the following header in any response: 171 Alt-Svc: hq=":50781" 173 On receipt of an Alt-Svc header indicating HTTP/QUIC support, a 174 client MAY attempt to establish a QUIC connection to the indicated 175 host and port and, if successful, send HTTP requests using the 176 mapping described in this document. 178 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 179 connection establishment failure, in which case the client SHOULD 180 continue using the existing connection or try another alternative 181 endpoint offered by the origin. 183 Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the 184 same port across all IP addresses that serve a single domain, and 185 SHOULD NOT change this port. 187 2.1.1. QUIC Version Hints 189 This document defines the "quic" parameter for Alt-Svc, which MAY be 190 used to provide version-negotiation hints to HTTP/QUIC clients. QUIC 191 versions are four-octet sequences with no additional constraints on 192 format. Leading zeros SHOULD be omitted for brevity. 194 Syntax: 196 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 197 version-number = 1*8HEXDIG; hex-encoded QUIC version 199 Where multiple versions are listed, the order of the values reflects 200 the server's preference (with the first value being the most 201 preferred version). Reserved versions MAY be listed, but unreserved 202 versions which are not supported by the alternative SHOULD NOT be 203 present in the list. Origins MAY omit supported versions for any 204 reason. 206 Clients MUST ignore any included versions which they do not support. 207 The "quic" parameter MUST NOT occur more than once; clients SHOULD 208 process only the first occurrence. 210 For example, suppose a server supported both version 0x00000001 and 211 the version rendered in ASCII as "Q034". If it opted to include the 212 reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and 213 0x1abadaba, it could specify the following header: 215 Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0" 217 A client acting on this header would drop the reserved versions 218 (because it does not support them), then attempt to connect to the 219 alternative using the first version in the list which it does 220 support. 222 2.2. Connection Establishment 224 HTTP/QUIC relies on QUIC as the underlying transport. The QUIC 225 version being used MUST use TLS version 1.3 or greater as its 226 handshake protocol. The Server Name Indication (SNI) extension 227 [RFC6066] MUST be included in the TLS handshake. 229 QUIC connections are established as described in [QUIC-TRANSPORT]. 230 During connection establishment, HTTP/QUIC support is indicated by 231 selecting the ALPN token "hq" in the TLS handshake. Support for 232 other application-layer protocols MAY be offered in the same 233 handshake. 235 While connection-level options pertaining to the core QUIC protocol 236 are set in the initial crypto handshake, HTTP-specific settings are 237 conveyed in the SETTINGS frame. After the QUIC connection is 238 established, a SETTINGS frame (Section 4.2.5) MUST be sent by each 239 endpoint as the initial frame of their respective HTTP control stream 240 (Stream ID 2 or 3, see Section 3). The server MUST NOT send data on 241 any other stream until the client's SETTINGS frame has been received. 243 2.2.1. Draft Version Identification 245 *RFC Editor's Note:* Please remove this section prior to 246 publication of a final version of this document. 248 Only implementations of the final, published RFC can identify 249 themselves as "hq". Until such an RFC exists, implementations MUST 250 NOT identify themselves using this string. 252 Implementations of draft versions of the protocol MUST add the string 253 "-" and the corresponding draft number to the identifier. For 254 example, draft-ietf-quic-http-01 is identified using the string "hq- 255 01". 257 Non-compatible experiments that are based on these draft versions 258 MUST append the string "-" and an experiment name to the identifier. 259 For example, an experimental implementation based on draft-ietf-quic- 260 http-09 which reserves an extra stream for unsolicited transmission 261 of 1980s pop music might identify itself as "hq-09-rickroll". Note 262 that any label MUST conform to the "token" syntax defined in 263 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 264 coordinate their experiments on the quic@ietf.org mailing list. 266 2.3. Connection Reuse 268 Once a connection exists to a server endpoint, this connection MAY be 269 reused for requests with multiple different URI authority components. 270 The client MAY send any requests for which the client considers the 271 server authoritative. 273 An authoritative HTTP/QUIC endpoint is typically discovered because 274 the client has received an Alt-Svc record from the request's origin 275 which nominates the endpoint as a valid HTTP Alternative Service for 276 that origin. As required by [RFC7838], clients MUST check that the 277 nominated server can present a valid certificate for the origin 278 before considering it authoritative. Clients MUST NOT assume that an 279 HTTP/QUIC endpoint is authoritative for other origins without an 280 explicit signal. 282 A server that does not wish clients to reuse connections for a 283 particular origin can indicate that it is not authoritative for a 284 request by sending a 421 (Misdirected Request) status code in 285 response to the request (see Section 9.1.2 of [RFC7540]). 287 3. Stream Mapping and Usage 289 A QUIC stream provides reliable in-order delivery of bytes, but makes 290 no guarantees about order of delivery with regard to bytes on other 291 streams. On the wire, data is framed into QUIC STREAM frames, but 292 this framing is invisible to the HTTP framing layer. A QUIC receiver 293 buffers and orders received STREAM frames, exposing the data 294 contained within as a reliable byte stream to the application. 296 QUIC reserves the first client-initiated, bidirectional stream 297 (Stream 0) for cryptographic operations. HTTP over QUIC reserves the 298 first unidirectional stream sent by either peer (Streams 2 and 3) for 299 sending and receiving HTTP control frames. This pair of 300 unidirectional streams is analogous to HTTP/2's Stream 0. The data 301 sent on these streams is critical to the HTTP connection. If either 302 control stream is closed for any reason, this MUST be treated as a 303 connection error of type QUIC_CLOSED_CRITICAL_STREAM. 305 When HTTP headers and data are sent over QUIC, the QUIC layer handles 306 most of the stream management. 308 An HTTP request/response consumes a single client-initiated, 309 bidirectional stream. A bidirectional stream ensures that the 310 response can be readily correlated with the request. This means that 311 the client's first request occurs on QUIC stream 4, with subsequent 312 requests on stream 8, 12, and so on. 314 Server push uses server-initiated, unidirectional streams. Thus, the 315 server's first push consumes stream 7 and subsequent pushes use 316 stream 11, 15, and so on. 318 These streams carry frames related to the request/response (see 319 Section 4.2). When a stream terminates cleanly, if the last frame on 320 the stream was truncated, this MUST be treated as a connection error 321 (see HTTP_MALFORMED_FRAME in Section 6.1). Streams which terminate 322 abruptly may be reset at any point in the frame. 324 Streams SHOULD be used sequentially, with no gaps. 326 HTTP does not need to do any separate multiplexing when using QUIC - 327 data sent over a QUIC stream always maps to a particular HTTP 328 transaction. Requests and responses are considered complete when the 329 corresponding QUIC stream is closed in the appropriate direction. 331 3.1. Control Streams 333 Since most connection-level concerns will be managed by QUIC, the 334 primary use of Streams 2 and 3 will be for the SETTINGS frame when 335 the connection opens and for PRIORITY frames subsequently. 337 A pair of unidirectional streams is used rather than a single 338 bidirectional stream. This allows either peer to send data as soon 339 they are able. Depending on whether 0-RTT is enabled on the 340 connection, either client or server might be able to send stream data 341 first after the cryptographic handshake completes. 343 3.2. HTTP Message Exchanges 345 A client sends an HTTP request on a client-initiated, bidirectional 346 QUIC stream. A server sends an HTTP response on the same stream as 347 the request. 349 An HTTP message (request or response) consists of: 351 1. one header block (see Section 4.2.2) containing the message 352 headers (see [RFC7230], Section 3.2), 354 2. the payload body (see [RFC7230], Section 3.3), sent as a series 355 of DATA frames (see Section 4.2.1), 357 3. optionally, one header block containing the trailer-part, if 358 present (see [RFC7230], Section 4.1.2). 360 In addition, prior to sending the message header block indicated 361 above, a response may contain zero or more header blocks containing 362 the message headers of informational (1xx) HTTP responses (see 363 [RFC7230], Section 3.2 and [RFC7231], Section 6.2). 365 PUSH_PROMISE frames MAY be interleaved with the frames of a response 366 message indicating a pushed resource related to the response. These 367 PUSH_PROMISE frames are not part of the response, but carry the 368 headers of a separate HTTP request message. See Section 3.4 for more 369 details. 371 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 372 MUST NOT be used. 374 Trailing header fields are carried in an additional header block 375 following the body. Such a header block is a sequence of HEADERS 376 frames with End Header Block set on the last frame. Senders MUST 377 send only one header block in the trailers section; receivers MUST 378 discard any subsequent header blocks. 380 An HTTP request/response exchange fully consumes a QUIC stream. 381 After sending a request, a client closes the stream for sending; 382 after sending a response, the server closes the stream for sending 383 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. 394 Servers MUST NOT abort a response in progress as a result of 395 receiving a solicited RST_STREAM. 397 3.2.1. Header Compression 399 HTTP/QUIC uses QCRAM header compression as described in [QCRAM], a 400 variation of HPACK which allows the flexibility to avoid header- 401 compression-induced head-of-line blocking. See that document for 402 additional details. 404 3.2.2. The CONNECT Method 406 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 407 used with HTTP proxies to establish a TLS session with an origin 408 server for the purposes of interacting with "https" resources. In 409 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 410 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 411 establish a tunnel over a single HTTP/2 stream to a remote host for 412 similar purposes. 414 A CONNECT request in HTTP/QUIC functions in the same manner as in 415 HTTP/2. The request MUST be formatted as described in [RFC7540], 416 Section 8.3. A CONNECT request that does not conform to these 417 restrictions is malformed. The request stream MUST NOT be half- 418 closed at the end of the request. 420 A proxy that supports CONNECT establishes a TCP connection 421 ([RFC0793]) to the server identified in the ":authority" pseudo- 422 header field. Once this connection is successfully established, the 423 proxy sends a HEADERS frame containing a 2xx series status code to 424 the client, as defined in [RFC7231], Section 4.3.6. 426 All DATA frames on the request stream correspond to data sent on the 427 TCP connection. Any DATA frame sent by the client is transmitted by 428 the proxy to the TCP server; data received from the TCP server is 429 packaged into DATA frames by the proxy. Note that the size and 430 number of TCP segments is not guaranteed to map predictably to the 431 size and number of HTTP DATA or QUIC STREAM frames. 433 The TCP connection can be closed by either peer. When the client 434 ends the request stream (that is, the receive stream at the proxy 435 enters the "Data Recvd" state), the proxy will set the FIN bit on its 436 connection to the TCP server. When the proxy receives a packet with 437 the FIN bit set, it will terminate the send stream that it sends to 438 client. TCP connections which remain half-closed in a single 439 direction are not invalid, but are often handled poorly by servers, 440 so clients SHOULD NOT cause send a STREAM frame with a FIN bit for 441 connections on which they are still expecting data. 443 A TCP connection error is signaled with RST_STREAM. A proxy treats 444 any error in the TCP connection, which includes receiving a TCP 445 segment with the RST bit set, as a stream error of type 446 HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send 447 a TCP segment with the RST bit set if it detects an error with the 448 stream or the QUIC connection. 450 3.2.3. Request Cancellation 452 Either client or server can cancel requests by closing the stream 453 (QUIC RST_STREAM or STOP_SENDING frames, as appropriate) with an 454 error type of HTTP_REQUEST_CANCELLED (Section 6.1). When the client 455 cancels a request or response, it indicates that the response is no 456 longer of interest. 458 When the server cancels either direction of the request stream using 459 HTTP_REQUEST_CANCELLED, it indicates that no application processing 460 was performed. The client can treat requests cancelled by the server 461 as though they had never been sent at all, thereby allowing them to 462 be retried later on a new connection. Servers MUST NOT use the 463 HTTP_REQUEST_CANCELLED status for requests which were partially or 464 fully processed. 466 Note: In this context, "processed" means that some data from the 467 stream was passed to some higher layer of software that might have 468 taken some action as a result. 470 If a stream is cancelled after receiving a complete response, the 471 client MAY ignore the cancellation and use the response. However, if 472 a stream is cancelled after receiving a partial response, the 473 response SHOULD NOT be used. Automatically retrying such requests is 474 not possible, unless this is otherwise permitted (e.g., idempotent 475 actions like GET, PUT, or DELETE). 477 3.3. Request Prioritization 479 HTTP/QUIC uses the priority scheme described in [RFC7540], 480 Section 5.3. In this priority scheme, a given request can be 481 designated as dependent upon another request, which expresses the 482 preference that the latter stream (the "parent" request) be allocated 483 resources before the former stream (the "dependent" request). Taken 484 together, the dependencies across all requests in a connection form a 485 dependency tree. The structure of the dependency tree changes as 486 PRIORITY frames add, remove, or change the dependency links between 487 requests. 489 The PRIORITY frame Section 4.2.3 identifies a request either by 490 identifying the stream that carries a request or by using a Push ID 491 (Section 4.2.6). 493 Only a client can send PRIORITY frames. A server MUST NOT send a 494 PRIORITY frame. 496 3.4. Server Push 498 HTTP/QUIC supports server push as described in [RFC7540]. During 499 connection establishment, the client enables server push by sending a 500 MAX_PUSH_ID frame (see Section 4.2.9). A server cannot use server 501 push until it receives a MAX_PUSH_ID frame. 503 As with server push for HTTP/2, the server initiates a server push by 504 sending a PUSH_PROMISE frame that includes request header fields 505 attributed to the request. The PUSH_PROMISE frame is sent on the 506 client-initiated, bidirectional stream that carried the request that 507 generated the push. This allows the server push to be associated 508 with a request. Ordering of a PUSH_PROMISE in relation to certain 509 parts of the response is important (see Section 8.2.1 of [RFC7540]). 511 Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it 512 contains a Push ID. The Push ID uniquely identifies a server push 513 (see Section 4.2.6). This allows a server to fulfill promises in the 514 order that best suits its needs. 516 When a server later fulfills a promise, the server push response is 517 conveyed on a push stream. A push stream is a server-initiated, 518 unidirectional stream. A push stream always begins with a header 519 (see Figure 1) that identifies the Push ID of the promise that it 520 fulfills, encoded as a variable-length integer. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Push ID (i) ... 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Figure 1: Push Stream Header 530 A server SHOULD use Push IDs sequentially, starting at 0. A client 531 uses the MAX_PUSH_ID frame (Section 4.2.9) to limit the number of 532 pushes that a server can promise. A client MUST treat receipt of a 533 push stream with a Push ID that is greater than the maximum Push ID 534 as a connection error of type HTTP_PUSH_LIMIT_EXCEEDED. 536 Each Push ID MUST only be used once in a push stream header. If a 537 push stream header includes a Push ID that was used in another push 538 stream header, the client MUST treat this as a connection error of 539 type HTTP_DUPLICATE_PUSH. The same Push ID can be used in multiple 540 PUSH_PROMISE frames (see Section 4.2.6). 542 After the push stream header, a push contains a response 543 (Section 3.2), with response headers, a response body (if any) 544 carried by DATA frames, then trailers (if any) carried by HEADERS 545 frames. 547 If a promised server push is not needed by the client, the client 548 SHOULD send a CANCEL_PUSH frame; if the push stream is already open, 549 a QUIC STOP_SENDING frame with an appropriate error code can be used 550 instead (e.g., HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see 551 Section 6). This asks the server not to transfer the data and 552 indicates that it will be discarded upon receipt. 554 4. HTTP Framing Layer 556 Frames are used on each stream. This section describes HTTP framing 557 in QUIC and highlights some differences from HTTP/2 framing. For 558 more detail on differences from HTTP/2, see Section 7.2. 560 4.1. Frame Layout 562 All frames have the following format: 564 0 1 2 3 565 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Length (i) ... 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type (8) | Flags (8) | Frame Payload (*) ... 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Figure 2: HTTP/QUIC frame format 574 A frame includes the following fields: 576 Length: A variable-length integer that describes the length of the 577 Frame Payload. This length does not include the frame header. 579 Type: An 8-bit type for the frame. 581 Flags: An 8-bit field containing flags. The Type field determines 582 the semantics of flags. 584 Frame Payload: A payload, the semantics of which are determined by 585 the Type field. 587 4.2. Frame Definitions 589 4.2.1. DATA 591 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 592 octets associated with an HTTP request or response payload. 594 The DATA frame defines no flags. 596 DATA frames MUST be associated with an HTTP request or response. If 597 a DATA frame is received on either control stream, the recipient MUST 598 respond with a connection error (Section 6) of type 599 HTTP_WRONG_STREAM. 601 DATA frames MUST contain a non-zero-length payload. If a DATA frame 602 is received with a payload length of zero, the recipient MUST respond 603 with a stream error (Section 6) of type HTTP_MALFORMED_FRAME. 605 4.2.2. HEADERS 607 The HEADERS frame (type=0x1) is used to carry a header block, 608 compressed using HPACK Section 3.2.1. 610 The HEADERS frame defines a single flag: 612 BLOCKING (0x01): Indicates the stream might need to wait for 613 dependent headers before processing. If 0, the frame can be 614 processed immediately upon receipt. 616 HEADERS frames can be sent on the Control Stream as well as on 617 request / push streams. The value of BLOCKING MUST be 0 for HEADERS 618 frames on the Control Stream, since they can only depend on previous 619 HEADERS on the same stream. 621 4.2.3. PRIORITY 623 The PRIORITY (type=0x02) frame specifies the sender-advised priority 624 of a stream and is substantially different in format from [RFC7540]. 625 In order to ensure that prioritization is processed in a consistent 626 order, PRIORITY frames MUST be sent on the control stream. A 627 PRIORITY frame sent on any other stream MUST be treated as a 628 HTTP_WRONG_STREAM error. 630 The format has been modified to accommodate not being sent on a 631 request stream, to allow for identification of server pushes, and the 632 larger stream ID space of QUIC. The semantics of the Stream 633 Dependency, Weight, and E flag are otherwise the same as in HTTP/2. 635 The flags defined are: 637 PUSH_PRIORITIZED (0x04): Indicates that the Prioritized Stream is a 638 server push rather than a request. 640 PUSH_DEPENDENT (0x02): Indicates a dependency on a server push. 642 E (0x01): Indicates that the stream dependency is exclusive (see 643 [RFC7540], Section 5.3). 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Prioritized Request ID (i) | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Stream Dependency ID (i) | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Weight (8) | 653 +-+-+-+-+-+-+-+-+ 655 Figure 3: PRIORITY frame payload 657 The PRIORITY frame payload has the following fields: 659 Prioritized Request ID: A variable-length integer that identifies a 660 request. This contains the Stream ID of a request stream when the 661 PUSH_PRIORITIZED flag is clear, or a Push ID when the 662 PUSH_PRIORITIZED flag is set. 664 Stream Dependency ID: A variable-length integer that identifies a 665 dependent request. This contains the Stream ID of a request 666 stream when the PUSH_DEPENDENT flag is clear, or a Push ID when 667 the PUSH_DEPENDENT flag is set. A request Stream ID of 0 668 indicates a dependency on the root stream. For details of 669 dependencies, see Section 3.3 and [RFC7540], Section 5.3. 671 Weight: An unsigned 8-bit integer representing a priority weight for 672 the stream (see [RFC7540], Section 5.3). Add one to the value to 673 obtain a weight between 1 and 256. 675 A PRIORITY frame identifies a request to prioritize, and a request 676 upon which that request is dependent. A Prioritized Request ID or 677 Stream Dependency ID identifies a client-initiated request using the 678 corresponding stream ID when the corresponding PUSH_PRIORITIZED or 679 PUSH_DEPENDENT flag is not set. Setting the PUSH_PRIORITIZED or 680 PUSH_DEPENDENT flag causes the Prioritized Request ID or Stream 681 Dependency ID (respectively) to identify a server push using a Push 682 ID (see Section 4.2.6 for details). 684 A PRIORITY frame MAY identify a Stream Dependency ID using a Stream 685 ID of 0; as in [RFC7540], this makes the request dependent on the 686 root of the dependency tree. 688 A PRIORITY frame MUST identify a client-initiated, bidirectional 689 stream. A server MUST treat receipt of PRIORITY frame with a Stream 690 ID of any other type as a connection error of type 691 HTTP_MALFORMED_FRAME. 693 Stream ID 0 cannot be reprioritized. A Prioritized Request ID that 694 identifies Stream 0 MUST be treated as a connection error of type 695 HTTP_MALFORMED_FRAME. 697 A PRIORITY frame that does not reference a request MUST be treated as 698 a HTTP_MALFORMED_FRAME error, unless it references Stream ID 0. A 699 PRIORITY that sets a PUSH_PRIORITIZED or PUSH_DEPENDENT flag, but 700 then references a non-existent Push ID MUST be treated as a 701 HTTP_MALFORMED_FRAME error. 703 A PRIORITY frame MUST contain only the identified fields. A PRIORITY 704 frame that contains more or fewer fields, or a PRIORITY frame that 705 includes a truncated integer encoding MUST be treated as a connection 706 error of type HTTP_MALFORMED_FRAME. 708 4.2.4. CANCEL_PUSH 710 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of 711 server push prior to the push stream being created. The CANCEL_PUSH 712 frame identifies a server push request by Push ID (see Section 4.2.6) 713 using a variable-length integer. 715 When a server receives this frame, it aborts sending the response for 716 the identified server push. If the server has not yet started to 717 send the server push, it can use the receipt of a CANCEL_PUSH frame 718 to avoid opening a stream. If the push stream has been opened by the 719 server, the server SHOULD sent a QUIC RST_STREAM frame on those 720 streams and cease transmission of the response. 722 A server can send this frame to indicate that it won't be sending a 723 response prior to creation of a push stream. Once the push stream 724 has been created, sending CANCEL_PUSH has no effect on the state of 725 the push stream. A QUIC RST_STREAM frame SHOULD be used instead to 726 cancel transmission of the server push response. 728 A CANCEL_PUSH frame is sent on the control stream. Sending a 729 CANCEL_PUSH frame on a stream other than the control stream MUST be 730 treated as a stream error of type HTTP_WRONG_STREAM. 732 The CANCEL_PUSH frame has no defined flags. 734 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 735 integer. The Push ID identifies the server push that is being 736 cancelled (see Section 4.2.6). 738 If the client receives a CANCEL_PUSH frame, that frame might identify 739 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 741 An endpoint MUST treat a CANCEL_PUSH frame which does not contain 742 exactly one properly-formatted variable-length integer as a 743 connection error of type HTTP_MALFORMED_FRAME. 745 4.2.5. SETTINGS 747 The SETTINGS frame (type=0x4) conveys configuration parameters that 748 affect how endpoints communicate, such as preferences and constraints 749 on peer behavior, and is different from [RFC7540]. Individually, a 750 SETTINGS parameter can also be referred to as a "setting". 752 SETTINGS parameters are not negotiated; they describe characteristics 753 of the sending peer, which can be used by the receiving peer. 754 However, a negotiation can be implied by the use of SETTINGS - a peer 755 uses SETTINGS to advertise a set of supported values. The recipient 756 can then choose which entries from this list are also acceptable and 757 proceed with the value it has chosen. (This choice could be 758 announced in a field of an extension frame, or in its own value in 759 SETTINGS.) 761 Different values for the same parameter can be advertised by each 762 peer. For example, a client might be willing to consume very large 763 response headers, while servers are more cautious about request size. 765 Parameters MUST NOT occur more than once. A receiver MAY treat the 766 presence of the same parameter more than once as a connection error 767 of type HTTP_MALFORMED_FRAME. 769 The SETTINGS frame defines no flags. 771 The payload of a SETTINGS frame consists of zero or more parameters, 772 each consisting of an unsigned 16-bit setting identifier and a 773 length-prefixed binary value. 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Identifier (16) | Length (i) ... 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Contents (?) ... 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Figure 4: SETTINGS value format 785 A zero-length content indicates that the setting value is a Boolean 786 and true. False is indicated by the absence of the setting. 788 Non-zero-length values MUST be compared against the remaining length 789 of the SETTINGS frame. Any value which purports to cross the end of 790 the frame MUST cause the SETTINGS frame to be considered malformed 791 and trigger a connection error of type HTTP_MALFORMED_FRAME. 793 An implementation MUST ignore the contents for any SETTINGS 794 identifier it does not understand. 796 SETTINGS frames always apply to a connection, never a single stream. 797 A SETTINGS frame MUST be sent as the first frame of either control 798 stream (see Section 3) by each peer, and MUST NOT be sent 799 subsequently or on any other stream. If an endpoint receives an 800 SETTINGS frame on a different stream, the endpoint MUST respond with 801 a connection error of type HTTP_WRONG_STREAM. If an endpoint 802 receives a second SETTINGS frame, the endpoint MUST respond with a 803 connection error of type HTTP_MALFORMED_FRAME. 805 The SETTINGS frame affects connection state. A badly formed or 806 incomplete SETTINGS frame MUST be treated as a connection error 807 (Section 6) of type HTTP_MALFORMED_FRAME. 809 4.2.5.1. Integer encoding 811 Settings which are integers use the QUIC variable-length integer 812 encoding. 814 4.2.5.2. Defined SETTINGS Parameters 816 The following settings are defined in HTTP/QUIC: 818 SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of 819 2^30 - 1. 821 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value 822 of 2^30 - 1 824 4.2.5.3. Usage in 0-RTT 826 When a 0-RTT QUIC connection is being used, the client's initial 827 requests will be sent before the arrival of the server's SETTINGS 828 frame. Clients SHOULD cache at least the following settings about 829 servers: 831 o SETTINGS_HEADER_TABLE_SIZE 833 o SETTINGS_MAX_HEADER_LIST_SIZE 835 Clients MUST comply with cached settings until the server's current 836 settings are received. If a client does not have cached values, it 837 SHOULD assume the following values: 839 o SETTINGS_HEADER_TABLE_SIZE: 0 octets 841 o SETTINGS_MAX_HEADER_LIST_SIZE: 16,384 octets 843 Servers MAY continue processing data from clients which exceed its 844 current configuration during the initial flight. In this case, the 845 client MUST apply the new settings immediately upon receipt. 847 If the connection is closed because these or other constraints were 848 violated during the 0-RTT flight (e.g. with 849 HTTP_HPACK_DECOMPRESSION_FAILED), clients MAY establish a new 850 connection and retry any 0-RTT requests using the settings sent by 851 the server on the closed connection. (This assumes that only 852 requests that are safe to retry are sent in 0-RTT.) If the 853 connection was closed before the SETTINGS frame was received, clients 854 SHOULD discard any cached values and use the defaults above on the 855 next connection. 857 4.2.6. PUSH_PROMISE 859 The PUSH_PROMISE frame (type=0x05) is used to carry a request header 860 set from server to client, as in HTTP/2. The PUSH_PROMISE frame 861 defines a single flag: 863 BLOCKING (0x01): Indicates the stream might need to wait for 864 dependent headers before processing. If 0, the frame can be 865 processed immediately upon receipt. 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Push ID (i) ... 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Header Block (*) ... 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Figure 5: PUSH_PROMISE frame payload 877 The payload consists of: 879 Push ID: A variable-length integer that identifies the server push 880 request. A push ID is used in push stream header (Section 3.4), 881 CANCEL_PUSH frames (Section 4.2.4), and PRIORITY frames 882 (Section 4.2.3). 884 Header Block: QCRAM-compressed request headers for the promised 885 response. See [QCRAM] for more details. 887 A server MUST NOT use a Push ID that is larger than the client has 888 provided in a MAX_PUSH_ID frame (Section 4.2.9). A client MUST treat 889 receipt of a PUSH_PROMISE that contains a larger Push ID than the 890 client has advertised as a connection error of type 891 HTTP_MALFORMED_FRAME. 893 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 894 This allows the server to use the same server push in response to 895 multiple concurrent requests. Referencing the same server push 896 ensures that a PUSH_PROMISE can be made in relation to every response 897 in which server push might be needed without duplicating pushes. 899 A server that uses the same Push ID in multiple PUSH_PROMISE frames 900 MUST include the same header fields each time. The octets of the 901 header block MAY be different due to differing encoding, but the 902 header fields and their values MUST be identical. Note that ordering 903 of header fields is significant. A client MUST treat receipt of a 904 PUSH_PROMISE with conflicting header field values for the same Push 905 ID as a connection error of type HTTP_MALFORMED_FRAME. 907 Allowing duplicate references to the same Push ID is primarily to 908 reduce duplication caused by concurrent requests. A server SHOULD 909 avoid reusing a Push ID over a long period. Clients are likely to 910 consume server push responses and not retain them for reuse over 911 time. Clients that see a PUSH_PROMISE that uses a Push ID that they 912 have since consumed and discarded are forced to ignore the 913 PUSH_PROMISE. 915 4.2.7. GOAWAY 917 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 918 a connection by a server. GOAWAY allows a server to stop accepting 919 new requests while still finishing processing of previously received 920 requests. This enables administrative actions, like server 921 maintenance. GOAWAY by itself does not close a connection. 923 The GOAWAY frame does not define any flags, and the payload is a QUIC 924 Stream ID for a client-initiated, bidirectional stream encoded as a 925 variable-length integer. A client MUST treat receipt of a GOAWAY 926 frame containing a Stream ID of any other type as a connection error 927 of type HTTP_MALFORMED_FRAME. 929 Clients do not need to send GOAWAY to initiate a graceful shutdown; 930 they simply stop making new requests. A server MUST treat receipt of 931 a GOAWAY frame as a connection error (Section 6) of type 932 HTTP_UNEXPECTED_GOAWAY. 934 The GOAWAY frame applies to the connection, not a specific stream. 935 An endpoint MUST treat a GOAWAY frame on a stream other than the 936 control stream as a connection error (Section 6) of type 937 HTTP_WRONG_STREAM. 939 New client requests might already have been sent before the client 940 receives the server's GOAWAY frame. The GOAWAY frame contains the 941 Stream ID of the last client-initiated request that was or might be 942 processed in this connection, which enables client and server to 943 agree on which requests were accepted prior to the connection 944 shutdown. This identifier MAY be lower than the stream limit 945 identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no 946 requests were processed. Servers SHOULD NOT increase the 947 MAX_STREAM_ID limit after sending a GOAWAY frame. 949 Once sent, the server MUST cancel requests sent on streams with an 950 identifier higher than the included last Stream ID. Clients MUST NOT 951 send new requests on the connection after receiving GOAWAY, although 952 requests might already be in transit. A new connection can be 953 established for new requests. 955 If the client has sent requests on streams with a higher Stream ID 956 than indicated in the GOAWAY frame, those requests are considered 957 cancelled (Section 3.2.3). Clients SHOULD reset any streams above 958 this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also 959 cancel requests on streams below the indicated ID if these requests 960 were not processed. 962 Requests on Stream IDs less than or equal to the Stream ID in the 963 GOAWAY frame might have been processed; their status cannot be known 964 until they are completed successfully, reset individually, or the 965 connection terminates. 967 Servers SHOULD send a GOAWAY frame when the closing of a connection 968 is known in advance, even if the advance notice is small, so that the 969 remote peer can know whether a stream has been partially processed or 970 not. For example, if an HTTP client sends a POST at the same time 971 that a server closes a QUIC connection, the client cannot know if the 972 server started to process that POST request if the server does not 973 send a GOAWAY frame to indicate what streams it might have acted on. 975 For unexpected closures caused by error conditions, a QUIC 976 CONNECTION_CLOSE or APPLICATION_CLOSE frame MUST be used. However, a 977 GOAWAY MAY be sent first to provide additional detail to clients and 978 to allow the client to retry requests. Including the GOAWAY frame in 979 the same packet as the QUIC CONNECTION_CLOSE or APPLICATION_CLOSE 980 frame improves the chances of the frame being received by clients. 982 If a connection terminates without a GOAWAY frame, the last Stream ID 983 is effectively the highest possible Stream ID (as determined by 984 QUIC's MAX_STREAM_ID). 986 An endpoint MAY send multiple GOAWAY frames if circumstances change. 987 For instance, an endpoint that sends GOAWAY without an error code 988 during graceful shutdown could subsequently encounter an error 989 condition. The last stream identifier from the last GOAWAY frame 990 received indicates which streams could have been acted upon. A 991 server MUST NOT increase the value they send in the last Stream ID, 992 since clients might already have retried unprocessed requests on 993 another connection. 995 A client that is unable to retry requests loses all requests that are 996 in flight when the server closes the connection. A server that is 997 attempting to gracefully shut down a connection SHOULD send an 998 initial GOAWAY frame with the last Stream ID set to the current value 999 of QUIC's MAX_STREAM_ID and SHOULD NOT increase the MAX_STREAM_ID 1000 thereafter. This signals to the client that a shutdown is imminent 1001 and that initiating further requests is prohibited. After allowing 1002 time for any in-flight requests (at least one round-trip time), the 1003 server MAY send another GOAWAY frame with an updated last Stream ID. 1004 This ensures that a connection can be cleanly shut down without 1005 losing requests. 1007 Once all requests on streams at or below the identified stream number 1008 have been completed or cancelled, and all promised server push 1009 responses associated with those requests have been completed or 1010 cancelled, the connection can be closed using an Immediate Close (see 1011 [QUIC-TRANSPORT]). An endpoint that completes a graceful shutdown 1012 SHOULD use the QUIC APPLICATION_CLOSE frame with the HTTP_NO_ERROR 1013 code. 1015 4.2.8. HEADER_ACK 1017 The HEADER_ACK frame (type=0x8) is used by header compression to 1018 ensure consistency. The frames are sent from the QCRAM decoder to 1019 the QCRAM encoder; that is, the server sends them to the client to 1020 acknowledge processing of the client's header blocks, and the client 1021 sends them to the server to acknowledge processing of the server's 1022 header blocks. 1024 The HEADER_ACK frame is sent on the Control Stream when the QCRAM 1025 decoder has fully processed a header block. It is used by the peer's 1026 QCRAM encoder to determine whether subsequent indexed representations 1027 that might reference that block are vulnerable to head-of-line 1028 blocking, and to prevent eviction races. See [QCRAM] for more 1029 details on the use of this information. 1031 The HEADER_ACK frame indicates the stream on which the header block 1032 was processed by encoding the Stream ID as a variable-length integer. 1033 The same Stream ID can be identified multiple times, as multiple 1034 header-containing blocks can be sent on a single stream in the case 1035 of intermediate responses, trailers, pushed requests, etc. as well as 1036 on the Control Streams. Since header frames on each stream are 1037 received and processed in order, this gives the encoder precise 1038 feedback on which header blocks within a stream have been fully 1039 processed. 1041 0 1 2 3 4 5 6 7 1042 +---+---+---+---+---+---+---+---+ 1043 | Stream ID (i) ... 1044 +---+---+---+---+---+---+---+---+ 1046 HEADER_ACK frame 1048 The HEADER_ACK frame does not define any flags. 1050 4.2.9. MAX_PUSH_ID 1052 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 1053 number of server pushes that the server can initiate. This sets the 1054 maximum value for a Push ID that the server can use in a PUSH_PROMISE 1055 frame. Consequently, this also limits the number of push streams 1056 that the server can initiate in addition to the limit set by the QUIC 1057 MAX_STREAM_ID frame. 1059 The MAX_PUSH_ID frame is always sent on a control stream. Receipt of 1060 a MAX_PUSH_ID frame on any other stream MUST be treated as a 1061 connection error of type HTTP_WRONG_STREAM. 1063 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1064 receipt of a MAX_PUSH_ID frame as a connection error of type 1065 HTTP_MALFORMED_FRAME. 1067 The maximum Push ID is unset when a connection is created, meaning 1068 that a server cannot push until it receives a MAX_PUSH_ID frame. A 1069 client that wishes to manage the number of promised server pushes can 1070 increase the maximum Push ID by sending a MAX_PUSH_ID frame as the 1071 server fulfills or cancels server pushes. 1073 The MAX_PUSH_ID frame has no defined flags. 1075 The MAX_PUSH_ID frame carries a single variable-length integer that 1076 identifies the maximum value for a Push ID that the server can use 1077 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 1078 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 1079 previously received MUST be treated as a connection error of type 1080 HTTP_MALFORMED_FRAME. 1082 A server MUST treat a MAX_PUSH_ID frame payload that does not contain 1083 a single variable-length integer as a connection error of type 1084 HTTP_MALFORMED_FRAME. 1086 5. Connection Management 1088 QUIC connections are persistent. All of the considerations in 1089 Section 9.1 of [RFC7540] apply to the management of QUIC connections. 1091 HTTP clients are expected to use QUIC PING frames to keep connections 1092 open. Servers SHOULD NOT use PING frames to keep a connection open. 1093 A client SHOULD NOT use PING frames for this purpose unless there are 1094 responses outstanding for requests or server pushes. If the client 1095 is not expecting a response from the server, allowing an idle 1096 connection to time out (based on the idle_timeout transport 1097 parameter) is preferred over expending effort maintaining a 1098 connection that might not be needed. A gateway MAY use PING to 1099 maintain connections in anticipation of need rather than incur the 1100 latency cost of connection establishment to servers. 1102 6. Error Handling 1104 QUIC allows the application to abruptly terminate (reset) individual 1105 streams or the entire connection when an error is encountered. These 1106 are referred to as "stream errors" or "connection errors" and are 1107 described in more detail in [QUIC-TRANSPORT]. 1109 This section describes HTTP-specific error codes which can be used to 1110 express the cause of a connection or stream error. 1112 6.1. HTTP/QUIC Error Codes 1114 The following error codes are defined for use in QUIC RST_STREAM, 1115 STOP_SENDING, and CONNECTION_CLOSE frames when using HTTP/QUIC. 1117 STOPPING (0x00): This value is reserved by the transport to be used 1118 in response to QUIC STOP_SENDING frames. 1120 HTTP_NO_ERROR (0x01): No error. This is used when the connection or 1121 stream needs to be closed, but there is no error to signal. 1123 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1124 which the client will not accept on this connection. 1126 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1127 HTTP stack. 1129 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1130 content which the client has cached. 1132 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1133 requested data. 1135 HTTP_HPACK_DECOMPRESSION_FAILED (0x06): HPACK failed to decompress a 1136 frame and cannot continue. 1138 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1139 a CONNECT request was reset or abnormally closed. 1141 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1142 exhibiting a behavior that might be generating excessive load. 1144 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1145 served over HTTP/QUIC. The peer should retry over HTTP/2. 1147 HTTP_WRONG_STREAM (0x0A): A frame was received on stream where it is 1148 not permitted. 1150 HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current 1151 maximum Push ID was referenced. 1153 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1154 different stream headers. 1156 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1157 The frame type is included as the last octet of the error code. 1158 For example, an error in a MAX_PUSH_ID frame would be indicated 1159 with the code (0x10D). 1161 7. Considerations for Transitioning from HTTP/2 1163 HTTP/QUIC is strongly informed by HTTP/2, and bears many 1164 similarities. This section describes the approach taken to design 1165 HTTP/QUIC, points out important differences from HTTP/2, and 1166 describes how to map HTTP/2 extensions into HTTP/QUIC. 1168 HTTP/QUIC begins from the premise that HTTP/2 code reuse is a useful 1169 feature, but not a hard requirement. HTTP/QUIC departs from HTTP/2 1170 primarily where necessary to accommodate the differences in behavior 1171 between QUIC and TCP (lack of ordering, support for streams). We 1172 intend to avoid gratuitous changes which make it difficult or 1173 impossible to build extensions with the same semantics applicable to 1174 both protocols at once. 1176 These departures are noted in this section. 1178 7.1. Streams 1180 HTTP/QUIC permits use of a larger number of streams (2^62-1) than 1181 HTTP/2. The considerations about exhaustion of stream identifier 1182 space apply, though the space is significantly larger such that it is 1183 likely that other limits in QUIC are reached first, such as the limit 1184 on the connection flow control window. 1186 7.2. HTTP Frame Types 1188 Many framing concepts from HTTP/2 can be elided away on QUIC, because 1189 the transport deals with them. Because frames are already on a 1190 stream, they can omit the stream number. Because frames do not block 1191 multiplexing (QUIC's multiplexing occurs below this layer), the 1192 support for variable-maximum-length packets can be removed. Because 1193 stream termination is handled by QUIC, an END_STREAM flag is not 1194 required. 1196 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1197 includes many features (e.g. flow control) which are also present in 1198 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 1199 As a result, several HTTP/2 frame types are not required in HTTP/ 1200 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 1201 has been reserved in order to maximize portability between HTTP/2 and 1202 HTTP/QUIC implementations. However, even equivalent frames between 1203 the two mappings are not identical. 1205 Many of the differences arise from the fact that HTTP/2 provides an 1206 absolute ordering between frames across all streams, while QUIC 1207 provides this guarantee on each stream only. As a result, if a frame 1208 type makes assumptions that frames from different streams will still 1209 be received in the order sent, HTTP/QUIC will break them. 1211 For example, implicit in the HTTP/2 prioritization scheme is the 1212 notion of in-order delivery of priority changes (i.e., dependency 1213 tree mutations): since operations on the dependency tree such as 1214 reparenting a subtree are not commutative, both sender and receiver 1215 must apply them in the same order to ensure that both sides have a 1216 consistent view of the stream dependency tree. HTTP/2 specifies 1217 priority assignments in PRIORITY frames and (optionally) in HEADERS 1218 frames. To achieve in-order delivery of priority changes in HTTP/ 1219 QUIC, PRIORITY frames are sent on the control stream and the PRIORITY 1220 section is removed from the HEADERS frame. 1222 Likewise, HPACK was designed with the assumption of in-order 1223 delivery. A sequence of encoded header blocks must arrive (and be 1224 decoded) at an endpoint in the same order in which they were encoded. 1225 This ensures that the dynamic state at the two endpoints remains in 1226 sync. As a result, HTTP/QUIC uses a modified version of HPACK, 1227 described in [QCRAM]. 1229 Frame type definitions in HTTP/QUIC often use the QUIC variable- 1230 length integer encoding. In particular, Stream IDs use this 1231 encoding, which allow for a larger range of possible values than the 1232 encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier 1233 rather than a Stream ID (e.g. Push IDs in PRIORITY frames). 1234 Redefinition of the encoding of extension frame types might be 1235 necessary if the encoding includes a Stream ID. 1237 Other than this issue, frame type HTTP/2 extensions are typically 1238 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 2 1239 or 3 in HTTP/QUIC. HTTP/QUIC extensions will not assume ordering, 1240 but would not be harmed by ordering, and would be portable to HTTP/2 1241 in the same manner. 1243 Below is a listing of how each HTTP/2 frame type is mapped: 1245 DATA (0x0): Padding is not defined in HTTP/QUIC frames. See 1246 Section 4.2.1. 1248 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 1249 not supported. A separate PRIORITY frame MUST be used. Padding 1250 is not defined in HTTP/QUIC frames. See Section 4.2.2. 1252 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 1253 the control stream and can reference either a Stream ID or a Push 1254 ID. See Section 4.2.3. 1256 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 1257 provides stream lifecycle management. The same code point is used 1258 for the CANCEL_PUSH frame (Section 4.2.4). 1260 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 1261 the connection. See Section 4.2.5 and Section 7.3. 1263 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 1264 instead the push stream references the PUSH_PROMISE frame using a 1265 Push ID. See Section 4.2.6. 1267 PING (0x6): PING frames do not exist, since QUIC provides equivalent 1268 functionality. 1270 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 1271 contain an error code. See Section 4.2.7. 1273 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 1274 provides flow control. 1276 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 1277 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted, and 1278 HEADERS frames can be used in series. 1280 Frame types defined by extensions to HTTP/2 need to be separately 1281 registered for HTTP/QUIC if still applicable. The IDs of frames 1282 defined in [RFC7540] have been reserved for simplicity. See 1283 Section 9.3. 1285 7.3. HTTP/2 SETTINGS Parameters 1287 An important difference from HTTP/2 is that settings are sent once, 1288 at the beginning of the connection, and thereafter cannot change. 1289 This eliminates many corner cases around synchronization of changes. 1291 Some transport-level options that HTTP/2 specifies via the SETTINGS 1292 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 1293 HTTP-level options that are retained in HTTP/QUIC have the same value 1294 as in HTTP/2. 1296 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 1298 SETTINGS_HEADER_TABLE_SIZE: See Section 4.2.5.2. 1300 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 1301 which provides a more granular control over server push. 1303 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 1304 Stream ID as part of its flow control logic. Specifying 1305 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 1307 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 1308 connection flow control window sizes to be specified in the 1309 initial transport handshake. Specifying 1310 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 1312 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 1313 QUIC. Specifying it in the SETTINGS frame is an error. 1315 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.2. 1317 Settings need to be defined separately for HTTP/2 and HTTP/QUIC. The 1318 IDs of settings defined in [RFC7540] have been reserved for 1319 simplicity. See Section 9.4. 1321 7.4. HTTP/2 Error Codes 1323 QUIC has the same concepts of "stream" and "connection" errors that 1324 HTTP/2 provides. However, because the error code space is shared 1325 between multiple components, there is no direct portability of HTTP/2 1326 error codes. 1328 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 1329 HTTP over QUIC error codes as follows: 1331 NO_ERROR (0x0): HTTP_NO_ERROR in Section 6.1. 1333 PROTOCOL_ERROR (0x1): No single mapping. See new 1334 HTTP_MALFORMED_FRAME error codes defined in Section 6.1. 1336 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 6.1. 1338 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 1339 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 1340 from the QUIC layer. 1342 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 1343 SETTINGS is defined. 1345 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 1346 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 1347 from the QUIC layer. 1349 FRAME_SIZE_ERROR (0x6) No single mapping. See new error codes 1350 defined in Section 6.1. 1352 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 1353 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 1354 QUIC layer. 1356 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 1358 COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in 1359 Section 6.1. 1361 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 1363 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 1365 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 1366 provide sufficient security on all connections. 1368 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 1370 Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. 1371 See Section 9.5. 1373 8. Security Considerations 1375 The security considerations of HTTP over QUIC should be comparable to 1376 those of HTTP/2. 1378 The modified SETTINGS format contains nested length elements, which 1379 could pose a security risk to an uncautious implementer. A SETTINGS 1380 frame parser MUST ensure that the length of the frame exactly matches 1381 the length of the settings it contains. 1383 9. IANA Considerations 1385 9.1. Registration of HTTP/QUIC Identification String 1387 This document creates a new registration for the identification of 1388 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 1389 Protocol IDs" registry established in [RFC7301]. 1391 The "hq" string identifies HTTP/QUIC: 1393 Protocol: HTTP over QUIC 1395 Identification Sequence: 0x68 0x71 ("hq") 1397 Specification: This document 1399 9.2. Registration of QUIC Version Hint Alt-Svc Parameter 1401 This document creates a new registration for version-negotiation 1402 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1403 registry established in [RFC7838]. 1405 Parameter: "quic" 1407 Specification: This document, Section 2.1.1 1409 9.3. Frame Types 1411 This document establishes a registry for HTTP/QUIC frame type codes. 1412 The "HTTP/QUIC Frame Type" registry manages an 8-bit space. The 1413 "HTTP/QUIC Frame Type" registry operates under either of the "IETF 1414 Review" or "IESG Approval" policies [RFC8126] for values between 0x00 1415 and 0xef, with values between 0xf0 and 0xff being reserved for 1416 Experimental Use. 1418 While this registry is separate from the "HTTP/2 Frame Type" registry 1419 defined in [RFC7540], it is preferable that the assignments parallel 1420 each other. If an entry is present in only one registry, every 1421 effort SHOULD be made to avoid assigning the corresponding value to 1422 an unrelated operation. 1424 New entries in this registry require the following information: 1426 Frame Type: A name or label for the frame type. 1428 Code: The 8-bit code assigned to the frame type. 1430 Specification: A reference to a specification that includes a 1431 description of the frame layout, its semantics, and flags that the 1432 frame type uses, including any parts of the frame that are 1433 conditionally present based on the value of flags. 1435 The entries in the following table are registered by this document. 1437 +--------------+------+---------------------+ 1438 | Frame Type | Code | Specification | 1439 +--------------+------+---------------------+ 1440 | DATA | 0x0 | Section 4.2.1 | 1441 | | | | 1442 | HEADERS | 0x1 | Section 4.2.2 | 1443 | | | | 1444 | PRIORITY | 0x2 | Section 4.2.3 | 1445 | | | | 1446 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1447 | | | | 1448 | SETTINGS | 0x4 | Section 4.2.5 | 1449 | | | | 1450 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1451 | | | | 1452 | Reserved | 0x6 | N/A | 1453 | | | | 1454 | GOAWAY | 0x7 | Section 4.2.7 | 1455 | | | | 1456 | HEADER_ACK | 0x8 | {{frame-header-ack} | 1457 | | | | 1458 | Reserved | 0x9 | N/A | 1459 | | | | 1460 | MAX_PUSH_ID | 0xD | Section 4.2.9 | 1461 +--------------+------+---------------------+ 1463 9.4. Settings Parameters 1465 This document establishes a registry for HTTP/QUIC settings. The 1466 "HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC 1467 Settings" registry operates under the "Expert Review" policy 1468 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1469 between and 0xf000 and 0xffff being reserved for Experimental Use. 1470 The designated experts are the same as those for the "HTTP/2 1471 Settings" registry defined in [RFC7540]. 1473 While this registry is separate from the "HTTP/2 Settings" registry 1474 defined in [RFC7540], it is preferable that the assignments parallel 1475 each other. If an entry is present in only one registry, every 1476 effort SHOULD be made to avoid assigning the corresponding value to 1477 an unrelated operation. 1479 New registrations are advised to provide the following information: 1481 Name: A symbolic name for the setting. Specifying a setting name is 1482 optional. 1484 Code: The 16-bit code assigned to the setting. 1486 Specification: An optional reference to a specification that 1487 describes the use of the setting. 1489 The entries in the following table are registered by this document. 1491 +----------------------+------+-----------------+ 1492 | Setting Name | Code | Specification | 1493 +----------------------+------+-----------------+ 1494 | HEADER_TABLE_SIZE | 0x1 | Section 4.2.5.2 | 1495 | | | | 1496 | Reserved | 0x2 | N/A | 1497 | | | | 1498 | Reserved | 0x3 | N/A | 1499 | | | | 1500 | Reserved | 0x4 | N/A | 1501 | | | | 1502 | Reserved | 0x5 | N/A | 1503 | | | | 1504 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.2 | 1505 +----------------------+------+-----------------+ 1507 9.5. Error Codes 1509 This document establishes a registry for HTTP/QUIC error codes. The 1510 "HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/ 1511 QUIC Error Code" registry operates under the "Expert Review" policy 1512 [RFC8126]. 1514 Registrations for error codes are required to include a description 1515 of the error code. An expert reviewer is advised to examine new 1516 registrations for possible duplication with existing error codes. 1517 Use of existing registrations is to be encouraged, but not mandated. 1519 New registrations are advised to provide the following information: 1521 Name: A name for the error code. Specifying an error code name is 1522 optional. 1524 Code: The 16-bit error code value. 1526 Description: A brief description of the error code semantics, longer 1527 if no detailed specification is provided. 1529 Specification: An optional reference for a specification that 1530 defines the error code. 1532 The entries in the following table are registered by this document. 1534 +----------------------------+--------+------------+----------------+ 1535 | Name | Code | Descriptio | Specification | 1536 | | | n | | 1537 +----------------------------+--------+------------+----------------+ 1538 | STOPPING | 0x0000 | Reserved | [QUIC-TRANSPOR | 1539 | | | by QUIC | T] | 1540 | | | | | 1541 | HTTP_NO_ERROR | 0x0001 | No error | Section 6.1 | 1542 | | | | | 1543 | HTTP_PUSH_REFUSED | 0x0002 | Client | Section 6.1 | 1544 | | | refused | | 1545 | | | pushed | | 1546 | | | content | | 1547 | | | | | 1548 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 6.1 | 1549 | | | error | | 1550 | | | | | 1551 | HTTP_PUSH_ALREADY_IN_CACHE | 0x0004 | Pushed | Section 6.1 | 1552 | | | content | | 1553 | | | already | | 1554 | | | cached | | 1555 | | | | | 1556 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 6.1 | 1557 | | | longer | | 1558 | | | needed | | 1559 | | | | | 1560 | HTTP_HPACK_DECOMPRESSION_F | 0x0006 | HPACK | Section 6.1 | 1561 | AILED | | cannot | | 1562 | | | continue | | 1563 | | | | | 1564 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset | Section 6.1 | 1565 | | | or error | | 1566 | | | on CONNECT | | 1567 | | | request | | 1568 | | | | | 1569 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 6.1 | 1570 | | | generating | | 1571 | | | excessive | | 1572 | | | load | | 1573 | | | | | 1574 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 6.1 | 1575 | | | HTTP/2 | | 1576 | | | | | 1577 | HTTP_WRONG_STREAM | 0x000A | A frame | Section 6.1 | 1578 | | | was sent | | 1579 | | | on the | | 1580 | | | wrong | | 1581 | | | stream | | 1582 | | | | | 1583 | HTTP_PUSH_LIMIT_EXCEEDED | 0x000B | Maximum | Section 6.1 | 1584 | | | Push ID | | 1585 | | | exceeded | | 1586 | | | | | 1587 | HTTP_DUPLICATE_PUSH | 0x000C | Push ID | Section 6.1 | 1588 | | | was | | 1589 | | | fulfilled | | 1590 | | | multiple | | 1591 | | | times | | 1592 | | | | | 1593 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 6.1 | 1594 | | | frame | | 1595 | | | formatting | | 1596 | | | or use | | 1597 +----------------------------+--------+------------+----------------+ 1599 10. References 1601 10.1. Normative References 1603 [QCRAM] Krasic, C., Bishop, M., and A. Frindell, Ed., "Header 1604 Compression for HTTP over QUIC", draft-ietf-quic-qcram-00 1605 (work in progress), March 2018. 1607 [QUIC-TRANSPORT] 1608 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1609 Multiplexed and Secure Transport", draft-ietf-quic- 1610 transport-10 (work in progress), March 2018. 1612 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1613 RFC 793, DOI 10.17487/RFC0793, September 1981, 1614 . 1616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1617 Requirement Levels", BCP 14, RFC 2119, 1618 DOI 10.17487/RFC2119, March 1997, 1619 . 1621 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1622 Specifications: ABNF", STD 68, RFC 5234, 1623 DOI 10.17487/RFC5234, January 2008, 1624 . 1626 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1627 Extensions: Extension Definitions", RFC 6066, 1628 DOI 10.17487/RFC6066, January 2011, 1629 . 1631 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1632 Protocol (HTTP/1.1): Message Syntax and Routing", 1633 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1634 . 1636 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1637 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1638 DOI 10.17487/RFC7231, June 2014, 1639 . 1641 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1642 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1643 DOI 10.17487/RFC7540, May 2015, 1644 . 1646 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1647 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1648 April 2016, . 1650 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1651 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1652 May 2017, . 1654 10.2. Informative References 1656 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1657 "Transport Layer Security (TLS) Application-Layer Protocol 1658 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1659 July 2014, . 1661 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1662 Writing an IANA Considerations Section in RFCs", BCP 26, 1663 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1664 . 1666 10.3. URIs 1668 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1670 [2] https://github.com/quicwg 1672 [3] https://github.com/quicwg/base-drafts/labels/-http 1674 Appendix A. Contributors 1676 The original authors of this specification were Robbie Shade and Mike 1677 Warres. 1679 A substantial portion of Mike's contribution was supported by 1680 Microsoft during his employment there. 1682 Appendix B. Change Log 1684 *RFC Editor's Note:* Please remove this section prior to 1685 publication of a final version of this document. 1687 B.1. Since draft-ietf-quic-http-09 1689 o Selected QCRAM for header compression (#228, #1117) 1691 o The server_name TLS extension is now mandatory (#296, #495) 1693 o Specified handling of unsupported versions in Alt-Svc (#1093, 1694 #1097) 1696 B.2. Since draft-ietf-quic-http-08 1698 o Clarified connection coalescing rules (#940, #1024) 1700 B.3. Since draft-ietf-quic-http-07 1702 o Changes for integer encodings in QUIC (#595,#905) 1704 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 1706 o Improvement to the description of GOAWAY (#604, #898) 1708 o Improve description of server push usage (#947, #950, #957) 1710 B.4. Since draft-ietf-quic-http-06 1712 o Track changes in QUIC error code usage (#485) 1714 B.5. Since draft-ietf-quic-http-05 1716 o Made push ID sequential, add MAX_PUSH_ID, remove 1717 SETTINGS_ENABLE_PUSH (#709) 1719 o Guidance about keep-alive and QUIC PINGs (#729) 1721 o Expanded text on GOAWAY and cancellation (#757) 1723 B.6. Since draft-ietf-quic-http-04 1725 o Cite RFC 5234 (#404) 1727 o Return to a single stream per request (#245,#557) 1729 o Use separate frame type and settings registries from HTTP/2 (#81) 1731 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 1733 o Restored GOAWAY (#696) 1735 o Identify server push using Push ID rather than a stream ID 1736 (#702,#281) 1738 o DATA frames cannot be empty (#700) 1740 B.7. Since draft-ietf-quic-http-03 1742 None. 1744 B.8. Since draft-ietf-quic-http-02 1746 o Track changes in transport draft 1748 B.9. Since draft-ietf-quic-http-01 1750 o SETTINGS changes (#181): 1752 * SETTINGS can be sent only once at the start of a connection; no 1753 changes thereafter 1755 * SETTINGS_ACK removed 1757 * Settings can only occur in the SETTINGS frame a single time 1758 * Boolean format updated 1760 o Alt-Svc parameter changed from "v" to "quic"; format updated 1761 (#229) 1763 o Closing the connection control stream or any message control 1764 stream is a fatal error (#176) 1766 o HPACK Sequence counter can wrap (#173) 1768 o 0-RTT guidance added 1770 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 1771 added (#127,#242) 1773 B.10. Since draft-ietf-quic-http-00 1775 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 1777 o Changed from using HTTP/2 framing within Stream 3 to new framing 1778 format and two-stream-per-request model (#71,#72,#73) 1780 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 1781 settings-01 1783 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 1784 order (#75) 1786 o Described CONNECT pseudo-method (#95) 1788 o Updated ALPN token and Alt-Svc guidance (#13,#87) 1790 o Application-layer-defined error codes (#19,#74) 1792 B.11. Since draft-shade-quic-http2-mapping-00 1794 o Adopted as base for draft-ietf-quic-http 1796 o Updated authors/editors list 1798 Author's Address 1800 Mike Bishop (editor) 1801 Akamai 1803 Email: mbishop@evequefou.be