idnits 2.17.00 (12 Aug 2021) /tmp/idnits51664/draft-ietf-quic-http-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2018) is 1304 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1838 -- Looks like a reference, but probably isn't: '2' on line 1840 -- Looks like a reference, but probably isn't: '3' on line 1842 -- Looks like a reference, but probably isn't: '4' on line 1844 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-04 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALTSVC'. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Akamai 4 Intended status: Standards Track October 24, 2018 5 Expires: April 27, 2019 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-16 10 Abstract 12 The QUIC transport protocol has several features that are desirable 13 in a transport for HTTP, such as stream multiplexing, per-stream flow 14 control, and low-latency connection establishment. This document 15 describes a mapping of HTTP semantics over QUIC. This document also 16 identifies HTTP/2 features that are subsumed by QUIC, and describes 17 how HTTP/2 extensions can be ported to QUIC. 19 Note to Readers 21 Discussion of this draft takes place on the QUIC working group 22 mailing list (quic@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 25 Working Group information can be found at https://github.com/quicwg 26 [2]; source code and issues list for this draft can be found at 27 https://github.com/quicwg/base-drafts/labels/-http [3]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 27, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 65 2. Connection Setup and Management . . . . . . . . . . . . . . . 5 66 2.1. Draft Version Identification . . . . . . . . . . . . . . 5 67 2.2. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 5 68 2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6 69 2.3. Connection Establishment . . . . . . . . . . . . . . . . 6 70 2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7 71 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 72 3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8 73 3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8 74 3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 9 75 3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 9 76 3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 10 77 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10 78 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10 79 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11 80 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12 83 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 14 84 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 15 85 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 17 86 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 19 88 4.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 19 89 5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 20 90 5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 20 91 5.1.1. Header Formatting and Compression . . . . . . . . . . 21 92 5.1.2. Request Cancellation . . . . . . . . . . . . . . . . 22 93 5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 22 94 5.3. Request Prioritization . . . . . . . . . . . . . . . . . 23 95 5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 24 96 5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 24 97 5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 25 98 6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 26 99 6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 26 100 6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 27 101 6.3. Immediate Application Closure . . . . . . . . . . . . . . 28 102 6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 28 103 7. Extensions to HTTP/QUIC . . . . . . . . . . . . . . . . . . . 29 104 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29 105 8.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 30 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 108 10.1. Registration of HTTP/QUIC Identification String . . . . 32 109 10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 32 110 10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 32 111 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 33 112 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 34 113 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 37 114 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 115 11.1. Normative References . . . . . . . . . . . . . . . . . . 38 116 11.2. Informative References . . . . . . . . . . . . . . . . . 39 117 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39 118 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 39 119 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 40 120 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 40 121 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 42 122 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 43 123 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 44 124 B.1. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 44 125 B.2. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 44 126 B.3. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 44 127 B.4. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 45 128 B.5. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 45 129 B.6. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 45 130 B.7. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 45 131 B.8. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 46 132 B.9. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 46 133 B.10. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 46 134 B.11. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 46 135 B.12. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 46 136 B.13. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 47 137 B.14. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 47 138 B.15. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 47 139 B.16. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 47 140 B.17. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 48 141 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48 142 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 144 1. Introduction 146 HTTP semantics are used for a broad range of services on the 147 Internet. These semantics have commonly been used with two different 148 TCP mappings, HTTP/1.1 and HTTP/2. HTTP/2 introduced a framing and 149 multiplexing layer to improve latency without modifying the transport 150 layer. However, TCP's lack of visibility into parallel requests in 151 both mappings limited the possible performance gains. 153 The QUIC transport protocol incorporates stream multiplexing and per- 154 stream flow control, similar to that provided by the HTTP/2 framing 155 layer. By providing reliability at the stream level and congestion 156 control across the entire connection, it has the capability to 157 improve the performance of HTTP compared to a TCP mapping. QUIC also 158 incorporates TLS 1.3 at the transport layer, offering comparable 159 security to running TLS over TCP, but with improved connection setup 160 latency. 162 This document describes a mapping of HTTP semantics over the QUIC 163 transport protocol, drawing heavily on design of HTTP/2. This 164 document identifies HTTP/2 features that are subsumed by QUIC, and 165 describes how the other features can be implemented atop QUIC. 167 QUIC is described in [QUIC-TRANSPORT]. For a full description of 168 HTTP/2, see [RFC7540]. 170 1.1. Notational Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 179 defined in [RFC5234]. 181 This document uses the variable-length integer encoding from 182 [QUIC-TRANSPORT]. 184 Protocol elements called "frames" exist in both this document and 185 [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, 186 the frame name will be prefaced with "QUIC." For example, "QUIC 187 APPLICATION_CLOSE frames." References without this preface refer to 188 frames defined in Section 4.2. 190 2. Connection Setup and Management 192 2.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 HTTP/QUIC uses the token "hq" to identify itself in ALPN and Alt-Svc. 198 Only implementations of the final, published RFC can identify 199 themselves as "hq". Until such an RFC exists, implementations MUST 200 NOT identify themselves using this string. 202 Implementations of draft versions of the protocol MUST add the string 203 "-" and the corresponding draft number to the identifier. For 204 example, draft-ietf-quic-http-01 is identified using the string "hq- 205 01". 207 Non-compatible experiments that are based on these draft versions 208 MUST append the string "-" and an experiment name to the identifier. 209 For example, an experimental implementation based on draft-ietf-quic- 210 http-09 which reserves an extra stream for unsolicited transmission 211 of 1980s pop music might identify itself as "hq-09-rickroll". Note 212 that any label MUST conform to the "token" syntax defined in 213 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 214 coordinate their experiments on the quic@ietf.org mailing list. 216 2.2. Discovering an HTTP/QUIC Endpoint 218 An HTTP origin advertises the availability of an equivalent HTTP/QUIC 219 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 220 ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 2.3. 222 For example, an origin could indicate in an HTTP/1.1 or HTTP/2 223 response that HTTP/QUIC was available on UDP port 50781 at the same 224 hostname by including the following header field in any response: 226 Alt-Svc: hq=":50781" 228 On receipt of an Alt-Svc record indicating HTTP/QUIC support, a 229 client MAY attempt to establish a QUIC connection to the indicated 230 host and port and, if successful, send HTTP requests using the 231 mapping described in this document. 233 Connectivity problems (e.g. firewall blocking UDP) can result in QUIC 234 connection establishment failure, in which case the client SHOULD 235 continue using the existing connection or try another alternative 236 endpoint offered by the origin. 238 Servers MAY serve HTTP/QUIC on any UDP port, since an alternative 239 always includes an explicit port. 241 2.2.1. QUIC Version Hints 243 This document defines the "quic" parameter for Alt-Svc, which MAY be 244 used to provide version-negotiation hints to HTTP/QUIC clients. QUIC 245 versions are four-octet sequences with no additional constraints on 246 format. Leading zeros SHOULD be omitted for brevity. 248 Syntax: 250 quic = DQUOTE version-number [ "," version-number ] * DQUOTE 251 version-number = 1*8HEXDIG; hex-encoded QUIC version 253 Where multiple versions are listed, the order of the values reflects 254 the server's preference (with the first value being the most 255 preferred version). Reserved versions MAY be listed, but unreserved 256 versions which are not supported by the alternative SHOULD NOT be 257 present in the list. Origins MAY omit supported versions for any 258 reason. 260 Clients MUST ignore any included versions which they do not support. 261 The "quic" parameter MUST NOT occur more than once; clients SHOULD 262 process only the first occurrence. 264 For example, suppose a server supported both version 0x00000001 and 265 the version rendered in ASCII as "Q034". If it also opted to include 266 the reserved version (from Section 3 of [QUIC-TRANSPORT]) 0x1abadaba, 267 it could specify the following header field: 269 Alt-Svc: hq=":49288";quic="1,1abadaba,51303334" 271 A client acting on this header field would drop the reserved version 272 (not supported), then attempt to connect to the alternative using the 273 first version in the list which it does support, if any. 275 2.3. Connection Establishment 277 HTTP/QUIC relies on QUIC as the underlying transport. The QUIC 278 version being used MUST use TLS version 1.3 or greater as its 279 handshake protocol. HTTP/QUIC clients MUST indicate the target 280 domain name during the TLS handshake. This may be done using the 281 Server Name Indication (SNI) [RFC6066] extension to TLS or using some 282 other mechanism. 284 QUIC connections are established as described in [QUIC-TRANSPORT]. 285 During connection establishment, HTTP/QUIC support is indicated by 286 selecting the ALPN token "hq" in the TLS handshake. Support for 287 other application-layer protocols MAY be offered in the same 288 handshake. 290 While connection-level options pertaining to the core QUIC protocol 291 are set in the initial crypto handshake, HTTP/QUIC-specific settings 292 are conveyed in the SETTINGS frame. After the QUIC connection is 293 established, a SETTINGS frame (Section 4.2.5) MUST be sent by each 294 endpoint as the initial frame of their respective HTTP control stream 295 (see Section 3.2.1). The server MUST NOT process any request streams 296 or send responses until the client's SETTINGS frame has been 297 received. 299 2.4. Connection Reuse 301 Once a connection exists to a server endpoint, this connection MAY be 302 reused for requests with multiple different URI authority components. 303 The client MAY send any requests for which the client considers the 304 server authoritative. 306 An authoritative HTTP/QUIC endpoint is typically discovered because 307 the client has received an Alt-Svc record from the request's origin 308 which nominates the endpoint as a valid HTTP Alternative Service for 309 that origin. As required by [RFC7838], clients MUST check that the 310 nominated server can present a valid certificate for the origin 311 before considering it authoritative. Clients MUST NOT assume that an 312 HTTP/QUIC endpoint is authoritative for other origins without an 313 explicit signal. 315 A server that does not wish clients to reuse connections for a 316 particular origin can indicate that it is not authoritative for a 317 request by sending a 421 (Misdirected Request) status code in 318 response to the request (see Section 9.1.2 of [RFC7540]). 320 The considerations discussed in Section 9.1 of [RFC7540] also apply 321 to the management of HTTP/QUIC connections. 323 3. Stream Mapping and Usage 325 A QUIC stream provides reliable in-order delivery of bytes, but makes 326 no guarantees about order of delivery with regard to bytes on other 327 streams. On the wire, data is framed into QUIC STREAM frames, but 328 this framing is invisible to the HTTP framing layer. The transport 329 layer buffers and orders received QUIC STREAM frames, exposing the 330 data contained within as a reliable byte stream to the application. 332 QUIC streams can be either unidirectional, carrying data only from 333 initiator to receiver, or bidirectional. Streams can be initiated by 334 either the client or the server. For more detail on QUIC streams, 335 see [QUIC-TRANSPORT], Section 9. 337 When HTTP headers and data are sent over QUIC, the QUIC layer handles 338 most of the stream management. HTTP does not need to do any separate 339 multiplexing when using QUIC - data sent over a QUIC stream always 340 maps to a particular HTTP transaction or connection context. 342 3.1. Bidirectional Streams 344 All client-initiated bidirectional streams are used for HTTP requests 345 and responses. A bidirectional stream ensures that the response can 346 be readily correlated with the request. This means that the client's 347 first request occurs on QUIC stream 0, with subsequent requests on 348 stream 4, 8, and so on. In order to permit these streams to open, an 349 HTTP/QUIC client SHOULD send non-zero values for the QUIC transport 350 parameters "initial_max_stream_data_bidi_local". An HTTP/QUIC server 351 SHOULD send non-zero values for the QUIC transport parameters 352 "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". 353 It is recommended that "initial_max_bidi_streams" be no smaller than 354 100, so as to not unnecessarily limit parallelism. 356 These streams carry frames related to the request/response (see 357 Section 5.1). When a stream terminates cleanly, if the last frame on 358 the stream was truncated, this MUST be treated as a connection error 359 (see HTTP_MALFORMED_FRAME in Section 8.1). Streams which terminate 360 abruptly may be reset at any point in the frame. 362 HTTP/QUIC does not use server-initiated bidirectional streams; 363 clients MUST omit or specify a value of zero for the QUIC transport 364 parameter "initial_max_bidi_streams". 366 3.2. Unidirectional Streams 368 Unidirectional streams, in either direction, are used for a range of 369 purposes. The purpose is indicated by a stream type, which is sent 370 as a single octet header at the start of the stream. The format and 371 structure of data that follows this header is determined by the 372 stream type. 374 0 1 2 3 4 5 6 7 375 +-+-+-+-+-+-+-+-+ 376 |Stream Type (8)| 377 +-+-+-+-+-+-+-+-+ 379 Figure 1: Unidirectional Stream Header 381 Some stream types are reserved (Section 3.2.3). Two stream types are 382 defined in this document: control streams (Section 3.2.1) and push 383 streams (Section 3.2.2). Other stream types can be defined by 384 extensions to HTTP/QUIC. 386 Both clients and servers SHOULD send a value of three or greater for 387 the QUIC transport parameter "initial_max_uni_streams". 389 If the stream header indicates a stream type which is not supported 390 by the recipient, the remainder of the stream cannot be consumed as 391 the semantics are unknown. Recipients of unknown stream types MAY 392 trigger a QUIC STOP_SENDING frame with an error code of 393 HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an 394 error of any kind. 396 Implementations MAY send stream types before knowing whether the peer 397 supports them. However, stream types which could modify the state or 398 semantics of existing protocol components, including QPACK or other 399 extensions, MUST NOT be sent until the peer is known to support them. 401 3.2.1. Control Streams 403 The control stream is indicated by a stream type of "0x43" (ASCII 404 'C'). Data on this stream consists of HTTP/QUIC frames, as defined 405 in Section 4.2. 407 Each side MUST initiate a single control stream at the beginning of 408 the connection and send its SETTINGS frame as the first frame on this 409 stream. If the first frame of the control stream is any other frame 410 type, this MUST be treated as a connection error of type 411 HTTP_MISSING_SETTINGS. Only one control stream per peer is 412 permitted; receipt of a second stream which claims to be a control 413 stream MUST be treated as a connection error of type 414 HTTP_WRONG_STREAM_COUNT. If the control stream is closed at any 415 point, this MUST be treated as a connection error of type 416 HTTP_CLOSED_CRITICAL_STREAM. 418 A pair of unidirectional streams is used rather than a single 419 bidirectional stream. This allows either peer to send data as soon 420 they are able. Depending on whether 0-RTT is enabled on the 421 connection, either client or server might be able to send stream data 422 first after the cryptographic handshake completes. 424 3.2.2. Push Streams 426 A push stream is indicated by a stream type of "0x50" (ASCII 'P'), 427 followed by the Push ID of the promise that it fulfills, encoded as a 428 variable-length integer. The remaining data on this stream consists 429 of HTTP/QUIC frames, as defined in Section 4.2, and fulfills a 430 promised server push. Server push and Push IDs are described in 431 Section 5.4. 433 Only servers can push; if a server receives a client-initiated push 434 stream, this MUST be treated as a stream error of type 435 HTTP_WRONG_STREAM_DIRECTION. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |Stream Type (8)| Push ID (i) ... 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 2: Push Stream Header 445 Each Push ID MUST only be used once in a push stream header. If a 446 push stream header includes a Push ID that was used in another push 447 stream header, the client MUST treat this as a connection error of 448 type HTTP_DUPLICATE_PUSH. 450 3.2.3. Reserved Stream Types 452 Stream types of the format "0x1f * N" are reserved to exercise the 453 requirement that unknown types be ignored. These streams have no 454 semantic meaning, and can be sent when application-layer padding is 455 desired. They MAY also be sent on connections where no request data 456 is currently being transferred. Endpoints MUST NOT consider these 457 streams to have any meaning upon receipt. 459 The payload and length of the stream are selected in any manner the 460 implementation chooses. 462 4. HTTP Framing Layer 464 Frames are used on the control stream, request streams, and push 465 streams. This section describes HTTP framing in QUIC. For a 466 comparison with HTTP/2 frames, see Appendix A.2. 468 4.1. Frame Layout 470 All frames have the following format: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Length (i) ... 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type (8) | Frame Payload (*) ... 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 3: HTTP/QUIC frame format 482 A frame includes the following fields: 484 Length: A variable-length integer that describes the length of the 485 Frame Payload. This length does not include the Type field. 487 Type: An 8-bit type for the frame. 489 Frame Payload: A payload, the semantics of which are determined by 490 the Type field. 492 Each frame's payload MUST contain exactly the identified fields. A 493 frame that contains additional octets after the identified fields or 494 a frame that terminates before the end of the identified fields MUST 495 be treated as a connection error of type HTTP_MALFORMED_FRAME. 497 4.2. Frame Definitions 499 4.2.1. DATA 501 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 502 octets associated with an HTTP request or response payload. 504 DATA frames MUST be associated with an HTTP request or response. If 505 a DATA frame is received on either control stream, the recipient MUST 506 respond with a connection error (Section 8) of type 507 HTTP_WRONG_STREAM. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Payload (*) ... 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 4: DATA frame payload 517 DATA frames MUST contain a non-zero-length payload. If a DATA frame 518 is received with a payload length of zero, the recipient MUST respond 519 with a stream error (Section 8) of type HTTP_MALFORMED_FRAME. 521 4.2.2. HEADERS 523 The HEADERS frame (type=0x1) is used to carry a header block, 524 compressed using QPACK. See [QPACK] for more details. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Header Block (*) ... 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 5: HEADERS frame payload 534 HEADERS frames can only be sent on request / push streams. 536 4.2.3. PRIORITY 538 The PRIORITY (type=0x02) frame specifies the sender-advised priority 539 of a stream. In order to ensure that prioritization is processed in 540 a consistent order, PRIORITY frames MUST be sent on the control 541 stream. A PRIORITY frame sent on any other stream MUST be treated as 542 a connection error of type HTTP_WRONG_STREAM. 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |PT |DT |Empty|E| Prioritized Element ID (i) ... 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Element Dependency ID (i) ... 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Weight (8) | 552 +-+-+-+-+-+-+-+-+ 554 Figure 6: PRIORITY frame payload 556 The PRIORITY frame payload has the following fields: 558 Prioritized Type: A two-bit field indicating the type of element 559 being prioritized. 561 Dependency Type: A two-bit field indicating the type of element 562 being depended on. 564 Empty: A three-bit field which MUST be zero when sent and MUST be 565 ignored on receipt. 567 Exclusive: A flag which indicates that the stream dependency is 568 exclusive (see [RFC7540], Section 5.3). 570 Prioritized Element ID: A variable-length integer that identifies 571 the element being prioritized. Depending on the value of 572 Prioritized Type, this contains the Stream ID of a request stream, 573 the Push ID of a promised resource, or a Placeholder ID of a 574 placeholder. 576 Element Dependency ID: A variable-length integer that identifies the 577 element on which a dependency is being expressed. Depending on 578 the value of Dependency Type, this contains the Stream ID of a 579 request stream, the Push ID of a promised resource, the 580 Placeholder ID of a placeholder, or is ignored. For details of 581 dependencies, see Section 5.3 and [RFC7540], Section 5.3. 583 Weight: An unsigned 8-bit integer representing a priority weight for 584 the stream (see [RFC7540], Section 5.3). Add one to the value to 585 obtain a weight between 1 and 256. 587 A PRIORITY frame identifies an element to prioritize, and an element 588 upon which it depends. A Prioritized ID or Dependency ID identifies 589 a client-initiated request using the corresponding stream ID, a 590 server push using a Push ID (see Section 4.2.6), or a placeholder 591 using a Placeholder ID (see Section 5.3.1). 593 The values for the Prioritized Element Type and Element Dependency 594 Type imply the interpretation of the associated Element ID fields. 596 +-----------+------------------+---------------------+ 597 | Type Bits | Type Description | Element ID Contents | 598 +-----------+------------------+---------------------+ 599 | 00 | Request stream | Stream ID | 600 | | | | 601 | 01 | Push stream | Push ID | 602 | | | | 603 | 10 | Placeholder | Placeholder ID | 604 | | | | 605 | 11 | Root of the tree | Ignored | 606 +-----------+------------------+---------------------+ 608 Note that the root of the tree cannot be referenced using a Stream ID 609 of 0, as in [RFC7540]; QUIC stream 0 carries a valid HTTP request. 610 The root of the tree cannot be reprioritized. A PRIORITY frame that 611 prioritizes the root of the tree MUST be treated as a connection 612 error of type HTTP_MALFORMED_FRAME. 614 When a PRIORITY frame claims to reference a request, the associated 615 ID MUST identify a client-initiated bidirectional stream. A server 616 MUST treat receipt of PRIORITY frame with a Stream ID of any other 617 type as a connection error of type HTTP_MALFORMED_FRAME. 619 A PRIORITY frame that references a non-existent Push ID or a 620 Placeholder ID greater than the server's limit MUST be treated as a 621 HTTP_MALFORMED_FRAME error. 623 4.2.4. CANCEL_PUSH 625 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 626 server push prior to the push stream being created. The CANCEL_PUSH 627 frame identifies a server push by Push ID (see Section 4.2.6), 628 encoded as a variable-length integer. 630 When a server receives this frame, it aborts sending the response for 631 the identified server push. If the server has not yet started to 632 send the server push, it can use the receipt of a CANCEL_PUSH frame 633 to avoid opening a push stream. If the push stream has been opened 634 by the server, the server SHOULD send a QUIC RST_STREAM frame on that 635 stream and cease transmission of the response. 637 A server can send this frame to indicate that it will not be 638 fulfilling a promise prior to creation of a push stream. Once the 639 push stream has been created, sending CANCEL_PUSH has no effect on 640 the state of the push stream. A QUIC RST_STREAM frame SHOULD be used 641 instead to abort transmission of the server push response. 643 A CANCEL_PUSH frame is sent on the control stream. Sending a 644 CANCEL_PUSH frame on a stream other than the control stream MUST be 645 treated as a stream error of type HTTP_WRONG_STREAM. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Push ID (i) ... 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Figure 7: CANCEL_PUSH frame payload 655 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 656 integer. The Push ID identifies the server push that is being 657 cancelled (see Section 4.2.6). 659 If the client receives a CANCEL_PUSH frame, that frame might identify 660 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. 662 An endpoint MUST treat a CANCEL_PUSH frame which does not contain 663 exactly one properly-formatted variable-length integer as a 664 connection error of type HTTP_MALFORMED_FRAME. 666 4.2.5. SETTINGS 668 The SETTINGS frame (type=0x4) conveys configuration parameters that 669 affect how endpoints communicate, such as preferences and constraints 670 on peer behavior. Individually, a SETTINGS parameter can also be 671 referred to as a "setting"; the identifier and value of each setting 672 parameter can be referred to as a "setting identifier" and a "setting 673 value". 675 SETTINGS parameters are not negotiated; they describe characteristics 676 of the sending peer, which can be used by the receiving peer. 677 However, a negotiation can be implied by the use of SETTINGS - a peer 678 uses SETTINGS to advertise a set of supported values. The recipient 679 can then choose which entries from this list are also acceptable and 680 proceed with the value it has chosen. (This choice could be 681 announced in a field of an extension frame, or in its own value in 682 SETTINGS.) 684 Different values for the same parameter can be advertised by each 685 peer. For example, a client might be willing to consume a very large 686 response header, while servers are more cautious about request size. 688 Parameters MUST NOT occur more than once. A receiver MAY treat the 689 presence of the same parameter more than once as a connection error 690 of type HTTP_MALFORMED_FRAME. 692 The payload of a SETTINGS frame consists of zero or more parameters, 693 each consisting of an unsigned 16-bit setting identifier and a value 694 which uses the QUIC variable-length integer encoding. 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Identifier (16) | Value (i) ... 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Figure 8: SETTINGS parameter format 704 Each value MUST be compared against the remaining length of the 705 SETTINGS frame. A variable-length integer value which cannot fit 706 within the remaining length of the SETTINGS frame MUST cause the 707 SETTINGS frame to be considered malformed and trigger a connection 708 error of type HTTP_MALFORMED_FRAME. 710 An implementation MUST ignore the contents for any SETTINGS 711 identifier it does not understand. 713 SETTINGS frames always apply to a connection, never a single stream. 714 A SETTINGS frame MUST be sent as the first frame of each control 715 stream (see Section 3.2.1) by each peer, and MUST NOT be sent 716 subsequently or on any other stream. If an endpoint receives a 717 SETTINGS frame on a different stream, the endpoint MUST respond with 718 a connection error of type HTTP_WRONG_STREAM. If an endpoint 719 receives a second SETTINGS frame, the endpoint MUST respond with a 720 connection error of type HTTP_MALFORMED_FRAME. 722 The SETTINGS frame affects connection state. A badly formed or 723 incomplete SETTINGS frame MUST be treated as a connection error 724 (Section 8) of type HTTP_MALFORMED_FRAME. 726 4.2.5.1. Defined SETTINGS Parameters 728 The following settings are defined in HTTP/QUIC: 730 SETTINGS_NUM_PLACEHOLDERS (0x3): This value SHOULD be non-zero. The 731 default value is 16. 733 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. 735 Setting identifiers of the format "0x?a?a" are reserved to exercise 736 the requirement that unknown identifiers be ignored. Such settings 737 have no defined meaning. Endpoints SHOULD include at least one such 738 setting in their SETTINGS frame. Endpoints MUST NOT consider such 739 settings to have any meaning upon receipt. 741 Because the setting has no defined meaning, the value of the setting 742 can be any value the implementation selects. 744 Additional settings MAY be defined by extensions to HTTP/QUIC. 746 4.2.5.2. Initialization 748 When a 0-RTT QUIC connection is being used, the client's initial 749 requests will be sent before the arrival of the server's SETTINGS 750 frame. Clients MUST store the settings the server provided in the 751 session being resumed and MUST comply with stored settings until the 752 server's current settings are received. Remembered settings apply to 753 the new connection until the server's SETTINGS frame is received. 755 A server can remember the settings that it advertised, or store an 756 integrity-protected copy of the values in the ticket and recover the 757 information when accepting 0-RTT data. A server uses the HTTP/QUIC 758 settings values in determining whether to accept 0-RTT data. 760 A server MAY accept 0-RTT and subsequently provide different settings 761 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 762 SETTINGS frame MUST NOT reduce any limits or alter any values that 763 might be violated by the client with its 0-RTT data. 765 When a 1-RTT QUIC connection is being used, the client MUST NOT send 766 requests prior to receiving and processing the server's SETTINGS 767 frame. 769 4.2.6. PUSH_PROMISE 771 The PUSH_PROMISE frame (type=0x05) is used to carry a promised 772 request header set from server to client, as in HTTP/2. 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Push ID (i) ... 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Header Block (*) ... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Figure 9: PUSH_PROMISE frame payload 784 The payload consists of: 786 Push ID: A variable-length integer that identifies the server push 787 operation. A Push ID is used in push stream headers 788 (Section 5.4), CANCEL_PUSH frames (Section 4.2.4), and PRIORITY 789 frames (Section 4.2.3). 791 Header Block: QPACK-compressed request header fields for the 792 promised response. See [QPACK] for more details. 794 A server MUST NOT use a Push ID that is larger than the client has 795 provided in a MAX_PUSH_ID frame (Section 4.2.8). A client MUST treat 796 receipt of a PUSH_PROMISE that contains a larger Push ID than the 797 client has advertised as a connection error of type 798 HTTP_MALFORMED_FRAME. 800 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 801 This allows the server to use the same server push in response to 802 multiple concurrent requests. Referencing the same server push 803 ensures that a PUSH_PROMISE can be made in relation to every response 804 in which server push might be needed without duplicating pushes. 806 A server that uses the same Push ID in multiple PUSH_PROMISE frames 807 MUST include the same header fields each time. The octets of the 808 header block MAY be different due to differing encoding, but the 809 header fields and their values MUST be identical. Note that ordering 810 of header fields is significant. A client MUST treat receipt of a 811 PUSH_PROMISE with conflicting header field values for the same Push 812 ID as a connection error of type HTTP_MALFORMED_FRAME. 814 Allowing duplicate references to the same Push ID is primarily to 815 reduce duplication caused by concurrent requests. A server SHOULD 816 avoid reusing a Push ID over a long period. Clients are likely to 817 consume server push responses and not retain them for reuse over 818 time. Clients that see a PUSH_PROMISE that uses a Push ID that they 819 have since consumed and discarded are forced to ignore the 820 PUSH_PROMISE. 822 4.2.7. GOAWAY 824 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 825 a connection by a server. GOAWAY allows a server to stop accepting 826 new requests while still finishing processing of previously received 827 requests. This enables administrative actions, like server 828 maintenance. GOAWAY by itself does not close a connection. 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Stream ID (i) ... 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Figure 10: GOAWAY frame payload 838 The GOAWAY frame carries a QUIC Stream ID for a client-initiated 839 bidirectional stream encoded as a variable-length integer. A client 840 MUST treat receipt of a GOAWAY frame containing a Stream ID of any 841 other type as a connection error of type HTTP_MALFORMED_FRAME. 843 Clients do not need to send GOAWAY to initiate a graceful shutdown; 844 they simply stop making new requests. A server MUST treat receipt of 845 a GOAWAY frame as a connection error (Section 8) of type 846 HTTP_UNEXPECTED_GOAWAY. 848 The GOAWAY frame applies to the connection, not a specific stream. 849 An endpoint MUST treat a GOAWAY frame on a stream other than the 850 control stream as a connection error (Section 8) of type 851 HTTP_WRONG_STREAM. 853 See Section 6.2 for more information on the use of the GOAWAY frame. 855 4.2.8. MAX_PUSH_ID 857 The MAX_PUSH_ID frame (type=0xD) is used by clients to control the 858 number of server pushes that the server can initiate. This sets the 859 maximum value for a Push ID that the server can use in a PUSH_PROMISE 860 frame. Consequently, this also limits the number of push streams 861 that the server can initiate in addition to the limit set by the QUIC 862 MAX_STREAM_ID frame. 864 The MAX_PUSH_ID frame is always sent on a control stream. Receipt of 865 a MAX_PUSH_ID frame on any other stream MUST be treated as a 866 connection error of type HTTP_WRONG_STREAM. 868 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 869 receipt of a MAX_PUSH_ID frame as a connection error of type 870 HTTP_MALFORMED_FRAME. 872 The maximum Push ID is unset when a connection is created, meaning 873 that a server cannot push until it receives a MAX_PUSH_ID frame. A 874 client that wishes to manage the number of promised server pushes can 875 increase the maximum Push ID by sending MAX_PUSH_ID frames as the 876 server fulfills or cancels server pushes. 878 0 1 2 3 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Push ID (i) ... 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Figure 11: MAX_PUSH_ID frame payload 886 The MAX_PUSH_ID frame carries a single variable-length integer that 887 identifies the maximum value for a Push ID that the server can use 888 (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum 889 Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than 890 previously received MUST be treated as a connection error of type 891 HTTP_MALFORMED_FRAME. 893 A server MUST treat a MAX_PUSH_ID frame payload that does not contain 894 a single variable-length integer as a connection error of type 895 HTTP_MALFORMED_FRAME. 897 4.2.9. Reserved Frame Types 899 Frame types of the format "0xb + (0x1f * N)" are reserved to exercise 900 the requirement that unknown types be ignored (Section 7). These 901 frames have no semantic value, and can be sent when application-layer 902 padding is desired. They MAY also be sent on connections where no 903 request data is currently being transferred. Endpoints MUST NOT 904 consider these frames to have any meaning upon receipt. 906 The payload and length of the frames are selected in any manner the 907 implementation chooses. 909 5. HTTP Request Lifecycle 911 5.1. HTTP Message Exchanges 913 A client sends an HTTP request on a client-initiated bidirectional 914 QUIC stream. A server sends an HTTP response on the same stream as 915 the request. 917 An HTTP message (request or response) consists of: 919 1. the message header (see [RFC7230], Section 3.2), sent as a single 920 HEADERS frame (see Section 4.2.2), 922 2. the payload body (see [RFC7230], Section 3.3), sent as a series 923 of DATA frames (see Section 4.2.1), 925 3. optionally, one HEADERS frame containing the trailer-part, if 926 present (see [RFC7230], Section 4.1.2). 928 A server MAY interleave one or more PUSH_PROMISE frames (see 929 Section 4.2.6) with the frames of a response message. These 930 PUSH_PROMISE frames are not part of the response; see Section 5.4 for 931 more details. 933 The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] 934 MUST NOT be used. 936 Trailing header fields are carried in an additional header block 937 following the body. Senders MUST send only one header block in the 938 trailers section; receivers MUST discard any subsequent header 939 blocks. 941 A response MAY consist of multiple messages when and only when one or 942 more informational responses (1xx, see [RFC7231], Section 6.2) 943 precede a final response to the same request. Non-final responses do 944 not contain a payload body or trailers. 946 An HTTP request/response exchange fully consumes a bidirectional QUIC 947 stream. After sending a request, a client closes the stream for 948 sending; after sending a final response, the server closes the stream 949 for sending and the QUIC stream is fully closed. Requests and 950 responses are considered complete when the corresponding QUIC stream 951 is closed in the appropriate direction. 953 A server can send a complete response prior to the client sending an 954 entire request if the response does not depend on any portion of the 955 request that has not been sent and received. When this is true, a 956 server MAY request that the client abort transmission of a request 957 without error by triggering a QUIC STOP_SENDING frame with error code 958 HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing 959 its stream. Clients MUST NOT discard complete responses as a result 960 of having their request terminated abruptly, though clients can 961 always discard responses at their discretion for other reasons. 963 Changes to the state of a request stream, including receiving a 964 RST_STREAM with any error code, do not affect the state of the 965 server's response. Servers do not abort a response in progress 966 solely due to a state change on the request stream. However, if the 967 request stream terminates without containing a usable HTTP request, 968 the server SHOULD abort its response with the error code 969 HTTP_INCOMPLETE_REQUEST. 971 5.1.1. Header Formatting and Compression 973 HTTP message headers carry information as a series of key-value 974 pairs, called header fields. For a listing of registered HTTP header 975 fields, see the "Message Header Field" registry maintained at 976 https://www.iana.org/assignments/message-headers [4]. 978 Just as in previous versions of HTTP, header field names are strings 979 of ASCII characters that are compared in a case-insensitive fashion. 980 Properties of HTTP header field names and values are discussed in 981 more detail in Section 3.2 of [RFC7230], though the wire rendering in 982 HTTP/QUIC differs. As in HTTP/2, header field names MUST be 983 converted to lowercase prior to their encoding. A request or 984 response containing uppercase header field names MUST be treated as 985 malformed. 987 As in HTTP/2, HTTP/QUIC uses special pseudo-header fields beginning 988 with the ':' character (ASCII 0x3a) to convey the target URI, the 989 method of the request, and the status code for the response. These 990 pseudo-header fields are defined in Section 8.1.2.3 and 8.1.2.4 of 991 [RFC7540]. Pseudo-header fields are not HTTP header fields. 992 Endpoints MUST NOT generate pseudo-header fields other than those 993 defined in [RFC7540]. The restrictions on the use of pseudo-header 994 fields in Section 8.1.2.1 of [RFC7540] also apply to HTTP/QUIC. 996 HTTP/QUIC uses QPACK header compression as described in [QPACK], a 997 variation of HPACK which allows the flexibility to avoid header- 998 compression-induced head-of-line blocking. See that document for 999 additional details. 1001 An HTTP/QUIC implementation MAY impose a limit on the maximum size of 1002 the header it will accept on an individual HTTP message. This limit 1003 is conveyed as a number of octets in the 1004 "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. The size of a header list 1005 is calculated based on the uncompressed size of header fields, 1006 including the length of the name and value in octets plus an overhead 1007 of 32 octets for each header field. Encountering a message header 1008 larger than this value SHOULD be treated as a stream error of type 1009 "HTTP_EXCESSIVE_LOAD". 1011 5.1.2. Request Cancellation 1013 Either client or server can cancel requests by aborting the stream 1014 (QUIC RST_STREAM and/or STOP_SENDING frames, as appropriate) with an 1015 error code of HTTP_REQUEST_CANCELLED (Section 8.1). When the client 1016 cancels a response, it indicates that this response is no longer of 1017 interest. Implementations SHOULD cancel requests by aborting both 1018 directions of a stream. 1020 When the server aborts its response stream using 1021 HTTP_REQUEST_CANCELLED, it indicates that no application processing 1022 was performed. The client can treat requests cancelled by the server 1023 as though they had never been sent at all, thereby allowing them to 1024 be retried later on a new connection. Servers MUST NOT use the 1025 HTTP_REQUEST_CANCELLED status for requests which were partially or 1026 fully processed. 1028 Note: In this context, "processed" means that some data from the 1029 stream was passed to some higher layer of software that might have 1030 taken some action as a result. 1032 If a stream is cancelled after receiving a complete response, the 1033 client MAY ignore the cancellation and use the response. However, if 1034 a stream is cancelled after receiving a partial response, the 1035 response SHOULD NOT be used. Automatically retrying such requests is 1036 not possible, unless this is otherwise permitted (e.g., idempotent 1037 actions like GET, PUT, or DELETE). 1039 5.2. The CONNECT Method 1041 The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily 1042 used with HTTP proxies to establish a TLS session with an origin 1043 server for the purposes of interacting with "https" resources. In 1044 HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a 1045 tunnel to a remote host. In HTTP/2, the CONNECT method is used to 1046 establish a tunnel over a single HTTP/2 stream to a remote host for 1047 similar purposes. 1049 A CONNECT request in HTTP/QUIC functions in the same manner as in 1050 HTTP/2. The request MUST be formatted as described in [RFC7540], 1051 Section 8.3. A CONNECT request that does not conform to these 1052 restrictions is malformed. The request stream MUST NOT be closed at 1053 the end of the request. 1055 A proxy that supports CONNECT establishes a TCP connection 1056 ([RFC0793]) to the server identified in the ":authority" pseudo- 1057 header field. Once this connection is successfully established, the 1058 proxy sends a HEADERS frame containing a 2xx series status code to 1059 the client, as defined in [RFC7231], Section 4.3.6. 1061 All DATA frames on the stream correspond to data sent or received on 1062 the TCP connection. Any DATA frame sent by the client is transmitted 1063 by the proxy to the TCP server; data received from the TCP server is 1064 packaged into DATA frames by the proxy. Note that the size and 1065 number of TCP segments is not guaranteed to map predictably to the 1066 size and number of HTTP DATA or QUIC STREAM frames. 1068 The TCP connection can be closed by either peer. When the client 1069 ends the request stream (that is, the receive stream at the proxy 1070 enters the "Data Recvd" state), the proxy will set the FIN bit on its 1071 connection to the TCP server. When the proxy receives a packet with 1072 the FIN bit set, it will terminate the send stream that it sends to 1073 the client. TCP connections which remain half-closed in a single 1074 direction are not invalid, but are often handled poorly by servers, 1075 so clients SHOULD NOT close a stream for sending while they still 1076 expect to receive data from the target of the CONNECT. 1078 A TCP connection error is signaled with RST_STREAM. A proxy treats 1079 any error in the TCP connection, which includes receiving a TCP 1080 segment with the RST bit set, as a stream error of type 1081 HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, a proxy MUST send 1082 a TCP segment with the RST bit set if it detects an error with the 1083 stream or the QUIC connection. 1085 5.3. Request Prioritization 1087 HTTP/QUIC uses a priority scheme similar to that described in 1088 [RFC7540], Section 5.3. In this priority scheme, a given stream can 1089 be designated as dependent upon another request, which expresses the 1090 preference that the latter stream (the "parent" request) be allocated 1091 resources before the former stream (the "dependent" request). Taken 1092 together, the dependencies across all requests in a connection form a 1093 dependency tree. The structure of the dependency tree changes as 1094 PRIORITY frames add, remove, or change the dependency links between 1095 requests. 1097 The PRIORITY frame Section 4.2.3 identifies a prioritized element. 1098 The elements which can be prioritized are: 1100 o Requests, identified by the ID of the request stream 1102 o Pushes, identified by the Push ID of the promised resource 1103 (Section 4.2.6) 1105 o Placeholders, identified by a Placeholder ID 1107 An element can depend on another element or on the root of the tree. 1108 A reference to an element which is no longer in the tree is treated 1109 as a reference to the root of the tree. 1111 5.3.1. Placeholders 1113 In HTTP/2, certain implementations used closed or unused streams as 1114 placeholders in describing the relative priority of requests. 1115 However, this created confusion as servers could not reliably 1116 identify which elements of the priority tree could safely be 1117 discarded. Clients could potentially reference closed streams long 1118 after the server had discarded state, leading to disparate views of 1119 the prioritization the client had attempted to express. 1121 In HTTP/QUIC, a number of placeholders are explicitly permitted by 1122 the server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because 1123 the server commits to maintain these IDs in the tree, clients can use 1124 them with confidence that the server will not have discarded the 1125 state. 1127 Placeholders are identified by an ID between zero and one less than 1128 the number of placeholders the server has permitted. 1130 5.3.2. Priority Tree Maintenance 1132 Servers can aggressively prune inactive regions from the priority 1133 tree, because placeholders will be used to "root" any persistent 1134 structure of the tree which the client cares about retaining. For 1135 prioritization purposes, a node in the tree is considered "inactive" 1136 when the corresponding stream has been closed for at least two round- 1137 trip times (using any reasonable estimate available on the server). 1138 This delay helps mitigate race conditions where the server has pruned 1139 a node the client believed was still active and used as a Stream 1140 Dependency. 1142 Specifically, the server MAY at any time: 1144 o Identify and discard branches of the tree containing only inactive 1145 nodes (i.e. a node with only other inactive nodes as descendants, 1146 along with those descendants) 1148 o Identify and condense interior regions of the tree containing only 1149 inactive nodes, allocating weight appropriately 1151 x x x 1152 | | | 1153 P P P 1154 / \ | | 1155 I I ==> I ==> A 1156 / \ | | 1157 A I A A 1158 | | 1159 A A 1161 Figure 12: Example of Priority Tree Pruning 1163 In the example in Figure 12, "P" represents a Placeholder, "A" 1164 represents an active node, and "I" represents an inactive node. In 1165 the first step, the server discards two inactive branches (each a 1166 single node). In the second step, the server condenses an interior 1167 inactive node. Note that these transformations will result in no 1168 change in the resources allocated to a particular active stream. 1170 Clients SHOULD assume the server is actively performing such pruning 1171 and SHOULD NOT declare a dependency on a stream it knows to have been 1172 closed. 1174 5.4. Server Push 1176 HTTP/QUIC server push is similar to what is described in HTTP/2 1177 [RFC7540], but uses different mechanisms. 1179 Each server push is identified by a unique Push ID. The same Push ID 1180 can be used in one or more PUSH_PROMISE frames (see Section 4.2.6), 1181 then included with the push stream which ultimately fulfills those 1182 promises. 1184 Server push is only enabled on a connection when a client sends a 1185 MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server 1186 push until it receives a MAX_PUSH_ID frame. A client sends 1187 additional MAX_PUSH_ID frames to control the number of pushes that a 1188 server can promise. A server SHOULD use Push IDs sequentially, 1189 starting at 0. A client MUST treat receipt of a push stream with a 1190 Push ID that is greater than the maximum Push ID as a connection 1191 error of type HTTP_PUSH_LIMIT_EXCEEDED. 1193 The header of the request message is carried by a PUSH_PROMISE frame 1194 (see Section 4.2.6) on the request stream which generated the push. 1195 This allows the server push to be associated with a client request. 1196 Ordering of a PUSH_PROMISE in relation to certain parts of the 1197 response is important (see Section 8.2.1 of [RFC7540]). Promised 1198 requests MUST conform to the requirements in Section 8.2 of 1199 [RFC7540]. 1201 When a server later fulfills a promise, the server push response is 1202 conveyed on a push stream (see Section 3.2.2). The push stream 1203 identifies the Push ID of the promise that it fulfills, then contains 1204 a response to the promised request using the same format described 1205 for responses in Section 5.1. 1207 If a promised server push is not needed by the client, the client 1208 SHOULD send a CANCEL_PUSH frame. If the push stream is already open 1209 or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING 1210 frame with an appropriate error code can also be used (e.g., 1211 HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This 1212 asks the server not to transfer additional data and indicates that it 1213 will be discarded upon receipt. 1215 6. Connection Closure 1217 Once established, an HTTP/QUIC connection can be used for many 1218 requests and responses over time until the connection is closed. 1219 Connection closure can happen in any of several different ways. 1221 6.1. Idle Connections 1223 Each QUIC endpoint declares an idle timeout during the handshake. If 1224 the connection remains idle (no packets received) for longer than 1225 this duration, the peer will assume that the connection has been 1226 closed. HTTP/QUIC implementations will need to open a new connection 1227 for new requests if the existing connection has been idle for longer 1228 than the server's advertised idle timeout, and SHOULD do so if 1229 approaching the idle timeout. 1231 HTTP clients are expected to use QUIC PING frames to keep connections 1232 open while there are responses outstanding for requests or server 1233 pushes. If the client is not expecting a response from the server, 1234 allowing an idle connection to time out is preferred over expending 1235 effort maintaining a connection that might not be needed. A gateway 1236 MAY use PING to maintain connections in anticipation of need rather 1237 than incur the latency cost of connection establishment to servers. 1238 Servers SHOULD NOT use PING frames to keep a connection open. 1240 6.2. Connection Shutdown 1242 Even when a connection is not idle, either endpoint can decide to 1243 stop using the connection and let the connection close gracefully. 1244 Since clients drive request generation, clients perform a connection 1245 shutdown by not sending additional requests on the connection; 1246 responses and pushed responses associated to previous requests will 1247 continue to completion. Servers perform the same function by 1248 communicating with clients. 1250 Servers initiate the shutdown of a connection by sending a GOAWAY 1251 frame (Section 4.2.7). The GOAWAY frame indicates that client- 1252 initiated requests on lower stream IDs were or might be processed in 1253 this connection, while requests on the indicated stream ID and 1254 greater were not accepted. This enables client and server to agree 1255 on which requests were accepted prior to the connection shutdown. 1256 This identifier MAY be lower than the stream limit identified by a 1257 QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were 1258 processed. Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit 1259 after sending a GOAWAY frame. 1261 Once sent, the server MUST cancel requests sent on streams with an 1262 identifier higher than the indicated last Stream ID. Clients MUST 1263 NOT send new requests on the connection after receiving GOAWAY, 1264 although requests might already be in transit. A new connection can 1265 be established for new requests. 1267 If the client has sent requests on streams with a higher Stream ID 1268 than indicated in the GOAWAY frame, those requests are considered 1269 cancelled (Section 5.1.2). Clients SHOULD reset any streams above 1270 this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also 1271 cancel requests on streams below the indicated ID if these requests 1272 were not processed. 1274 Requests on Stream IDs less than the Stream ID in the GOAWAY frame 1275 might have been processed; their status cannot be known until they 1276 are completed successfully, reset individually, or the connection 1277 terminates. 1279 Servers SHOULD send a GOAWAY frame when the closing of a connection 1280 is known in advance, even if the advance notice is small, so that the 1281 remote peer can know whether a stream has been partially processed or 1282 not. For example, if an HTTP client sends a POST at the same time 1283 that a server closes a QUIC connection, the client cannot know if the 1284 server started to process that POST request if the server does not 1285 send a GOAWAY frame to indicate what streams it might have acted on. 1287 A client that is unable to retry requests loses all requests that are 1288 in flight when the server closes the connection. A server MAY send 1289 multiple GOAWAY frames indicating different stream IDs, but MUST NOT 1290 increase the value they send in the last Stream ID, since clients 1291 might already have retried unprocessed requests on another 1292 connection. A server that is attempting to gracefully shut down a 1293 connection SHOULD send an initial GOAWAY frame with the last Stream 1294 ID set to the current value of QUIC's MAX_STREAM_ID and SHOULD NOT 1295 increase the MAX_STREAM_ID thereafter. This signals to the client 1296 that a shutdown is imminent and that initiating further requests is 1297 prohibited. After allowing time for any in-flight requests (at least 1298 one round-trip time), the server MAY send another GOAWAY frame with 1299 an updated last Stream ID. This ensures that a connection can be 1300 cleanly shut down without losing requests. 1302 Once all accepted requests have been processed, the server can permit 1303 the connection to become idle, or MAY initiate an immediate closure 1304 of the connection. An endpoint that completes a graceful shutdown 1305 SHOULD use the HTTP_NO_ERROR code when closing the connection. 1307 6.3. Immediate Application Closure 1309 An HTTP/QUIC implementation can immediately close the QUIC connection 1310 at any time. This results in sending a QUIC APPLICATION_CLOSE frame 1311 to the peer; the error code in this frame indicates to the peer why 1312 the connection is being closed. See Section 8 for error codes which 1313 can be used when closing a connection. 1315 Before closing the connection, a GOAWAY MAY be sent to allow the 1316 client to retry some requests. Including the GOAWAY frame in the 1317 same packet as the QUIC APPLICATION_CLOSE frame improves the chances 1318 of the frame being received by clients. 1320 6.4. Transport Closure 1322 For various reasons, the QUIC transport could indicate to the 1323 application layer that the connection has terminated. This might be 1324 due to an explicit closure by the peer, a transport-level error, or a 1325 change in network topology which interrupts connectivity. 1327 If a connection terminates without a GOAWAY frame, clients MUST 1328 assume that any request which was sent, whether in whole or in part, 1329 might have been processed. 1331 7. Extensions to HTTP/QUIC 1333 HTTP/QUIC permits extension of the protocol. Within the limitations 1334 described in this section, protocol extensions can be used to provide 1335 additional services or alter any aspect of the protocol. Extensions 1336 are effective only within the scope of a single HTTP/QUIC connection. 1338 This applies to the protocol elements defined in this document. This 1339 does not affect the existing options for extending HTTP, such as 1340 defining new methods, status codes, or header fields. 1342 Extensions are permitted to use new frame types (Section 4.2), new 1343 settings (Section 4.2.5.1), new error codes (Section 8), or new 1344 unidirectional stream types (Section 3.2). Registries are 1345 established for managing these extension points: frame types 1346 (Section 10.3), settings (Section 10.4), error codes (Section 10.5), 1347 and stream types (Section 10.6). 1349 Implementations MUST ignore unknown or unsupported values in all 1350 extensible protocol elements. Implementations MUST discard frames 1351 and unidirectional streams that have unknown or unsupported types. 1352 This means that any of these extension points can be safely used by 1353 extensions without prior arrangement or negotiation. 1355 Extensions that could change the semantics of existing protocol 1356 components MUST be negotiated before being used. For example, an 1357 extension that changes the layout of the HEADERS frame cannot be used 1358 until the peer has given a positive signal that this is acceptable. 1359 In this case, it could also be necessary to coordinate when the 1360 revised layout comes into effect. 1362 This document doesn't mandate a specific method for negotiating the 1363 use of an extension but notes that a setting (Section 4.2.5.1) could 1364 be used for that purpose. If both peers set a value that indicates 1365 willingness to use the extension, then the extension can be used. If 1366 a setting is used for extension negotiation, the default value MUST 1367 be defined in such a fashion that the extension is disabled if the 1368 setting is omitted. 1370 8. Error Handling 1372 QUIC allows the application to abruptly terminate (reset) individual 1373 streams or the entire connection when an error is encountered. These 1374 are referred to as "stream errors" or "connection errors" and are 1375 described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose 1376 to treat a stream error as a connection error. 1378 This section describes HTTP/QUIC-specific error codes which can be 1379 used to express the cause of a connection or stream error. 1381 8.1. HTTP/QUIC Error Codes 1383 The following error codes are defined for use in QUIC RST_STREAM, 1384 STOP_SENDING, and APPLICATION_CLOSE frames when using HTTP/QUIC. 1386 STOPPING (0x00): This value is reserved by the transport to be used 1387 in response to QUIC STOP_SENDING frames. 1389 HTTP_NO_ERROR (0x01): No error. This is used when the connection or 1390 stream needs to be closed, but there is no error to signal. 1392 HTTP_PUSH_REFUSED (0x02): The server has attempted to push content 1393 which the client will not accept on this connection. 1395 HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the 1396 HTTP stack. 1398 HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push 1399 content which the client has cached. 1401 HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the 1402 requested data. 1404 HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated 1405 without containing a fully-formed request. 1407 HTTP_CONNECT_ERROR (0x07): The connection established in response to 1408 a CONNECT request was reset or abnormally closed. 1410 HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is 1411 exhibiting a behavior that might be generating excessive load. 1413 HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be 1414 served over HTTP/QUIC. The peer should retry over HTTP/1.1. 1416 HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it 1417 is not permitted. 1419 HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current 1420 maximum Push ID was referenced. 1422 HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two 1423 different stream headers. 1425 HTTP_UNKNOWN_STREAM_TYPE (0x0D): A unidirectional stream header 1426 contained an unknown stream type. 1428 HTTP_WRONG_STREAM_COUNT (0x0E): A unidirectional stream type was 1429 used more times than is permitted by that type. 1431 HTTP_CLOSED_CRITICAL_STREAM (0x0F): A stream required by the 1432 connection was closed or reset. 1434 HTTP_WRONG_STREAM_DIRECTION (0x0010): A unidirectional stream type 1435 was used by a peer which is not permitted to do so. 1437 HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request 1438 is not needed to produce a response. For use in STOP_SENDING 1439 only. 1441 HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at 1442 the beginning of the control stream. 1444 HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol 1445 requirements in a way which doesn't match a more specific error 1446 code, or endpoint declines to use the more specific error code. 1448 HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. 1449 The frame type is included as the last octet of the error code. 1450 For example, an error in a MAX_PUSH_ID frame would be indicated 1451 with the code (0x10D). 1453 9. Security Considerations 1455 The security considerations of HTTP/QUIC should be comparable to 1456 those of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING 1457 frames and Padding fields in other frames to make a connection more 1458 resistant to traffic analysis, HTTP/QUIC can rely on QUIC PADDING 1459 frames or employ the reserved frame and stream types discussed in 1460 Section 4.2.9 and Section 3.2.3. 1462 When HTTP Alternative Services is used for discovery for HTTP/QUIC 1463 endpoints, the security considerations of [ALTSVC] also apply. 1465 Several protocol elements contain nested length elements, typically 1466 in the form of frames with an explicit length containing variable- 1467 length integers. This could pose a security risk to an incautious 1468 implementer. An implementation MUST ensure that the length of a 1469 frame exactly matches the length of the fields it contains. 1471 10. IANA Considerations 1473 10.1. Registration of HTTP/QUIC Identification String 1475 This document creates a new registration for the identification of 1476 HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN) 1477 Protocol IDs" registry established in [RFC7301]. 1479 The "hq" string identifies HTTP/QUIC: 1481 Protocol: HTTP/QUIC 1483 Identification Sequence: 0x68 0x71 ("hq") 1485 Specification: This document 1487 10.2. Registration of QUIC Version Hint Alt-Svc Parameter 1489 This document creates a new registration for version-negotiation 1490 hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" 1491 registry established in [RFC7838]. 1493 Parameter: "quic" 1495 Specification: This document, Section 2.2.1 1497 10.3. Frame Types 1499 This document establishes a registry for HTTP/QUIC frame type codes. 1500 The "HTTP/QUIC Frame Type" registry manages an 8-bit space. The 1501 "HTTP/QUIC Frame Type" registry operates under either of the "IETF 1502 Review" or "IESG Approval" policies [RFC8126] for values from 0x00 up 1503 to and including 0xef, with values from 0xf0 up to and including 0xff 1504 being reserved for Experimental Use. 1506 While this registry is separate from the "HTTP/2 Frame Type" registry 1507 defined in [RFC7540], it is preferable that the assignments parallel 1508 each other. If an entry is present in only one registry, every 1509 effort SHOULD be made to avoid assigning the corresponding value to 1510 an unrelated operation. 1512 New entries in this registry require the following information: 1514 Frame Type: A name or label for the frame type. 1516 Code: The 8-bit code assigned to the frame type. 1518 Specification: A reference to a specification that includes a 1519 description of the frame layout and its semantics, including any 1520 parts of the frame that are conditionally present. 1522 The entries in the following table are registered by this document. 1524 +--------------+------+---------------+ 1525 | Frame Type | Code | Specification | 1526 +--------------+------+---------------+ 1527 | DATA | 0x0 | Section 4.2.1 | 1528 | | | | 1529 | HEADERS | 0x1 | Section 4.2.2 | 1530 | | | | 1531 | PRIORITY | 0x2 | Section 4.2.3 | 1532 | | | | 1533 | CANCEL_PUSH | 0x3 | Section 4.2.4 | 1534 | | | | 1535 | SETTINGS | 0x4 | Section 4.2.5 | 1536 | | | | 1537 | PUSH_PROMISE | 0x5 | Section 4.2.6 | 1538 | | | | 1539 | Reserved | 0x6 | N/A | 1540 | | | | 1541 | GOAWAY | 0x7 | Section 4.2.7 | 1542 | | | | 1543 | Reserved | 0x8 | N/A | 1544 | | | | 1545 | Reserved | 0x9 | N/A | 1546 | | | | 1547 | MAX_PUSH_ID | 0xD | Section 4.2.8 | 1548 +--------------+------+---------------+ 1550 Additionally, each code of the format "0xb + (0x1f * N)" for values 1551 of N in the range (0..7) (that is, "0xb", "0x2a", "0x49", "0x68", 1552 "0x87", "0xa6", "0xc5", and "0xe4"), the following values should be 1553 registered: 1555 Frame Type: Reserved - GREASE 1557 Specification: Section 4.2.9 1559 10.4. Settings Parameters 1561 This document establishes a registry for HTTP/QUIC settings. The 1562 "HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC 1563 Settings" registry operates under the "Expert Review" policy 1564 [RFC8126] for values in the range from 0x0000 to 0xefff, with values 1565 between and 0xf000 and 0xffff being reserved for Experimental Use. 1567 The designated experts are the same as those for the "HTTP/2 1568 Settings" registry defined in [RFC7540]. 1570 While this registry is separate from the "HTTP/2 Settings" registry 1571 defined in [RFC7540], it is preferable that the assignments parallel 1572 each other. If an entry is present in only one registry, every 1573 effort SHOULD be made to avoid assigning the corresponding value to 1574 an unrelated operation. 1576 New registrations are advised to provide the following information: 1578 Name: A symbolic name for the setting. Specifying a setting name is 1579 optional. 1581 Code: The 16-bit code assigned to the setting. 1583 Specification: An optional reference to a specification that 1584 describes the use of the setting. 1586 The entries in the following table are registered by this document. 1588 +----------------------+------+-----------------+ 1589 | Setting Name | Code | Specification | 1590 +----------------------+------+-----------------+ 1591 | Reserved | 0x2 | N/A | 1592 | | | | 1593 | NUM_PLACEHOLDERS | 0x3 | Section 4.2.5.1 | 1594 | | | | 1595 | Reserved | 0x4 | N/A | 1596 | | | | 1597 | Reserved | 0x5 | N/A | 1598 | | | | 1599 | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 | 1600 +----------------------+------+-----------------+ 1602 Additionally, each code of the format "0x?a?a" where each "?" is any 1603 four bits (that is, "0x0a0a", "0x0a1a", etc. through "0xfafa"), the 1604 following values should be registered: 1606 Name: Reserved - GREASE 1608 Specification: Section 4.2.5.1 1610 10.5. Error Codes 1612 This document establishes a registry for HTTP/QUIC error codes. The 1613 "HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/ 1614 QUIC Error Code" registry operates under the "Expert Review" policy 1615 [RFC8126]. 1617 Registrations for error codes are required to include a description 1618 of the error code. An expert reviewer is advised to examine new 1619 registrations for possible duplication with existing error codes. 1620 Use of existing registrations is to be encouraged, but not mandated. 1622 New registrations are advised to provide the following information: 1624 Name: A name for the error code. Specifying an error code name is 1625 optional. 1627 Code: The 16-bit error code value. 1629 Description: A brief description of the error code semantics, longer 1630 if no detailed specification is provided. 1632 Specification: An optional reference for a specification that 1633 defines the error code. 1635 The entries in the following table are registered by this document. 1637 +-------------------------+-------+---------------+-----------------+ 1638 | Name | Code | Description | Specification | 1639 +-------------------------+-------+---------------+-----------------+ 1640 | STOPPING | 0x000 | Reserved by | [QUIC-TRANSPORT | 1641 | | 0 | QUIC | ] | 1642 | | | | | 1643 | HTTP_NO_ERROR | 0x000 | No error | Section 8.1 | 1644 | | 1 | | | 1645 | | | | | 1646 | HTTP_PUSH_REFUSED | 0x000 | Client | Section 8.1 | 1647 | | 2 | refused | | 1648 | | | pushed | | 1649 | | | content | | 1650 | | | | | 1651 | HTTP_INTERNAL_ERROR | 0x000 | Internal | Section 8.1 | 1652 | | 3 | error | | 1653 | | | | | 1654 | HTTP_PUSH_ALREADY_IN_CA | 0x000 | Pushed | Section 8.1 | 1655 | CHE | 4 | content | | 1656 | | | already | | 1657 | | | cached | | 1658 | | | | | 1659 | HTTP_REQUEST_CANCELLED | 0x000 | Data no | Section 8.1 | 1660 | | 5 | longer needed | | 1661 | | | | | 1662 | HTTP_INCOMPLETE_REQUEST | 0x000 | Stream | Section 8.1 | 1663 | | 6 | terminated | | 1664 | | | early | | 1665 | | | | | 1666 | HTTP_CONNECT_ERROR | 0x000 | TCP reset or | Section 8.1 | 1667 | | 7 | error on | | 1668 | | | CONNECT | | 1669 | | | request | | 1670 | | | | | 1671 | HTTP_EXCESSIVE_LOAD | 0x000 | Peer | Section 8.1 | 1672 | | 8 | generating | | 1673 | | | excessive | | 1674 | | | load | | 1675 | | | | | 1676 | HTTP_VERSION_FALLBACK | 0x000 | Retry over | Section 8.1 | 1677 | | 9 | HTTP/1.1 | | 1678 | | | | | 1679 | HTTP_WRONG_STREAM | 0x000 | A frame was | Section 8.1 | 1680 | | A | sent on the | | 1681 | | | wrong stream | | 1682 | | | | | 1683 | HTTP_PUSH_LIMIT_EXCEEDE | 0x000 | Maximum Push | Section 8.1 | 1684 | D | B | ID exceeded | | 1685 | | | | | 1686 | HTTP_DUPLICATE_PUSH | 0x000 | Push ID was | Section 8.1 | 1687 | | C | fulfilled | | 1688 | | | multiple | | 1689 | | | times | | 1690 | | | | | 1691 | HTTP_UNKNOWN_STREAM_TYP | 0x000 | Unknown unidi | Section 8.1 | 1692 | E | D | rectional | | 1693 | | | stream type | | 1694 | | | | | 1695 | HTTP_WRONG_STREAM_COUNT | 0x000 | Too many unid | Section 8.1 | 1696 | | E | irectional | | 1697 | | | streams | | 1698 | | | | | 1699 | HTTP_CLOSED_CRITICAL_ST | 0x000 | Critical | Section 8.1 | 1700 | REAM | F | stream was | | 1701 | | | closed | | 1702 | | | | | 1703 | HTTP_WRONG_STREAM_DIREC | 0x001 | Unidirectiona | Section 8.1 | 1704 | TION | 0 | l stream in | | 1705 | | | wrong | | 1706 | | | direction | | 1707 | | | | | 1708 | HTTP_EARLY_RESPONSE | 0x001 | Remainder of | Section 8.1 | 1709 | | 1 | request not | | 1710 | | | needed | | 1711 | | | | | 1712 | HTTP_MISSING_SETTINGS | 0x001 | No SETTINGS | Section 8.1 | 1713 | | 2 | frame | | 1714 | | | received | | 1715 | | | | | 1716 | HTTP_MALFORMED_FRAME | 0x01X | Error in | Section 8.1 | 1717 | | X | frame | | 1718 | | | formatting or | | 1719 | | | use | | 1720 +-------------------------+-------+---------------+-----------------+ 1722 10.6. Stream Types 1724 This document establishes a registry for HTTP/QUIC unidirectional 1725 stream types. The "HTTP/QUIC Stream Type" registry manages an 8-bit 1726 space. The "HTTP/QUIC Stream Type" registry operates under either of 1727 the "IETF Review" or "IESG Approval" policies [RFC8126] for values 1728 from 0x00 up to and including 0xef, with values from 0xf0 up to and 1729 including 0xff being reserved for Experimental Use. 1731 New entries in this registry require the following information: 1733 Stream Type: A name or label for the stream type. 1735 Code: The 8-bit code assigned to the stream type. 1737 Specification: A reference to a specification that includes a 1738 description of the stream type, including the layout semantics of 1739 its payload. 1741 Sender: Which endpoint on a connection may initiate a stream of this 1742 type. Values are "Client", "Server", or "Both". 1744 The entries in the following table are registered by this document. 1746 +----------------+------+---------------+--------+ 1747 | Stream Type | Code | Specification | Sender | 1748 +----------------+------+---------------+--------+ 1749 | Control Stream | 0x43 | Section 3.2.1 | Both | 1750 | | | | | 1751 | Push Stream | 0x50 | Section 5.4 | Server | 1752 +----------------+------+---------------+--------+ 1754 Additionally, for each code of the format "0x1f * N" for values of N 1755 in the range (0..8) (that is, "0x00", "0x1f", "0x3e", "0x5d", "0x7c", 1756 "0x9b", "0xba", "0xd9", "0xf8"), the following values should be 1757 registered: 1759 Stream Type: Reserved - GREASE 1761 Specification: Section 3.2.3 1763 Sender: Both 1765 11. References 1767 11.1. Normative References 1769 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1770 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1771 April 2016, . 1773 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 1774 Header Compression for HTTP over QUIC", draft-ietf-quic- 1775 qpack-04 (work in progress), October 2018. 1777 [QUIC-TRANSPORT] 1778 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1779 Multiplexed and Secure Transport", draft-ietf-quic- 1780 transport-16 (work in progress), October 2018. 1782 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1783 RFC 793, DOI 10.17487/RFC0793, September 1981, 1784 . 1786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1787 Requirement Levels", BCP 14, RFC 2119, 1788 DOI 10.17487/RFC2119, March 1997, 1789 . 1791 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1792 Specifications: ABNF", STD 68, RFC 5234, 1793 DOI 10.17487/RFC5234, January 2008, 1794 . 1796 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1797 Extensions: Extension Definitions", RFC 6066, 1798 DOI 10.17487/RFC6066, January 2011, 1799 . 1801 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1802 Protocol (HTTP/1.1): Message Syntax and Routing", 1803 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1804 . 1806 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1807 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1808 DOI 10.17487/RFC7231, June 2014, 1809 . 1811 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1812 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1813 DOI 10.17487/RFC7540, May 2015, 1814 . 1816 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1817 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1818 April 2016, . 1820 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1821 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1822 May 2017, . 1824 11.2. Informative References 1826 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1827 "Transport Layer Security (TLS) Application-Layer Protocol 1828 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1829 July 2014, . 1831 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1832 Writing an IANA Considerations Section in RFCs", BCP 26, 1833 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1834 . 1836 11.3. URIs 1838 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1840 [2] https://github.com/quicwg 1842 [3] https://github.com/quicwg/base-drafts/labels/-http 1844 [4] https://www.iana.org/assignments/message-headers 1846 Appendix A. Considerations for Transitioning from HTTP/2 1848 HTTP/QUIC is strongly informed by HTTP/2, and bears many 1849 similarities. This section describes the approach taken to design 1850 HTTP/QUIC, points out important differences from HTTP/2, and 1851 describes how to map HTTP/2 extensions into HTTP/QUIC. 1853 HTTP/QUIC begins from the premise that similarity to HTTP/2 is 1854 preferable, but not a hard requirement. HTTP/QUIC departs from 1855 HTTP/2 primarily where necessary to accommodate the differences in 1856 behavior between QUIC and TCP (lack of ordering, support for 1857 streams). We intend to avoid gratuitous changes which make it 1858 difficult or impossible to build extensions with the same semantics 1859 applicable to both protocols at once. 1861 These departures are noted in this section. 1863 A.1. Streams 1865 HTTP/QUIC permits use of a larger number of streams (2^62-1) than 1866 HTTP/2. The considerations about exhaustion of stream identifier 1867 space apply, though the space is significantly larger such that it is 1868 likely that other limits in QUIC are reached first, such as the limit 1869 on the connection flow control window. 1871 A.2. HTTP Frame Types 1873 Many framing concepts from HTTP/2 can be elided away on QUIC, because 1874 the transport deals with them. Because frames are already on a 1875 stream, they can omit the stream number. Because frames do not block 1876 multiplexing (QUIC's multiplexing occurs below this layer), the 1877 support for variable-maximum-length packets can be removed. Because 1878 stream termination is handled by QUIC, an END_STREAM flag is not 1879 required. This permits the removal of the Flags field from the 1880 generic frame layout. 1882 Frame payloads are largely drawn from [RFC7540]. However, QUIC 1883 includes many features (e.g. flow control) which are also present in 1884 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 1885 As a result, several HTTP/2 frame types are not required in HTTP/ 1886 QUIC. Where an HTTP/2-defined frame is no longer used, the frame ID 1887 has been reserved in order to maximize portability between HTTP/2 and 1888 HTTP/QUIC implementations. However, even equivalent frames between 1889 the two mappings are not identical. 1891 Many of the differences arise from the fact that HTTP/2 provides an 1892 absolute ordering between frames across all streams, while QUIC 1893 provides this guarantee on each stream only. As a result, if a frame 1894 type makes assumptions that frames from different streams will still 1895 be received in the order sent, HTTP/QUIC will break them. 1897 For example, implicit in the HTTP/2 prioritization scheme is the 1898 notion of in-order delivery of priority changes (i.e., dependency 1899 tree mutations): since operations on the dependency tree such as 1900 reparenting a subtree are not commutative, both sender and receiver 1901 must apply them in the same order to ensure that both sides have a 1902 consistent view of the stream dependency tree. HTTP/2 specifies 1903 priority assignments in PRIORITY frames and (optionally) in HEADERS 1904 frames. To achieve in-order delivery of priority changes in HTTP/ 1905 QUIC, PRIORITY frames are sent on the control stream and the PRIORITY 1906 section is removed from the HEADERS frame. 1908 Likewise, HPACK was designed with the assumption of in-order 1909 delivery. A sequence of encoded header blocks must arrive (and be 1910 decoded) at an endpoint in the same order in which they were encoded. 1911 This ensures that the dynamic state at the two endpoints remains in 1912 sync. As a result, HTTP/QUIC uses a modified version of HPACK, 1913 described in [QPACK]. 1915 Frame type definitions in HTTP/QUIC often use the QUIC variable- 1916 length integer encoding. In particular, Stream IDs use this 1917 encoding, which allow for a larger range of possible values than the 1918 encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier 1919 rather than a Stream ID (e.g. Push IDs in PRIORITY frames). 1920 Redefinition of the encoding of extension frame types might be 1921 necessary if the encoding includes a Stream ID. 1923 Because the Flags field is not present in generic HTTP/QUIC frames, 1924 those frames which depend on the presence of flags need to allocate 1925 space for flags as part of their frame payload. 1927 Other than this issue, frame type HTTP/2 extensions are typically 1928 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 1929 control stream in HTTP/QUIC. HTTP/QUIC extensions will not assume 1930 ordering, but would not be harmed by ordering, and would be portable 1931 to HTTP/2 in the same manner. 1933 Below is a listing of how each HTTP/2 frame type is mapped: 1935 DATA (0x0): Padding is not defined in HTTP/QUIC frames. See 1936 Section 4.2.1. 1938 HEADERS (0x1): As described above, the PRIORITY region of HEADERS is 1939 not supported. A separate PRIORITY frame MUST be used. Padding 1940 is not defined in HTTP/QUIC frames. See Section 4.2.2. 1942 PRIORITY (0x2): As described above, the PRIORITY frame is sent on 1943 the control stream and can reference a variety of identifiers. 1944 See Section 4.2.3. 1946 RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC 1947 provides stream lifecycle management. The same code point is used 1948 for the CANCEL_PUSH frame (Section 4.2.4). 1950 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 1951 the connection. See Section 4.2.5 and Appendix A.3. 1953 PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; 1954 instead the push stream references the PUSH_PROMISE frame using a 1955 Push ID. See Section 4.2.6. 1957 PING (0x6): PING frames do not exist, since QUIC provides equivalent 1958 functionality. 1960 GOAWAY (0x7): GOAWAY is sent only from server to client and does not 1961 contain an error code. See Section 4.2.7. 1963 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC 1964 provides flow control. 1966 CONTINUATION (0x9): CONTINUATION frames do not exist; instead, 1967 larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. 1969 Frame types defined by extensions to HTTP/2 need to be separately 1970 registered for HTTP/QUIC if still applicable. The IDs of frames 1971 defined in [RFC7540] have been reserved for simplicity. See 1972 Section 10.3. 1974 A.3. HTTP/2 SETTINGS Parameters 1976 An important difference from HTTP/2 is that settings are sent once, 1977 at the beginning of the connection, and thereafter cannot change. 1978 This eliminates many corner cases around synchronization of changes. 1980 Some transport-level options that HTTP/2 specifies via the SETTINGS 1981 frame are superseded by QUIC transport parameters in HTTP/QUIC. The 1982 HTTP-level options that are retained in HTTP/QUIC have the same value 1983 as in HTTP/2. 1985 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 1987 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 1989 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 1990 which provides a more granular control over server push. 1992 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 1993 Stream ID as part of its flow control logic. Specifying 1994 SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. 1996 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 1997 connection flow control window sizes to be specified in the 1998 initial transport handshake. Specifying 1999 SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. 2001 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/ 2002 QUIC. Specifying it in the SETTINGS frame is an error. 2004 SETTINGS_MAX_HEADER_LIST_SIZE: See Section 4.2.5.1. 2006 In HTTP/QUIC, setting values are variable-length integers (6, 14, 30, 2007 or 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2008 This will often produce a shorter encoding, but can produce a longer 2009 encoding for settings which use the full 32-bit space. Settings 2010 ported from HTTP/2 might choose to redefine the format of their 2011 settings to avoid using the 62-bit encoding. 2013 Settings need to be defined separately for HTTP/2 and HTTP/QUIC. The 2014 IDs of settings defined in [RFC7540] have been reserved for 2015 simplicity. See Section 10.4. 2017 A.4. HTTP/2 Error Codes 2019 QUIC has the same concepts of "stream" and "connection" errors that 2020 HTTP/2 provides. However, there is no direct portability of HTTP/2 2021 error codes. 2023 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the 2024 HTTP/QUIC error codes as follows: 2026 NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1. 2028 PROTOCOL_ERROR (0x1): No single mapping. See new 2029 HTTP_MALFORMED_FRAME error codes defined in Section 8.1. 2031 INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1. 2033 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2034 control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA 2035 from the QUIC layer. 2037 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2038 SETTINGS is defined. 2040 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2041 management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION 2042 from the QUIC layer. 2044 FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in 2045 Section 8.1. 2047 REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream 2048 management. Would provoke a STREAM_ID_ERROR from the QUIC layer. 2050 CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. 2052 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2053 [QPACK]. 2055 CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. 2057 ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. 2059 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2060 provide sufficient security on all connections. 2062 HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1. 2064 Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. 2065 See Section 10.5. 2067 Appendix B. Change Log 2069 *RFC Editor's Note:* Please remove this section prior to 2070 publication of a final version of this document. 2072 B.1. Since draft-ietf-quic-http-15 2074 Substantial editorial reorganization; no technical changes. 2076 B.2. Since draft-ietf-quic-http-14 2078 o Recommend sensible values for QUIC transport parameters 2079 (#1720,#1806) 2081 o Define error for missing SETTINGS frame (#1697,#1808) 2083 o Setting values are variable-length integers (#1556,#1807) and do 2084 not have separate maximum values (#1820) 2086 o Expanded discussion of connection closure (#1599,#1717,#1712) 2088 o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 2090 B.3. Since draft-ietf-quic-http-13 2092 o Reserved some frame types for grease (#1333, #1446) 2093 o Unknown unidirectional stream types are tolerated, not errors; 2094 some reserved for grease (#1490, #1525) 2096 o Require settings to be remembered for 0-RTT, prohibit reductions 2097 (#1541, #1641) 2099 o Specify behavior for truncated requests (#1596, #1643) 2101 B.4. Since draft-ietf-quic-http-12 2103 o TLS SNI extension isn't mandatory if an alternative method is used 2104 (#1459, #1462, #1466) 2106 o Removed flags from HTTP/QUIC frames (#1388, #1398) 2108 o Reserved frame types and settings for use in preserving 2109 extensibility (#1333, #1446) 2111 o Added general error code (#1391, #1397) 2113 o Unidirectional streams carry a type byte and are extensible 2114 (#910,#1359) 2116 o Priority mechanism now uses explicit placeholders to enable 2117 persistent structure in the tree (#441,#1421,#1422) 2119 B.5. Since draft-ietf-quic-http-11 2121 o Moved QPACK table updates and acknowledgments to dedicated streams 2122 (#1121, #1122, #1238) 2124 B.6. Since draft-ietf-quic-http-10 2126 o Settings need to be remembered when attempting and accepting 0-RTT 2127 (#1157, #1207) 2129 B.7. Since draft-ietf-quic-http-09 2131 o Selected QCRAM for header compression (#228, #1117) 2133 o The server_name TLS extension is now mandatory (#296, #495) 2135 o Specified handling of unsupported versions in Alt-Svc (#1093, 2136 #1097) 2138 B.8. Since draft-ietf-quic-http-08 2140 o Clarified connection coalescing rules (#940, #1024) 2142 B.9. Since draft-ietf-quic-http-07 2144 o Changes for integer encodings in QUIC (#595,#905) 2146 o Use unidirectional streams as appropriate (#515, #240, #281, #886) 2148 o Improvement to the description of GOAWAY (#604, #898) 2150 o Improve description of server push usage (#947, #950, #957) 2152 B.10. Since draft-ietf-quic-http-06 2154 o Track changes in QUIC error code usage (#485) 2156 B.11. Since draft-ietf-quic-http-05 2158 o Made push ID sequential, add MAX_PUSH_ID, remove 2159 SETTINGS_ENABLE_PUSH (#709) 2161 o Guidance about keep-alive and QUIC PINGs (#729) 2163 o Expanded text on GOAWAY and cancellation (#757) 2165 B.12. Since draft-ietf-quic-http-04 2167 o Cite RFC 5234 (#404) 2169 o Return to a single stream per request (#245,#557) 2171 o Use separate frame type and settings registries from HTTP/2 (#81) 2173 o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 2175 o Restored GOAWAY (#696) 2177 o Identify server push using Push ID rather than a stream ID 2178 (#702,#281) 2180 o DATA frames cannot be empty (#700) 2182 B.13. Since draft-ietf-quic-http-03 2184 None. 2186 B.14. Since draft-ietf-quic-http-02 2188 o Track changes in transport draft 2190 B.15. Since draft-ietf-quic-http-01 2192 o SETTINGS changes (#181): 2194 * SETTINGS can be sent only once at the start of a connection; no 2195 changes thereafter 2197 * SETTINGS_ACK removed 2199 * Settings can only occur in the SETTINGS frame a single time 2201 * Boolean format updated 2203 o Alt-Svc parameter changed from "v" to "quic"; format updated 2204 (#229) 2206 o Closing the connection control stream or any message control 2207 stream is a fatal error (#176) 2209 o HPACK Sequence counter can wrap (#173) 2211 o 0-RTT guidance added 2213 o Guide to differences from HTTP/2 and porting HTTP/2 extensions 2214 added (#127,#242) 2216 B.16. Since draft-ietf-quic-http-00 2218 o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 2220 o Changed from using HTTP/2 framing within Stream 3 to new framing 2221 format and two-stream-per-request model (#71,#72,#73) 2223 o Adopted SETTINGS format from draft-bishop-httpbis-extended- 2224 settings-01 2226 o Reworked SETTINGS_ACK to account for indeterminate inter-stream 2227 order (#75) 2229 o Described CONNECT pseudo-method (#95) 2230 o Updated ALPN token and Alt-Svc guidance (#13,#87) 2232 o Application-layer-defined error codes (#19,#74) 2234 B.17. Since draft-shade-quic-http2-mapping-00 2236 o Adopted as base for draft-ietf-quic-http 2238 o Updated authors/editors list 2240 Acknowledgements 2242 The original authors of this specification were Robbie Shade and Mike 2243 Warres. 2245 A substantial portion of Mike's contribution was supported by 2246 Microsoft during his employment there. 2248 Author's Address 2250 Mike Bishop (editor) 2251 Akamai 2253 Email: mbishop@evequefou.be