idnits 2.17.1 draft-ietf-quic-http-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-TRANSPORT' ** 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Microsoft 4 Intended status: Standards Track March 13, 2017 5 Expires: September 14, 2017 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-02 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 . 25 Working Group information can be found at https://github.com/quicwg ; 26 source code and issues list for this draft can be found at 27 https://github.com/quicwg/base-drafts/labels/http . 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 http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 14, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 65 2. QUIC Advertisement . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . . . 4 67 3. Connection Establishment . . . . . . . . . . . . . . . . . . 4 68 3.1. Draft Version Identification . . . . . . . . . . . . . . 5 69 4. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 5 70 4.1. Stream 3: Connection Control Stream . . . . . . . . . . . 6 71 4.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 6 72 4.2.1. Header Compression . . . . . . . . . . . . . . . . . 7 73 4.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 8 74 4.3. Stream Priorities . . . . . . . . . . . . . . . . . . . . 9 75 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 10 79 5.2.1. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2.2. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 11 81 5.2.3. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 12 82 5.2.4. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 15 83 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.1. HTTP-Defined QUIC Error Codes . . . . . . . . . . . . . . 16 85 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 17 86 7.1. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 17 87 7.2. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 18 88 7.3. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 19 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 9.1. Registration of HTTP/QUIC Identification String . . . . . 21 92 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 21 93 9.3. Existing Frame Types . . . . . . . . . . . . . . . . . . 21 94 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 22 95 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 23 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 98 10.2. Informative References . . . . . . . . . . . . . . . . . 26 99 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26 100 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 101 B.1. Since draft-ietf-quic-http-01: . . . . . . . . . . . . . 26 102 B.2. Since draft-ietf-quic-http-00: . . . . . . . . . . . . . 27 103 B.3. Since draft-shade-quic-http2-mapping-00: . . . . . . . . 27 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 The QUIC transport protocol has several features that are desirable 109 in a transport for HTTP, such as stream multiplexing, per-stream flow 110 control, and low-latency connection establishment. This document 111 describes a mapping of HTTP semantics over QUIC, drawing heavily on 112 the existing TCP mapping, HTTP/2. Specifically, this document 113 identifies HTTP/2 features that are subsumed by QUIC, and describes 114 how the other features can be implemented atop QUIC. 116 QUIC is described in [QUIC-TRANSPORT]. For a full description of 117 HTTP/2, see [RFC7540]. 119 1.1. Notational Conventions 121 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 122 document. It's not shouting; when they are capitalized, they have 123 the special meaning defined in [RFC2119]. 125 2. QUIC Advertisement 127 An HTTP origin advertises the availability of an equivalent HTTP/QUIC 128 endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC 129 frame ([RFC7838]), using the ALPN token defined in Section 3. 131 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 132 response that HTTP/QUIC was available on UDP port 443 at the same 133 hostname by including the following header in any response: 135 Alt-Svc: hq=":443" 137 On receipt of an Alt-Svc header indicating HTTP/QUIC support, a 138 client MAY attempt to establish a QUIC connection to the indicated 139 host and port and, if successful, send HTTP requests using the 140 mapping described in this document. 142 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 143 connection establishment failure, in which case the client SHOULD 144 continue using the existing connection or try another alternative 145 endpoint offered by the origin. 147 2.1. QUIC Version Hints 149 This document defines the "quic" parameter for Alt-Svc, which MAY be 150 used to provide version-negotiation hints to HTTP/QUIC clients. QUIC 151 versions are four-octet sequences with no additional constraints on 152 format. Syntax: 154 quic = version-number 155 version-number = 1*8HEXDIG; hex-encoded QUIC version 157 Leading zeros SHOULD be omitted for brevity. When multiple versions 158 are supported, the "quic" parameter MAY be repeated multiple times in 159 a single Alt-Svc entry. For example, if a server supported both 160 version 0x00000001 and the version rendered in ASCII as "Q034", it 161 could specify the following header: 163 Alt-Svc: hq=":443";quic=1;quic=51303334 165 Where multiple versions are listed, the order of the values reflects 166 the server's preference (with the first value being the most 167 preferred version). Origins SHOULD list only versions which are 168 supported by the alternative, but MAY omit supported versions for any 169 reason. 171 3. Connection Establishment 173 HTTP/QUIC connections are established as described in 174 [QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support 175 is indicated by selecting the ALPN token "hq" in the crypto 176 handshake. 178 While connection-level options pertaining to the core QUIC protocol 179 are set in the initial crypto handshake, HTTP-specific settings are 180 conveyed in the SETTINGS frame. After the QUIC connection is 181 established, a SETTINGS frame (Section 5.2.3) MUST be sent as the 182 initial frame of the HTTP control stream (StreamID 3, see Section 4). 183 The server MUST NOT send data on any other stream until the client's 184 SETTINGS frame has been received. 186 3.1. Draft Version Identification 188 *RFC Editor's Note:* Please remove this section prior to 189 publication of a final version of this document. 191 Only implementations of the final, published RFC can identify 192 themselves as "hq". Until such an RFC exists, implementations MUST 193 NOT identify themselves using this string. 195 Implementations of draft versions of the protocol MUST add the string 196 "-" and the corresponding draft number to the identifier. For 197 example, draft-ietf-quic-http-01 is identified using the string "hq- 198 01". 200 Non-compatible experiments that are based on these draft versions 201 MUST append the string "-" and an experiment name to the identifier. 202 For example, an experimental implementation based on draft-ietf-quic- 203 http-09 which reserves an extra stream for unsolicited transmission 204 of 1980s pop music might identify itself as "hq-09-rickroll". Note 205 that any label MUST conform to the "token" syntax defined in 206 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 207 coordinate their experiments on the quic@ietf.org mailing list. 209 4. Stream Mapping and Usage 211 A QUIC stream provides reliable in-order delivery of bytes, but makes 212 no guarantees about order of delivery with regard to bytes on other 213 streams. On the wire, data is framed into QUIC STREAM frames, but 214 this framing is invisible to the HTTP framing layer. A QUIC receiver 215 buffers and orders received STREAM frames, exposing the data 216 contained within as a reliable byte stream to the application. 218 QUIC reserves Stream 1 for crypto operations (the handshake, crypto 219 config updates). Stream 3 is reserved for sending and receiving HTTP 220 control frames, and is analogous to HTTP/2's Stream 0. This 221 connection control stream is considered critical to the HTTP 222 connection. If the connection control stream is closed for any 223 reason, this MUST be treated as a connection error of type 224 QUIC_CLOSED_CRITICAL_STREAM. 226 When HTTP headers and data are sent over QUIC, the QUIC layer handles 227 most of the stream management. An HTTP request/response consumes a 228 pair of streams: This means that the client's first request occurs on 229 QUIC streams 5 and 7, the second on stream 9 and 11, and so on. The 230 server's first push consumes streams 2 and 4. This amounts to the 231 second least-significant bit differentiating the two streams in a 232 request. 234 The lower-numbered stream is called the message control stream and 235 carries frames related to the request/response, including HEADERS. 236 The higher-numbered stream is the data stream and carries the 237 request/response body with no additional framing. Note that a 238 request or response without a body will cause this stream to be half- 239 closed in the corresponding direction without transferring data. 241 Because the message control stream contains HPACK data which 242 manipulates connection-level state, the message control stream MUST 243 NOT be closed with a stream-level error. If an implementation 244 chooses to reject a request with a QUIC error code, it MUST trigger a 245 QUIC RST_STREAM on the data stream only. An implementation MAY close 246 (FIN) a message control stream without completing a full HTTP message 247 if the data stream has been abruptly closed. Data on message control 248 streams MUST be fully consumed, or the connection terminated. 250 All message control streams are considered critical to the HTTP 251 connection. If a message control stream is terminated abruptly for 252 any reason, this MUST be treated as a connection error of type 253 HTTP_RST_CONTROL_STREAM. When a message control stream terminates 254 cleanly, if the last frame on the stream was truncated, this MUST be 255 treated as a connection error (see HTTP_MALFORMED_* in Section 6.1). 257 Pairs of streams must be utilized sequentially, with no gaps. The 258 data stream is opened at the same time as the message control stream 259 is opened and is closed after transferring the body. The data stream 260 is closed immediately after sending the request headers if there is 261 no body. 263 HTTP does not need to do any separate multiplexing when using QUIC - 264 data sent over a QUIC stream always maps to a particular HTTP 265 transaction. Requests and responses are considered complete when the 266 corresponding QUIC streams are closed in the appropriate direction. 268 4.1. Stream 3: Connection Control Stream 270 Since most connection-level concerns will be managed by QUIC, the 271 primary use of Stream 3 will be for the SETTINGS frame when the 272 connection opens and for PRIORITY frames subsequently. 274 4.2. HTTP Message Exchanges 276 A client sends an HTTP request on a new pair of QUIC streams. A 277 server sends an HTTP response on the same streams as the request. 279 An HTTP message (request or response) consists of: 281 1. one header block (see Section 5.2.1) on the control stream 282 containing the message headers (see [RFC7230], Section 3.2), 284 2. the payload body (see [RFC7230], Section 3.3), sent on the data 285 stream, 287 3. optionally, one header block on the control stream containing the 288 trailer-part, if present (see [RFC7230], Section 4.1.2). 290 In addition, prior to sending the message header block indicated 291 above, a response may contain zero or more header blocks on the 292 control stream containing the message headers of informational (1xx) 293 HTTP responses (see [RFC7230], Section 3.2 and [RFC7231], 294 Section 6.2). 296 The data stream MUST be half-closed immediately after the transfer of 297 the body. If the message does not contain a body, the corresponding 298 data stream MUST still be half-closed without transferring any data. 299 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 300 MUST NOT be used. 302 Trailing header fields are carried in an additional header block on 303 the message control stream. Such a header block is a sequence of 304 HEADERS frames with End Header Block set on the last frame. Senders 305 MUST send only one header block in the trailers section; receivers 306 MUST decode any subsequent header blocks in order to maintain HPACK 307 decoder state, but the resulting output MUST be discarded. 309 An HTTP request/response exchange fully consumes a pair of streams. 310 After sending a request, a client closes the streams for sending; 311 after sending a response, the server closes its streams for sending 312 and the QUIC streams are fully closed. 314 A server can send a complete response prior to the client sending an 315 entire request if the response does not depend on any portion of the 316 request that has not been sent and received. When this is true, a 317 server MAY request that the client abort transmission of a request 318 without error by sending a RST_STREAM with an error code of NO_ERROR 319 after sending a complete response and closing its stream. Clients 320 MUST NOT discard responses as a result of receiving such a 321 RST_STREAM, though clients can always discard responses at their 322 discretion for other reasons. 324 4.2.1. Header Compression 326 HTTP/QUIC uses HPACK header compression as described in [RFC7541]. 327 HPACK was designed for HTTP/2 with the assumption of in-order 328 delivery such as that provided by TCP. A sequence of encoded header 329 blocks must arrive (and be decoded) at an endpoint in the same order 330 in which they were encoded. This ensures that the dynamic state at 331 the two endpoints remains in sync. 333 QUIC streams provide in-order delivery of data sent on those streams, 334 but there are no guarantees about order of delivery between streams. 335 To achieve in-order delivery of HEADERS frames in QUIC, the HPACK- 336 bearing frames contain a counter which can be used to ensure in-order 337 processing. Data (request/response bodies) which arrive out of order 338 are buffered until the corresponding HEADERS arrive. 340 This does introduce head-of-line blocking: if the packet containing 341 HEADERS for stream N is lost or reordered then the HEADERS for stream 342 N+4 cannot be processed until it has been retransmitted successfully, 343 even though the HEADERS for stream N+4 may have arrived. 345 DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- 346 invariant? How much do we need to retain compatibility with 347 HTTP/2's HPACK? 349 4.2.2. The CONNECT Method 351 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 352 used with HTTP proxies to establish a TLS session with an origin 353 server for the purposes of interacting with "https" resources. In 354 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 355 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 356 establish a tunnel over a single HTTP/2 stream to a remote host for 357 similar purposes. 359 A CONNECT request in HTTP/QUIC functions in the same manner as in 360 HTTP/2. The request MUST be formatted as described in [RFC7540], 361 Section 8.3. A CONNECT request that does not conform to these 362 restrictions is malformed. The message data stream MUST NOT be 363 closed at the end of the request. 365 A proxy that supports CONNECT establishes a TCP connection 366 ([RFC0793]) to the server identified in the ":authority" pseudo- 367 header field. Once this connection is successfully established, the 368 proxy sends a HEADERS frame containing a 2xx series status code to 369 the client, as defined in [RFC7231], Section 4.3.6, on the message 370 control stream. 372 All QUIC STREAM frames on the message data stream correspond to data 373 sent on the TCP connection. Any QUIC STREAM frame sent by the client 374 is transmitted by the proxy to the TCP server; data received from the 375 TCP server is written to the data stream by the proxy. Note that the 376 size and number of TCP segments is not guaranteed to map predictably 377 to the size and number of QUIC STREAM frames. 379 The TCP connection can be closed by either peer. When the client 380 half-closes the data stream, the proxy will set the FIN bit on its 381 connection to the TCP server. When the proxy receives a packet with 382 the FIN bit set, it will half-close the corresponding data stream. 383 TCP connections which remain half-closed in a single direction are 384 not invalid, but are often handled poorly by servers, so clients 385 SHOULD NOT half-close connections on which they are still expecting 386 data. 388 A TCP connection error is signaled with RST_STREAM. A proxy treats 389 any error in the TCP connection, which includes receiving a TCP 390 segment with the RST bit set, as a stream error of type 391 HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send 392 a TCP segment with the RST bit set if it detects an error with the 393 stream or the QUIC connection. 395 4.3. Stream Priorities 397 HTTP/QUIC uses the priority scheme described in [RFC7540] 398 Section 5.3. In this priority scheme, a given stream can be 399 designated as dependent upon another stream, which expresses the 400 preference that the latter stream (the "parent" stream) be allocated 401 resources before the former stream (the "dependent" stream). Taken 402 together, the dependencies across all streams in a connection form a 403 dependency tree. The structure of the dependency tree changes as 404 PRIORITY frames add, remove, or change the dependency links between 405 streams. 407 For consistency's sake, all PRIORITY frames MUST refer to the message 408 control stream of the dependent request, not the data stream. 410 4.4. Server Push 412 HTTP/QUIC supports server push as described in [RFC7540]. During 413 connection establishment, the client indicates whether it is willing 414 to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the 415 SETTINGS frame (see Section 3), which defaults to 1 (true). 417 As with server push for HTTP/2, the server initiates a server push by 418 sending a PUSH_PROMISE frame containing the StreamID of the stream to 419 be pushed, as well as request header fields attributed to the 420 request. The PUSH_PROMISE frame is sent on the control stream of the 421 associated (client-initiated) request, while the Promised Stream ID 422 field specifies the Stream ID of the control stream for the server- 423 initiated request. 425 The server push response is conveyed in the same way as a non-server- 426 push response, with response headers and (if present) trailers 427 carried by HEADERS frames sent on the control stream, and response 428 body (if any) sent via the corresponding data stream. 430 5. HTTP Framing Layer 432 Frames are used only on the connection (stream 3) and message 433 (streams 5, 9, etc.) control streams. Other streams carry data 434 payload and are not framed at the HTTP layer. 436 This section describes HTTP framing in QUIC and highlights some 437 differences from HTTP/2 framing. For more detail on differences from 438 HTTP/2, see Section 7.1. 440 5.1. Frame Layout 442 All frames have the following format: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Length (16) | Type (8) | Flags (8) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Frame Payload (*) ... 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 1: HTTP/QUIC frame format 454 5.2. Frame Definitions 456 5.2.1. HEADERS 458 The HEADERS frame (type=0x1) is used to carry part of a header set, 459 compressed using HPACK [RFC7541]. 461 One flag is defined: 463 End Header Block (0x4): This frame concludes a header block. 465 A HEADERS frame with any other flags set MUST be treated as a 466 connection error of type HTTP_MALFORMED_HEADERS. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Sequence? (16) | Header Block Fragment (*)... 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 2: HEADERS frame payload 476 The HEADERS frame payload has the following fields: 478 Sequence Number: Present only on the first frame of a header block 479 sequence. This MUST be set to zero on the first header block 480 sequence, and incremented on each header block. 482 The next frame on the same stream after a HEADERS frame without the 483 EHB flag set MUST be another HEADERS frame. A receiver MUST treat 484 the receipt of any other type of frame as a stream error of type 485 HTTP_INTERRUPTED_HEADERS. (Note that QUIC can intersperse data from 486 other streams between frames, or even during transmission of frames, 487 so multiplexing is not blocked by this requirement.) 489 A full header block is contained in a sequence of zero or more 490 HEADERS frames without EHB set, followed by a HEADERS frame with EHB 491 set. 493 On receipt, header blocks (HEADERS, PUSH_PROMISE) MUST be processed 494 by the HPACK decoder in sequence. If a block is missing, all 495 subsequent HPACK frames MUST be held until it arrives, or the 496 connection terminated. 498 When the Sequence counter reaches its maximum value (0xFFFF), the 499 next increment returns it to zero. An endpoint MUST NOT wrap the 500 Sequence counter to zero until the previous zero-value header block 501 has been confirmed received. 503 5.2.2. PRIORITY 505 The PRIORITY (type=0x02) frame specifies the sender-advised priority 506 of a stream and is substantially different from [RFC7540]. In order 507 to support ordering, it MUST be sent only on the connection control 508 stream. The format has been modified to accommodate not being sent 509 on-stream and the larger stream ID space of QUIC. 511 The semantics of the Stream Dependency, Weight, and E flag are the 512 same as in HTTP/2. 514 The flags defined are: 516 E (0x01): Indicates that the stream dependency is exclusive (see 517 [RFC7540] Section 5.3). 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Prioritized Stream (32) | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Dependent Stream (32) | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Weight (8) | 527 +-+-+-+-+-+-+-+-+ 529 Figure 3: PRIORITY frame payload 531 The HEADERS frame payload has the following fields: 533 Prioritized Stream: A 32-bit stream identifier for the message 534 control stream whose priority is being updated. 536 Stream Dependency: A 32-bit stream identifier for the stream that 537 this stream depends on (see Section 4.3 and {!RFC7540}} 538 Section 5.3). 540 Weight: An unsigned 8-bit integer representing a priority weight for 541 the stream (see [RFC7540] Section 5.3). Add one to the value to 542 obtain a weight between 1 and 256. 544 A PRIORITY frame MUST have a payload length of nine octets. A 545 PRIORITY frame of any other length MUST be treated as a connection 546 error of type HTTP_MALFORMED_PRIORITY. 548 5.2.3. SETTINGS 550 The SETTINGS frame (type=0x4) conveys configuration parameters that 551 affect how endpoints communicate, such as preferences and constraints 552 on peer behavior, and is substantially different from [RFC7540]. 553 Individually, a SETTINGS parameter can also be referred to as a 554 "setting". 556 SETTINGS parameters are not negotiated; they describe characteristics 557 of the sending peer, which can be used by the receiving peer. 558 However, a negotiation can be implied by the use of SETTINGS - a peer 559 uses SETTINGS to advertise a set of supported values. The recipient 560 can then choose which entries from this list are also acceptable and 561 proceed with the value it has chosen. (This choice could be 562 announced in a field of an extension frame, or in its own value in 563 SETTINGS.) 564 Different values for the same parameter can be advertised by each 565 peer. For example, a client might permit a very large HPACK state 566 table while a server chooses to use a small one to conserve memory. 568 Parameters MUST NOT occur more than once. A receiver MAY treat the 569 presence of the same parameter more than once as a connection error 570 of type HTTP_MALFORMED_SETTINGS. 572 The SETTINGS frame defines no flags. 574 The payload of a SETTINGS frame consists of zero or more parameters, 575 each consisting of an unsigned 16-bit setting identifier and a 576 length-prefixed binary value. 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Identifier (16) | Length (16) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Contents (?) ... 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 4: SETTINGS value format 588 A zero-length content indicates that the setting value is a Boolean 589 and true. False is indicated by the absence of the setting. 591 Non-zero-length values MUST be compared against the remaining length 592 of the SETTINGS frame. Any value which purports to cross the end of 593 the frame MUST cause the SETTINGS frame to be considered malformed 594 and trigger a connection error of type HTTP_MALFORMED_SETTINGS. 596 An implementation MUST ignore the contents for any SETTINGS 597 identifier it does not understand. 599 SETTINGS frames always apply to a connection, never a single stream. 600 A SETTINGS frame MUST be sent as the first frame of the connection 601 control stream (see Section 4) by each peer, and MUST NOT be sent 602 subsequently or on any other stream. If an endpoint receives an 603 SETTINGS frame on a different stream, the endpoint MUST respond with 604 a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an 605 endpoint receives a second SETTINGS frame, the endpoint MUST respond 606 with a connection error of type HTTP_MULTIPLE_SETTINGS. 608 The SETTINGS frame affects connection state. A badly formed or 609 incomplete SETTINGS frame MUST be treated as a connection error 610 (Section 5.4.1) of type HTTP_MALFORMED_SETTINGS. 612 5.2.3.1. Integer encoding 614 Settings which are integers are transmitted in network byte order. 615 Leading zero octets are permitted, but implementations SHOULD use 616 only as many bytes as are needed to represent the value. An integer 617 MUST NOT be represented in more bytes than would be used to transfer 618 the maximum permitted value. 620 5.2.3.2. Defined SETTINGS Parameters 622 The following settings are defined in HTTP/QUIC: 624 SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of 625 2^32 - 1. 627 SETTINGS_DISABLE_PUSH (0x2): Transmitted as a Boolean; replaces 628 SETTINGS_ENABLE_PUSH 630 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value 631 of 2^32 - 1. 633 5.2.3.3. Usage in 0-RTT 635 When a 0-RTT QUIC connection is being used, the client's initial 636 requests will be sent before the arrival of the server's SETTINGS 637 frame. Clients SHOULD cache at least the following settings about 638 servers: 640 o SETTINGS_HEADER_TABLE_SIZE 642 o SETTINGS_MAX_HEADER_LIST_SIZE 644 Clients MUST comply with cached settings until the server's current 645 settings are received. If a client does not have cached values, it 646 SHOULD assume the following values: 648 o SETTINGS_HEADER_TABLE_SIZE: 0 octets 650 o SETTINGS_MAX_HEADER_LIST_SIZE: 16,384 octets 652 Servers MAY continue processing data from clients which exceed its 653 current configuration during the initial flight. In this case, the 654 client MUST apply the new settings immediately upon receipt. 656 If the connection is closed because these or other constraints were 657 violated during the 0-RTT flight (e.g. with 658 HTTP_HPACK_DECOMPRESSION_FAILED), clients MAY establish a new 659 connection and retry any 0-RTT requests using the settings sent by 660 the server on the closed connection. (This assumes that only 661 requests that are safe to retry are sent in 0-RTT.) If the 662 connection was closed before the SETTINGS frame was received, clients 663 SHOULD discard any cached values and use the defaults above on the 664 next connection. 666 5.2.4. PUSH_PROMISE 668 The PUSH_PROMISE frame (type=0x05) is used to carry a request header 669 set from server to client, as in HTTP/2. It defines no flags. 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Promised Stream ID (32) | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Sequence? (16) | Header Block (*) ... 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Figure 5: PUSH_PROMISE frame payload 681 The payload consists of: 683 Promised Stream ID: A 32-bit Stream ID indicating the QUIC stream on 684 which the response headers will be sent. (The response body 685 stream is implied by the headers stream, as defined in Section 4.) 687 HPACK Sequence: A sixteen-bit counter, equivalent to the Sequence 688 field in HEADERS 690 Payload: HPACK-compressed request headers for the promised response. 692 6. Error Handling 694 QUIC allows the application to abruptly terminate individual streams 695 or the entire connection when an error is encountered. These are 696 referred to as "stream errors" or "connection errors" and are 697 described in more detail in [QUIC-TRANSPORT]. 699 HTTP/QUIC requires that only data streams be terminated abruptly. 700 Terminating a message control stream will result in an error of type 701 HTTP_RST_CONTROL_STREAM. 703 This section describes HTTP-specific error codes which can be used to 704 express the cause of a connection or stream error. 706 6.1. HTTP-Defined QUIC Error Codes 708 QUIC allocates error codes 0x0000-0x3FFF to application protocol 709 definition. The following error codes are defined by HTTP for use in 710 QUIC RST_STREAM, GOAWAY, and CONNECTION_CLOSE frames. 712 HTTP_PUSH_REFUSED (0x01): The server has attempted to push content 713 which the client will not accept on this connection. 715 HTTP_INTERNAL_ERROR (0x02): An internal error has occurred in the 716 HTTP stack. 718 HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push 719 content which the client has cached. 721 HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the 722 requested data. 724 HTTP_HPACK_DECOMPRESSION_FAILED (0x05): HPACK failed to decompress a 725 frame and cannot continue. 727 HTTP_CONNECT_ERROR (0x06): The connection established in response to 728 a CONNECT request was reset or abnormally closed. 730 HTTP_EXCESSIVE_LOAD (0x07): The endpoint detected that its peer is 731 exhibiting a behavior that might be generating excessive load. 733 HTTP_VERSION_FALLBACK (0x08): The requested operation cannot be 734 served over HTTP/QUIC. The peer should retry over HTTP/2. 736 HTTP_MALFORMED_HEADERS (0x09): A HEADERS frame has been received 737 with an invalid format. 739 HTTP_MALFORMED_PRIORITY (0x0A): A PRIORITY frame has been received 740 with an invalid format. 742 HTTP_MALFORMED_SETTINGS (0x0B): A SETTINGS frame has been received 743 with an invalid format. 745 HTTP_MALFORMED_PUSH_PROMISE (0x0C): A PUSH_PROMISE frame has been 746 received with an invalid format. 748 HTTP_INTERRUPTED_HEADERS (0x0E): A HEADERS frame without the End 749 Header Block flag was followed by a frame other than HEADERS. 751 HTTP_SETTINGS_ON_WRONG_STREAM (0x0F): A SETTINGS frame was received 752 on a request control stream. 754 HTTP_MULTIPLE_SETTINGS (0x10): More than one SETTINGS frame was 755 received. 757 HTTP_RST_CONTROL_STREAM (0x11): A message control stream closed 758 abruptly. 760 7. Considerations for Transitioning from HTTP/2 762 HTTP/QUIC is strongly informed by HTTP/2, and bears many 763 similarities. This section points out important differences from 764 HTTP/2 and describes how to map HTTP/2 extensions into HTTP/QUIC. 766 7.1. HTTP Frame Types 768 Many framing concepts from HTTP/2 can be elided away on QUIC, because 769 the transport deals with them. Because frames are already on a 770 stream, they can omit the stream number. Because frames do not block 771 multiplexing (QUIC's multiplexing occurs below this layer), the 772 support for variable-maximum-length packets can be removed. Because 773 stream termination is handled by QUIC, an END_STREAM flag is not 774 required. 776 Frame payloads are largely drawn from [RFC7540]. However, QUIC 777 includes many features (e.g. flow control) which are also present in 778 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 779 As a result, several HTTP/2 frame types are not required in HTTP/ 780 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 781 has been reserved in order to maximize portability between HTTP/2 and 782 HTTP/QUIC implementations. However, even equivalent frames between 783 the two mappings are not identical. 785 Many of the differences arise from the fact that HTTP/2 provides an 786 absolute ordering between frames across all streams, while QUIC 787 provides this guarantee on each stream only. As a result, if a frame 788 type makes assumptions that frames from different streams will still 789 be received in the order sent, HTTP/QUIC will break them. 791 For example, implicit in the HTTP/2 prioritization scheme is the 792 notion of in-order delivery of priority changes (i.e., dependency 793 tree mutations): since operations on the dependency tree such as 794 reparenting a subtree are not commutative, both sender and receiver 795 must apply them in the same order to ensure that both sides have a 796 consistent view of the stream dependency tree. HTTP/2 specifies 797 priority assignments in PRIORITY frames and (optionally) in HEADERS 798 frames. To achieve in-order delivery of priority changes in HTTP/ 799 QUIC, PRIORITY frames are sent on the connection control stream and 800 the PRIORITY section is removed from the HEADERS frame. 802 Other than this issue, frame type HTTP/2 extensions are typically 803 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 3 804 in HTTP/QUIC. 806 Below is a listing of how each HTTP/2 frame type is mapped: 808 DATA (0x0): Instead of DATA frames, HTTP/QUIC uses a separate data 809 stream. See Section 4. 811 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 812 not supported. A separate PRIORITY frame MUST be used. Padding 813 is not defined in HTTP/QUIC frames. See Section 5.2.1. 815 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 816 the connection control stream. See Section 5.2.2. 818 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 819 provides stream lifecycle management. 821 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 822 the connection. See Section 5.2.3 and Section 7.2. 824 PUSH_PROMISE (0x5): See Section 5.2.4. 826 PING (0x6): PING frames do not exist, since QUIC provides equivalent 827 functionality. 829 GOAWAY (0x7): GOAWAY frames do not exist, since QUIC provides 830 equivalent functionality. 832 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 833 provides flow control. 835 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 836 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted, and 837 HEADERS frames can be used in series. 839 The IANA registry of frame types has been updated in Section 9.3 to 840 include references to the definition for each frame type in HTTP/2 841 and in HTTP/QUIC. Frames not defined as available in HTTP/QUIC 842 SHOULD NOT be sent and SHOULD be ignored as unknown on receipt. 844 7.2. HTTP/2 SETTINGS Parameters 846 An important difference from HTTP/2 is that settings are sent once, 847 at the beginning of the connection, and thereafter cannot change. 848 This eliminates many corner cases around synchronization of changes. 850 Some transport-level options that HTTP/2 specifies via the SETTINGS 851 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 852 HTTP-level options that are retained in HTTP/QUIC have the same value 853 as in HTTP/2. 855 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 857 SETTINGS_HEADER_TABLE_SIZE: See Section 5.2.3.2. 859 SETTINGS_ENABLE_PUSH: See SETTINGS_DISABLE_PUSH in Section 5.2.3.2. 861 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC requires the maximum number of 862 incoming streams per connection to be specified in the initial 863 transport handshake. Specifying SETTINGS_MAX_CONCURRENT_STREAMS 864 in the SETTINGS frame is an error. 866 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 867 connection flow control window sizes to be specified in the 868 initial transport handshake. Specifying 869 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 871 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 872 QUIC. Specifying it in the SETTINGS frame is an error. 874 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 5.2.3.2. 876 Settings defined by extensions to HTTP/2 MAY be expressed as integers 877 with a maximum value of 2^32-1, if they are applicable to HTTP/QUIC, 878 but SHOULD have a specification describing their usage. Fields for 879 this purpose have been added to the IANA registry in Section 9.4. 881 7.3. HTTP/2 Error Codes 883 QUIC has the same concepts of "stream" and "connection" errors that 884 HTTP/2 provides. However, because the error code space is shared 885 between multiple components, there is no direct portability of HTTP/2 886 error codes. 888 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to QUIC 889 error codes as follows: 891 NO_ERROR (0x0): QUIC_NO_ERROR 893 PROTOCOL_ERROR (0x1): No single mapping. See new HTTP_MALFORMED_* 894 error codes defined in Section 6.1. 896 INTERNAL_ERROR (0x2) HTTP_INTERNAL_ERROR in Section 6.1. 898 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 899 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 900 from the QUIC layer. 902 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 903 SETTINGS is defined. 905 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 906 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 907 from the QUIC layer. 909 FRAME_SIZE_ERROR (0x6) No single mapping. See new error codes 910 defined in Section 6.1. 912 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 913 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 914 QUIC layer. 916 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 918 COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in 919 Section 6.1. 921 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 923 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 925 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 926 provide sufficient security on all connections. 928 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 930 Error codes defined by HTTP/2 extensions need to be re-registered for 931 HTTP/QUIC if still applicable. See Section 9.5. 933 8. Security Considerations 935 The security considerations of HTTP over QUIC should be comparable to 936 those of HTTP/2. 938 The modified SETTINGS format contains nested length elements, which 939 could pose a security risk to an uncautious implementer. A SETTINGS 940 frame parser MUST ensure that the length of the frame exactly matches 941 the length of the settings it contains. 943 9. IANA Considerations 945 9.1. Registration of HTTP/QUIC Identification String 947 This document creates a new registration for the identification of 948 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 949 Protocol IDs" registry established in [RFC7301]. 951 The "hq" string identifies HTTP/QUIC: 953 Protocol: HTTP over QUIC 955 Identification Sequence: 0x68 0x71 ("hq") 957 Specification: This document 959 9.2. Registration of QUIC Version Hint Alt-Svc Parameter 961 This document creates a new registration for version-negotiation 962 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 963 registry established in [RFC7838]. 965 Parameter: "quic" 967 Specification: This document, Section 2.1 969 9.3. Existing Frame Types 971 This document adds two new columns to the "HTTP/2 Frame Type" 972 registry defined in [RFC7540]: 974 Supported Protocols: Indicates which associated protocols use the 975 frame type. Values MUST be one of: 977 * "HTTP/2 only" 979 * "HTTP/QUIC only" 981 * "Both" 983 HTTP/QUIC Specification: Indicates where this frame's behavior over 984 QUIC is defined; required if the frame is supported over QUIC. 986 Values for existing registrations are assigned by this document: 988 +---------------+---------------------+-------------------------+ 989 | Frame Type | Supported Protocols | HTTP/QUIC Specification | 990 +---------------+---------------------+-------------------------+ 991 | DATA | HTTP/2 only | N/A | 992 | | | | 993 | HEADERS | Both | Section 5.2.1 | 994 | | | | 995 | PRIORITY | Both | Section 5.2.2 | 996 | | | | 997 | RST_STREAM | HTTP/2 only | N/A | 998 | | | | 999 | SETTINGS | Both | Section 5.2.3 | 1000 | | | | 1001 | PUSH_PROMISE | Both | Section 5.2.4 | 1002 | | | | 1003 | PING | HTTP/2 only | N/A | 1004 | | | | 1005 | GOAWAY | HTTP/2 only | N/A | 1006 | | | | 1007 | WINDOW_UPDATE | HTTP/2 only | N/A | 1008 | | | | 1009 | CONTINUATION | HTTP/2 only | N/A | 1010 +---------------+---------------------+-------------------------+ 1012 The "Specification" column is renamed to "HTTP/2 specification" and 1013 is only required if the frame is supported over HTTP/2. 1015 9.4. Settings Parameters 1017 This document adds two new columns to the "HTTP/2 Settings" registry 1018 defined in [RFC7540]: 1020 Supported Protocols: Indicates which associated protocols use the 1021 setting. Values MUST be one of: 1023 * "HTTP/2 only" 1025 * "HTTP/QUIC only" 1027 * "Both" 1029 HTTP/QUIC Specification: Indicates where this setting's behavior 1030 over QUIC is defined; required if the frame is supported over 1031 QUIC. 1033 Values for existing registrations are assigned by this document: 1035 +-------------------------+------------------+----------------------+ 1036 | Setting Name | Supported | HTTP/QUIC | 1037 | | Protocols | Specification | 1038 +-------------------------+------------------+----------------------+ 1039 | HEADER_TABLE_SIZE | Both | Section 5.2.3.2 | 1040 | | | | 1041 | ENABLE_PUSH / | Both | Section 5.2.3.2 | 1042 | DISABLE_PUSH | | | 1043 | | | | 1044 | MAX_CONCURRENT_STREAMS | HTTP/2 Only | N/A | 1045 | | | | 1046 | INITIAL_WINDOW_SIZE | HTTP/2 Only | N/A | 1047 | | | | 1048 | MAX_FRAME_SIZE | HTTP/2 Only | N/A | 1049 | | | | 1050 | MAX_HEADER_LIST_SIZE | Both | Section 5.2.3.2 | 1051 +-------------------------+------------------+----------------------+ 1053 The "Specification" column is renamed to "HTTP/2 Specification" and 1054 is only required if the setting is supported over HTTP/2. 1056 9.5. Error Codes 1058 This document establishes a registry for HTTP/QUIC error codes. The 1059 "HTTP/QUIC Error Code" registry manages a 30-bit space. The "HTTP/ 1060 QUIC Error Code" registry operates under the "Expert Review" policy 1061 [RFC5226]. 1063 Registrations for error codes are required to include a description 1064 of the error code. An expert reviewer is advised to examine new 1065 registrations for possible duplication with existing error codes. 1066 Use of existing registrations is to be encouraged, but not mandated. 1068 New registrations are advised to provide the following information: 1070 Name: A name for the error code. Specifying an error code name is 1071 optional. 1073 Code: The 30-bit error code value. 1075 Description: A brief description of the error code semantics, longer 1076 if no detailed specification is provided. 1078 Specification: An optional reference for a specification that 1079 defines the error code. 1081 The entries in the following table are registered by this document. 1083 +------------------------------+-----+--------------+---------------+ 1084 | Name | Cod | Description | Specification | 1085 | | e | | | 1086 +------------------------------+-----+--------------+---------------+ 1087 | HTTP_PUSH_REFUSED | 0x0 | Client | Section 6.1 | 1088 | | 1 | refused | | 1089 | | | pushed | | 1090 | | | content | | 1091 | | | | | 1092 | HTTP_INTERNAL_ERROR | 0x0 | Internal | Section 6.1 | 1093 | | 2 | error | | 1094 | | | | | 1095 | HTTP_PUSH_ALREADY_IN_CACHE | 0x0 | Pushed | Section 6.1 | 1096 | | 3 | content | | 1097 | | | already | | 1098 | | | cached | | 1099 | | | | | 1100 | HTTP_REQUEST_CANCELLED | 0x0 | Data no | Section 6.1 | 1101 | | 4 | longer | | 1102 | | | needed | | 1103 | | | | | 1104 | HTTP_HPACK_DECOMPRESSION_FAI | 0x0 | HPACK cannot | Section 6.1 | 1105 | LED | 5 | continue | | 1106 | | | | | 1107 | HTTP_CONNECT_ERROR | 0x0 | TCP reset or | Section 6.1 | 1108 | | 6 | error on | | 1109 | | | CONNECT | | 1110 | | | request | | 1111 | | | | | 1112 | HTTP_EXCESSIVE_LOAD | 0x0 | Peer | Section 6.1 | 1113 | | 7 | generating | | 1114 | | | excessive | | 1115 | | | load | | 1116 | | | | | 1117 | HTTP_VERSION_FALLBACK | 0x0 | Retry over | Section 6.1 | 1118 | | 8 | HTTP/2 | | 1119 | | | | | 1120 | HTTP_MALFORMED_HEADERS | 0x0 | Invalid | Section 6.1 | 1121 | | 9 | HEADERS | | 1122 | | | frame | | 1123 | | | | | 1124 | HTTP_MALFORMED_PRIORITY | 0x0 | Invalid | Section 6.1 | 1125 | | A | PRIORITY | | 1126 | | | frame | | 1127 | | | | | 1128 | HTTP_MALFORMED_SETTINGS | 0x0 | Invalid | Section 6.1 | 1129 | | B | SETTINGS | | 1130 | | | frame | | 1131 | | | | | 1132 | HTTP_MALFORMED_PUSH_PROMISE | 0x0 | Invalid | Section 6.1 | 1133 | | C | PUSH_PROMISE | | 1134 | | | frame | | 1135 | | | | | 1136 | HTTP_INTERRUPTED_HEADERS | 0x0 | Incomplete | Section 6.1 | 1137 | | E | HEADERS | | 1138 | | | block | | 1139 | | | | | 1140 | HTTP_SETTINGS_ON_WRONG_STREA | 0x0 | SETTINGS | Section 6.1 | 1141 | M | F | frame on a | | 1142 | | | request | | 1143 | | | control | | 1144 | | | stream | | 1145 | | | | | 1146 | HTTP_MULTIPLE_SETTINGS | 0x1 | Multiple | Section 6.1 | 1147 | | 0 | SETTINGS | | 1148 | | | frames | | 1149 | | | | | 1150 | HTTP_RST_CONTROL_STREAM | 0x1 | Message | Section 6.1 | 1151 | | 1 | control | | 1152 | | | stream was | | 1153 | | | RST | | 1154 +------------------------------+-----+--------------+---------------+ 1156 10. References 1158 10.1. Normative References 1160 [QUIC-TRANSPORT] 1161 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1162 Multiplexed and Secure Transport". 1164 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1165 RFC 793, DOI 10.17487/RFC0793, September 1981, 1166 . 1168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1169 Requirement Levels", BCP 14, RFC 2119, 1170 DOI 10.17487/RFC2119, March 1997, 1171 . 1173 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1174 Protocol (HTTP/1.1): Message Syntax and Routing", 1175 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1176 . 1178 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1179 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1180 DOI 10.17487/RFC7231, June 2014, 1181 . 1183 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1184 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1185 DOI 10.17487/RFC7540, May 2015, 1186 . 1188 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1189 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1190 . 1192 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1193 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1194 April 2016, . 1196 10.2. Informative References 1198 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1199 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1200 DOI 10.17487/RFC5226, May 2008, 1201 . 1203 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1204 "Transport Layer Security (TLS) Application-Layer Protocol 1205 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1206 July 2014, . 1208 Appendix A. Contributors 1210 The original authors of this specification were Robbie Shade and Mike 1211 Warres. 1213 Appendix B. Change Log 1215 *RFC Editor's Note:* Please remove this section prior to 1216 publication of a final version of this document. 1218 B.1. Since draft-ietf-quic-http-01: 1220 o SETTINGS changes (#181): 1222 * SETTINGS can be sent only once at the start of a connection; no 1223 changes thereafter 1225 * SETTINGS_ACK removed 1226 * Settings can only occur in the SETTINGS frame a single time 1228 * Boolean format updated 1230 o Alt-Svc parameter changed from "v" to "quic"; format updated 1231 (#229) 1233 o Closing the connection control stream or any message control 1234 stream is a fatal error (#176) 1236 o HPACK Sequence counter can wrap (#173) 1238 o 0-RTT guidance added 1240 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 1241 added (#127,#242) 1243 B.2. Since draft-ietf-quic-http-00: 1245 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 1247 o Changed from using HTTP/2 framing within Stream 3 to new framing 1248 format and two-stream-per-request model (#71,#72,#73) 1250 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 1251 settings-01 1253 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 1254 order (#75) 1256 o Described CONNECT pseudo-method (#95) 1258 o Updated ALPN token and Alt-Svc guidance (#13,#87) 1260 o Application-layer-defined error codes (#19,#74) 1262 B.3. Since draft-shade-quic-http2-mapping-00: 1264 o Adopted as base for draft-ietf-quic-http. 1266 o Updated authors/editors list. 1268 Author's Address 1270 Mike Bishop (editor) 1271 Microsoft 1273 Email: Michael.Bishop@microsoft.com