idnits 2.17.1 draft-ietf-quic-http-12.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 (May 22, 2018) is 2165 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 1658 -- Looks like a reference, but probably isn't: '2' on line 1660 -- Looks like a reference, but probably isn't: '3' on line 1662 == 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 May 22, 2018 5 Expires: November 23, 2018 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-12 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 November 23, 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 . . . . . . . . . . . . . . . . . . . . . . 13 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. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 22 90 5. Connection Management . . . . . . . . . . . . . . . . . . . . 23 91 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24 92 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 24 93 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 25 94 7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 25 96 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 27 97 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 28 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 100 9.1. Registration of HTTP/QUIC Identification String . . . . . 29 101 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 30 102 9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 30 103 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 31 104 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 32 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 107 10.2. Informative References . . . . . . . . . . . . . . . . . 35 108 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 109 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 110 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 111 B.1. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 36 112 B.2. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 36 113 B.3. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 36 114 B.4. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 36 115 B.5. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 36 116 B.6. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37 117 B.7. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37 118 B.8. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 37 119 B.9. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 37 120 B.10. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 37 121 B.11. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 37 122 B.12. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 38 123 B.13. 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 record 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, since an alternative 184 always includes an explicit port. 186 2.1.1. QUIC Version Hints 188 This document defines the "quic" parameter for Alt-Svc, which MAY be 189 used to provide version-negotiation hints to HTTP/QUIC clients. QUIC 190 versions are four-octet sequences with no additional constraints on 191 format. Leading zeros SHOULD be omitted for brevity. 193 Syntax: 195 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 196 version-number = 1*8HEXDIG; hex-encoded QUIC version 198 Where multiple versions are listed, the order of the values reflects 199 the server's preference (with the first value being the most 200 preferred version). Reserved versions MAY be listed, but unreserved 201 versions which are not supported by the alternative SHOULD NOT be 202 present in the list. Origins MAY omit supported versions for any 203 reason. 205 Clients MUST ignore any included versions which they do not support. 206 The "quic" parameter MUST NOT occur more than once; clients SHOULD 207 process only the first occurrence. 209 For example, suppose a server supported both version 0x00000001 and 210 the version rendered in ASCII as "Q034". If it opted to include the 211 reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and 212 0x1abadaba, it could specify the following header: 214 Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0" 216 A client acting on this header would drop the reserved versions 217 (because it does not support them), then attempt to connect to the 218 alternative using the first version in the list which it does 219 support. 221 2.2. Connection Establishment 223 HTTP/QUIC relies on QUIC as the underlying transport. The QUIC 224 version being used MUST use TLS version 1.3 or greater as its 225 handshake protocol. The Server Name Indication (SNI) extension 226 [RFC6066] MUST be included in the TLS handshake. 228 QUIC connections are established as described in [QUIC-TRANSPORT]. 229 During connection establishment, HTTP/QUIC support is indicated by 230 selecting the ALPN token "hq" in the TLS handshake. Support for 231 other application-layer protocols MAY be offered in the same 232 handshake. 234 While connection-level options pertaining to the core QUIC protocol 235 are set in the initial crypto handshake, HTTP-specific settings are 236 conveyed in the SETTINGS frame. After the QUIC connection is 237 established, a SETTINGS frame (Section 4.2.5) MUST be sent by each 238 endpoint as the initial frame of their respective HTTP control stream 239 (Stream ID 2 or 3, see Section 3). The server MUST NOT send data on 240 any other stream until the client's SETTINGS frame has been received. 242 2.2.1. Draft Version Identification 244 *RFC Editor's Note:* Please remove this section prior to 245 publication of a final version of this document. 247 Only implementations of the final, published RFC can identify 248 themselves as "hq". Until such an RFC exists, implementations MUST 249 NOT identify themselves using this string. 251 Implementations of draft versions of the protocol MUST add the string 252 "-" and the corresponding draft number to the identifier. For 253 example, draft-ietf-quic-http-01 is identified using the string "hq- 254 01". 256 Non-compatible experiments that are based on these draft versions 257 MUST append the string "-" and an experiment name to the identifier. 258 For example, an experimental implementation based on draft-ietf-quic- 259 http-09 which reserves an extra stream for unsolicited transmission 260 of 1980s pop music might identify itself as "hq-09-rickroll". Note 261 that any label MUST conform to the "token" syntax defined in 262 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 263 coordinate their experiments on the quic@ietf.org mailing list. 265 2.3. Connection Reuse 267 Once a connection exists to a server endpoint, this connection MAY be 268 reused for requests with multiple different URI authority components. 269 The client MAY send any requests for which the client considers the 270 server authoritative. 272 An authoritative HTTP/QUIC endpoint is typically discovered because 273 the client has received an Alt-Svc record from the request's origin 274 which nominates the endpoint as a valid HTTP Alternative Service for 275 that origin. As required by [RFC7838], clients MUST check that the 276 nominated server can present a valid certificate for the origin 277 before considering it authoritative. Clients MUST NOT assume that an 278 HTTP/QUIC endpoint is authoritative for other origins without an 279 explicit signal. 281 A server that does not wish clients to reuse connections for a 282 particular origin can indicate that it is not authoritative for a 283 request by sending a 421 (Misdirected Request) status code in 284 response to the request (see Section 9.1.2 of [RFC7540]). 286 3. Stream Mapping and Usage 288 A QUIC stream provides reliable in-order delivery of bytes, but makes 289 no guarantees about order of delivery with regard to bytes on other 290 streams. On the wire, data is framed into QUIC STREAM frames, but 291 this framing is invisible to the HTTP framing layer. A QUIC receiver 292 buffers and orders received STREAM frames, exposing the data 293 contained within as a reliable byte stream to the application. 295 QUIC reserves the first client-initiated, bidirectional stream 296 (Stream 0) for cryptographic operations. HTTP over QUIC reserves the 297 first unidirectional stream sent by either peer (Streams 2 and 3) for 298 sending and receiving HTTP control frames. This pair of 299 unidirectional streams is analogous to HTTP/2's Stream 0. HTTP over 300 QUIC also reserves the second and third unidirectional streams for 301 each peer's QPACK encoder and decoder. The client's QPACK encoder 302 uses stream 6 and decoder uses stream 10. The server's encoder and 303 decoder use streams 7 and 11, respectively. The data sent on these 304 streams is critical to the HTTP connection. If any control stream is 305 closed for any reason, this MUST be treated as a connection error of 306 type QUIC_CLOSED_CRITICAL_STREAM. 308 When HTTP headers and data are sent over QUIC, the QUIC layer handles 309 most of the stream management. 311 An HTTP request/response consumes a single client-initiated, 312 bidirectional stream. A bidirectional stream ensures that the 313 response can be readily correlated with the request. This means that 314 the client's first request occurs on QUIC stream 4, with subsequent 315 requests on stream 8, 12, and so on. 317 Server push uses server-initiated, unidirectional streams. Thus, the 318 server's first push consumes stream 7 and subsequent pushes use 319 stream 11, 15, and so on. 321 These streams carry frames related to the request/response (see 322 Section 4.2). When a stream terminates cleanly, if the last frame on 323 the stream was truncated, this MUST be treated as a connection error 324 (see HTTP_MALFORMED_FRAME in Section 6.1). Streams which terminate 325 abruptly may be reset at any point in the frame. 327 Streams SHOULD be used sequentially, with no gaps. 329 HTTP does not need to do any separate multiplexing when using QUIC - 330 data sent over a QUIC stream always maps to a particular HTTP 331 transaction. Requests and responses are considered complete when the 332 corresponding QUIC stream is closed in the appropriate direction. 334 3.1. Control Streams 336 Since most connection-level concerns will be managed by QUIC, the 337 primary use of Streams 2 and 3 will be for the SETTINGS frame when 338 the connection opens and for PRIORITY frames subsequently. 340 A pair of unidirectional streams is used rather than a single 341 bidirectional stream. This allows either peer to send data as soon 342 they are able. Depending on whether 0-RTT is enabled on the 343 connection, either client or server might be able to send stream data 344 first after the cryptographic handshake completes. 346 3.2. HTTP Message Exchanges 348 A client sends an HTTP request on a client-initiated, bidirectional 349 QUIC stream. A server sends an HTTP response on the same stream as 350 the request. 352 An HTTP message (request or response) consists of: 354 1. one header block (see Section 4.2.2) containing the message 355 headers (see [RFC7230], Section 3.2), 357 2. the payload body (see [RFC7230], Section 3.3), sent as a series 358 of DATA frames (see Section 4.2.1), 360 3. optionally, one header block containing the trailer-part, if 361 present (see [RFC7230], Section 4.1.2). 363 In addition, prior to sending the message header block indicated 364 above, a response may contain zero or more header blocks containing 365 the message headers of informational (1xx) HTTP responses (see 366 [RFC7230], Section 3.2 and [RFC7231], Section 6.2). 368 PUSH_PROMISE frames MAY be interleaved with the frames of a response 369 message indicating a pushed resource related to the response. These 370 PUSH_PROMISE frames are not part of the response, but carry the 371 headers of a separate HTTP request message. See Section 3.4 for more 372 details. 374 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 375 MUST NOT be used. 377 Trailing header fields are carried in an additional header block 378 following the body. Such a header block is a sequence of HEADERS 379 frames with End Header Block set on the last frame. Senders MUST 380 send only one header block in the trailers section; receivers MUST 381 discard any subsequent header blocks. 383 An HTTP request/response exchange fully consumes a QUIC stream. 384 After sending a request, a client closes the stream for sending; 385 after sending a response, the server closes the stream for sending 386 and the QUIC stream is fully closed. 388 A server can send a complete response prior to the client sending an 389 entire request if the response does not depend on any portion of the 390 request that has not been sent and received. When this is true, a 391 server MAY request that the client abort transmission of a request 392 without error by triggering a QUIC STOP_SENDING with error code 393 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 394 its streams. Clients MUST NOT discard complete responses as a result 395 of having their request terminated abruptly, though clients can 396 always discard responses at their discretion for other reasons. 397 Servers MUST NOT abort a response in progress as a result of 398 receiving a solicited RST_STREAM. 400 3.2.1. Header Compression 402 HTTP/QUIC uses QPACK header compression as described in [QPACK], a 403 variation of HPACK which allows the flexibility to avoid header- 404 compression-induced head-of-line blocking. See that document for 405 additional details. 407 3.2.2. The CONNECT Method 409 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 410 used with HTTP proxies to establish a TLS session with an origin 411 server for the purposes of interacting with "https" resources. In 412 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 413 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 414 establish a tunnel over a single HTTP/2 stream to a remote host for 415 similar purposes. 417 A CONNECT request in HTTP/QUIC functions in the same manner as in 418 HTTP/2. The request MUST be formatted as described in [RFC7540], 419 Section 8.3. A CONNECT request that does not conform to these 420 restrictions is malformed. The request stream MUST NOT be half- 421 closed at the end of the request. 423 A proxy that supports CONNECT establishes a TCP connection 424 ([RFC0793]) to the server identified in the ":authority" pseudo- 425 header field. Once this connection is successfully established, the 426 proxy sends a HEADERS frame containing a 2xx series status code to 427 the client, as defined in [RFC7231], Section 4.3.6. 429 All DATA frames on the request stream correspond to data sent on the 430 TCP connection. Any DATA frame sent by the client is transmitted by 431 the proxy to the TCP server; data received from the TCP server is 432 packaged into DATA frames by the proxy. Note that the size and 433 number of TCP segments is not guaranteed to map predictably to the 434 size and number of HTTP DATA or QUIC STREAM frames. 436 The TCP connection can be closed by either peer. When the client 437 ends the request stream (that is, the receive stream at the proxy 438 enters the "Data Recvd" state), the proxy will set the FIN bit on its 439 connection to the TCP server. When the proxy receives a packet with 440 the FIN bit set, it will terminate the send stream that it sends to 441 client. TCP connections which remain half-closed in a single 442 direction are not invalid, but are often handled poorly by servers, 443 so clients SHOULD NOT cause send a STREAM frame with a FIN bit for 444 connections on which they are still expecting data. 446 A TCP connection error is signaled with RST_STREAM. A proxy treats 447 any error in the TCP connection, which includes receiving a TCP 448 segment with the RST bit set, as a stream error of type 449 HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send 450 a TCP segment with the RST bit set if it detects an error with the 451 stream or the QUIC connection. 453 3.2.3. Request Cancellation 455 Either client or server can cancel requests by closing the stream 456 (QUIC RST_STREAM or STOP_SENDING frames, as appropriate) with an 457 error type of HTTP_REQUEST_CANCELLED (Section 6.1). When the client 458 cancels a request or response, it indicates that the response is no 459 longer of interest. 461 When the server cancels either direction of the request stream using 462 HTTP_REQUEST_CANCELLED, it indicates that no application processing 463 was performed. The client can treat requests cancelled by the server 464 as though they had never been sent at all, thereby allowing them to 465 be retried later on a new connection. Servers MUST NOT use the 466 HTTP_REQUEST_CANCELLED status for requests which were partially or 467 fully processed. 469 Note: In this context, "processed" means that some data from the 470 stream was passed to some higher layer of software that might have 471 taken some action as a result. 473 If a stream is cancelled after receiving a complete response, the 474 client MAY ignore the cancellation and use the response. However, if 475 a stream is cancelled after receiving a partial response, the 476 response SHOULD NOT be used. Automatically retrying such requests is 477 not possible, unless this is otherwise permitted (e.g., idempotent 478 actions like GET, PUT, or DELETE). 480 3.3. Request Prioritization 482 HTTP/QUIC uses the priority scheme described in [RFC7540], 483 Section 5.3. In this priority scheme, a given request can be 484 designated as dependent upon another request, which expresses the 485 preference that the latter stream (the "parent" request) be allocated 486 resources before the former stream (the "dependent" request). Taken 487 together, the dependencies across all requests in a connection form a 488 dependency tree. The structure of the dependency tree changes as 489 PRIORITY frames add, remove, or change the dependency links between 490 requests. 492 The PRIORITY frame Section 4.2.3 identifies a request either by 493 identifying the stream that carries a request or by using a Push ID 494 (Section 4.2.6). 496 Only a client can send PRIORITY frames. A server MUST NOT send a 497 PRIORITY frame. 499 3.4. Server Push 501 HTTP/QUIC supports server push in a similar manner to [RFC7540], but 502 uses different mechanisms. During connection establishment, the 503 client enables server push by sending a MAX_PUSH_ID frame (see 504 Section 4.2.8). A server cannot use server push until it receives a 505 MAX_PUSH_ID frame. 507 As with server push for HTTP/2, the server initiates a server push by 508 sending a PUSH_PROMISE frame (see Section 4.2.6) that includes 509 request headers for the promised request. Promised requests MUST 510 conform to the requirements in Section 8.2 of [RFC7540]. 512 The PUSH_PROMISE frame is sent on the client-initiated, bidirectional 513 stream that carried the request that generated the push. This allows 514 the server push to be associated with a request. Ordering of a 515 PUSH_PROMISE in relation to certain parts of the response is 516 important (see Section 8.2.1 of [RFC7540]). 518 Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it 519 contains a Push ID. The Push ID uniquely identifies a server push. 521 This allows a server to fulfill promises in the order that best suits 522 its needs. 524 When a server later fulfills a promise, the server push response is 525 conveyed on a push stream. A push stream is a server-initiated, 526 unidirectional stream. A push stream identifies the Push ID of the 527 promise that it fulfills, encoded as a variable-length integer. 529 A server SHOULD use Push IDs sequentially, starting at 0. A client 530 uses the MAX_PUSH_ID frame (Section 4.2.8) to limit the number of 531 pushes that a server can promise. A client MUST treat receipt of a 532 push stream with a Push ID that is greater than the maximum Push ID 533 as a connection error of type HTTP_PUSH_LIMIT_EXCEEDED. 535 If a promised server push is not needed by the client, the client 536 SHOULD send a CANCEL_PUSH frame; if the push stream is already open, 537 a QUIC STOP_SENDING frame with an appropriate error code can be used 538 instead (e.g., HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see 539 Section 6). This asks the server not to transfer the data and 540 indicates that it will be discarded upon receipt. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Push ID (i) ... 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 1: Push Stream Header 550 Push streams always begin with a header containing the Push ID. Each 551 Push ID MUST only be used once in a push stream header. If a push 552 stream header includes a Push ID that was used in another push stream 553 header, the client MUST treat this as a connection error of type 554 HTTP_DUPLICATE_PUSH. The same Push ID can be used in multiple 555 PUSH_PROMISE frames (see Section 4.2.6). 557 After the header, a push stream contains a response (Section 3.2), 558 with response headers, a response body (if any) carried by DATA 559 frames, then trailers (if any) carried by HEADERS frames. 561 4. HTTP Framing Layer 563 Frames are used on each stream. This section describes HTTP framing 564 in QUIC and highlights some differences from HTTP/2 framing. For 565 more detail on differences from HTTP/2, see Section 7.2. 567 4.1. Frame Layout 569 All frames have the following format: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Length (i) ... 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Type (8) | Flags (8) | Frame Payload (*) ... 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 2: HTTP/QUIC frame format 581 A frame includes the following fields: 583 Length: A variable-length integer that describes the length of the 584 Frame Payload. This length does not include the frame header. 586 Type: An 8-bit type for the frame. 588 Flags: An 8-bit field containing flags. The Type field determines 589 the semantics of flags. 591 Frame Payload: A payload, the semantics of which are determined by 592 the Type field. 594 4.2. Frame Definitions 596 4.2.1. DATA 598 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 599 octets associated with an HTTP request or response payload. 601 The DATA frame defines no flags. 603 DATA frames MUST be associated with an HTTP request or response. If 604 a DATA frame is received on either control stream, the recipient MUST 605 respond with a connection error (Section 6) of type 606 HTTP_WRONG_STREAM. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Payload (*) ... 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 3: DATA frame payload 616 DATA frames MUST contain a non-zero-length payload. If a DATA frame 617 is received with a payload length of zero, the recipient MUST respond 618 with a stream error (Section 6) of type HTTP_MALFORMED_FRAME. 620 4.2.2. HEADERS 622 The HEADERS frame (type=0x1) is used to carry a header block, 623 compressed using QPACK. See [QPACK] for more details. 625 The HEADERS frame defines no flags. 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 only be sent on request / push streams. 637 4.2.3. PRIORITY 639 The PRIORITY (type=0x02) frame specifies the sender-advised priority 640 of a stream and is substantially different in format from [RFC7540]. 641 In order to ensure that prioritization is processed in a consistent 642 order, PRIORITY frames MUST be sent on the control stream. A 643 PRIORITY frame sent on any other stream MUST be treated as a 644 HTTP_WRONG_STREAM error. 646 The format has been modified to accommodate not being sent on a 647 request stream, to allow for identification of server pushes, and the 648 larger stream ID space of QUIC. The semantics of the Stream 649 Dependency, Weight, and E flag are otherwise the same as in HTTP/2. 651 The flags defined are: 653 PUSH_PRIORITIZED (0x04): Indicates that the Prioritized Stream is a 654 server push rather than a request. 656 PUSH_DEPENDENT (0x02): Indicates a dependency on a server push. 658 E (0x01): Indicates that the stream dependency is exclusive (see 659 [RFC7540], Section 5.3). 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Prioritized Request ID (i) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Stream Dependency ID (i) | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Weight (8) | 669 +-+-+-+-+-+-+-+-+ 671 Figure 5: PRIORITY frame payload 673 The PRIORITY frame payload has the following fields: 675 Prioritized Request ID: A variable-length integer that identifies a 676 request. This contains the Stream ID of a request stream when the 677 PUSH_PRIORITIZED flag is clear, or a Push ID when the 678 PUSH_PRIORITIZED flag is set. 680 Stream Dependency ID: A variable-length integer that identifies a 681 dependent request. This contains the Stream ID of a request 682 stream when the PUSH_DEPENDENT flag is clear, or a Push ID when 683 the PUSH_DEPENDENT flag is set. A request Stream ID of 0 684 indicates a dependency on the root stream. For details of 685 dependencies, see Section 3.3 and [RFC7540], Section 5.3. 687 Weight: An unsigned 8-bit integer representing a priority weight for 688 the stream (see [RFC7540], Section 5.3). Add one to the value to 689 obtain a weight between 1 and 256. 691 A PRIORITY frame identifies a request to prioritize, and a request 692 upon which that request is dependent. A Prioritized Request ID or 693 Stream Dependency ID identifies a client-initiated request using the 694 corresponding stream ID when the corresponding PUSH_PRIORITIZED or 695 PUSH_DEPENDENT flag is not set. Setting the PUSH_PRIORITIZED or 696 PUSH_DEPENDENT flag causes the Prioritized Request ID or Stream 697 Dependency ID (respectively) to identify a server push using a Push 698 ID (see Section 4.2.6 for details). 700 A PRIORITY frame MAY identify a Stream Dependency ID using a Stream 701 ID of 0; as in [RFC7540], this makes the request dependent on the 702 root of the dependency tree. 704 A PRIORITY frame MUST identify a client-initiated, bidirectional 705 stream. A server MUST treat receipt of PRIORITY frame with a Stream 706 ID of any other type as a connection error of type 707 HTTP_MALFORMED_FRAME. 709 Stream ID 0 cannot be reprioritized. A Prioritized Request ID that 710 identifies Stream 0 MUST be treated as a connection error of type 711 HTTP_MALFORMED_FRAME. 713 A PRIORITY frame that does not reference a request MUST be treated as 714 a HTTP_MALFORMED_FRAME error, unless it references Stream ID 0. A 715 PRIORITY that sets a PUSH_PRIORITIZED or PUSH_DEPENDENT flag, but 716 then references a non-existent Push ID MUST be treated as a 717 HTTP_MALFORMED_FRAME error. 719 A PRIORITY frame MUST contain only the identified fields. A PRIORITY 720 frame that contains more or fewer fields, or a PRIORITY frame that 721 includes a truncated integer encoding MUST be treated as a connection 722 error of type HTTP_MALFORMED_FRAME. 724 4.2.4. CANCEL_PUSH 726 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of 727 server push prior to the push stream being created. The CANCEL_PUSH 728 frame identifies a server push request by Push ID (see Section 4.2.6) 729 using a variable-length integer. 731 When a server receives this frame, it aborts sending the response for 732 the identified server push. If the server has not yet started to 733 send the server push, it can use the receipt of a CANCEL_PUSH frame 734 to avoid opening a stream. If the push stream has been opened by the 735 server, the server SHOULD sent a QUIC RST_STREAM frame on those 736 streams and cease transmission of the response. 738 A server can send this frame to indicate that it won't be sending a 739 response prior to creation of a push stream. Once the push stream 740 has been created, sending CANCEL_PUSH has no effect on the state of 741 the push stream. A QUIC RST_STREAM frame SHOULD be used instead to 742 cancel transmission of the server push response. 744 A CANCEL_PUSH frame is sent on the control stream. Sending a 745 CANCEL_PUSH frame on a stream other than the control stream MUST be 746 treated as a stream error of type HTTP_WRONG_STREAM. 748 The CANCEL_PUSH frame has no defined flags. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Push ID (i) ... 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Figure 6: CANCEL_PUSH frame payload 758 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 759 integer. The Push ID identifies the server push that is being 760 cancelled (see Section 4.2.6). 762 If the client receives a CANCEL_PUSH frame, that frame might identify 763 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 765 An endpoint MUST treat a CANCEL_PUSH frame which does not contain 766 exactly one properly-formatted variable-length integer as a 767 connection error of type HTTP_MALFORMED_FRAME. 769 4.2.5. SETTINGS 771 The SETTINGS frame (type=0x4) conveys configuration parameters that 772 affect how endpoints communicate, such as preferences and constraints 773 on peer behavior, and is different from [RFC7540]. Individually, a 774 SETTINGS parameter can also be referred to as a "setting". 776 SETTINGS parameters are not negotiated; they describe characteristics 777 of the sending peer, which can be used by the receiving peer. 778 However, a negotiation can be implied by the use of SETTINGS - a peer 779 uses SETTINGS to advertise a set of supported values. The recipient 780 can then choose which entries from this list are also acceptable and 781 proceed with the value it has chosen. (This choice could be 782 announced in a field of an extension frame, or in its own value in 783 SETTINGS.) 785 Different values for the same parameter can be advertised by each 786 peer. For example, a client might be willing to consume very large 787 response headers, while servers are more cautious about request size. 789 Parameters MUST NOT occur more than once. A receiver MAY treat the 790 presence of the same parameter more than once as a connection error 791 of type HTTP_MALFORMED_FRAME. 793 The SETTINGS frame defines no flags. 795 The payload of a SETTINGS frame consists of zero or more parameters, 796 each consisting of an unsigned 16-bit setting identifier and a 797 length-prefixed binary value. 799 0 1 2 3 800 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Identifier (16) | Length (i) ... 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Contents (?) ... 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Figure 7: SETTINGS value format 809 A zero-length content indicates that the setting value is a Boolean 810 and true. False is indicated by the absence of the setting. 812 Non-zero-length values MUST be compared against the remaining length 813 of the SETTINGS frame. Any value which purports to cross the end of 814 the frame MUST cause the SETTINGS frame to be considered malformed 815 and trigger a connection error of type HTTP_MALFORMED_FRAME. 817 An implementation MUST ignore the contents for any SETTINGS 818 identifier it does not understand. 820 SETTINGS frames always apply to a connection, never a single stream. 821 A SETTINGS frame MUST be sent as the first frame of either control 822 stream (see Section 3) by each peer, and MUST NOT be sent 823 subsequently or on any other stream. If an endpoint receives an 824 SETTINGS frame on a different stream, the endpoint MUST respond with 825 a connection error of type HTTP_WRONG_STREAM. If an endpoint 826 receives a second SETTINGS frame, the endpoint MUST respond with a 827 connection error of type HTTP_MALFORMED_FRAME. 829 The SETTINGS frame affects connection state. A badly formed or 830 incomplete SETTINGS frame MUST be treated as a connection error 831 (Section 6) of type HTTP_MALFORMED_FRAME. 833 4.2.5.1. Integer encoding 835 Settings which are integers use the QUIC variable-length integer 836 encoding. 838 4.2.5.2. Defined SETTINGS Parameters 840 The following settings are defined in HTTP/QUIC: 842 SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of 843 2^30 - 1. The default value is 4,096 bytes. 845 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value 846 of 2^30 - 1. The default value is unlimited. 848 SETTINGS_QPACK_BLOCKED_STREAMS (0x7): An integer with a maximum 849 value of 2^16 - 1. The default value is 100. 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 no flags. 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Push ID (i) ... 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Header Block (*) ... 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Figure 8: PUSH_PROMISE frame payload 883 The payload consists of: 885 Push ID: A variable-length integer that identifies the server push 886 request. A push ID is used in push stream header (Section 3.4), 887 CANCEL_PUSH frames (Section 4.2.4), and PRIORITY frames 888 (Section 4.2.3). 890 Header Block: QPACK-compressed request headers for the promised 891 response. See [QPACK] for more details. 893 A server MUST NOT use a Push ID that is larger than the client has 894 provided in a MAX_PUSH_ID frame (Section 4.2.8). A client MUST treat 895 receipt of a PUSH_PROMISE that contains a larger Push ID than the 896 client has advertised as a connection error of type 897 HTTP_MALFORMED_FRAME. 899 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 900 This allows the server to use the same server push in response to 901 multiple concurrent requests. Referencing the same server push 902 ensures that a PUSH_PROMISE can be made in relation to every response 903 in which server push might be needed without duplicating pushes. 905 A server that uses the same Push ID in multiple PUSH_PROMISE frames 906 MUST include the same header fields each time. The octets of the 907 header block MAY be different due to differing encoding, but the 908 header fields and their values MUST be identical. Note that ordering 909 of header fields is significant. A client MUST treat receipt of a 910 PUSH_PROMISE with conflicting header field values for the same Push 911 ID as a connection error of type HTTP_MALFORMED_FRAME. 913 Allowing duplicate references to the same Push ID is primarily to 914 reduce duplication caused by concurrent requests. A server SHOULD 915 avoid reusing a Push ID over a long period. Clients are likely to 916 consume server push responses and not retain them for reuse over 917 time. Clients that see a PUSH_PROMISE that uses a Push ID that they 918 have since consumed and discarded are forced to ignore the 919 PUSH_PROMISE. 921 4.2.7. GOAWAY 923 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 924 a connection by a server. GOAWAY allows a server to stop accepting 925 new requests while still finishing processing of previously received 926 requests. This enables administrative actions, like server 927 maintenance. GOAWAY by itself does not close a connection. 929 The GOAWAY frame does not define any flags. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Stream ID (i) ... 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 Figure 9: GOAWAY frame payload 939 The GOAWAY frame carries a QUIC Stream ID for a client-initiated, 940 bidirectional stream encoded as a variable-length integer. A client 941 MUST treat receipt of a GOAWAY frame containing a Stream ID of any 942 other type as a connection error of type HTTP_MALFORMED_FRAME. 944 Clients do not need to send GOAWAY to initiate a graceful shutdown; 945 they simply stop making new requests. A server MUST treat receipt of 946 a GOAWAY frame as a connection error (Section 6) of type 947 HTTP_UNEXPECTED_GOAWAY. 949 The GOAWAY frame applies to the connection, not a specific stream. 950 An endpoint MUST treat a GOAWAY frame on a stream other than the 951 control stream as a connection error (Section 6) of type 952 HTTP_WRONG_STREAM. 954 New client requests might already have been sent before the client 955 receives the server's GOAWAY frame. The GOAWAY frame contains the 956 Stream ID of the last client-initiated request that was or might be 957 processed in this connection, which enables client and server to 958 agree on which requests were accepted prior to the connection 959 shutdown. This identifier MAY be lower than the stream limit 960 identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no 961 requests were processed. Servers SHOULD NOT increase the 962 MAX_STREAM_ID limit after sending a GOAWAY frame. 964 Once sent, the server MUST cancel requests sent on streams with an 965 identifier higher than the included last Stream ID. Clients MUST NOT 966 send new requests on the connection after receiving GOAWAY, although 967 requests might already be in transit. A new connection can be 968 established for new requests. 970 If the client has sent requests on streams with a higher Stream ID 971 than indicated in the GOAWAY frame, those requests are considered 972 cancelled (Section 3.2.3). Clients SHOULD reset any streams above 973 this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also 974 cancel requests on streams below the indicated ID if these requests 975 were not processed. 977 Requests on Stream IDs less than or equal to the Stream ID in the 978 GOAWAY frame might have been processed; their status cannot be known 979 until they are completed successfully, reset individually, or the 980 connection terminates. 982 Servers SHOULD send a GOAWAY frame when the closing of a connection 983 is known in advance, even if the advance notice is small, so that the 984 remote peer can know whether a stream has been partially processed or 985 not. For example, if an HTTP client sends a POST at the same time 986 that a server closes a QUIC connection, the client cannot know if the 987 server started to process that POST request if the server does not 988 send a GOAWAY frame to indicate what streams it might have acted on. 990 For unexpected closures caused by error conditions, a QUIC 991 CONNECTION_CLOSE or APPLICATION_CLOSE frame MUST be used. However, a 992 GOAWAY MAY be sent first to provide additional detail to clients and 993 to allow the client to retry requests. Including the GOAWAY frame in 994 the same packet as the QUIC CONNECTION_CLOSE or APPLICATION_CLOSE 995 frame improves the chances of the frame being received by clients. 997 If a connection terminates without a GOAWAY frame, the last Stream ID 998 is effectively the highest possible Stream ID (as determined by 999 QUIC's MAX_STREAM_ID). 1001 An endpoint MAY send multiple GOAWAY frames if circumstances change. 1002 For instance, an endpoint that sends GOAWAY without an error code 1003 during graceful shutdown could subsequently encounter an error 1004 condition. The last stream identifier from the last GOAWAY frame 1005 received indicates which streams could have been acted upon. A 1006 server MUST NOT increase the value they send in the last Stream ID, 1007 since clients might already have retried unprocessed requests on 1008 another connection. 1010 A client that is unable to retry requests loses all requests that are 1011 in flight when the server closes the connection. A server that is 1012 attempting to gracefully shut down a connection SHOULD send an 1013 initial GOAWAY frame with the last Stream ID set to the current value 1014 of QUIC's MAX_STREAM_ID and SHOULD NOT increase the MAX_STREAM_ID 1015 thereafter. This signals to the client that a shutdown is imminent 1016 and that initiating further requests is prohibited. After allowing 1017 time for any in-flight requests (at least one round-trip time), the 1018 server MAY send another GOAWAY frame with an updated last Stream ID. 1019 This ensures that a connection can be cleanly shut down without 1020 losing requests. 1022 Once all requests on streams at or below the identified stream number 1023 have been completed or cancelled, and all promised server push 1024 responses associated with those requests have been completed or 1025 cancelled, the connection can be closed using an Immediate Close (see 1026 [QUIC-TRANSPORT]). An endpoint that completes a graceful shutdown 1027 SHOULD use the QUIC APPLICATION_CLOSE frame with the HTTP_NO_ERROR 1028 code. 1030 4.2.8. MAX_PUSH_ID 1032 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 1033 number of server pushes that the server can initiate. This sets the 1034 maximum value for a Push ID that the server can use in a PUSH_PROMISE 1035 frame. Consequently, this also limits the number of push streams 1036 that the server can initiate in addition to the limit set by the QUIC 1037 MAX_STREAM_ID frame. 1039 The MAX_PUSH_ID frame is always sent on a control stream. Receipt of 1040 a MAX_PUSH_ID frame on any other stream MUST be treated as a 1041 connection error of type HTTP_WRONG_STREAM. 1043 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1044 receipt of a MAX_PUSH_ID frame as a connection error of type 1045 HTTP_MALFORMED_FRAME. 1047 The maximum Push ID is unset when a connection is created, meaning 1048 that a server cannot push until it receives a MAX_PUSH_ID frame. A 1049 client that wishes to manage the number of promised server pushes can 1050 increase the maximum Push ID by sending a MAX_PUSH_ID frame as the 1051 server fulfills or cancels server pushes. 1053 The MAX_PUSH_ID frame has no defined flags. 1055 0 1 2 3 1056 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 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Push ID (i) ... 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 Figure 10: MAX_PUSH_ID frame payload 1063 The MAX_PUSH_ID frame carries a single variable-length integer that 1064 identifies the maximum value for a Push ID that the server can use 1065 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 1066 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 1067 previously received MUST be treated as a connection error of type 1068 HTTP_MALFORMED_FRAME. 1070 A server MUST treat a MAX_PUSH_ID frame payload that does not contain 1071 a single variable-length integer as a connection error of type 1072 HTTP_MALFORMED_FRAME. 1074 5. Connection Management 1076 QUIC connections are persistent. All of the considerations in 1077 Section 9.1 of [RFC7540] apply to the management of QUIC connections. 1079 HTTP clients are expected to use QUIC PING frames to keep connections 1080 open. Servers SHOULD NOT use PING frames to keep a connection open. 1081 A client SHOULD NOT use PING frames for this purpose unless there are 1082 responses outstanding for requests or server pushes. If the client 1083 is not expecting a response from the server, allowing an idle 1084 connection to time out (based on the idle_timeout transport 1085 parameter) is preferred over expending effort maintaining a 1086 connection that might not be needed. A gateway MAY use PING to 1087 maintain connections in anticipation of need rather than incur the 1088 latency cost of connection establishment to servers. 1090 6. Error Handling 1092 QUIC allows the application to abruptly terminate (reset) individual 1093 streams or the entire connection when an error is encountered. These 1094 are referred to as "stream errors" or "connection errors" and are 1095 described in more detail in [QUIC-TRANSPORT]. 1097 This section describes HTTP-specific error codes which can be used to 1098 express the cause of a connection or stream error. 1100 6.1. HTTP/QUIC Error Codes 1102 The following error codes are defined for use in QUIC RST_STREAM, 1103 STOP_SENDING, and CONNECTION_CLOSE frames when using HTTP/QUIC. 1105 STOPPING (0x00): This value is reserved by the transport to be used 1106 in response to QUIC STOP_SENDING frames. 1108 HTTP_NO_ERROR (0x01): No error. This is used when the connection or 1109 stream needs to be closed, but there is no error to signal. 1111 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1112 which the client will not accept on this connection. 1114 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1115 HTTP stack. 1117 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1118 content which the client has cached. 1120 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1121 requested data. 1123 HTTP_QPACK_DECOMPRESSION_FAILED (0x06): QPACK failed to decompress a 1124 frame and cannot continue. 1126 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1127 a CONNECT request was reset or abnormally closed. 1129 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1130 exhibiting a behavior that might be generating excessive load. 1132 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1133 served over HTTP/QUIC. The peer should retry over HTTP/2. 1135 HTTP_WRONG_STREAM (0x0A): A frame was received on stream where it is 1136 not permitted. 1138 HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current 1139 maximum Push ID was referenced. 1141 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1142 different stream headers. 1144 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1145 The frame type is included as the last octet of the error code. 1146 For example, an error in a MAX_PUSH_ID frame would be indicated 1147 with the code (0x10D). 1149 7. Considerations for Transitioning from HTTP/2 1151 HTTP/QUIC is strongly informed by HTTP/2, and bears many 1152 similarities. This section describes the approach taken to design 1153 HTTP/QUIC, points out important differences from HTTP/2, and 1154 describes how to map HTTP/2 extensions into HTTP/QUIC. 1156 HTTP/QUIC begins from the premise that HTTP/2 code reuse is a useful 1157 feature, but not a hard requirement. HTTP/QUIC departs from HTTP/2 1158 primarily where necessary to accommodate the differences in behavior 1159 between QUIC and TCP (lack of ordering, support for streams). We 1160 intend to avoid gratuitous changes which make it difficult or 1161 impossible to build extensions with the same semantics applicable to 1162 both protocols at once. 1164 These departures are noted in this section. 1166 7.1. Streams 1168 HTTP/QUIC permits use of a larger number of streams (2^62-1) than 1169 HTTP/2. The considerations about exhaustion of stream identifier 1170 space apply, though the space is significantly larger such that it is 1171 likely that other limits in QUIC are reached first, such as the limit 1172 on the connection flow control window. 1174 7.2. HTTP Frame Types 1176 Many framing concepts from HTTP/2 can be elided away on QUIC, because 1177 the transport deals with them. Because frames are already on a 1178 stream, they can omit the stream number. Because frames do not block 1179 multiplexing (QUIC's multiplexing occurs below this layer), the 1180 support for variable-maximum-length packets can be removed. Because 1181 stream termination is handled by QUIC, an END_STREAM flag is not 1182 required. 1184 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1185 includes many features (e.g. flow control) which are also present in 1186 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 1187 As a result, several HTTP/2 frame types are not required in HTTP/ 1188 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 1189 has been reserved in order to maximize portability between HTTP/2 and 1190 HTTP/QUIC implementations. However, even equivalent frames between 1191 the two mappings are not identical. 1193 Many of the differences arise from the fact that HTTP/2 provides an 1194 absolute ordering between frames across all streams, while QUIC 1195 provides this guarantee on each stream only. As a result, if a frame 1196 type makes assumptions that frames from different streams will still 1197 be received in the order sent, HTTP/QUIC will break them. 1199 For example, implicit in the HTTP/2 prioritization scheme is the 1200 notion of in-order delivery of priority changes (i.e., dependency 1201 tree mutations): since operations on the dependency tree such as 1202 reparenting a subtree are not commutative, both sender and receiver 1203 must apply them in the same order to ensure that both sides have a 1204 consistent view of the stream dependency tree. HTTP/2 specifies 1205 priority assignments in PRIORITY frames and (optionally) in HEADERS 1206 frames. To achieve in-order delivery of priority changes in HTTP/ 1207 QUIC, PRIORITY frames are sent on the control stream and the PRIORITY 1208 section is removed from the HEADERS frame. 1210 Likewise, HPACK was designed with the assumption of in-order 1211 delivery. A sequence of encoded header blocks must arrive (and be 1212 decoded) at an endpoint in the same order in which they were encoded. 1213 This ensures that the dynamic state at the two endpoints remains in 1214 sync. As a result, HTTP/QUIC uses a modified version of HPACK, 1215 described in [QPACK]. 1217 Frame type definitions in HTTP/QUIC often use the QUIC variable- 1218 length integer encoding. In particular, Stream IDs use this 1219 encoding, which allow for a larger range of possible values than the 1220 encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier 1221 rather than a Stream ID (e.g. Push IDs in PRIORITY frames). 1222 Redefinition of the encoding of extension frame types might be 1223 necessary if the encoding includes a Stream ID. 1225 Other than this issue, frame type HTTP/2 extensions are typically 1226 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 2 1227 or 3 in HTTP/QUIC. HTTP/QUIC extensions will not assume ordering, 1228 but would not be harmed by ordering, and would be portable to HTTP/2 1229 in the same manner. 1231 Below is a listing of how each HTTP/2 frame type is mapped: 1233 DATA (0x0): Padding is not defined in HTTP/QUIC frames. See 1234 Section 4.2.1. 1236 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 1237 not supported. A separate PRIORITY frame MUST be used. Padding 1238 is not defined in HTTP/QUIC frames. See Section 4.2.2. 1240 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 1241 the control stream and can reference either a Stream ID or a Push 1242 ID. See Section 4.2.3. 1244 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 1245 provides stream lifecycle management. The same code point is used 1246 for the CANCEL_PUSH frame (Section 4.2.4). 1248 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 1249 the connection. See Section 4.2.5 and Section 7.3. 1251 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 1252 instead the push stream references the PUSH_PROMISE frame using a 1253 Push ID. See Section 4.2.6. 1255 PING (0x6): PING frames do not exist, since QUIC provides equivalent 1256 functionality. 1258 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 1259 contain an error code. See Section 4.2.7. 1261 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 1262 provides flow control. 1264 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 1265 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted, and 1266 HEADERS frames can be used in series. 1268 Frame types defined by extensions to HTTP/2 need to be separately 1269 registered for HTTP/QUIC if still applicable. The IDs of frames 1270 defined in [RFC7540] have been reserved for simplicity. See 1271 Section 9.3. 1273 7.3. HTTP/2 SETTINGS Parameters 1275 An important difference from HTTP/2 is that settings are sent once, 1276 at the beginning of the connection, and thereafter cannot change. 1277 This eliminates many corner cases around synchronization of changes. 1279 Some transport-level options that HTTP/2 specifies via the SETTINGS 1280 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 1281 HTTP-level options that are retained in HTTP/QUIC have the same value 1282 as in HTTP/2. 1284 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 1286 SETTINGS_HEADER_TABLE_SIZE: See Section 4.2.5.2. 1288 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 1289 which provides a more granular control over server push. 1291 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 1292 Stream ID as part of its flow control logic. Specifying 1293 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 1295 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 1296 connection flow control window sizes to be specified in the 1297 initial transport handshake. Specifying 1298 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 1300 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 1301 QUIC. Specifying it in the SETTINGS frame is an error. 1303 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.2. 1305 Settings need to be defined separately for HTTP/2 and HTTP/QUIC. The 1306 IDs of settings defined in [RFC7540] have been reserved for 1307 simplicity. See Section 9.4. 1309 7.4. HTTP/2 Error Codes 1311 QUIC has the same concepts of "stream" and "connection" errors that 1312 HTTP/2 provides. However, because the error code space is shared 1313 between multiple components, there is no direct portability of HTTP/2 1314 error codes. 1316 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 1317 HTTP over QUIC error codes as follows: 1319 NO_ERROR (0x0): HTTP_NO_ERROR in Section 6.1. 1321 PROTOCOL_ERROR (0x1): No single mapping. See new 1322 HTTP_MALFORMED_FRAME error codes defined in Section 6.1. 1324 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 6.1. 1326 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 1327 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 1328 from the QUIC layer. 1330 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 1331 SETTINGS is defined. 1333 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 1334 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 1335 from the QUIC layer. 1337 FRAME_SIZE_ERROR (0x6): No single mapping. See new error codes 1338 defined in Section 6.1. 1340 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 1341 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 1342 QUIC layer. 1344 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 1346 COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in 1347 Section 6.1. 1349 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 1351 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 1353 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 1354 provide sufficient security on all connections. 1356 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 1358 Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. 1359 See Section 9.5. 1361 8. Security Considerations 1363 The security considerations of HTTP over QUIC should be comparable to 1364 those of HTTP/2 with TLS. 1366 The modified SETTINGS format contains nested length elements, which 1367 could pose a security risk to an uncautious implementer. A SETTINGS 1368 frame parser MUST ensure that the length of the frame exactly matches 1369 the length of the settings it contains. 1371 9. IANA Considerations 1373 9.1. Registration of HTTP/QUIC Identification String 1375 This document creates a new registration for the identification of 1376 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 1377 Protocol IDs" registry established in [RFC7301]. 1379 The "hq" string identifies HTTP/QUIC: 1381 Protocol: HTTP over QUIC 1383 Identification Sequence: 0x68 0x71 ("hq") 1385 Specification: This document 1387 9.2. Registration of QUIC Version Hint Alt-Svc Parameter 1389 This document creates a new registration for version-negotiation 1390 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1391 registry established in [RFC7838]. 1393 Parameter: "quic" 1395 Specification: This document, Section 2.1.1 1397 9.3. Frame Types 1399 This document establishes a registry for HTTP/QUIC frame type codes. 1400 The "HTTP/QUIC Frame Type" registry manages an 8-bit space. The 1401 "HTTP/QUIC Frame Type" registry operates under either of the "IETF 1402 Review" or "IESG Approval" policies [RFC8126] for values between 0x00 1403 and 0xef, with values between 0xf0 and 0xff being reserved for 1404 Experimental Use. 1406 While this registry is separate from the "HTTP/2 Frame Type" registry 1407 defined in [RFC7540], it is preferable that the assignments parallel 1408 each other. If an entry is present in only one registry, every 1409 effort SHOULD be made to avoid assigning the corresponding value to 1410 an unrelated operation. 1412 New entries in this registry require the following information: 1414 Frame Type: A name or label for the frame type. 1416 Code: The 8-bit code assigned to the frame type. 1418 Specification: A reference to a specification that includes a 1419 description of the frame layout, its semantics, and flags that the 1420 frame type uses, including any parts of the frame that are 1421 conditionally present based on the value of flags. 1423 The entries in the following table are registered by this document. 1425 +--------------+------+---------------+ 1426 | Frame Type | Code | Specification | 1427 +--------------+------+---------------+ 1428 | DATA | 0x0 | Section 4.2.1 | 1429 | | | | 1430 | HEADERS | 0x1 | Section 4.2.2 | 1431 | | | | 1432 | PRIORITY | 0x2 | Section 4.2.3 | 1433 | | | | 1434 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1435 | | | | 1436 | SETTINGS | 0x4 | Section 4.2.5 | 1437 | | | | 1438 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1439 | | | | 1440 | Reserved | 0x6 | N/A | 1441 | | | | 1442 | GOAWAY | 0x7 | Section 4.2.7 | 1443 | | | | 1444 | Reserved | 0x8 | N/A | 1445 | | | | 1446 | Reserved | 0x9 | N/A | 1447 | | | | 1448 | MAX_PUSH_ID | 0xD | Section 4.2.8 | 1449 +--------------+------+---------------+ 1451 9.4. Settings Parameters 1453 This document establishes a registry for HTTP/QUIC settings. The 1454 "HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC 1455 Settings" registry operates under the "Expert Review" policy 1456 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1457 between and 0xf000 and 0xffff being reserved for Experimental Use. 1458 The designated experts are the same as those for the "HTTP/2 1459 Settings" registry defined in [RFC7540]. 1461 While this registry is separate from the "HTTP/2 Settings" registry 1462 defined in [RFC7540], it is preferable that the assignments parallel 1463 each other. If an entry is present in only one registry, every 1464 effort SHOULD be made to avoid assigning the corresponding value to 1465 an unrelated operation. 1467 New registrations are advised to provide the following information: 1469 Name: A symbolic name for the setting. Specifying a setting name is 1470 optional. 1472 Code: The 16-bit code assigned to the setting. 1474 Specification: An optional reference to a specification that 1475 describes the use of the setting. 1477 The entries in the following table are registered by this document. 1479 +-----------------------+------+-----------------+ 1480 | Setting Name | Code | Specification | 1481 +-----------------------+------+-----------------+ 1482 | HEADER_TABLE_SIZE | 0x1 | Section 4.2.5.2 | 1483 | | | | 1484 | Reserved | 0x2 | N/A | 1485 | | | | 1486 | Reserved | 0x3 | N/A | 1487 | | | | 1488 | Reserved | 0x4 | N/A | 1489 | | | | 1490 | Reserved | 0x5 | N/A | 1491 | | | | 1492 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.2 | 1493 | | | | 1494 | QPACK_BLOCKED_STREAMS | 0x7 | Section 4.2.5.2 | 1495 +-----------------------+------+-----------------+ 1497 9.5. Error Codes 1499 This document establishes a registry for HTTP/QUIC error codes. The 1500 "HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/ 1501 QUIC Error Code" registry operates under the "Expert Review" policy 1502 [RFC8126]. 1504 Registrations for error codes are required to include a description 1505 of the error code. An expert reviewer is advised to examine new 1506 registrations for possible duplication with existing error codes. 1507 Use of existing registrations is to be encouraged, but not mandated. 1509 New registrations are advised to provide the following information: 1511 Name: A name for the error code. Specifying an error code name is 1512 optional. 1514 Code: The 16-bit error code value. 1516 Description: A brief description of the error code semantics, longer 1517 if no detailed specification is provided. 1519 Specification: An optional reference for a specification that 1520 defines the error code. 1522 The entries in the following table are registered by this document. 1524 +----------------------------+--------+------------+----------------+ 1525 | Name | Code | Descriptio | Specification | 1526 | | | n | | 1527 +----------------------------+--------+------------+----------------+ 1528 | STOPPING | 0x0000 | Reserved | [QUIC-TRANSPOR | 1529 | | | by QUIC | T] | 1530 | | | | | 1531 | HTTP_NO_ERROR | 0x0001 | No error | Section 6.1 | 1532 | | | | | 1533 | HTTP_PUSH_REFUSED | 0x0002 | Client | Section 6.1 | 1534 | | | refused | | 1535 | | | pushed | | 1536 | | | content | | 1537 | | | | | 1538 | HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 6.1 | 1539 | | | error | | 1540 | | | | | 1541 | HTTP_PUSH_ALREADY_IN_CACHE | 0x0004 | Pushed | Section 6.1 | 1542 | | | content | | 1543 | | | already | | 1544 | | | cached | | 1545 | | | | | 1546 | HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 6.1 | 1547 | | | longer | | 1548 | | | needed | | 1549 | | | | | 1550 | HTTP_HPACK_DECOMPRESSION_F | 0x0006 | HPACK | Section 6.1 | 1551 | AILED | | cannot | | 1552 | | | continue | | 1553 | | | | | 1554 | HTTP_CONNECT_ERROR | 0x0007 | TCP reset | Section 6.1 | 1555 | | | or error | | 1556 | | | on CONNECT | | 1557 | | | request | | 1558 | | | | | 1559 | HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 6.1 | 1560 | | | generating | | 1561 | | | excessive | | 1562 | | | load | | 1563 | | | | | 1564 | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 6.1 | 1565 | | | HTTP/2 | | 1566 | | | | | 1567 | HTTP_WRONG_STREAM | 0x000A | A frame | Section 6.1 | 1568 | | | was sent | | 1569 | | | on the | | 1570 | | | wrong | | 1571 | | | stream | | 1572 | | | | | 1573 | HTTP_PUSH_LIMIT_EXCEEDED | 0x000B | Maximum | Section 6.1 | 1574 | | | Push ID | | 1575 | | | exceeded | | 1576 | | | | | 1577 | HTTP_DUPLICATE_PUSH | 0x000C | Push ID | Section 6.1 | 1578 | | | was | | 1579 | | | fulfilled | | 1580 | | | multiple | | 1581 | | | times | | 1582 | | | | | 1583 | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 6.1 | 1584 | | | frame | | 1585 | | | formatting | | 1586 | | | or use | | 1587 +----------------------------+--------+------------+----------------+ 1589 10. References 1591 10.1. Normative References 1593 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 1594 Header Compression for HTTP over QUIC", draft-ietf-quic- 1595 qpack-00 (work in progress), May 2018. 1597 [QUIC-TRANSPORT] 1598 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1599 Multiplexed and Secure Transport", draft-ietf-quic- 1600 transport-11 (work in progress), May 2018. 1602 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1603 RFC 793, DOI 10.17487/RFC0793, September 1981, 1604 . 1606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1607 Requirement Levels", BCP 14, RFC 2119, 1608 DOI 10.17487/RFC2119, March 1997, 1609 . 1611 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1612 Specifications: ABNF", STD 68, RFC 5234, 1613 DOI 10.17487/RFC5234, January 2008, 1614 . 1616 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1617 Extensions: Extension Definitions", RFC 6066, 1618 DOI 10.17487/RFC6066, January 2011, 1619 . 1621 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1622 Protocol (HTTP/1.1): Message Syntax and Routing", 1623 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1624 . 1626 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1627 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1628 DOI 10.17487/RFC7231, June 2014, 1629 . 1631 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1632 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1633 DOI 10.17487/RFC7540, May 2015, 1634 . 1636 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1637 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1638 April 2016, . 1640 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1641 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1642 May 2017, . 1644 10.2. Informative References 1646 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1647 "Transport Layer Security (TLS) Application-Layer Protocol 1648 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1649 July 2014, . 1651 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1652 Writing an IANA Considerations Section in RFCs", BCP 26, 1653 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1654 . 1656 10.3. URIs 1658 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1660 [2] https://github.com/quicwg 1662 [3] https://github.com/quicwg/base-drafts/labels/-http 1664 Appendix A. Contributors 1666 The original authors of this specification were Robbie Shade and Mike 1667 Warres. 1669 A substantial portion of Mike's contribution was supported by 1670 Microsoft during his employment there. 1672 Appendix B. Change Log 1674 *RFC Editor's Note:* Please remove this section prior to 1675 publication of a final version of this document. 1677 B.1. Since draft-ietf-quic-http-11 1679 o Moved QPACK table updates and acknowledgments to dedicated streams 1680 (#1121, #1122, #1238) 1682 B.2. Since draft-ietf-quic-http-10 1684 o Settings need to be remembered when attempting and accepting 0-RTT 1685 (#1157, #1207) 1687 B.3. 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.4. Since draft-ietf-quic-http-08 1698 o Clarified connection coalescing rules (#940, #1024) 1700 B.5. 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.6. Since draft-ietf-quic-http-06 1712 o Track changes in QUIC error code usage (#485) 1714 B.7. 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.8. 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.9. Since draft-ietf-quic-http-03 1742 None. 1744 B.10. Since draft-ietf-quic-http-02 1746 o Track changes in transport draft 1748 B.11. 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.12. 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.13. 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