idnits 2.17.1 draft-ietf-quic-http-01.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 (January 14, 2017) is 2651 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) == Unused Reference: 'QUIC-TLS' is defined on line 1048, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-TLS' -- 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) Summary: 4 errors (**), 0 flaws (~~), 3 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 January 14, 2017 5 Expires: July 18, 2017 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-01 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. Specifically, this 16 document identifies HTTP/2 features that are subsumed by QUIC, and 17 describes how the other features can be implemented atop 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 July 18, 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. Flow Control . . . . . . . . . . . . . . . . . . . . . . 9 76 4.5. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10 78 5.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11 80 5.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12 83 5.2.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . 13 84 5.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 13 85 5.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 16 86 5.2.7. PING . . . . . . . . . . . . . . . . . . . . . . . . 17 87 5.2.8. GOAWAY frame . . . . . . . . . . . . . . . . . . . . 17 88 5.2.9. WINDOW_UPDATE frame . . . . . . . . . . . . . . . . . 17 89 5.2.10. CONTINUATION frame . . . . . . . . . . . . . . . . . 17 90 5.2.11. SETTINGS_ACK Frame . . . . . . . . . . . . . . . . . 18 91 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 19 92 6.1. HTTP-Defined QUIC Error Codes . . . . . . . . . . . . . . 19 93 6.2. Mapping HTTP/2 Error Codes . . . . . . . . . . . . . . . 20 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 8.1. Registration of HTTP/QUIC Identification String . . . . . 21 98 8.2. Registration of Version Hint Alt-Svc Parameter . . . . . 21 99 8.3. Existing Frame Types . . . . . . . . . . . . . . . . . . 22 100 8.4. New Frame Types . . . . . . . . . . . . . . . . . . . . . 23 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 9.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24 105 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 106 B.1. Since draft-ietf-quic-http-00: . . . . . . . . . . . . . 24 107 B.2. Since draft-shade-quic-http2-mapping-00: . . . . . . . . 25 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 110 1. Introduction 112 The QUIC transport protocol has several features that are desirable 113 in a transport for HTTP, such as stream multiplexing, per-stream flow 114 control, and low-latency connection establishment. This document 115 describes a mapping of HTTP semantics over QUIC, drawing heavily on 116 the existing TCP mapping, HTTP/2. Specifically, this document 117 identifies HTTP/2 features that are subsumed by QUIC, and describes 118 how the other features can be implemented atop QUIC. 120 QUIC is described in [QUIC-TRANSPORT]. For a full description of 121 HTTP/2, see [RFC7540]. 123 1.1. Notational Conventions 125 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 126 document. It's not shouting; when they are capitalized, they have 127 the special meaning defined in [RFC2119]. 129 2. QUIC Advertisement 131 A server advertises that it can speak HTTP/QUIC via the Alt-Svc 132 ([RFC7838]) HTTP response header (or the semantically equivalent Alt- 133 Svc HTTP/2 Extension Frame Type), using the ALPN token defined in 134 Section 3. 136 Thus, a server could indicate in an HTTP/1.1 or HTTP/2 response that 137 HTTP/QUIC was available on UDP port 443 by including the following 138 header in any response: 140 Alt-Svc: hq=":443" 142 2.1. QUIC Version Hints 144 This document defines the "v" parameter for Alt-Svc, which is used to 145 provide version-negotiation hints to HTTP/QUIC clients. Syntax: 147 v = version 148 version = DQUOTE ( "c" version-string / "x" version-number ) DQUOTE 149 version-string = token; percent-encoded QUIC version 150 version-number = 1*8 HEXDIG; hex-encoded QUIC version 152 When multiple versions are supported, the "v" parameter MAY be 153 repeated multiple times in a single Alt-Svc entry. For example, if a 154 server supported both version "Q034" and version 0x00000001, it would 155 specify the following header: 157 Alt-Svc: hq=":443";v="x1";v="cQ034" 159 Where multiple versions are listed, the order of the values reflects 160 the server's preference (with the first value being the most 161 preferred version). 163 QUIC versions are four-octet sequences with no additional constraints 164 on format. Versions containing octets not allowed in tokens 165 ([RFC7230], Section 3.2.6) MUST be encoded using the hexidecimal 166 representation. Versions containing only octets allowed in tokens 167 MAY be encoded using either representation. 169 On receipt of an Alt-Svc header indicating QUIC support, a client MAY 170 attempt to establish a QUIC connection on the indicated port and, if 171 successful, send HTTP requests using the mapping described in this 172 document. Servers SHOULD list only versions which they support, but 173 MAY omit supported versions for any reason. 175 Connectivity problems (e.g. firewall blocking UDP) may result in QUIC 176 connection establishment failure, in which case the client should 177 gracefully fall back to HTTP/2. 179 3. Connection Establishment 181 HTTP/QUIC connections are established as described in 182 [QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support 183 is indicated by selecting the ALPN token "hq" in the crypto 184 handshake. 186 While connection-level options pertaining to the core QUIC protocol 187 are set in the initial crypto handshake, HTTP-specific settings are 188 conveyed in the SETTINGS frame. After the QUIC connection is 189 established, a SETTINGS frame (Section 5.2.5) MUST be sent as the 190 initial frame of the HTTP control stream (StreamID 3, see Section 4). 192 3.1. Draft Version Identification 194 *RFC Editor's Note:* Please remove this section prior to 195 publication of a final version of this document. 197 Only implementations of the final, published RFC can identify 198 themselves as "hq". Until such an RFC exists, implementations MUST 199 NOT identify themselves using these strings. 201 Implementations of draft versions of the protocol MUST add the string 202 "-" and the corresponding draft number to the identifier. For 203 example, draft-ietf-quic-http-01 is identified using the string "hq- 204 01". 206 Non-compatible experiments that are based on these draft versions 207 MUST append the string "-" and an experiment name to the identifier. 208 For example, an experimental implementation based on draft-ietf-quic- 209 http-09 which reserves an extra stream for unsolicited transmission 210 of 1980s pop music might identify itself as "hq-09-rickroll". Note 211 that any label MUST conform to the "token" syntax defined in 212 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 213 coordinate their experiments on the quic@ietf.org mailing list. 215 4. Stream Mapping and Usage 217 A QUIC stream provides reliable in-order delivery of bytes, but makes 218 no guarantees about order of delivery with regard to bytes on other 219 streams. On the wire, data is framed into QUIC STREAM frames, but 220 this framing is invisible to the HTTP framing layer. A QUIC receiver 221 buffers and orders received STREAM frames, exposing the data 222 contained within as a reliable byte stream to the application. 224 QUIC reserves Stream 1 for crypto operations (the handshake, crypto 225 config updates). Stream 3 is reserved for sending and receiving HTTP 226 control frames, and is analogous to HTTP/2's Stream 0. 228 When HTTP headers and data are sent over QUIC, the QUIC layer handles 229 most of the stream management. An HTTP request/response consumes a 230 pair of streams: This means that the client's first request occurs on 231 QUIC streams 5 and 7, the second on stream 9 and 11, and so on. The 232 server's first push consumes streams 2 and 4. This amounts to the 233 second least-significant bit differentiating the two streams in a 234 request. 236 The lower-numbered stream is called the message control stream and 237 carries frames related to the request/response, including HEADERS. 238 All request control streams are exempt from connection-level flow 239 control. The higher-numbered stream is the data stream and carries 240 the request/response body with no additional framing. Note that a 241 request or response without a body will cause this stream to be half- 242 closed in the corresponding direction without transferring data. 244 Pairs of streams must be utilized sequentially, with no gaps. The 245 data stream MUST be reserved with the QUIC implementation when the 246 message control stream is opened or reserved, and MUST be closed 247 after transferring the body, or else closed immediately after sending 248 the request headers if there is no body. 250 HTTP does not need to do any separate multiplexing when using QUIC - 251 data sent over a QUIC stream always maps to a particular HTTP 252 transaction. Requests and responses are considered complete when the 253 corresponding QUIC streams are closed in the appropriate direction. 255 4.1. Stream 3: Connection Control Stream 257 Since most connection-level concerns from HTTP/2 will be managed by 258 QUIC, the primary use of Stream 3 will be for SETTINGS and PRIORITY 259 frames. Stream 3 is exempt from connection-level flow-control. 261 4.2. HTTP Message Exchanges 263 A client sends an HTTP request on a new pair of QUIC streams. A 264 server sends an HTTP response on the same streams as the request. 266 An HTTP message (request or response) consists of: 268 1. for a response only, zero or more header blocks (a sequence of 269 HEADERS frames with End Header Block set on the last) on the 270 control stream containing the message headers of informational 271 (1xx) HTTP responses (see [RFC7230], Section 3.2 and [RFC7231], 272 Section 6.2), 274 2. one header block on the control stream containing the message 275 headers (see [RFC7230], Section 3.2), 277 3. the payload body (see [RFC7230], Section 3.3), sent on the data 278 stream, 280 4. optionally, one header block on the control stream containing the 281 trailer-part, if present (see [RFC7230], Section 4.1.2). 283 The data stream MUST be half-closed immediately after the transfer of 284 the body. If the message does not contain a body, the corresponding 285 data stream MUST still be half-closed without transferring any data. 286 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 287 MUST NOT be used. 289 Trailing header fields are carried in a header block following the 290 body. Such a header block is a sequence of HEADERS frames with End 291 Header Block set on the last frame. Header blocks after the first 292 but before the end of the stream are invalid. These MUST be decoded 293 to maintain HPACK decoder state, but the resulting output MUST be 294 discarded. 296 An HTTP request/response exchange fully consumes a pair of streams. 297 After sending a request, a client closes the streams for sending; 298 after sending a response, the server closes its streams for sending 299 and the QUIC streams are fully closed. 301 A server can send a complete response prior to the client sending an 302 entire request if the response does not depend on any portion of the 303 request that has not been sent and received. When this is true, a 304 server MAY request that the client abort transmission of a request 305 without error by sending a RST_STREAM with an error code of NO_ERROR 306 after sending a complete response and closing its stream. Clients 307 MUST NOT discard responses as a result of receiving such a 308 RST_STREAM, though clients can always discard responses at their 309 discretion for other reasons. 311 4.2.1. Header Compression 313 HTTP/QUIC uses HPACK header compression as described in [RFC7541]. 314 HPACK was designed for HTTP/2 with the assumption of in- order 315 delivery such as that provided by TCP. A sequence of encoded header 316 blocks must arrive (and be decoded) at an endpoint in the same order 317 in which they were encoded. This ensures that the dynamic state at 318 the two endpoints remains in sync. 320 QUIC streams provide in-order delivery of data sent on those streams, 321 but there are no guarantees about order of delivery between streams. 322 To achieve in-order delivery of HEADERS frames in QUIC, the HPACK- 323 bearing frames contain a counter which can be used to ensure in-order 324 processing. Data (request/response bodies) which arrive out of order 325 are buffered until the corresponding HEADERS arrive. 327 This does introduce head-of-line blocking: if the packet containing 328 HEADERS for stream N is lost or reordered then the HEADERS for stream 329 N+4 cannot be processed until it has been retransmitted successfully, 330 even though the HEADERS for stream N+4 may have arrived. 332 DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- 333 invariant? How much do we need to retain compatibility with 334 HTTP/2's HPACK? 336 4.2.2. The CONNECT Method 338 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 339 used with HTTP proxies to establish a TLS session with an origin 340 server for the purposes of interacting with "https" resources. In 341 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 342 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 343 establish a tunnel over a single HTTP/2 stream to a remote host for 344 similar purposes. 346 A CONNECT request in HTTP/QUIC functions in the same manner as in 347 HTTP/2. The request MUST be formatted as described in [RFC7540], 348 Section 8.3. A CONNECT request that does not conform to these 349 restrictions is malformed. The message data stream MUST NOT be 350 closed at the end of the request. 352 A proxy that supports CONNECT establishes a TCP connection 353 ([RFC0793]) to the server identified in the ":authority" pseudo- 354 header field. Once this connection is successfully established, the 355 proxy sends a HEADERS frame containing a 2xx series status code to 356 the client, as defined in [RFC7231], Section 4.3.6, on the message 357 control stream. 359 All QUIC STREAM frames on the message data stream correspond to data 360 sent on the TCP connection. Any QUIC STREAM frame sent by the client 361 is transmitted by the proxy to the TCP server; data received from the 362 TCP server is written to the data stream by the proxy. Note that the 363 size and number of TCP segments is not guaranteed to map predictably 364 to the size and number of QUIC STREAM frames. 366 The TCP connection can be closed by either peer. When the client 367 half-closes the data stream, the proxy will set the FIN bit on its 368 connection to the TCP server. When the proxy receives a packet with 369 the FIN bit set, it will half-close the corresponding data stream. 370 TCP connections which remain half-closed in a single direction are 371 not invalid, but are often handled poorly by servers, so clients 372 SHOULD NOT half-close connections on which they are still expecting 373 data. 375 A TCP connection error is signaled with RST_STREAM. A proxy treats 376 any error in the TCP connection, which includes receiving a TCP 377 segment with the RST bit set, as a stream error of type 378 HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send 379 a TCP segment with the RST bit set if it detects an error with the 380 stream or the QUIC connection. 382 4.3. Stream Priorities 384 HTTP/QUIC uses the priority scheme described in [RFC7540] 385 Section 5.3. In this priority scheme, a given stream can be 386 designated as dependent upon another stream, which expresses the 387 preference that the latter stream (the "parent" stream) be allocated 388 resources before the former stream (the "dependent" stream). Taken 389 together, the dependencies across all streams in a connection form a 390 dependency tree. The structure of the dependency tree changes as 391 HEADERS and PRIORITY frames add, remove, or change the dependency 392 links between streams. 394 Implicit in this scheme is the notion of in-order delivery of 395 priority changes (i.e., dependency tree mutations): since operations 396 on the dependency tree such as reparenting a subtree are not 397 commutative, both sender and receiver must apply them in the same 398 order to ensure that both sides have a consistent view of the stream 399 dependency tree. HTTP/2 specifies priority assignments in PRIORITY 400 frames and (optionally) in HEADERS frames. To achieve in-order 401 delivery of priority changes in HTTP/QUIC, PRIORITY frames are sent 402 on the connection control stream and the PRIORITY section is removed 403 from the HEADERS frame. The semantics of the Stream Dependency, 404 Weight, E flag, and (for HEADERS frames) PRIORITY flag are the same 405 as in HTTP/2. 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. Flow Control 412 QUIC provides stream and connection level flow control, similar in 413 principle to HTTP/2's flow control but with some implementation 414 differences. As flow control is handled by QUIC, the HTTP mapping 415 need not concern itself with maintaining flow control state. The 416 HTTP mapping MUST NOT send WINDOW_UPDATE frames at the HTTP level. 418 4.5. Server Push 420 HTTP/QUIC supports server push as described in [RFC7540]. During 421 connection establishment, the client indicates whether it is willing 422 to receive server pushes via the SETTINGS_ENABLE_PUSH setting in the 423 SETTINGS frame (see Section 3), which defaults to 1 (true). 425 As with server push for HTTP/2, the server initiates a server push by 426 sending a PUSH_PROMISE frame containing the StreamID of the stream to 427 be pushed, as well as request header fields attributed to the 428 request. The PUSH_PROMISE frame is sent on the control stream of the 429 associated (client-initiated) request, while the Promised Stream ID 430 field specifies the Stream ID of the control stream for the server- 431 initiated request. 433 The server push response is conveyed in the same way as a non-server- 434 push response, with response headers and (if present) trailers 435 carried by HEADERS frames sent on the control stream, and response 436 body (if any) sent via the corresponding data stream. 438 5. HTTP Framing Layer 440 Many framing concepts from HTTP/2 can be elided away on QUIC, because 441 the transport deals with them. Because frames are already on a 442 stream, they can omit the stream number. Because frames do not block 443 multiplexing (QUIC's multiplexing occurs below this layer), the 444 support for variable-maximum-length packets can be removed. Because 445 stream termination is handled by QUIC, an END_STREAM flag is not 446 required. 448 Frames are used only on the connection (stream 3) and message 449 (streams 5, 9, etc.) control streams. Other streams carry data 450 payload and are not framed at the HTTP layer. 452 Frame payloads are largely drawn from [RFC7540]. However, QUIC 453 includes some features (e.g. flow control) which are also present in 454 HTTP/2. In these cases, the HTTP mapping need not re-implement them. 455 As a result, some frame types are not required when using QUIC. 456 Where an HTTP/2-defined frame is no longer used, the frame ID is 457 reserved in order to maximize portability between HTTP/2 and HTTP/ 458 QUIC implementations. However, equivalent frames between the two 459 mappings are not necessarily identical. 461 This section describes HTTP framing in QUIC and highlights 462 differences from HTTP/2 framing. 464 5.1. Frame Layout 466 All frames have the following format: 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 | Length (16) | Type (8) | Flags (8) | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Frame Payload (*) ... 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 HTTP/QUIC frame format 478 5.2. Frame Definitions 480 5.2.1. DATA 482 DATA frames do not exist. Frame type 0x0 is reserved. 484 5.2.2. HEADERS 486 The HEADERS frame (type=0x1) is used to carry part of a header set, 487 compressed using HPACK [RFC7541]. Because HEADERS frames from 488 different streams will be delivered out-of-order and priority-changes 489 are not commutative, the PRIORITY region of HEADERS is not supported. 490 A separate PRIORITY frame MUST be used. 492 Padding MUST NOT be used. The flags defined are: 494 Reserved (0x1): Reserved for HTTP/2 compatibility. 496 End Header Block (0x4): This frame concludes a header block. 498 Reserved (0x8): Reserved for HTTP/2 compatibility. 500 Reserved (0x20): Reserved for HTTP/2 compatibility. 502 A HEADERS frame with the Reserved bits set MUST be treated as a 503 connection error of type HTTP_MALFORMED_HEADERS. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Sequence? (16) | Header Block Fragment (*)... 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 HEADERS frame payload 513 The HEADERS frame payload has the following fields: 515 Sequence Number: Present only on the first frame of a header block 516 sequence. This MUST be set to zero on the first header block 517 sequence, and incremented on each header block. 519 The next frame on the same stream after a HEADERS frame without the 520 EHB flag set MUST be another HEADERS frame. A receiver MUST treat 521 the receipt of any other type of frame as a stream error of type 522 HTTP_INTERRUPTED_HEADERS. (Note that QUIC can intersperse data from 523 other streams between frames, or even during transmission of frames, 524 so multiplexing is not blocked by this requirement.) 526 A full header block is contained in a sequence of zero or more 527 HEADERS frames without EHB set, followed by a HEADERS frame with EHB 528 set. 530 On receipt, header blocks (HEADERS, PUSH_PROMISE) MUST be processed 531 by the HPACK decoder in sequence. If a block is missing, all 532 subsequent HPACK frames MUST be held until it arrives, or the 533 connection terminated. 535 5.2.3. PRIORITY 537 The PRIORITY (type=0x02) frame specifies the sender-advised priority 538 of a stream and is substantially different from [RFC7540]. In order 539 to support ordering, it MUST be sent only on the connection control 540 stream. The format has been modified to accommodate not being sent 541 on-stream and the larger stream ID space of QUIC. 543 The flags defined are: 545 E (0x01): Indicates that the stream dependency is exclusive (see 546 [RFC7540] Section 5.3). 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Prioritized Stream (32) | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Dependent Stream (32) | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Weight (8) | 556 +-+-+-+-+-+-+-+-+ 558 HEADERS frame payload 560 The HEADERS frame payload has the following fields: 562 Prioritized Stream: A 32-bit stream identifier for the message 563 control stream whose priority is being updated. 565 Stream Dependency: A 32-bit stream identifier for the stream that 566 this stream depends on (see Section 4.3 and {!RFC7540}} 567 Section 5.3). 569 Weight: An unsigned 8-bit integer representing a priority weight for 570 the stream (see [RFC7540] Section 5.3). Add one to the value to 571 obtain a weight between 1 and 256. 573 A PRIORITY frame MUST have a payload length of nine octets. A 574 PRIORITY frame of any other length MUST be treated as a connection 575 error of type HTTP_MALFORMED_PRIORITY. 577 5.2.4. RST_STREAM 579 RST_STREAM frames do not exist, since QUIC provides stream lifecycle 580 management. Frame type 0x3 is reserved. 582 5.2.5. SETTINGS 584 The SETTINGS frame (type=0x4) conveys configuration parameters that 585 affect how endpoints communicate, such as preferences and constraints 586 on peer behavior, and is substantially different from [RFC7540]. 587 Individually, a SETTINGS parameter can also be referred to as a 588 "setting". 590 SETTINGS parameters are not negotiated; they describe characteristics 591 of the sending peer, which can be used by the receiving peer. 592 However, a negotiation can be implied by the use of SETTINGS - a peer 593 uses SETTINGS to advertise a set of supported values. The recipient 594 can then choose which entries from this list are also acceptable and 595 proceed with the value it has chosen. (This choice could be 596 announced in a field of an extension frame, or in its own value in 597 SETTINGS.) 599 Different values for the same parameter can be advertised by each 600 peer. For example, a client might permit a very large HPACK state 601 table while a server chooses to use a small one to conserve memory. 603 A SETTINGS frame MAY be sent at any time by either endpoint over the 604 lifetime of the connection. 606 Each parameter in a SETTINGS frame replaces any existing value for 607 that parameter. Parameters are processed in the order in which they 608 appear, and a receiver of a SETTINGS frame does not need to maintain 609 any state other than the current value of its parameters. Therefore, 610 the value of a SETTINGS parameter is the last value that is seen by a 611 receiver. 613 The SETTINGS frame defines the following flag: 615 REQUEST_ACK (0x1): When set, bit 0 indicates that this frame 616 contains values which the sender wants to know were understood and 617 applied. For more information, see Section 5.2.5.3. 619 The payload of a SETTINGS frame consists of zero or more parameters, 620 each consisting of an unsigned 16-bit setting identifier and a 621 length-prefixed binary value. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Identifier (16) |B| Length (15) | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Contents (?) ... 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 1: SETTINGS value format 633 A zero-length content indicates that the setting value is a Boolean 634 given by the B bit. If Length is not zero, the B bit MUST be zero, 635 and MUST be ignored by receivers. The initial value of each setting 636 is "false" unless otherwise specified by the definition of the 637 setting. 639 Non-zero-length values MUST be compared against the remaining length 640 of the SETTINGS frame. Any value which purports to cross the end of 641 the frame MUST cause the SETTINGS frame to be considered malformed 642 and trigger a connection error. 644 An implementation MUST ignore the contents for any SETTINGS 645 identifier it does not understand. 647 SETTINGS frames always apply to a connection, never a single stream, 648 and MUST only be sent on the connection control stream (Stream 3). 649 If an endpoint receives an SETTINGS frame whose stream identifier 650 field is anything other than 0x0, the endpoint MUST respond with a 651 connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. 653 The SETTINGS frame affects connection state. A badly formed or 654 incomplete SETTINGS frame MUST be treated as a connection error 655 (Section 5.4.1) of type HTTP_MALFORMED_SETTINGS. 657 5.2.5.1. Integer encoding 659 Settings which are integers are transmitted in network byte order. 660 Leading zero octets are permitted, but implementations SHOULD use 661 only as many bytes as are needed to represent the value. An integer 662 MUST NOT be represented in more bytes than would be used to transfer 663 the maximum permitted value. 665 5.2.5.2. Defined SETTINGS Parameters 667 Some transport-level options that HTTP/2 specifies via the SETTINGS 668 frame are superseded by QUIC transport parameters in HTTP/QUIC. 669 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 671 SETTINGS_HEADER_TABLE_SIZE: An integer with a maximum value of 2^32 672 - 1. 674 SETTINGS_ENABLE_PUSH: Transmitted as a Boolean. The default remains 675 "true" as specified in [RFC7540]. 677 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC requires the maximum number of 678 incoming streams per connection to be specified in the initial 679 crypto handshake, using the "MSPC" tag. Specifying 680 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 682 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 683 connection flow control window sizes to be specified in the 684 initial crypto handshake, using the "SFCW" and "CFCW" tags, 685 respectively. Specifying SETTINGS_INITIAL_WINDOW_SIZE in the 686 SETTINGS frame is an error. 688 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in QUIC. 689 Specifying it in the SETTINGS frame is an error. 691 SETTINGS_MAX_HEADER_LIST_SIZE: An integer with a maximium value of 692 2^32 - 1. 694 5.2.5.3. Settings Synchronization 696 Some values in SETTINGS benefit from or require an understanding of 697 when the peer has received and applied the changed parameter values. 698 In order to provide such synchronization timepoints, the recipient of 699 a SETTINGS frame MUST apply the updated parameters as soon as 700 possible upon receipt. The values in the SETTINGS frame MUST be 701 processed in the order they appear, with no other frame processing 702 between values. Unsupported parameters MUST be ignored. 704 Once all values have been processed, if the REQUEST_ACK flag was set, 705 the recipient MUST emit the following frames: 707 o On the connection control stream, a SETTINGS_ACK frame 708 (Section 5.2.11) listing the identifiers whose values were not 709 understood. 711 o On each request control stream which is not in the "half-closed 712 (local)" or "closed" state, an empty SETTINGS_ACK frame. 714 The SETTINGS_ACK frame on the connection control stream contains the 715 highest stream number which was open at the time the SETTINGS frame 716 was received. All streams with higher numbers can safely be assumed 717 to have the new settings in effect when they open. 719 For already-open streams including the connection control stream, the 720 SETTINGS_ACK frame indicates the point at which the new settings took 721 effect, if they did so before the peer half-closed the stream. If 722 the peer closed the stream before receiving the SETTINGS frame, the 723 previous settings were in effect for the full lifetime of that 724 stream. 726 In certain conditions, the SETTINGS_ACK frame can be the first frame 727 on a given stream - this simply indicates that the new settings apply 728 from the beginning of that stream. 730 If the sender of a SETTINGS frame with the REQUEST_ACK flag set does 731 not receive full acknowledgement within a reasonable amount of time, 732 it MAY issue a connection error (Section 6) of type 733 HTTP_SETTINGS_TIMEOUT. A full acknowledgement has occurred when: 735 o All previous SETTINGS frames have been fully acknowledged, 737 o A SETTINGS_ACK frame has been received on the connection control 738 stream, 740 o All message control streams with a Stream ID through those given 741 in the SETTINGS_ACK frame have either closed or received a 742 SETTINGS_ACK frame. 744 5.2.6. PUSH_PROMISE 746 The PUSH_PROMISE frame (type=0x05) is used to carry a request header 747 set from server to client, as in HTTP/2. It defines no flags. 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Promised Stream ID (32) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Sequence? (16) | Header Block (*) ... 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 PUSH_PROMISE frame payload 759 The payload consists of: 761 Promised Stream ID: A 32-bit Stream ID indicating the QUIC stream on 762 which the response headers will be sent. (The response body 763 stream is implied by the headers stream, as defined in Section 4.) 765 HPACK Sequence: A sixteen-bit counter, equivalent to the Sequence 766 field in HEADERS 768 Payload: HPACK-compressed request headers for the promised response. 770 TODOs: 772 o QUIC stream space may be enlarged; would need to redefine Promised 773 Stream field in this case. 775 o No CONTINUATION - HEADERS have EHB; do we need it here? 777 5.2.7. PING 779 PING frames do not exist, since QUIC provides equivalent 780 functionality. Frame type 0x6 is reserved. 782 5.2.8. GOAWAY frame 784 GOAWAY frames do not exist, since QUIC provides equivalent 785 functionality. Frame type 0x7 is reserved. 787 5.2.9. WINDOW_UPDATE frame 789 WINDOW_UPDATE frames do not exist, since QUIC provides equivalent 790 functionality. Frame type 0x8 is reserved. 792 5.2.10. CONTINUATION frame 794 CONTINUATION frames do not exist, since larger supported HEADERS/ 795 PUSH_PROMISE frames provide equivalent functionality. Frame type 0x9 796 is reserved. 798 5.2.11. SETTINGS_ACK Frame 800 The SETTINGS_ACK frame (id = 0x0b) acknowledges receipt and 801 application of specific values in the peer's SETTINGS frame. 802 Depending on the stream where it is sent, it takes two different 803 forms. 805 On the connection control stream, it contains information about how 806 and when the sender has processed the most recently-received SETTINGS 807 frame, and has the following payload: 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Highest Local Stream (32) | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Highest Remote Stream (32) | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Unrecognized Identifiers (*) ... 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Figure 2: SETTINGS_ACK connection control stream format 821 Highest Local Stream (32 bits): The highest locally-initiated Stream 822 ID which is not in the "idle" state 824 Highest Remote Stream (32 bits): The highest peer-initiated Stream 825 ID which is not in the "idle" state 827 Unrecognized Identifiers: A list of 16-bit SETTINGS identifiers 828 which the sender has not understood and therefore ignored. This 829 list MAY be empty. 831 On message control streams, the SETTINGS_ACK frame carries no 832 payload, and is strictly a synchronization marker for settings 833 application. See Section 5.2.5.3 for more detail. A SETTINGS_ACK 834 frame with a non-zero length MUST be treated as a connection error of 835 type HTTP_MALFORMED_SETTINGS_ACK. 837 On the connection control stream, the SETTINGS_ACK frame MUST have a 838 length which is a multiple of two octets. A SETTINGS_ACK frame of 839 any other length MUST be treated as a connection error of type 840 HTTP_MALFORMED_SETTINGS_ACK. 842 6. Error Handling 844 This section describes the specific error codes defined by HTTP and 845 the mapping of HTTP/2 error codes into the QUIC error code space. 847 6.1. HTTP-Defined QUIC Error Codes 849 QUIC allocates error codes 0x0000-0x3FFF to application protocol 850 definition. The following error codes are defined by HTTP for use in 851 QUIC RST_STREAM, GOAWAY, and CONNECTION_CLOSE frames. 853 HTTP_SETTINGS_TIMEOUT (0x00): After sending a SETTINGS frame which 854 requested acknowledgement, the acknowledgement was not completed 855 (see Section 5.2.5.3) in a timely manner. 857 HTTP_PUSH_REFUSED (0x01): The server has attempted to push content 858 which the client will not accept on this connection. 860 HTTP_INTERNAL_ERROR (0x02): An internal error has occurred in the 861 HTTP stack. 863 HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push 864 content which the client has cached. 866 HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the 867 requested data. 869 HTTP_HPACK_DECOMPRESSION_FAILED (0x05): HPACK failed to decompress a 870 frame and cannot continue. 872 HTTP_CONNECT_ERROR (0x06): The connection established in response to 873 a CONNECT request was reset or abnormally closed. 875 HTTP_EXCESSIVE_LOAD (0x07): The endpoint detected that its peer is 876 exhibiting a behavior that might be generating excessive load. 878 HTTP_VERSION_FALLBACK (0x08): The requested operation cannot be 879 served over HTTP/QUIC. The peer should retry over HTTP/2. 881 HTTP_MALFORMED_HEADERS (0x09): A HEADERS frame has been received 882 with an invalid format. 884 HTTP_MALFORMED_PRIORITY (0x0A): A HEADERS frame has been received 885 with an invalid format. 887 HTTP_MALFORMED_SETTINGS (0x0B): A HEADERS frame has been received 888 with an invalid format. 890 HTTP_MALFORMED_PUSH_PROMISE (0x0C): A HEADERS frame has been 891 received with an invalid format. 893 HTTP_MALFORMED_SETTINGS_ACK (0x0D): A HEADERS frame has been 894 received with an invalid format. 896 HTTP_INTERRUPTED_HEADERS (0x0E): A HEADERS frame without the End 897 Header Block flag was followed by a frame other than HEADERS. 899 HTTP_SETTINGS_ON_WRONG_STREAM (0x0F): A SETTINGS frame was received 900 on a request control stream. 902 6.2. Mapping HTTP/2 Error Codes 904 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to QUIC 905 error codes as follows: 907 NO_ERROR (0x0): QUIC_NO_ERROR 909 PROTOCOL_ERROR (0x1): No single mapping. See new HTTP_MALFORMED_* 910 error codes defined in Section 6.1. 912 INTERNAL_ERROR (0x2) HTTP_INTERNAL_ERROR in Section 6.1. 914 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 915 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 916 from the QUIC layer. 918 SETTINGS_TIMEOUT (0x4): HTTP_SETTINGS_TIMEOUT in Section 6.1. 920 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 921 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 922 from the QUIC layer. 924 FRAME_SIZE_ERROR (0x6) No single mapping. See new error codes 925 defined in Section 6.1. 927 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 928 management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the 929 QUIC layer. 931 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. 933 COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in 934 Section 6.1. 936 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 6.1. 938 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 6.1. 940 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 941 provide sufficient security on all connections. 943 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. 945 TODO: fill in missing error code mappings. 947 7. Security Considerations 949 The security considerations of HTTP over QUIC should be comparable to 950 those of HTTP/2. 952 The modified SETTINGS format contains nested length elements, which 953 could pose a security risk to an uncautious implementer. A SETTINGS 954 frame parser MUST ensure that the length of the frame exactly matches 955 the length of the settings it contains. 957 8. IANA Considerations 959 8.1. Registration of HTTP/QUIC Identification String 961 This document creates a new registration for the identification of 962 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 963 Protocol IDs" registry established in [RFC7301]. 965 The "hq" string identifies HTTP/QUIC: 967 Protocol: HTTP over QUIC 969 Identification Sequence: 0x68 0x71 ("hq") 971 Specification: This document 973 8.2. Registration of Version Hint Alt-Svc Parameter 975 This document creates a new registration for version-negotiation 976 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 977 registry established in [RFC7838]. 979 Parameter: "v" 981 Specification: This document, Section 2.1 983 8.3. Existing Frame Types 985 This document adds two new columns to the "HTTP/2 Frame Type" 986 registry defined in [RFC7540]: 988 Supported Protocols: Indicates which associated protocols use the 989 frame type. Values MUST be one of: 991 * "HTTP/2 only" 993 * "HTTP/QUIC only" 995 * "Both" 997 HTTP/QUIC Specification: Indicates where this frame's behavior over 998 QUIC is defined; required if the frame is supported over QUIC. 1000 Values for existing registrations are assigned by this document: 1002 +---+---------------+---------------------+-------------------------+ 1003 | | Frame Type | Supported Protocols | HTTP/QUIC Specification | 1004 +---+---------------+---------------------+-------------------------+ 1005 | | DATA | HTTP/2 only | N/A | 1006 | | | | | 1007 | | HEADERS | Both | Section 5.2.2 | 1008 | | | | | 1009 | | PRIORITY | Both | Section 5.2.3 | 1010 | | | | | 1011 | | RST_STREAM | HTTP/2 only | N/A | 1012 | | | | | 1013 | | SETTINGS | Both | Section 5.2.5 | 1014 | | | | | 1015 | | PUSH_PROMISE | Both | Section 5.2.6 | 1016 | | | | | 1017 | | PING | HTTP/2 only | N/A | 1018 | | | | | 1019 | | GOAWAY | HTTP/2 only | N/A | 1020 | | | | | 1021 | | WINDOW_UPDATE | HTTP/2 only | N/A | 1022 | | | | | 1023 | | CONTINUATION | HTTP/2 only | N/A | 1024 +---+---------------+---------------------+-------------------------+ 1026 The "Specification" column is renamed to "HTTP/2 specification" and 1027 is only required if the frame is supported over HTTP/2. 1029 8.4. New Frame Types 1031 This document adds one new entry to the "HTTP/2 Frame Type" registry 1032 defined in [RFC7540]: 1034 Frame Type: SETTINGS_ACK 1036 Code: 0x0b 1038 HTTP/2 Specification: N/A 1040 Supported Protocols: HTTP/QUIC only 1042 HTTP/QUIC Specification: Section 5.2.11 1044 9. References 1046 9.1. Normative References 1048 [QUIC-TLS] 1049 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1050 Layer Security (TLS) to Secure QUIC". 1052 [QUIC-TRANSPORT] 1053 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1054 Multiplexed and Secure Transport". 1056 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1057 RFC 793, DOI 10.17487/RFC0793, September 1981, 1058 . 1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", BCP 14, RFC 2119, 1062 DOI 10.17487/RFC2119, March 1997, 1063 . 1065 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1066 Protocol (HTTP/1.1): Message Syntax and Routing", 1067 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1068 . 1070 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1071 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1072 DOI 10.17487/RFC7231, June 2014, 1073 . 1075 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1076 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1077 DOI 10.17487/RFC7540, May 2015, 1078 . 1080 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1081 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1082 . 1084 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1085 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1086 April 2016, . 1088 9.2. Informative References 1090 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1091 "Transport Layer Security (TLS) Application-Layer Protocol 1092 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1093 July 2014, . 1095 Appendix A. Contributors 1097 The original authors of this specification were Robbie Shade and Mike 1098 Warres. 1100 Appendix B. Change Log 1102 *RFC Editor's Note:* Please remove this section prior to 1103 publication of a final version of this document. 1105 B.1. Since draft-ietf-quic-http-00: 1107 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout 1109 o Changed from using HTTP/2 framing within Stream 3 to new framing 1110 format and two-stream-per-request model 1112 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 1113 settings-01 1115 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 1116 order. 1118 o Described CONNECT pseudo-method 1120 o Updated ALPN token and Alt-Svc guidance 1122 o Application-layer-defined error codes 1124 B.2. Since draft-shade-quic-http2-mapping-00: 1126 o Adopted as base for draft-ietf-quic-http. 1128 o Updated authors/editors list. 1130 Author's Address 1132 Mike Bishop (editor) 1133 Microsoft 1135 Email: Michael.Bishop@microsoft.com