idnits 2.17.1 draft-ietf-quic-http-03.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 (May 21, 2017) is 2525 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) ** 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 (==), 2 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 May 21, 2017 5 Expires: November 22, 2017 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-03 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 November 22, 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 1: 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-02 . . . . . . . . . . . . . . 26 102 B.2. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 27 103 B.3. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 27 104 B.4. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 28 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 107 1. Introduction 109 The QUIC transport protocol has several features that are desirable 110 in a transport for HTTP, such as stream multiplexing, per-stream flow 111 control, and low-latency connection establishment. This document 112 describes a mapping of HTTP semantics over QUIC, drawing heavily on 113 the existing TCP mapping, HTTP/2. Specifically, this document 114 identifies HTTP/2 features that are subsumed by QUIC, and describes 115 how the other features can be implemented atop QUIC. 117 QUIC is described in [QUIC-TRANSPORT]. For a full description of 118 HTTP/2, see [RFC7540]. 120 1.1. Notational Conventions 122 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 123 document. It's not shouting; when they are capitalized, they have 124 the special meaning defined in [RFC2119]. 126 2. QUIC Advertisement 128 An HTTP origin advertises the availability of an equivalent HTTP/QUIC 129 endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC 130 frame ([RFC7838]), using the ALPN token defined in Section 3. 132 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 133 response that HTTP/QUIC was available on UDP port 50781 at the same 134 hostname by including the following header in any response: 136 Alt-Svc: hq=":50781" 138 On receipt of an Alt-Svc header indicating HTTP/QUIC support, a 139 client MAY attempt to establish a QUIC connection to the indicated 140 host and port and, if successful, send HTTP requests using the 141 mapping described in this document. 143 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 144 connection establishment failure, in which case the client SHOULD 145 continue using the existing connection or try another alternative 146 endpoint offered by the origin. 148 Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the 149 same port across all IP addresses that serve a single domain, and 150 SHOULD NOT change this port. 152 2.1. QUIC Version Hints 154 This document defines the "quic" parameter for Alt-Svc, which MAY be 155 used to provide version-negotiation hints to HTTP/QUIC clients. QUIC 156 versions are four-octet sequences with no additional constraints on 157 format. Syntax: 159 quic = version-number 160 version-number = 1*8HEXDIG; hex-encoded QUIC version 162 Leading zeros SHOULD be omitted for brevity. When multiple versions 163 are supported, the "quic" parameter MAY be repeated multiple times in 164 a single Alt-Svc entry. For example, if a server supported both 165 version 0x00000001 and the version rendered in ASCII as "Q034", it 166 could specify the following header: 168 Alt-Svc: hq=":49288";quic=1;quic=51303334 170 Where multiple versions are listed, the order of the values reflects 171 the server's preference (with the first value being the most 172 preferred version). Origins SHOULD list only versions which are 173 supported by the alternative, but MAY omit supported versions for any 174 reason. 176 3. Connection Establishment 178 HTTP/QUIC connections are established as described in 179 [QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support 180 is indicated by selecting the ALPN token "hq" in the crypto 181 handshake. 183 While connection-level options pertaining to the core QUIC protocol 184 are set in the initial crypto handshake, HTTP-specific settings are 185 conveyed in the SETTINGS frame. After the QUIC connection is 186 established, a SETTINGS frame (Section 5.2.3) MUST be sent as the 187 initial frame of the HTTP control stream (Stream ID 1, see 188 Section 4). The server MUST NOT send data on any other stream until 189 the client's SETTINGS frame has been received. 191 3.1. Draft Version Identification 193 *RFC Editor's Note:* Please remove this section prior to 194 publication of a final version of this document. 196 Only implementations of the final, published RFC can identify 197 themselves as "hq". Until such an RFC exists, implementations MUST 198 NOT identify themselves using this string. 200 Implementations of draft versions of the protocol MUST add the string 201 "-" and the corresponding draft number to the identifier. For 202 example, draft-ietf-quic-http-01 is identified using the string "hq- 203 01". 205 Non-compatible experiments that are based on these draft versions 206 MUST append the string "-" and an experiment name to the identifier. 207 For example, an experimental implementation based on draft-ietf-quic- 208 http-09 which reserves an extra stream for unsolicited transmission 209 of 1980s pop music might identify itself as "hq-09-rickroll". Note 210 that any label MUST conform to the "token" syntax defined in 211 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 212 coordinate their experiments on the quic@ietf.org mailing list. 214 4. Stream Mapping and Usage 216 A QUIC stream provides reliable in-order delivery of bytes, but makes 217 no guarantees about order of delivery with regard to bytes on other 218 streams. On the wire, data is framed into QUIC STREAM frames, but 219 this framing is invisible to the HTTP framing layer. A QUIC receiver 220 buffers and orders received STREAM frames, exposing the data 221 contained within as a reliable byte stream to the application. 223 QUIC reserves Stream 0 for crypto operations (the handshake, crypto 224 config updates). Stream 1 is reserved for sending and receiving HTTP 225 control frames, and is analogous to HTTP/2's Stream 0. This 226 connection control stream is considered critical to the HTTP 227 connection. If the connection control stream is closed for any 228 reason, this MUST be treated as a connection error of type 229 QUIC_CLOSED_CRITICAL_STREAM. 231 When HTTP headers and data are sent over QUIC, the QUIC layer handles 232 most of the stream management. An HTTP request/response consumes a 233 pair of streams: This means that the client's first request occurs on 234 QUIC streams 3 and 5, the second on stream 7 and 9, and so on. The 235 server's first push consumes streams 2 and 4. This amounts to the 236 second least-significant bit differentiating the two streams in a 237 request. 239 The lower-numbered stream is called the message control stream and 240 carries frames related to the request/response, including HEADERS. 241 The higher-numbered stream is the data stream and carries the 242 request/response body with no additional framing. Note that a 243 request or response without a body will cause this stream to be half- 244 closed in the corresponding direction without transferring data. 246 Because the message control stream contains HPACK data which 247 manipulates connection-level state, the message control stream MUST 248 NOT be closed with a stream-level error. If an implementation 249 chooses to reject a request with a QUIC error code, it MUST trigger a 250 QUIC RST_STREAM on the data stream only. An implementation MAY close 251 (FIN) a message control stream without completing a full HTTP message 252 if the data stream has been abruptly closed. Data on message control 253 streams MUST be fully consumed, or the connection terminated. 255 All message control streams are considered critical to the HTTP 256 connection. If a message control stream is terminated abruptly for 257 any reason, this MUST be treated as a connection error of type 258 HTTP_RST_CONTROL_STREAM. When a message control stream terminates 259 cleanly, if the last frame on the stream was truncated, this MUST be 260 treated as a connection error (see HTTP_MALFORMED_* in Section 6.1). 262 Pairs of streams must be utilized sequentially, with no gaps. The 263 data stream is opened at the same time as the message control stream 264 is opened and is closed after transferring the body. The data stream 265 is closed immediately after sending the request headers if there is 266 no body. 268 HTTP does not need to do any separate multiplexing when using QUIC - 269 data sent over a QUIC stream always maps to a particular HTTP 270 transaction. Requests and responses are considered complete when the 271 corresponding QUIC streams are closed in the appropriate direction. 273 4.1. Stream 1: Connection Control Stream 275 Since most connection-level concerns will be managed by QUIC, the 276 primary use of Stream 1 will be for the SETTINGS frame when the 277 connection opens and for PRIORITY frames subsequently. 279 4.2. HTTP Message Exchanges 281 A client sends an HTTP request on a new pair of QUIC streams. A 282 server sends an HTTP response on the same streams as the request. 284 An HTTP message (request or response) consists of: 286 1. one header block (see Section 5.2.1) on the control stream 287 containing the message headers (see [RFC7230], Section 3.2), 289 2. the payload body (see [RFC7230], Section 3.3), sent on the data 290 stream, 292 3. optionally, one header block on the control stream containing the 293 trailer-part, if present (see [RFC7230], Section 4.1.2). 295 In addition, prior to sending the message header block indicated 296 above, a response may contain zero or more header blocks on the 297 control stream containing the message headers of informational (1xx) 298 HTTP responses (see [RFC7230], Section 3.2 and [RFC7231], 299 Section 6.2). 301 The data stream MUST be half-closed immediately after the transfer of 302 the body. If the message does not contain a body, the corresponding 303 data stream MUST still be half-closed without transferring any data. 304 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 305 MUST NOT be used. 307 Trailing header fields are carried in an additional header block on 308 the message control stream. Such a header block is a sequence of 309 HEADERS frames with End Header Block set on the last frame. Senders 310 MUST send only one header block in the trailers section; receivers 311 MUST decode any subsequent header blocks in order to maintain HPACK 312 decoder state, but the resulting output MUST be discarded. 314 An HTTP request/response exchange fully consumes a pair of streams. 315 After sending a request, a client closes the streams for sending; 316 after sending a response, the server closes its streams for sending 317 and the QUIC streams are fully closed. 319 A server can send a complete response prior to the client sending an 320 entire request if the response does not depend on any portion of the 321 request that has not been sent and received. When this is true, a 322 server MAY request that the client abort transmission of a request 323 without error by sending a RST_STREAM with an error code of NO_ERROR 324 after sending a complete response and closing its stream. Clients 325 MUST NOT discard responses as a result of receiving such a 326 RST_STREAM, though clients can always discard responses at their 327 discretion for other reasons. 329 4.2.1. Header Compression 331 HTTP/QUIC uses HPACK header compression as described in [RFC7541]. 332 HPACK was designed for HTTP/2 with the assumption of in-order 333 delivery such as that provided by TCP. A sequence of encoded header 334 blocks must arrive (and be decoded) at an endpoint in the same order 335 in which they were encoded. This ensures that the dynamic state at 336 the two endpoints remains in sync. 338 QUIC streams provide in-order delivery of data sent on those streams, 339 but there are no guarantees about order of delivery between streams. 340 To achieve in-order delivery of HEADERS frames in QUIC, the HPACK- 341 bearing frames contain a counter which can be used to ensure in-order 342 processing. Data (request/response bodies) which arrive out of order 343 are buffered until the corresponding HEADERS arrive. 345 This does introduce head-of-line blocking: if the packet containing 346 HEADERS for stream N is lost or reordered then the HEADERS for stream 347 N+4 cannot be processed until it has been retransmitted successfully, 348 even though the HEADERS for stream N+4 may have arrived. 350 DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- 351 invariant? How much do we need to retain compatibility with 352 HTTP/2's HPACK? 354 4.2.2. The CONNECT Method 356 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 357 used with HTTP proxies to establish a TLS session with an origin 358 server for the purposes of interacting with "https" resources. In 359 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 360 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 361 establish a tunnel over a single HTTP/2 stream to a remote host for 362 similar purposes. 364 A CONNECT request in HTTP/QUIC functions in the same manner as in 365 HTTP/2. The request MUST be formatted as described in [RFC7540], 366 Section 8.3. A CONNECT request that does not conform to these 367 restrictions is malformed. The message data stream MUST NOT be 368 closed at the end of the request. 370 A proxy that supports CONNECT establishes a TCP connection 371 ([RFC0793]) to the server identified in the ":authority" pseudo- 372 header field. Once this connection is successfully established, the 373 proxy sends a HEADERS frame containing a 2xx series status code to 374 the client, as defined in [RFC7231], Section 4.3.6, on the message 375 control stream. 377 All QUIC STREAM frames on the message data stream correspond to data 378 sent on the TCP connection. Any QUIC STREAM frame sent by the client 379 is transmitted by the proxy to the TCP server; data received from the 380 TCP server is written to the data stream by the proxy. Note that the 381 size and number of TCP segments is not guaranteed to map predictably 382 to the size and number of QUIC STREAM frames. 384 The TCP connection can be closed by either peer. When the client 385 half-closes the data stream, the proxy will set the FIN bit on its 386 connection to the TCP server. When the proxy receives a packet with 387 the FIN bit set, it will half-close the corresponding data stream. 388 TCP connections which remain half-closed in a single direction are 389 not invalid, but are often handled poorly by servers, so clients 390 SHOULD NOT half-close connections on which they are still expecting 391 data. 393 A TCP connection error is signaled with RST_STREAM. A proxy treats 394 any error in the TCP connection, which includes receiving a TCP 395 segment with the RST bit set, as a stream error of type 396 HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send 397 a TCP segment with the RST bit set if it detects an error with the 398 stream or the QUIC connection. 400 4.3. Stream Priorities 402 HTTP/QUIC uses the priority scheme described in [RFC7540] 403 Section 5.3. In this priority scheme, a given stream can be 404 designated as dependent upon another stream, which expresses the 405 preference that the latter stream (the "parent" stream) be allocated 406 resources before the former stream (the "dependent" stream). Taken 407 together, the dependencies across all streams in a connection form a 408 dependency tree. The structure of the dependency tree changes as 409 PRIORITY frames add, remove, or change the dependency links between 410 streams. 412 For consistency's sake, all PRIORITY frames MUST refer to the message 413 control stream of the dependent request, not the data stream. 415 4.4. Server Push 417 HTTP/QUIC supports server push as described in [RFC7540]. During 418 connection establishment, the client indicates whether it is willing 419 to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the 420 SETTINGS frame (see Section 3), which defaults to 1 (true). 422 As with server push for HTTP/2, the server initiates a server push by 423 sending a PUSH_PROMISE frame containing the Stream ID of the stream 424 to be pushed, as well as request header fields attributed to the 425 request. The PUSH_PROMISE frame is sent on the control stream of the 426 associated (client-initiated) request, while the Promised Stream ID 427 field specifies the Stream ID of the control stream for the server- 428 initiated request. 430 The server push response is conveyed in the same way as a non-server- 431 push response, with response headers and (if present) trailers 432 carried by HEADERS frames sent on the control stream, and response 433 body (if any) sent via the corresponding data stream. 435 5. HTTP Framing Layer 437 Frames are used only on the connection (stream 1) and message 438 (streams 3, 7, etc.) control streams. Other streams carry data 439 payload and are not framed at the HTTP layer. 441 This section describes HTTP framing in QUIC and highlights some 442 differences from HTTP/2 framing. For more detail on differences from 443 HTTP/2, see Section 7.1. 445 5.1. Frame Layout 447 All frames have the following format: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Length (16) | Type (8) | Flags (8) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Frame Payload (*) ... 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 1: HTTP/QUIC frame format 459 5.2. Frame Definitions 461 5.2.1. HEADERS 463 The HEADERS frame (type=0x1) is used to carry part of a header set, 464 compressed using HPACK [RFC7541]. 466 One flag is defined: 468 End Header Block (0x4): This frame concludes a header block. 470 A HEADERS frame with any other flags set MUST be treated as a 471 connection error of type HTTP_MALFORMED_HEADERS. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Sequence? (16) | Header Block Fragment (*)... 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 2: HEADERS frame payload 481 The HEADERS frame payload has the following fields: 483 Sequence Number: Present only on the first frame of a header block 484 sequence. This MUST be set to zero on the first header block 485 sequence, and incremented on each header block. 487 The next frame on the same stream after a HEADERS frame without the 488 EHB flag set MUST be another HEADERS frame. A receiver MUST treat 489 the receipt of any other type of frame as a stream error of type 490 HTTP_INTERRUPTED_HEADERS. (Note that QUIC can intersperse data from 491 other streams between frames, or even during transmission of frames, 492 so multiplexing is not blocked by this requirement.) 494 A full header block is contained in a sequence of zero or more 495 HEADERS frames without EHB set, followed by a HEADERS frame with EHB 496 set. 498 On receipt, header blocks (HEADERS, PUSH_PROMISE) MUST be processed 499 by the HPACK decoder in sequence. If a block is missing, all 500 subsequent HPACK frames MUST be held until it arrives, or the 501 connection terminated. 503 When the Sequence counter reaches its maximum value (0xFFFF), the 504 next increment returns it to zero. An endpoint MUST NOT wrap the 505 Sequence counter to zero until the previous zero-value header block 506 has been confirmed received. 508 5.2.2. PRIORITY 510 The PRIORITY (type=0x02) frame specifies the sender-advised priority 511 of a stream and is substantially different from [RFC7540]. In order 512 to support ordering, it MUST be sent only on the connection control 513 stream. The format has been modified to accommodate not being sent 514 on-stream and the larger stream ID space of QUIC. 516 The semantics of the Stream Dependency, Weight, and E flag are the 517 same as in HTTP/2. 519 The flags defined are: 521 E (0x01): Indicates that the stream dependency is exclusive (see 522 [RFC7540] Section 5.3). 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Prioritized Stream (32) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Dependent Stream (32) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Weight (8) | 532 +-+-+-+-+-+-+-+-+ 534 Figure 3: PRIORITY frame payload 536 The HEADERS frame payload has the following fields: 538 Prioritized Stream: A 32-bit stream identifier for the message 539 control stream whose priority is being updated. 541 Stream Dependency: A 32-bit stream identifier for the stream that 542 this stream depends on (see Section 4.3 and {!RFC7540}} 543 Section 5.3). 545 Weight: An unsigned 8-bit integer representing a priority weight for 546 the stream (see [RFC7540] Section 5.3). Add one to the value to 547 obtain a weight between 1 and 256. 549 A PRIORITY frame MUST have a payload length of nine octets. A 550 PRIORITY frame of any other length MUST be treated as a connection 551 error of type HTTP_MALFORMED_PRIORITY. 553 5.2.3. SETTINGS 555 The SETTINGS frame (type=0x4) conveys configuration parameters that 556 affect how endpoints communicate, such as preferences and constraints 557 on peer behavior, and is substantially different from [RFC7540]. 558 Individually, a SETTINGS parameter can also be referred to as a 559 "setting". 561 SETTINGS parameters are not negotiated; they describe characteristics 562 of the sending peer, which can be used by the receiving peer. 563 However, a negotiation can be implied by the use of SETTINGS - a peer 564 uses SETTINGS to advertise a set of supported values. The recipient 565 can then choose which entries from this list are also acceptable and 566 proceed with the value it has chosen. (This choice could be 567 announced in a field of an extension frame, or in its own value in 568 SETTINGS.) 569 Different values for the same parameter can be advertised by each 570 peer. For example, a client might permit a very large HPACK state 571 table while a server chooses to use a small one to conserve memory. 573 Parameters MUST NOT occur more than once. A receiver MAY treat the 574 presence of the same parameter more than once as a connection error 575 of type HTTP_MALFORMED_SETTINGS. 577 The SETTINGS frame defines no flags. 579 The payload of a SETTINGS frame consists of zero or more parameters, 580 each consisting of an unsigned 16-bit setting identifier and a 581 length-prefixed binary value. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Identifier (16) | Length (16) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Contents (?) ... 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 4: SETTINGS value format 593 A zero-length content indicates that the setting value is a Boolean 594 and true. False is indicated by the absence of the setting. 596 Non-zero-length values MUST be compared against the remaining length 597 of the SETTINGS frame. Any value which purports to cross the end of 598 the frame MUST cause the SETTINGS frame to be considered malformed 599 and trigger a connection error of type HTTP_MALFORMED_SETTINGS. 601 An implementation MUST ignore the contents for any SETTINGS 602 identifier it does not understand. 604 SETTINGS frames always apply to a connection, never a single stream. 605 A SETTINGS frame MUST be sent as the first frame of the connection 606 control stream (see Section 4) by each peer, and MUST NOT be sent 607 subsequently or on any other stream. If an endpoint receives an 608 SETTINGS frame on a different stream, the endpoint MUST respond with 609 a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an 610 endpoint receives a second SETTINGS frame, the endpoint MUST respond 611 with a connection error of type HTTP_MULTIPLE_SETTINGS. 613 The SETTINGS frame affects connection state. A badly formed or 614 incomplete SETTINGS frame MUST be treated as a connection error 615 (Section 5.4.1) of type HTTP_MALFORMED_SETTINGS. 617 5.2.3.1. Integer encoding 619 Settings which are integers are transmitted in network byte order. 620 Leading zero octets are permitted, but implementations SHOULD use 621 only as many bytes as are needed to represent the value. An integer 622 MUST NOT be represented in more bytes than would be used to transfer 623 the maximum permitted value. 625 5.2.3.2. Defined SETTINGS Parameters 627 The following settings are defined in HTTP/QUIC: 629 SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of 630 2^32 - 1. 632 SETTINGS_DISABLE_PUSH (0x2): Transmitted as a Boolean; replaces 633 SETTINGS_ENABLE_PUSH 635 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value 636 of 2^32 - 1. 638 5.2.3.3. Usage in 0-RTT 640 When a 0-RTT QUIC connection is being used, the client's initial 641 requests will be sent before the arrival of the server's SETTINGS 642 frame. Clients SHOULD cache at least the following settings about 643 servers: 645 o SETTINGS_HEADER_TABLE_SIZE 647 o SETTINGS_MAX_HEADER_LIST_SIZE 649 Clients MUST comply with cached settings until the server's current 650 settings are received. If a client does not have cached values, it 651 SHOULD assume the following values: 653 o SETTINGS_HEADER_TABLE_SIZE: 0 octets 655 o SETTINGS_MAX_HEADER_LIST_SIZE: 16,384 octets 657 Servers MAY continue processing data from clients which exceed its 658 current configuration during the initial flight. In this case, the 659 client MUST apply the new settings immediately upon receipt. 661 If the connection is closed because these or other constraints were 662 violated during the 0-RTT flight (e.g. with 663 HTTP_HPACK_DECOMPRESSION_FAILED), clients MAY establish a new 664 connection and retry any 0-RTT requests using the settings sent by 665 the server on the closed connection. (This assumes that only 666 requests that are safe to retry are sent in 0-RTT.) If the 667 connection was closed before the SETTINGS frame was received, clients 668 SHOULD discard any cached values and use the defaults above on the 669 next connection. 671 5.2.4. PUSH_PROMISE 673 The PUSH_PROMISE frame (type=0x05) is used to carry a request header 674 set from server to client, as in HTTP/2. It defines no flags. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Promised Stream ID (32) | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Sequence? (16) | Header Block (*) ... 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Figure 5: PUSH_PROMISE frame payload 686 The payload consists of: 688 Promised Stream ID: A 32-bit Stream ID indicating the QUIC stream on 689 which the response headers will be sent. (The response body 690 stream is implied by the headers stream, as defined in Section 4.) 692 HPACK Sequence: A sixteen-bit counter, equivalent to the Sequence 693 field in HEADERS 695 Payload: HPACK-compressed request headers for the promised response. 697 6. Error Handling 699 QUIC allows the application to abruptly terminate individual streams 700 or the entire connection when an error is encountered. These are 701 referred to as "stream errors" or "connection errors" and are 702 described in more detail in [QUIC-TRANSPORT]. 704 HTTP/QUIC requires that only data streams be terminated abruptly. 705 Terminating a message control stream will result in an error of type 706 HTTP_RST_CONTROL_STREAM. 708 This section describes HTTP-specific error codes which can be used to 709 express the cause of a connection or stream error. 711 6.1. HTTP-Defined QUIC Error Codes 713 QUIC allocates error codes 0x0000-0x3FFF to application protocol 714 definition. The following error codes are defined by HTTP for use in 715 QUIC RST_STREAM, GOAWAY, and CONNECTION_CLOSE frames. 717 HTTP_PUSH_REFUSED (0x01): The server has attempted to push content 718 which the client will not accept on this connection. 720 HTTP_INTERNAL_ERROR (0x02): An internal error has occurred in the 721 HTTP stack. 723 HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push 724 content which the client has cached. 726 HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the 727 requested data. 729 HTTP_HPACK_DECOMPRESSION_FAILED (0x05): HPACK failed to decompress a 730 frame and cannot continue. 732 HTTP_CONNECT_ERROR (0x06): The connection established in response to 733 a CONNECT request was reset or abnormally closed. 735 HTTP_EXCESSIVE_LOAD (0x07): The endpoint detected that its peer is 736 exhibiting a behavior that might be generating excessive load. 738 HTTP_VERSION_FALLBACK (0x08): The requested operation cannot be 739 served over HTTP/QUIC. The peer should retry over HTTP/2. 741 HTTP_MALFORMED_HEADERS (0x09): A HEADERS frame has been received 742 with an invalid format. 744 HTTP_MALFORMED_PRIORITY (0x0A): A PRIORITY frame has been received 745 with an invalid format. 747 HTTP_MALFORMED_SETTINGS (0x0B): A SETTINGS frame has been received 748 with an invalid format. 750 HTTP_MALFORMED_PUSH_PROMISE (0x0C): A PUSH_PROMISE frame has been 751 received with an invalid format. 753 HTTP_INTERRUPTED_HEADERS (0x0E): A HEADERS frame without the End 754 Header Block flag was followed by a frame other than HEADERS. 756 HTTP_SETTINGS_ON_WRONG_STREAM (0x0F): A SETTINGS frame was received 757 on a request control stream. 759 HTTP_MULTIPLE_SETTINGS (0x10): More than one SETTINGS frame was 760 received. 762 HTTP_RST_CONTROL_STREAM (0x11): A message control stream closed 763 abruptly. 765 7. Considerations for Transitioning from HTTP/2 767 HTTP/QUIC is strongly informed by HTTP/2, and bears many 768 similarities. This section points out important differences from 769 HTTP/2 and describes how to map HTTP/2 extensions into HTTP/QUIC. 771 7.1. HTTP Frame Types 773 Many framing concepts from HTTP/2 can be elided away on QUIC, because 774 the transport deals with them. Because frames are already on a 775 stream, they can omit the stream number. Because frames do not block 776 multiplexing (QUIC's multiplexing occurs below this layer), the 777 support for variable-maximum-length packets can be removed. Because 778 stream termination is handled by QUIC, an END_STREAM flag is not 779 required. 781 Frame payloads are largely drawn from [RFC7540]. However, QUIC 782 includes many features (e.g. flow control) which are also present in 783 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 784 As a result, several HTTP/2 frame types are not required in HTTP/ 785 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 786 has been reserved in order to maximize portability between HTTP/2 and 787 HTTP/QUIC implementations. However, even equivalent frames between 788 the two mappings are not identical. 790 Many of the differences arise from the fact that HTTP/2 provides an 791 absolute ordering between frames across all streams, while QUIC 792 provides this guarantee on each stream only. As a result, if a frame 793 type makes assumptions that frames from different streams will still 794 be received in the order sent, HTTP/QUIC will break them. 796 For example, implicit in the HTTP/2 prioritization scheme is the 797 notion of in-order delivery of priority changes (i.e., dependency 798 tree mutations): since operations on the dependency tree such as 799 reparenting a subtree are not commutative, both sender and receiver 800 must apply them in the same order to ensure that both sides have a 801 consistent view of the stream dependency tree. HTTP/2 specifies 802 priority assignments in PRIORITY frames and (optionally) in HEADERS 803 frames. To achieve in-order delivery of priority changes in HTTP/ 804 QUIC, PRIORITY frames are sent on the connection control stream and 805 the PRIORITY section is removed from the HEADERS frame. 807 Other than this issue, frame type HTTP/2 extensions are typically 808 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 1 809 in HTTP/QUIC. 811 Below is a listing of how each HTTP/2 frame type is mapped: 813 DATA (0x0): Instead of DATA frames, HTTP/QUIC uses a separate data 814 stream. See Section 4. 816 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 817 not supported. A separate PRIORITY frame MUST be used. Padding 818 is not defined in HTTP/QUIC frames. See Section 5.2.1. 820 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 821 the connection control stream. See Section 5.2.2. 823 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 824 provides stream lifecycle management. 826 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 827 the connection. See Section 5.2.3 and Section 7.2. 829 PUSH_PROMISE (0x5): See Section 5.2.4. 831 PING (0x6): PING frames do not exist, since QUIC provides equivalent 832 functionality. 834 GOAWAY (0x7): GOAWAY frames do not exist, since QUIC provides 835 equivalent functionality. 837 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 838 provides flow control. 840 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 841 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted, and 842 HEADERS frames can be used in series. 844 The IANA registry of frame types has been updated in Section 9.3 to 845 include references to the definition for each frame type in HTTP/2 846 and in HTTP/QUIC. Frames not defined as available in HTTP/QUIC 847 SHOULD NOT be sent and SHOULD be ignored as unknown on receipt. 849 7.2. HTTP/2 SETTINGS Parameters 851 An important difference from HTTP/2 is that settings are sent once, 852 at the beginning of the connection, and thereafter cannot change. 853 This eliminates many corner cases around synchronization of changes. 855 Some transport-level options that HTTP/2 specifies via the SETTINGS 856 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 857 HTTP-level options that are retained in HTTP/QUIC have the same value 858 as in HTTP/2. 860 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 862 SETTINGS_HEADER_TABLE_SIZE: See Section 5.2.3.2. 864 SETTINGS_ENABLE_PUSH: See SETTINGS_DISABLE_PUSH in Section 5.2.3.2. 866 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC requires the maximum number of 867 incoming streams per connection to be specified in the initial 868 transport handshake. Specifying SETTINGS_MAX_CONCURRENT_STREAMS 869 in the SETTINGS frame is an error. 871 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 872 connection flow control window sizes to be specified in the 873 initial transport handshake. Specifying 874 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 876 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 877 QUIC. Specifying it in the SETTINGS frame is an error. 879 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 5.2.3.2. 881 Settings defined by extensions to HTTP/2 MAY be expressed as integers 882 with a maximum value of 2^32-1, if they are applicable to HTTP/QUIC, 883 but SHOULD have a specification describing their usage. Fields for 884 this purpose have been added to the IANA registry in Section 9.4. 886 7.3. HTTP/2 Error Codes 888 QUIC has the same concepts of "stream" and "connection" errors that 889 HTTP/2 provides. However, because the error code space is shared 890 between multiple components, there is no direct portability of HTTP/2 891 error codes. 893 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to QUIC 894 error codes as follows: 896 NO_ERROR (0x0): QUIC_NO_ERROR 898 PROTOCOL_ERROR (0x1): No single mapping. See new HTTP_MALFORMED_* 899 error codes defined in Section 6.1. 901 INTERNAL_ERROR (0x2) HTTP_INTERNAL_ERROR in Section 6.1. 903 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 904 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 905 from the QUIC layer. 907 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 908 SETTINGS is defined. 910 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 911 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 912 from the QUIC layer. 914 FRAME_SIZE_ERROR (0x6) No single mapping. See new error codes 915 defined in Section 6.1. 917 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 918 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 919 QUIC layer. 921 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 923 COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in 924 Section 6.1. 926 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 928 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 930 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 931 provide sufficient security on all connections. 933 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 935 Error codes defined by HTTP/2 extensions need to be re-registered for 936 HTTP/QUIC if still applicable. See Section 9.5. 938 8. Security Considerations 940 The security considerations of HTTP over QUIC should be comparable to 941 those of HTTP/2. 943 The modified SETTINGS format contains nested length elements, which 944 could pose a security risk to an uncautious implementer. A SETTINGS 945 frame parser MUST ensure that the length of the frame exactly matches 946 the length of the settings it contains. 948 9. IANA Considerations 950 9.1. Registration of HTTP/QUIC Identification String 952 This document creates a new registration for the identification of 953 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 954 Protocol IDs" registry established in [RFC7301]. 956 The "hq" string identifies HTTP/QUIC: 958 Protocol: HTTP over QUIC 960 Identification Sequence: 0x68 0x71 ("hq") 962 Specification: This document 964 9.2. Registration of QUIC Version Hint Alt-Svc Parameter 966 This document creates a new registration for version-negotiation 967 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 968 registry established in [RFC7838]. 970 Parameter: "quic" 972 Specification: This document, Section 2.1 974 9.3. Existing Frame Types 976 This document adds two new columns to the "HTTP/2 Frame Type" 977 registry defined in [RFC7540]: 979 Supported Protocols: Indicates which associated protocols use the 980 frame type. Values MUST be one of: 982 * "HTTP/2 only" 984 * "HTTP/QUIC only" 986 * "Both" 988 HTTP/QUIC Specification: Indicates where this frame's behavior over 989 QUIC is defined; required if the frame is supported over QUIC. 991 Values for existing registrations are assigned by this document: 993 +---------------+---------------------+-------------------------+ 994 | Frame Type | Supported Protocols | HTTP/QUIC Specification | 995 +---------------+---------------------+-------------------------+ 996 | DATA | HTTP/2 only | N/A | 997 | | | | 998 | HEADERS | Both | Section 5.2.1 | 999 | | | | 1000 | PRIORITY | Both | Section 5.2.2 | 1001 | | | | 1002 | RST_STREAM | HTTP/2 only | N/A | 1003 | | | | 1004 | SETTINGS | Both | Section 5.2.3 | 1005 | | | | 1006 | PUSH_PROMISE | Both | Section 5.2.4 | 1007 | | | | 1008 | PING | HTTP/2 only | N/A | 1009 | | | | 1010 | GOAWAY | HTTP/2 only | N/A | 1011 | | | | 1012 | WINDOW_UPDATE | HTTP/2 only | N/A | 1013 | | | | 1014 | CONTINUATION | HTTP/2 only | N/A | 1015 +---------------+---------------------+-------------------------+ 1017 The "Specification" column is renamed to "HTTP/2 specification" and 1018 is only required if the frame is supported over HTTP/2. 1020 9.4. Settings Parameters 1022 This document adds two new columns to the "HTTP/2 Settings" registry 1023 defined in [RFC7540]: 1025 Supported Protocols: Indicates which associated protocols use the 1026 setting. Values MUST be one of: 1028 * "HTTP/2 only" 1030 * "HTTP/QUIC only" 1032 * "Both" 1034 HTTP/QUIC Specification: Indicates where this setting's behavior 1035 over QUIC is defined; required if the frame is supported over 1036 QUIC. 1038 Values for existing registrations are assigned by this document: 1040 +-------------------------+------------------+----------------------+ 1041 | Setting Name | Supported | HTTP/QUIC | 1042 | | Protocols | Specification | 1043 +-------------------------+------------------+----------------------+ 1044 | HEADER_TABLE_SIZE | Both | Section 5.2.3.2 | 1045 | | | | 1046 | ENABLE_PUSH / | Both | Section 5.2.3.2 | 1047 | DISABLE_PUSH | | | 1048 | | | | 1049 | MAX_CONCURRENT_STREAMS | HTTP/2 Only | N/A | 1050 | | | | 1051 | INITIAL_WINDOW_SIZE | HTTP/2 Only | N/A | 1052 | | | | 1053 | MAX_FRAME_SIZE | HTTP/2 Only | N/A | 1054 | | | | 1055 | MAX_HEADER_LIST_SIZE | Both | Section 5.2.3.2 | 1056 +-------------------------+------------------+----------------------+ 1058 The "Specification" column is renamed to "HTTP/2 Specification" and 1059 is only required if the setting is supported over HTTP/2. 1061 9.5. Error Codes 1063 This document establishes a registry for HTTP/QUIC error codes. The 1064 "HTTP/QUIC Error Code" registry manages a 30-bit space. The "HTTP/ 1065 QUIC Error Code" registry operates under the "Expert Review" policy 1066 [RFC5226]. 1068 Registrations for error codes are required to include a description 1069 of the error code. An expert reviewer is advised to examine new 1070 registrations for possible duplication with existing error codes. 1071 Use of existing registrations is to be encouraged, but not mandated. 1073 New registrations are advised to provide the following information: 1075 Name: A name for the error code. Specifying an error code name is 1076 optional. 1078 Code: The 30-bit error code value. 1080 Description: A brief description of the error code semantics, longer 1081 if no detailed specification is provided. 1083 Specification: An optional reference for a specification that 1084 defines the error code. 1086 The entries in the following table are registered by this document. 1088 +------------------------------+-----+--------------+---------------+ 1089 | Name | Cod | Description | Specification | 1090 | | e | | | 1091 +------------------------------+-----+--------------+---------------+ 1092 | HTTP_PUSH_REFUSED | 0x0 | Client | Section 6.1 | 1093 | | 1 | refused | | 1094 | | | pushed | | 1095 | | | content | | 1096 | | | | | 1097 | HTTP_INTERNAL_ERROR | 0x0 | Internal | Section 6.1 | 1098 | | 2 | error | | 1099 | | | | | 1100 | HTTP_PUSH_ALREADY_IN_CACHE | 0x0 | Pushed | Section 6.1 | 1101 | | 3 | content | | 1102 | | | already | | 1103 | | | cached | | 1104 | | | | | 1105 | HTTP_REQUEST_CANCELLED | 0x0 | Data no | Section 6.1 | 1106 | | 4 | longer | | 1107 | | | needed | | 1108 | | | | | 1109 | HTTP_HPACK_DECOMPRESSION_FAI | 0x0 | HPACK cannot | Section 6.1 | 1110 | LED | 5 | continue | | 1111 | | | | | 1112 | HTTP_CONNECT_ERROR | 0x0 | TCP reset or | Section 6.1 | 1113 | | 6 | error on | | 1114 | | | CONNECT | | 1115 | | | request | | 1116 | | | | | 1117 | HTTP_EXCESSIVE_LOAD | 0x0 | Peer | Section 6.1 | 1118 | | 7 | generating | | 1119 | | | excessive | | 1120 | | | load | | 1121 | | | | | 1122 | HTTP_VERSION_FALLBACK | 0x0 | Retry over | Section 6.1 | 1123 | | 8 | HTTP/2 | | 1124 | | | | | 1125 | HTTP_MALFORMED_HEADERS | 0x0 | Invalid | Section 6.1 | 1126 | | 9 | HEADERS | | 1127 | | | frame | | 1128 | | | | | 1129 | HTTP_MALFORMED_PRIORITY | 0x0 | Invalid | Section 6.1 | 1130 | | A | PRIORITY | | 1131 | | | frame | | 1132 | | | | | 1133 | HTTP_MALFORMED_SETTINGS | 0x0 | Invalid | Section 6.1 | 1134 | | B | SETTINGS | | 1135 | | | frame | | 1136 | | | | | 1137 | HTTP_MALFORMED_PUSH_PROMISE | 0x0 | Invalid | Section 6.1 | 1138 | | C | PUSH_PROMISE | | 1139 | | | frame | | 1140 | | | | | 1141 | HTTP_INTERRUPTED_HEADERS | 0x0 | Incomplete | Section 6.1 | 1142 | | E | HEADERS | | 1143 | | | block | | 1144 | | | | | 1145 | HTTP_SETTINGS_ON_WRONG_STREA | 0x0 | SETTINGS | Section 6.1 | 1146 | M | F | frame on a | | 1147 | | | request | | 1148 | | | control | | 1149 | | | stream | | 1150 | | | | | 1151 | HTTP_MULTIPLE_SETTINGS | 0x1 | Multiple | Section 6.1 | 1152 | | 0 | SETTINGS | | 1153 | | | frames | | 1154 | | | | | 1155 | HTTP_RST_CONTROL_STREAM | 0x1 | Message | Section 6.1 | 1156 | | 1 | control | | 1157 | | | stream was | | 1158 | | | RST | | 1159 +------------------------------+-----+--------------+---------------+ 1161 10. References 1163 10.1. Normative References 1165 [QUIC-TRANSPORT] 1166 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1167 Multiplexed and Secure Transport", draft-ietf-quic- 1168 transport (work in progress), May 2017. 1170 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1171 RFC 793, DOI 10.17487/RFC0793, September 1981, 1172 . 1174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1175 Requirement Levels", BCP 14, RFC 2119, 1176 DOI 10.17487/RFC2119, March 1997, 1177 . 1179 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1180 Protocol (HTTP/1.1): Message Syntax and Routing", 1181 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1182 . 1184 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1185 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1186 DOI 10.17487/RFC7231, June 2014, 1187 . 1189 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1190 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1191 DOI 10.17487/RFC7540, May 2015, 1192 . 1194 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1195 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1196 . 1198 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1199 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1200 April 2016, . 1202 10.2. Informative References 1204 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1205 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1206 DOI 10.17487/RFC5226, May 2008, 1207 . 1209 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1210 "Transport Layer Security (TLS) Application-Layer Protocol 1211 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1212 July 2014, . 1214 Appendix A. Contributors 1216 The original authors of this specification were Robbie Shade and Mike 1217 Warres. 1219 Appendix B. Change Log 1221 *RFC Editor's Note:* Please remove this section prior to 1222 publication of a final version of this document. 1224 B.1. Since draft-ietf-quic-http-02 1226 o Track changes in transport draft 1228 B.2. Since draft-ietf-quic-http-01 1230 o SETTINGS changes (#181): 1232 * SETTINGS can be sent only once at the start of a connection; no 1233 changes thereafter 1235 * SETTINGS_ACK removed 1237 * Settings can only occur in the SETTINGS frame a single time 1239 * Boolean format updated 1241 o Alt-Svc parameter changed from "v" to "quic"; format updated 1242 (#229) 1244 o Closing the connection control stream or any message control 1245 stream is a fatal error (#176) 1247 o HPACK Sequence counter can wrap (#173) 1249 o 0-RTT guidance added 1251 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 1252 added (#127,#242) 1254 B.3. Since draft-ietf-quic-http-00 1256 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 1258 o Changed from using HTTP/2 framing within Stream 3 to new framing 1259 format and two-stream-per-request model (#71,#72,#73) 1261 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 1262 settings-01 1264 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 1265 order (#75) 1267 o Described CONNECT pseudo-method (#95) 1269 o Updated ALPN token and Alt-Svc guidance (#13,#87) 1271 o Application-layer-defined error codes (#19,#74) 1273 B.4. Since draft-shade-quic-http2-mapping-00 1275 o Adopted as base for draft-ietf-quic-http 1277 o Updated authors/editors list 1279 Author's Address 1281 Mike Bishop (editor) 1282 Microsoft 1284 Email: Michael.Bishop@microsoft.com