idnits 2.17.1 draft-ietf-quic-http-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2018) is 2200 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 1695 -- Looks like a reference, but probably isn't: '2' on line 1697 -- Looks like a reference, but probably isn't: '3' on line 1699 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-11 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 5 errors (**), 0 flaws (~~), 3 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 April 17, 2018 5 Expires: October 19, 2018 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-11 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 October 19, 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 . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14 85 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16 86 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 25 95 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 26 96 7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 26 98 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 28 99 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 29 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 . . . 31 104 9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 31 105 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 32 106 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 33 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 109 10.2. Informative References . . . . . . . . . . . . . . . . . 36 110 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 111 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 112 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37 113 B.1. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 37 114 B.2. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 37 115 B.3. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 37 116 B.4. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 37 117 B.5. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37 118 B.6. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37 119 B.7. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 38 120 B.8. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 38 121 B.9. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 38 122 B.10. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 38 123 B.11. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 39 124 B.12. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 39 125 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 127 1. Introduction 129 The QUIC transport protocol has several features that are desirable 130 in a transport for HTTP, such as stream multiplexing, per-stream flow 131 control, and low-latency connection establishment. This document 132 describes a mapping of HTTP semantics over QUIC, drawing heavily on 133 the existing TCP mapping, HTTP/2. Specifically, this document 134 identifies HTTP/2 features that are subsumed by QUIC, and describes 135 how the other features can be implemented atop QUIC. 137 QUIC is described in [QUIC-TRANSPORT]. For a full description of 138 HTTP/2, see [RFC7540]. 140 1.1. Notational Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 149 defined in [RFC5234]. 151 This document uses the variable-length integer encoding from 152 [QUIC-TRANSPORT]. 154 Protocol elements called "frames" exist in both this document and 155 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 156 the frame name will be prefaced with "QUIC." For example, "QUIC 157 APPLICATION_CLOSE frames." References without this preface refer to 158 frames defined in Section 4.2. 160 2. Connection Setup and Management 162 2.1. Discovering an HTTP/QUIC Endpoint 164 An HTTP origin advertises the availability of an equivalent HTTP/QUIC 165 endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC 166 frame ([RFC7838]), using the ALPN token defined in Section 2.2. 168 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 169 response that HTTP/QUIC was available on UDP port 50781 at the same 170 hostname by including the following header in any response: 172 Alt-Svc: hq=":50781" 174 On receipt of an Alt-Svc record indicating HTTP/QUIC support, a 175 client MAY attempt to establish a QUIC connection to the indicated 176 host and port and, if successful, send HTTP requests using the 177 mapping described in this document. 179 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 180 connection establishment failure, in which case the client SHOULD 181 continue using the existing connection or try another alternative 182 endpoint offered by the origin. 184 Servers MAY serve HTTP/QUIC on any UDP port, since an alternative 185 always includes an explicit 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 QPACK header compression as described in [QPACK], 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 in a similar manner to [RFC7540], but 499 uses different mechanisms. During connection establishment, the 500 client enables server push by sending a MAX_PUSH_ID frame (see 501 Section 4.2.9). A server cannot use server push until it receives a 502 MAX_PUSH_ID frame. 504 As with server push for HTTP/2, the server initiates a server push by 505 sending a PUSH_PROMISE frame (see Section 4.2.6) that includes 506 request headers for the promised request. Promised requests MUST 507 conform to the requirements in Section 8.2 of [RFC7540]. 509 The PUSH_PROMISE frame is sent on the client-initiated, bidirectional 510 stream that carried the request that generated the push. This allows 511 the server push to be associated with a request. Ordering of a 512 PUSH_PROMISE in relation to certain parts of the response is 513 important (see Section 8.2.1 of [RFC7540]). 515 Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it 516 contains a Push ID. The Push ID uniquely identifies a server push. 517 This allows a server to fulfill promises in the order that best suits 518 its needs. 520 When a server later fulfills a promise, the server push response is 521 conveyed on a push stream. A push stream is a server-initiated, 522 unidirectional stream. A push stream identifies the Push ID of the 523 promise that it fulfills, encoded as a variable-length integer. 525 A server SHOULD use Push IDs sequentially, starting at 0. A client 526 uses the MAX_PUSH_ID frame (Section 4.2.9) to limit the number of 527 pushes that a server can promise. A client MUST treat receipt of a 528 push stream with a Push ID that is greater than the maximum Push ID 529 as a connection error of type HTTP_PUSH_LIMIT_EXCEEDED. 531 If a promised server push is not needed by the client, the client 532 SHOULD send a CANCEL_PUSH frame; if the push stream is already open, 533 a QUIC STOP_SENDING frame with an appropriate error code can be used 534 instead (e.g., HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see 535 Section 6). This asks the server not to transfer the data and 536 indicates that it will be discarded upon receipt. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Push ID (i) ... 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 1: Push Stream Header 546 Push streams always begin with a header containing the Push ID. Each 547 Push ID MUST only be used once in a push stream header. If a push 548 stream header includes a Push ID that was used in another push stream 549 header, the client MUST treat this as a connection error of type 550 HTTP_DUPLICATE_PUSH. The same Push ID can be used in multiple 551 PUSH_PROMISE frames (see Section 4.2.6). 553 After the header, a push stream contains a response (Section 3.2), 554 with response headers, a response body (if any) carried by DATA 555 frames, then trailers (if any) carried by HEADERS frames. 557 4. HTTP Framing Layer 559 Frames are used on each stream. This section describes HTTP framing 560 in QUIC and highlights some differences from HTTP/2 framing. For 561 more detail on differences from HTTP/2, see Section 7.2. 563 4.1. Frame Layout 565 All frames have the following format: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Length (i) ... 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type (8) | Flags (8) | Frame Payload (*) ... 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 2: HTTP/QUIC frame format 577 A frame includes the following fields: 579 Length: A variable-length integer that describes the length of the 580 Frame Payload. This length does not include the frame header. 582 Type: An 8-bit type for the frame. 584 Flags: An 8-bit field containing flags. The Type field determines 585 the semantics of flags. 587 Frame Payload: A payload, the semantics of which are determined by 588 the Type field. 590 4.2. Frame Definitions 592 4.2.1. DATA 594 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 595 octets associated with an HTTP request or response payload. 597 The DATA frame defines no flags. 599 DATA frames MUST be associated with an HTTP request or response. If 600 a DATA frame is received on either control stream, the recipient MUST 601 respond with a connection error (Section 6) of type 602 HTTP_WRONG_STREAM. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Payload (*) ... 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Figure 3: DATA frame payload 612 DATA frames MUST contain a non-zero-length payload. If a DATA frame 613 is received with a payload length of zero, the recipient MUST respond 614 with a stream error (Section 6) of type HTTP_MALFORMED_FRAME. 616 4.2.2. HEADERS 618 The HEADERS frame (type=0x1) is used to carry a header block, 619 compressed using QPACK. See [QPACK] for more details. 621 The HEADERS frame defines a single flag: 623 BLOCKING (0x01): Indicates the stream might need to wait for 624 dependent headers before processing. If 0, the frame can be 625 processed immediately upon receipt. 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Header Block (*) ... 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Figure 4: HEADERS frame payload 635 HEADERS frames can be sent on the Control Stream as well as on 636 request / push streams. The value of BLOCKING MUST be 0 for HEADERS 637 frames on the Control Stream, since they can only depend on previous 638 HEADERS on the same stream. 640 4.2.3. PRIORITY 642 The PRIORITY (type=0x02) frame specifies the sender-advised priority 643 of a stream and is substantially different in format from [RFC7540]. 644 In order to ensure that prioritization is processed in a consistent 645 order, PRIORITY frames MUST be sent on the control stream. A 646 PRIORITY frame sent on any other stream MUST be treated as a 647 HTTP_WRONG_STREAM error. 649 The format has been modified to accommodate not being sent on a 650 request stream, to allow for identification of server pushes, and the 651 larger stream ID space of QUIC. The semantics of the Stream 652 Dependency, Weight, and E flag are otherwise the same as in HTTP/2. 654 The flags defined are: 656 PUSH_PRIORITIZED (0x04): Indicates that the Prioritized Stream is a 657 server push rather than a request. 659 PUSH_DEPENDENT (0x02): Indicates a dependency on a server push. 661 E (0x01): Indicates that the stream dependency is exclusive (see 662 [RFC7540], Section 5.3). 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Prioritized Request ID (i) | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Stream Dependency ID (i) | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Weight (8) | 672 +-+-+-+-+-+-+-+-+ 674 Figure 5: PRIORITY frame payload 676 The PRIORITY frame payload has the following fields: 678 Prioritized Request ID: A variable-length integer that identifies a 679 request. This contains the Stream ID of a request stream when the 680 PUSH_PRIORITIZED flag is clear, or a Push ID when the 681 PUSH_PRIORITIZED flag is set. 683 Stream Dependency ID: A variable-length integer that identifies a 684 dependent request. This contains the Stream ID of a request 685 stream when the PUSH_DEPENDENT flag is clear, or a Push ID when 686 the PUSH_DEPENDENT flag is set. A request Stream ID of 0 687 indicates a dependency on the root stream. For details of 688 dependencies, see Section 3.3 and [RFC7540], Section 5.3. 690 Weight: An unsigned 8-bit integer representing a priority weight for 691 the stream (see [RFC7540], Section 5.3). Add one to the value to 692 obtain a weight between 1 and 256. 694 A PRIORITY frame identifies a request to prioritize, and a request 695 upon which that request is dependent. A Prioritized Request ID or 696 Stream Dependency ID identifies a client-initiated request using the 697 corresponding stream ID when the corresponding PUSH_PRIORITIZED or 698 PUSH_DEPENDENT flag is not set. Setting the PUSH_PRIORITIZED or 699 PUSH_DEPENDENT flag causes the Prioritized Request ID or Stream 700 Dependency ID (respectively) to identify a server push using a Push 701 ID (see Section 4.2.6 for details). 703 A PRIORITY frame MAY identify a Stream Dependency ID using a Stream 704 ID of 0; as in [RFC7540], this makes the request dependent on the 705 root of the dependency tree. 707 A PRIORITY frame MUST identify a client-initiated, bidirectional 708 stream. A server MUST treat receipt of PRIORITY frame with a Stream 709 ID of any other type as a connection error of type 710 HTTP_MALFORMED_FRAME. 712 Stream ID 0 cannot be reprioritized. A Prioritized Request ID that 713 identifies Stream 0 MUST be treated as a connection error of type 714 HTTP_MALFORMED_FRAME. 716 A PRIORITY frame that does not reference a request MUST be treated as 717 a HTTP_MALFORMED_FRAME error, unless it references Stream ID 0. A 718 PRIORITY that sets a PUSH_PRIORITIZED or PUSH_DEPENDENT flag, but 719 then references a non-existent Push ID MUST be treated as a 720 HTTP_MALFORMED_FRAME error. 722 A PRIORITY frame MUST contain only the identified fields. A PRIORITY 723 frame that contains more or fewer fields, or a PRIORITY frame that 724 includes a truncated integer encoding MUST be treated as a connection 725 error of type HTTP_MALFORMED_FRAME. 727 4.2.4. CANCEL_PUSH 729 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of 730 server push prior to the push stream being created. The CANCEL_PUSH 731 frame identifies a server push request by Push ID (see Section 4.2.6) 732 using a variable-length integer. 734 When a server receives this frame, it aborts sending the response for 735 the identified server push. If the server has not yet started to 736 send the server push, it can use the receipt of a CANCEL_PUSH frame 737 to avoid opening a stream. If the push stream has been opened by the 738 server, the server SHOULD sent a QUIC RST_STREAM frame on those 739 streams and cease transmission of the response. 741 A server can send this frame to indicate that it won't be sending a 742 response prior to creation of a push stream. Once the push stream 743 has been created, sending CANCEL_PUSH has no effect on the state of 744 the push stream. A QUIC RST_STREAM frame SHOULD be used instead to 745 cancel transmission of the server push response. 747 A CANCEL_PUSH frame is sent on the control stream. Sending a 748 CANCEL_PUSH frame on a stream other than the control stream MUST be 749 treated as a stream error of type HTTP_WRONG_STREAM. 751 The CANCEL_PUSH frame has no defined flags. 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Push ID (i) ... 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Figure 6: CANCEL_PUSH frame payload 761 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 762 integer. The Push ID identifies the server push that is being 763 cancelled (see Section 4.2.6). 765 If the client receives a CANCEL_PUSH frame, that frame might identify 766 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 768 An endpoint MUST treat a CANCEL_PUSH frame which does not contain 769 exactly one properly-formatted variable-length integer as a 770 connection error of type HTTP_MALFORMED_FRAME. 772 4.2.5. SETTINGS 774 The SETTINGS frame (type=0x4) conveys configuration parameters that 775 affect how endpoints communicate, such as preferences and constraints 776 on peer behavior, and is different from [RFC7540]. Individually, a 777 SETTINGS parameter can also be referred to as a "setting". 779 SETTINGS parameters are not negotiated; they describe characteristics 780 of the sending peer, which can be used by the receiving peer. 781 However, a negotiation can be implied by the use of SETTINGS - a peer 782 uses SETTINGS to advertise a set of supported values. The recipient 783 can then choose which entries from this list are also acceptable and 784 proceed with the value it has chosen. (This choice could be 785 announced in a field of an extension frame, or in its own value in 786 SETTINGS.) 788 Different values for the same parameter can be advertised by each 789 peer. For example, a client might be willing to consume very large 790 response headers, while servers are more cautious about request size. 792 Parameters MUST NOT occur more than once. A receiver MAY treat the 793 presence of the same parameter more than once as a connection error 794 of type HTTP_MALFORMED_FRAME. 796 The SETTINGS frame defines no flags. 798 The payload of a SETTINGS frame consists of zero or more parameters, 799 each consisting of an unsigned 16-bit setting identifier and a 800 length-prefixed binary value. 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Identifier (16) | Length (i) ... 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Contents (?) ... 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Figure 7: SETTINGS value format 812 A zero-length content indicates that the setting value is a Boolean 813 and true. False is indicated by the absence of the setting. 815 Non-zero-length values MUST be compared against the remaining length 816 of the SETTINGS frame. Any value which purports to cross the end of 817 the frame MUST cause the SETTINGS frame to be considered malformed 818 and trigger a connection error of type HTTP_MALFORMED_FRAME. 820 An implementation MUST ignore the contents for any SETTINGS 821 identifier it does not understand. 823 SETTINGS frames always apply to a connection, never a single stream. 824 A SETTINGS frame MUST be sent as the first frame of either control 825 stream (see Section 3) by each peer, and MUST NOT be sent 826 subsequently or on any other stream. If an endpoint receives an 827 SETTINGS frame on a different stream, the endpoint MUST respond with 828 a connection error of type HTTP_WRONG_STREAM. If an endpoint 829 receives a second SETTINGS frame, the endpoint MUST respond with a 830 connection error of type HTTP_MALFORMED_FRAME. 832 The SETTINGS frame affects connection state. A badly formed or 833 incomplete SETTINGS frame MUST be treated as a connection error 834 (Section 6) of type HTTP_MALFORMED_FRAME. 836 4.2.5.1. Integer encoding 838 Settings which are integers use the QUIC variable-length integer 839 encoding. 841 4.2.5.2. Defined SETTINGS Parameters 843 The following settings are defined in HTTP/QUIC: 845 SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of 846 2^30 - 1. 848 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value 849 of 2^30 - 1 851 4.2.5.3. Initial SETTINGS Values 853 When a 0-RTT QUIC connection is being used, the client's initial 854 requests will be sent before the arrival of the server's SETTINGS 855 frame. Clients MUST store the settings the server provided in the 856 session being resumed and MUST comply with stored settings until the 857 server's current settings are received. 859 Servers MAY continue processing data from clients which exceed its 860 current configuration during the initial flight. In this case, the 861 client MUST apply the new settings immediately upon receipt. 863 When a 1-RTT QUIC connection is being used, the client MUST NOT send 864 requests prior to receiving and processing the server's SETTINGS 865 frame. 867 4.2.6. PUSH_PROMISE 869 The PUSH_PROMISE frame (type=0x05) is used to carry a request header 870 set from server to client, as in HTTP/2. The PUSH_PROMISE frame 871 defines a single flag: 873 BLOCKING (0x01): Indicates the stream might need to wait for 874 dependent headers before processing. If 0, the frame can be 875 processed immediately upon receipt. 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Push ID (i) ... 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Header Block (*) ... 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 Figure 8: PUSH_PROMISE frame payload 887 The payload consists of: 889 Push ID: A variable-length integer that identifies the server push 890 request. A push ID is used in push stream header (Section 3.4), 891 CANCEL_PUSH frames (Section 4.2.4), and PRIORITY frames 892 (Section 4.2.3). 894 Header Block: QPACK-compressed request headers for the promised 895 response. See [QPACK] for more details. 897 A server MUST NOT use a Push ID that is larger than the client has 898 provided in a MAX_PUSH_ID frame (Section 4.2.9). A client MUST treat 899 receipt of a PUSH_PROMISE that contains a larger Push ID than the 900 client has advertised as a connection error of type 901 HTTP_MALFORMED_FRAME. 903 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 904 This allows the server to use the same server push in response to 905 multiple concurrent requests. Referencing the same server push 906 ensures that a PUSH_PROMISE can be made in relation to every response 907 in which server push might be needed without duplicating pushes. 909 A server that uses the same Push ID in multiple PUSH_PROMISE frames 910 MUST include the same header fields each time. The octets of the 911 header block MAY be different due to differing encoding, but the 912 header fields and their values MUST be identical. Note that ordering 913 of header fields is significant. A client MUST treat receipt of a 914 PUSH_PROMISE with conflicting header field values for the same Push 915 ID as a connection error of type HTTP_MALFORMED_FRAME. 917 Allowing duplicate references to the same Push ID is primarily to 918 reduce duplication caused by concurrent requests. A server SHOULD 919 avoid reusing a Push ID over a long period. Clients are likely to 920 consume server push responses and not retain them for reuse over 921 time. Clients that see a PUSH_PROMISE that uses a Push ID that they 922 have since consumed and discarded are forced to ignore the 923 PUSH_PROMISE. 925 4.2.7. GOAWAY 927 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 928 a connection by a server. GOAWAY allows a server to stop accepting 929 new requests while still finishing processing of previously received 930 requests. This enables administrative actions, like server 931 maintenance. GOAWAY by itself does not close a connection. 933 The GOAWAY frame does not define any flags. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Stream ID (i) ... 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Figure 9: GOAWAY frame payload 943 The GOAWAY frame carries a QUIC Stream ID for a client-initiated, 944 bidirectional stream encoded as a variable-length integer. A client 945 MUST treat receipt of a GOAWAY frame containing a Stream ID of any 946 other type as a connection error of type HTTP_MALFORMED_FRAME. 948 Clients do not need to send GOAWAY to initiate a graceful shutdown; 949 they simply stop making new requests. A server MUST treat receipt of 950 a GOAWAY frame as a connection error (Section 6) of type 951 HTTP_UNEXPECTED_GOAWAY. 953 The GOAWAY frame applies to the connection, not a specific stream. 954 An endpoint MUST treat a GOAWAY frame on a stream other than the 955 control stream as a connection error (Section 6) of type 956 HTTP_WRONG_STREAM. 958 New client requests might already have been sent before the client 959 receives the server's GOAWAY frame. The GOAWAY frame contains the 960 Stream ID of the last client-initiated request that was or might be 961 processed in this connection, which enables client and server to 962 agree on which requests were accepted prior to the connection 963 shutdown. This identifier MAY be lower than the stream limit 964 identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no 965 requests were processed. Servers SHOULD NOT increase the 966 MAX_STREAM_ID limit after sending a GOAWAY frame. 968 Once sent, the server MUST cancel requests sent on streams with an 969 identifier higher than the included last Stream ID. Clients MUST NOT 970 send new requests on the connection after receiving GOAWAY, although 971 requests might already be in transit. A new connection can be 972 established for new requests. 974 If the client has sent requests on streams with a higher Stream ID 975 than indicated in the GOAWAY frame, those requests are considered 976 cancelled (Section 3.2.3). Clients SHOULD reset any streams above 977 this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also 978 cancel requests on streams below the indicated ID if these requests 979 were not processed. 981 Requests on Stream IDs less than or equal to the Stream ID in the 982 GOAWAY frame might have been processed; their status cannot be known 983 until they are completed successfully, reset individually, or the 984 connection terminates. 986 Servers SHOULD send a GOAWAY frame when the closing of a connection 987 is known in advance, even if the advance notice is small, so that the 988 remote peer can know whether a stream has been partially processed or 989 not. For example, if an HTTP client sends a POST at the same time 990 that a server closes a QUIC connection, the client cannot know if the 991 server started to process that POST request if the server does not 992 send a GOAWAY frame to indicate what streams it might have acted on. 994 For unexpected closures caused by error conditions, a QUIC 995 CONNECTION_CLOSE or APPLICATION_CLOSE frame MUST be used. However, a 996 GOAWAY MAY be sent first to provide additional detail to clients and 997 to allow the client to retry requests. Including the GOAWAY frame in 998 the same packet as the QUIC CONNECTION_CLOSE or APPLICATION_CLOSE 999 frame improves the chances of the frame being received by clients. 1001 If a connection terminates without a GOAWAY frame, the last Stream ID 1002 is effectively the highest possible Stream ID (as determined by 1003 QUIC's MAX_STREAM_ID). 1005 An endpoint MAY send multiple GOAWAY frames if circumstances change. 1006 For instance, an endpoint that sends GOAWAY without an error code 1007 during graceful shutdown could subsequently encounter an error 1008 condition. The last stream identifier from the last GOAWAY frame 1009 received indicates which streams could have been acted upon. A 1010 server MUST NOT increase the value they send in the last Stream ID, 1011 since clients might already have retried unprocessed requests on 1012 another connection. 1014 A client that is unable to retry requests loses all requests that are 1015 in flight when the server closes the connection. A server that is 1016 attempting to gracefully shut down a connection SHOULD send an 1017 initial GOAWAY frame with the last Stream ID set to the current value 1018 of QUIC's MAX_STREAM_ID and SHOULD NOT increase the MAX_STREAM_ID 1019 thereafter. This signals to the client that a shutdown is imminent 1020 and that initiating further requests is prohibited. After allowing 1021 time for any in-flight requests (at least one round-trip time), the 1022 server MAY send another GOAWAY frame with an updated last Stream ID. 1023 This ensures that a connection can be cleanly shut down without 1024 losing requests. 1026 Once all requests on streams at or below the identified stream number 1027 have been completed or cancelled, and all promised server push 1028 responses associated with those requests have been completed or 1029 cancelled, the connection can be closed using an Immediate Close (see 1030 [QUIC-TRANSPORT]). An endpoint that completes a graceful shutdown 1031 SHOULD use the QUIC APPLICATION_CLOSE frame with the HTTP_NO_ERROR 1032 code. 1034 4.2.8. HEADER_ACK 1036 The HEADER_ACK frame (type=0x8) is used by header compression to 1037 ensure consistency. The frames are sent from the QPACK decoder to 1038 the QPACK encoder; that is, the server sends them to the client to 1039 acknowledge processing of the client's header blocks, and the client 1040 sends them to the server to acknowledge processing of the server's 1041 header blocks. 1043 The HEADER_ACK frame is sent on the Control Stream when the QPACK 1044 decoder has fully processed a header block. It is used by the peer's 1045 QPACK encoder to determine whether subsequent indexed representations 1046 that might reference that block are vulnerable to head-of-line 1047 blocking, and to prevent eviction races. See [QPACK] for more 1048 details on the use of this information. 1050 The HEADER_ACK frame indicates the stream on which the header block 1051 was processed by encoding the Stream ID as a variable-length integer. 1052 The same Stream ID can be identified multiple times, as multiple 1053 header-containing blocks can be sent on a single stream in the case 1054 of intermediate responses, trailers, pushed requests, etc. as well as 1055 on the Control Streams. Since header frames on each stream are 1056 received and processed in order, this gives the encoder precise 1057 feedback on which header blocks within a stream have been fully 1058 processed. 1060 0 1 2 3 4 5 6 7 1061 +---+---+---+---+---+---+---+---+ 1062 | Stream ID (i) ... 1063 +---+---+---+---+---+---+---+---+ 1065 HEADER_ACK frame 1067 The HEADER_ACK frame does not define any flags. 1069 4.2.9. MAX_PUSH_ID 1071 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 1072 number of server pushes that the server can initiate. This sets the 1073 maximum value for a Push ID that the server can use in a PUSH_PROMISE 1074 frame. Consequently, this also limits the number of push streams 1075 that the server can initiate in addition to the limit set by the QUIC 1076 MAX_STREAM_ID frame. 1078 The MAX_PUSH_ID frame is always sent on a control stream. Receipt of 1079 a MAX_PUSH_ID frame on any other stream MUST be treated as a 1080 connection error of type HTTP_WRONG_STREAM. 1082 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1083 receipt of a MAX_PUSH_ID frame as a connection error of type 1084 HTTP_MALFORMED_FRAME. 1086 The maximum Push ID is unset when a connection is created, meaning 1087 that a server cannot push until it receives a MAX_PUSH_ID frame. A 1088 client that wishes to manage the number of promised server pushes can 1089 increase the maximum Push ID by sending a MAX_PUSH_ID frame as the 1090 server fulfills or cancels server pushes. 1092 The MAX_PUSH_ID frame has no defined flags. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Push ID (i) ... 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Figure 10: MAX_PUSH_ID frame payload 1102 The MAX_PUSH_ID frame carries a single variable-length integer that 1103 identifies the maximum value for a Push ID that the server can use 1104 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 1105 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 1106 previously received MUST be treated as a connection error of type 1107 HTTP_MALFORMED_FRAME. 1109 A server MUST treat a MAX_PUSH_ID frame payload that does not contain 1110 a single variable-length integer as a connection error of type 1111 HTTP_MALFORMED_FRAME. 1113 5. Connection Management 1115 QUIC connections are persistent. All of the considerations in 1116 Section 9.1 of [RFC7540] apply to the management of QUIC connections. 1118 HTTP clients are expected to use QUIC PING frames to keep connections 1119 open. Servers SHOULD NOT use PING frames to keep a connection open. 1120 A client SHOULD NOT use PING frames for this purpose unless there are 1121 responses outstanding for requests or server pushes. If the client 1122 is not expecting a response from the server, allowing an idle 1123 connection to time out (based on the idle_timeout transport 1124 parameter) is preferred over expending effort maintaining a 1125 connection that might not be needed. A gateway MAY use PING to 1126 maintain connections in anticipation of need rather than incur the 1127 latency cost of connection establishment to servers. 1129 6. Error Handling 1131 QUIC allows the application to abruptly terminate (reset) individual 1132 streams or the entire connection when an error is encountered. These 1133 are referred to as "stream errors" or "connection errors" and are 1134 described in more detail in [QUIC-TRANSPORT]. 1136 This section describes HTTP-specific error codes which can be used to 1137 express the cause of a connection or stream error. 1139 6.1. HTTP/QUIC Error Codes 1141 The following error codes are defined for use in QUIC RST_STREAM, 1142 STOP_SENDING, and CONNECTION_CLOSE frames when using HTTP/QUIC. 1144 STOPPING (0x00): This value is reserved by the transport to be used 1145 in response to QUIC STOP_SENDING frames. 1147 HTTP_NO_ERROR (0x01): No error. This is used when the connection or 1148 stream needs to be closed, but there is no error to signal. 1150 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1151 which the client will not accept on this connection. 1153 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1154 HTTP stack. 1156 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1157 content which the client has cached. 1159 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1160 requested data. 1162 HTTP_HPACK_DECOMPRESSION_FAILED (0x06): HPACK failed to decompress a 1163 frame and cannot continue. 1165 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1166 a CONNECT request was reset or abnormally closed. 1168 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1169 exhibiting a behavior that might be generating excessive load. 1171 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1172 served over HTTP/QUIC. The peer should retry over HTTP/2. 1174 HTTP_WRONG_STREAM (0x0A): A frame was received on stream where it is 1175 not permitted. 1177 HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current 1178 maximum Push ID was referenced. 1180 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1181 different stream headers. 1183 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1184 The frame type is included as the last octet of the error code. 1185 For example, an error in a MAX_PUSH_ID frame would be indicated 1186 with the code (0x10D). 1188 7. Considerations for Transitioning from HTTP/2 1190 HTTP/QUIC is strongly informed by HTTP/2, and bears many 1191 similarities. This section describes the approach taken to design 1192 HTTP/QUIC, points out important differences from HTTP/2, and 1193 describes how to map HTTP/2 extensions into HTTP/QUIC. 1195 HTTP/QUIC begins from the premise that HTTP/2 code reuse is a useful 1196 feature, but not a hard requirement. HTTP/QUIC departs from HTTP/2 1197 primarily where necessary to accommodate the differences in behavior 1198 between QUIC and TCP (lack of ordering, support for streams). We 1199 intend to avoid gratuitous changes which make it difficult or 1200 impossible to build extensions with the same semantics applicable to 1201 both protocols at once. 1203 These departures are noted in this section. 1205 7.1. Streams 1207 HTTP/QUIC permits use of a larger number of streams (2^62-1) than 1208 HTTP/2. The considerations about exhaustion of stream identifier 1209 space apply, though the space is significantly larger such that it is 1210 likely that other limits in QUIC are reached first, such as the limit 1211 on the connection flow control window. 1213 7.2. HTTP Frame Types 1215 Many framing concepts from HTTP/2 can be elided away on QUIC, because 1216 the transport deals with them. Because frames are already on a 1217 stream, they can omit the stream number. Because frames do not block 1218 multiplexing (QUIC's multiplexing occurs below this layer), the 1219 support for variable-maximum-length packets can be removed. Because 1220 stream termination is handled by QUIC, an END_STREAM flag is not 1221 required. 1223 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1224 includes many features (e.g. flow control) which are also present in 1225 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 1226 As a result, several HTTP/2 frame types are not required in HTTP/ 1227 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 1228 has been reserved in order to maximize portability between HTTP/2 and 1229 HTTP/QUIC implementations. However, even equivalent frames between 1230 the two mappings are not identical. 1232 Many of the differences arise from the fact that HTTP/2 provides an 1233 absolute ordering between frames across all streams, while QUIC 1234 provides this guarantee on each stream only. As a result, if a frame 1235 type makes assumptions that frames from different streams will still 1236 be received in the order sent, HTTP/QUIC will break them. 1238 For example, implicit in the HTTP/2 prioritization scheme is the 1239 notion of in-order delivery of priority changes (i.e., dependency 1240 tree mutations): since operations on the dependency tree such as 1241 reparenting a subtree are not commutative, both sender and receiver 1242 must apply them in the same order to ensure that both sides have a 1243 consistent view of the stream dependency tree. HTTP/2 specifies 1244 priority assignments in PRIORITY frames and (optionally) in HEADERS 1245 frames. To achieve in-order delivery of priority changes in HTTP/ 1246 QUIC, PRIORITY frames are sent on the control stream and the PRIORITY 1247 section is removed from the HEADERS frame. 1249 Likewise, HPACK was designed with the assumption of in-order 1250 delivery. A sequence of encoded header blocks must arrive (and be 1251 decoded) at an endpoint in the same order in which they were encoded. 1252 This ensures that the dynamic state at the two endpoints remains in 1253 sync. As a result, HTTP/QUIC uses a modified version of HPACK, 1254 described in [QPACK]. 1256 Frame type definitions in HTTP/QUIC often use the QUIC variable- 1257 length integer encoding. In particular, Stream IDs use this 1258 encoding, which allow for a larger range of possible values than the 1259 encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier 1260 rather than a Stream ID (e.g. Push IDs in PRIORITY frames). 1261 Redefinition of the encoding of extension frame types might be 1262 necessary if the encoding includes a Stream ID. 1264 Other than this issue, frame type HTTP/2 extensions are typically 1265 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 2 1266 or 3 in HTTP/QUIC. HTTP/QUIC extensions will not assume ordering, 1267 but would not be harmed by ordering, and would be portable to HTTP/2 1268 in the same manner. 1270 Below is a listing of how each HTTP/2 frame type is mapped: 1272 DATA (0x0): Padding is not defined in HTTP/QUIC frames. See 1273 Section 4.2.1. 1275 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 1276 not supported. A separate PRIORITY frame MUST be used. Padding 1277 is not defined in HTTP/QUIC frames. See Section 4.2.2. 1279 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 1280 the control stream and can reference either a Stream ID or a Push 1281 ID. See Section 4.2.3. 1283 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 1284 provides stream lifecycle management. The same code point is used 1285 for the CANCEL_PUSH frame (Section 4.2.4). 1287 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 1288 the connection. See Section 4.2.5 and Section 7.3. 1290 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 1291 instead the push stream references the PUSH_PROMISE frame using a 1292 Push ID. See Section 4.2.6. 1294 PING (0x6): PING frames do not exist, since QUIC provides equivalent 1295 functionality. 1297 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 1298 contain an error code. See Section 4.2.7. 1300 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 1301 provides flow control. 1303 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 1304 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted, and 1305 HEADERS frames can be used in series. 1307 Frame types defined by extensions to HTTP/2 need to be separately 1308 registered for HTTP/QUIC if still applicable. The IDs of frames 1309 defined in [RFC7540] have been reserved for simplicity. See 1310 Section 9.3. 1312 7.3. HTTP/2 SETTINGS Parameters 1314 An important difference from HTTP/2 is that settings are sent once, 1315 at the beginning of the connection, and thereafter cannot change. 1316 This eliminates many corner cases around synchronization of changes. 1318 Some transport-level options that HTTP/2 specifies via the SETTINGS 1319 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 1320 HTTP-level options that are retained in HTTP/QUIC have the same value 1321 as in HTTP/2. 1323 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 1325 SETTINGS_HEADER_TABLE_SIZE: See Section 4.2.5.2. 1327 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 1328 which provides a more granular control over server push. 1330 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 1331 Stream ID as part of its flow control logic. Specifying 1332 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 1334 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 1335 connection flow control window sizes to be specified in the 1336 initial transport handshake. Specifying 1337 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 1339 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 1340 QUIC. Specifying it in the SETTINGS frame is an error. 1342 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.2. 1344 Settings need to be defined separately for HTTP/2 and HTTP/QUIC. The 1345 IDs of settings defined in [RFC7540] have been reserved for 1346 simplicity. See Section 9.4. 1348 7.4. HTTP/2 Error Codes 1350 QUIC has the same concepts of "stream" and "connection" errors that 1351 HTTP/2 provides. However, because the error code space is shared 1352 between multiple components, there is no direct portability of HTTP/2 1353 error codes. 1355 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 1356 HTTP over QUIC error codes as follows: 1358 NO_ERROR (0x0): HTTP_NO_ERROR in Section 6.1. 1360 PROTOCOL_ERROR (0x1): No single mapping. See new 1361 HTTP_MALFORMED_FRAME error codes defined in Section 6.1. 1363 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 6.1. 1365 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 1366 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 1367 from the QUIC layer. 1369 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 1370 SETTINGS is defined. 1372 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 1373 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 1374 from the QUIC layer. 1376 FRAME_SIZE_ERROR (0x6) No single mapping. See new error codes 1377 defined in Section 6.1. 1379 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 1380 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 1381 QUIC layer. 1383 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 1385 COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in 1386 Section 6.1. 1388 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 1390 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 1392 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 1393 provide sufficient security on all connections. 1395 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 1397 Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. 1398 See Section 9.5. 1400 8. Security Considerations 1402 The security considerations of HTTP over QUIC should be comparable to 1403 those of HTTP/2. 1405 The modified SETTINGS format contains nested length elements, which 1406 could pose a security risk to an uncautious implementer. A SETTINGS 1407 frame parser MUST ensure that the length of the frame exactly matches 1408 the length of the settings it contains. 1410 9. IANA Considerations 1412 9.1. Registration of HTTP/QUIC Identification String 1414 This document creates a new registration for the identification of 1415 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 1416 Protocol IDs" registry established in [RFC7301]. 1418 The "hq" string identifies HTTP/QUIC: 1420 Protocol: HTTP over QUIC 1422 Identification Sequence: 0x68 0x71 ("hq") 1424 Specification: This document 1426 9.2. Registration of QUIC Version Hint Alt-Svc Parameter 1428 This document creates a new registration for version-negotiation 1429 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1430 registry established in [RFC7838]. 1432 Parameter: "quic" 1434 Specification: This document, Section 2.1.1 1436 9.3. Frame Types 1438 This document establishes a registry for HTTP/QUIC frame type codes. 1439 The "HTTP/QUIC Frame Type" registry manages an 8-bit space. The 1440 "HTTP/QUIC Frame Type" registry operates under either of the "IETF 1441 Review" or "IESG Approval" policies [RFC8126] for values between 0x00 1442 and 0xef, with values between 0xf0 and 0xff being reserved for 1443 Experimental Use. 1445 While this registry is separate from the "HTTP/2 Frame Type" registry 1446 defined in [RFC7540], it is preferable that the assignments parallel 1447 each other. If an entry is present in only one registry, every 1448 effort SHOULD be made to avoid assigning the corresponding value to 1449 an unrelated operation. 1451 New entries in this registry require the following information: 1453 Frame Type: A name or label for the frame type. 1455 Code: The 8-bit code assigned to the frame type. 1457 Specification: A reference to a specification that includes a 1458 description of the frame layout, its semantics, and flags that the 1459 frame type uses, including any parts of the frame that are 1460 conditionally present based on the value of flags. 1462 The entries in the following table are registered by this document. 1464 +--------------+------+---------------+ 1465 | Frame Type | Code | Specification | 1466 +--------------+------+---------------+ 1467 | DATA | 0x0 | Section 4.2.1 | 1468 | | | | 1469 | HEADERS | 0x1 | Section 4.2.2 | 1470 | | | | 1471 | PRIORITY | 0x2 | Section 4.2.3 | 1472 | | | | 1473 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1474 | | | | 1475 | SETTINGS | 0x4 | Section 4.2.5 | 1476 | | | | 1477 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1478 | | | | 1479 | Reserved | 0x6 | N/A | 1480 | | | | 1481 | GOAWAY | 0x7 | Section 4.2.7 | 1482 | | | | 1483 | HEADER_ACK | 0x8 | Section 4.2.8 | 1484 | | | | 1485 | Reserved | 0x9 | N/A | 1486 | | | | 1487 | MAX_PUSH_ID | 0xD | Section 4.2.9 | 1488 +--------------+------+---------------+ 1490 9.4. Settings Parameters 1492 This document establishes a registry for HTTP/QUIC settings. The 1493 "HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC 1494 Settings" registry operates under the "Expert Review" policy 1495 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1496 between and 0xf000 and 0xffff being reserved for Experimental Use. 1497 The designated experts are the same as those for the "HTTP/2 1498 Settings" registry defined in [RFC7540]. 1500 While this registry is separate from the "HTTP/2 Settings" registry 1501 defined in [RFC7540], it is preferable that the assignments parallel 1502 each other. If an entry is present in only one registry, every 1503 effort SHOULD be made to avoid assigning the corresponding value to 1504 an unrelated operation. 1506 New registrations are advised to provide the following information: 1508 Name: A symbolic name for the setting. Specifying a setting name is 1509 optional. 1511 Code: The 16-bit code assigned to the setting. 1513 Specification: An optional reference to a specification that 1514 describes the use of the setting. 1516 The entries in the following table are registered by this document. 1518 +----------------------+------+-----------------+ 1519 | Setting Name | Code | Specification | 1520 +----------------------+------+-----------------+ 1521 | HEADER_TABLE_SIZE | 0x1 | Section 4.2.5.2 | 1522 | | | | 1523 | Reserved | 0x2 | N/A | 1524 | | | | 1525 | Reserved | 0x3 | N/A | 1526 | | | | 1527 | Reserved | 0x4 | N/A | 1528 | | | | 1529 | Reserved | 0x5 | N/A | 1530 | | | | 1531 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.2 | 1532 +----------------------+------+-----------------+ 1534 9.5. Error Codes 1536 This document establishes a registry for HTTP/QUIC error codes. The 1537 "HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/ 1538 QUIC Error Code" registry operates under the "Expert Review" policy 1539 [RFC8126]. 1541 Registrations for error codes are required to include a description 1542 of the error code. An expert reviewer is advised to examine new 1543 registrations for possible duplication with existing error codes. 1544 Use of existing registrations is to be encouraged, but not mandated. 1546 New registrations are advised to provide the following information: 1548 Name: A name for the error code. Specifying an error code name is 1549 optional. 1551 Code: The 16-bit error code value. 1553 Description: A brief description of the error code semantics, longer 1554 if no detailed specification is provided. 1556 Specification: An optional reference for a specification that 1557 defines the error code. 1559 The entries in the following table are registered by this document. 1561 +----------------------------+--------+------------+----------------+ 1562 | Name | Code | Descriptio | Specification | 1563 | | | n | | 1564 +----------------------------+--------+------------+----------------+ 1565 | STOPPING | 0x0000 | Reserved | [QUIC-TRANSPOR | 1566 | | | by QUIC | T] | 1567 | | | | | 1568 | HTTP_NO_ERROR | 0x0001 | No error | Section 6.1 | 1569 | | | | | 1570 | HTTP_PUSH_REFUSED | 0x0002 | Client | Section 6.1 | 1571 | | | refused | | 1572 | | | pushed | | 1573 | | | content | | 1574 | | | | | 1575 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 6.1 | 1576 | | | error | | 1577 | | | | | 1578 | HTTP_PUSH_ALREADY_IN_CACHE | 0x0004 | Pushed | Section 6.1 | 1579 | | | content | | 1580 | | | already | | 1581 | | | cached | | 1582 | | | | | 1583 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 6.1 | 1584 | | | longer | | 1585 | | | needed | | 1586 | | | | | 1587 | HTTP_HPACK_DECOMPRESSION_F | 0x0006 | HPACK | Section 6.1 | 1588 | AILED | | cannot | | 1589 | | | continue | | 1590 | | | | | 1591 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset | Section 6.1 | 1592 | | | or error | | 1593 | | | on CONNECT | | 1594 | | | request | | 1595 | | | | | 1596 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 6.1 | 1597 | | | generating | | 1598 | | | excessive | | 1599 | | | load | | 1600 | | | | | 1601 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 6.1 | 1602 | | | HTTP/2 | | 1603 | | | | | 1604 | HTTP_WRONG_STREAM | 0x000A | A frame | Section 6.1 | 1605 | | | was sent | | 1606 | | | on the | | 1607 | | | wrong | | 1608 | | | stream | | 1609 | | | | | 1610 | HTTP_PUSH_LIMIT_EXCEEDED | 0x000B | Maximum | Section 6.1 | 1611 | | | Push ID | | 1612 | | | exceeded | | 1613 | | | | | 1614 | HTTP_DUPLICATE_PUSH | 0x000C | Push ID | Section 6.1 | 1615 | | | was | | 1616 | | | fulfilled | | 1617 | | | multiple | | 1618 | | | times | | 1619 | | | | | 1620 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 6.1 | 1621 | | | frame | | 1622 | | | formatting | | 1623 | | | or use | | 1624 +----------------------------+--------+------------+----------------+ 1626 10. References 1628 10.1. Normative References 1630 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 1631 Header Compression for HTTP over QUIC", draft-ietf-quic- 1632 qpack-00 (work in progress), April 2018. 1634 [QUIC-TRANSPORT] 1635 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1636 Multiplexed and Secure Transport", draft-ietf-quic- 1637 transport-11 (work in progress), April 2018. 1639 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1640 RFC 793, DOI 10.17487/RFC0793, September 1981, 1641 . 1643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1644 Requirement Levels", BCP 14, RFC 2119, 1645 DOI 10.17487/RFC2119, March 1997, 1646 . 1648 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1649 Specifications: ABNF", STD 68, RFC 5234, 1650 DOI 10.17487/RFC5234, January 2008, 1651 . 1653 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1654 Extensions: Extension Definitions", RFC 6066, 1655 DOI 10.17487/RFC6066, January 2011, 1656 . 1658 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1659 Protocol (HTTP/1.1): Message Syntax and Routing", 1660 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1661 . 1663 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1664 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1665 DOI 10.17487/RFC7231, June 2014, 1666 . 1668 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1669 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1670 DOI 10.17487/RFC7540, May 2015, 1671 . 1673 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1674 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1675 April 2016, . 1677 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1678 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1679 May 2017, . 1681 10.2. Informative References 1683 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1684 "Transport Layer Security (TLS) Application-Layer Protocol 1685 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1686 July 2014, . 1688 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1689 Writing an IANA Considerations Section in RFCs", BCP 26, 1690 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1691 . 1693 10.3. URIs 1695 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1697 [2] https://github.com/quicwg 1699 [3] https://github.com/quicwg/base-drafts/labels/-http 1701 Appendix A. Contributors 1703 The original authors of this specification were Robbie Shade and Mike 1704 Warres. 1706 A substantial portion of Mike's contribution was supported by 1707 Microsoft during his employment there. 1709 Appendix B. Change Log 1711 *RFC Editor's Note:* Please remove this section prior to 1712 publication of a final version of this document. 1714 B.1. Since draft-ietf-quic-http-10 1716 o Settings need to be remembered when attempting and accepting 0-RTT 1717 (#1157, #1207) 1719 B.2. Since draft-ietf-quic-http-09 1721 o Selected QCRAM for header compression (#228, #1117) 1723 o The server_name TLS extension is now mandatory (#296, #495) 1725 o Specified handling of unsupported versions in Alt-Svc (#1093, 1726 #1097) 1728 B.3. Since draft-ietf-quic-http-08 1730 o Clarified connection coalescing rules (#940, #1024) 1732 B.4. Since draft-ietf-quic-http-07 1734 o Changes for integer encodings in QUIC (#595,#905) 1736 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 1738 o Improvement to the description of GOAWAY (#604, #898) 1740 o Improve description of server push usage (#947, #950, #957) 1742 B.5. Since draft-ietf-quic-http-06 1744 o Track changes in QUIC error code usage (#485) 1746 B.6. Since draft-ietf-quic-http-05 1748 o Made push ID sequential, add MAX_PUSH_ID, remove 1749 SETTINGS_ENABLE_PUSH (#709) 1751 o Guidance about keep-alive and QUIC PINGs (#729) 1753 o Expanded text on GOAWAY and cancellation (#757) 1755 B.7. Since draft-ietf-quic-http-04 1757 o Cite RFC 5234 (#404) 1759 o Return to a single stream per request (#245,#557) 1761 o Use separate frame type and settings registries from HTTP/2 (#81) 1763 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 1765 o Restored GOAWAY (#696) 1767 o Identify server push using Push ID rather than a stream ID 1768 (#702,#281) 1770 o DATA frames cannot be empty (#700) 1772 B.8. Since draft-ietf-quic-http-03 1774 None. 1776 B.9. Since draft-ietf-quic-http-02 1778 o Track changes in transport draft 1780 B.10. Since draft-ietf-quic-http-01 1782 o SETTINGS changes (#181): 1784 * SETTINGS can be sent only once at the start of a connection; no 1785 changes thereafter 1787 * SETTINGS_ACK removed 1789 * Settings can only occur in the SETTINGS frame a single time 1791 * Boolean format updated 1793 o Alt-Svc parameter changed from "v" to "quic"; format updated 1794 (#229) 1796 o Closing the connection control stream or any message control 1797 stream is a fatal error (#176) 1799 o HPACK Sequence counter can wrap (#173) 1801 o 0-RTT guidance added 1802 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 1803 added (#127,#242) 1805 B.11. Since draft-ietf-quic-http-00 1807 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 1809 o Changed from using HTTP/2 framing within Stream 3 to new framing 1810 format and two-stream-per-request model (#71,#72,#73) 1812 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 1813 settings-01 1815 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 1816 order (#75) 1818 o Described CONNECT pseudo-method (#95) 1820 o Updated ALPN token and Alt-Svc guidance (#13,#87) 1822 o Application-layer-defined error codes (#19,#74) 1824 B.12. Since draft-shade-quic-http2-mapping-00 1826 o Adopted as base for draft-ietf-quic-http 1828 o Updated authors/editors list 1830 Author's Address 1832 Mike Bishop (editor) 1833 Akamai 1835 Email: mbishop@evequefou.be