idnits 2.17.1 draft-ietf-quic-http-32.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 October 2020) is 1282 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) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-cache-12 -- Possible downref: Normative reference to a draft: ref. 'CACHING' == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-19 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-31 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-12 -- Possible downref: Normative reference to a draft: ref. 'SEMANTICS' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-12 -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Akamai 4 Intended status: Standards Track 20 October 2020 5 Expires: 23 April 2021 7 Hypertext Transfer Protocol Version 3 (HTTP/3) 8 draft-ietf-quic-http-32 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 HTTP/3. 19 Note to Readers 21 Discussion of this draft takes place on the QUIC working group 22 mailing list (quic@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/search/?email_list=quic. 25 Working Group information can be found at https://github.com/quicwg; 26 source code and issues list for this draft can be found at 27 https://github.com/quicwg/base-drafts/labels/-http. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at 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 23 April 2021. 46 Copyright Notice 48 Copyright (c) 2020 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 (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 5 64 1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 65 2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5 66 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 67 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 7 68 3. Connection Setup and Management . . . . . . . . . . . . . . . 8 69 3.1. Draft Version Identification . . . . . . . . . . . . . . 8 70 3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 9 71 3.2.1. HTTP Alternative Services . . . . . . . . . . . . . . 10 72 3.2.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 10 73 3.3. Connection Establishment . . . . . . . . . . . . . . . . 10 74 3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 11 75 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 12 76 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 12 77 4.1.1. Field Formatting and Compression . . . . . . . . . . 14 78 4.1.2. Request Cancellation and Rejection . . . . . . . . . 17 79 4.1.3. Malformed Requests and Responses . . . . . . . . . . 18 80 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 19 81 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 20 82 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 83 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 23 84 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 23 85 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 23 86 5.3. Immediate Application Closure . . . . . . . . . . . . . . 25 87 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 26 88 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 26 89 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 26 90 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 27 91 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 28 92 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 29 93 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 29 95 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 30 96 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 31 97 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 31 98 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 31 99 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 32 100 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 32 101 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 34 102 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 37 103 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 38 104 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 39 105 7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 40 106 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 40 107 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 40 108 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 42 109 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 110 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 43 111 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 43 112 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 43 113 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 44 114 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 44 115 10.5.1. Limits on Field Section Size . . . . . . . . . . . . 45 116 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 45 117 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 46 118 10.7. Padding and Traffic Analysis . . . . . . . . . . . . . . 46 119 10.8. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 47 120 10.9. Early Data . . . . . . . . . . . . . . . . . . . . . . . 47 121 10.10. Migration . . . . . . . . . . . . . . . . . . . . . . . 47 122 10.11. Privacy Considerations . . . . . . . . . . . . . . . . . 47 123 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 124 11.1. Registration of HTTP/3 Identification String . . . . . . 48 125 11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 48 126 11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 48 127 11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 50 128 11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 51 129 11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 53 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 131 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 132 12.2. Informative References . . . . . . . . . . . . . . . . . 55 133 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 56 134 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 57 135 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 57 136 A.2.1. Prioritization Differences . . . . . . . . . . . . . 58 137 A.2.2. Field Compression Differences . . . . . . . . . . . . 58 138 A.2.3. Flow Control Differences . . . . . . . . . . . . . . 59 139 A.2.4. Guidance for New Frame Type Definitions . . . . . . . 59 140 A.2.5. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 59 141 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 60 142 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 61 143 A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors . . . . . . 62 144 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 63 145 B.1. Since draft-ietf-quic-http-31 . . . . . . . . . . . . . . 63 146 B.2. Since draft-ietf-quic-http-30 . . . . . . . . . . . . . . 63 147 B.3. Since draft-ietf-quic-http-29 . . . . . . . . . . . . . . 63 148 B.4. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 63 149 B.5. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 64 150 B.6. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 64 151 B.7. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 64 152 B.8. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 64 153 B.9. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 64 154 B.10. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 65 155 B.11. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 65 156 B.12. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 65 157 B.13. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 66 158 B.14. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 67 159 B.15. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 67 160 B.16. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 67 161 B.17. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 68 162 B.18. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 68 163 B.19. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 68 164 B.20. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 68 165 B.21. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 69 166 B.22. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 69 167 B.23. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 69 168 B.24. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 69 169 B.25. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 69 170 B.26. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 69 171 B.27. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 69 172 B.28. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 70 173 B.29. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 70 174 B.30. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 70 175 B.31. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 70 176 B.32. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 71 177 B.33. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 71 178 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 179 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 72 181 1. Introduction 183 HTTP semantics ([SEMANTICS]) are used for a broad range of services 184 on the Internet. These semantics have most commonly been used with 185 HTTP/1.1, over a variety of transport and session layers, and with 186 HTTP/2 over TLS. HTTP/3 supports the same semantics over a new 187 transport protocol, QUIC. 189 1.1. Prior versions of HTTP 191 HTTP/1.1 ([HTTP11]) uses whitespace-delimited text fields to convey 192 HTTP messages. While these exchanges are human-readable, using 193 whitespace for message formatting leads to parsing complexity and 194 excessive tolerance of variant behavior. Because HTTP/1.x does not 195 include a multiplexing layer, multiple TCP connections are often used 196 to service requests in parallel. However, that has a negative impact 197 on congestion control and network efficiency, since TCP does not 198 share congestion control across multiple connections. 200 HTTP/2 ([HTTP2]) introduced a binary framing and multiplexing layer 201 to improve latency without modifying the transport layer. However, 202 because the parallel nature of HTTP/2's multiplexing is not visible 203 to TCP's loss recovery mechanisms, a lost or reordered packet causes 204 all active transactions to experience a stall regardless of whether 205 that transaction was directly impacted by the lost packet. 207 1.2. Delegation to QUIC 209 The QUIC transport protocol incorporates stream multiplexing and per- 210 stream flow control, similar to that provided by the HTTP/2 framing 211 layer. By providing reliability at the stream level and congestion 212 control across the entire connection, QUIC has the capability to 213 improve the performance of HTTP compared to a TCP mapping. QUIC also 214 incorporates TLS 1.3 ([TLS13]) at the transport layer, offering 215 comparable security to running TLS over TCP, with the improved 216 connection setup latency of TCP Fast Open ([TFO]). 218 This document defines a mapping of HTTP semantics over the QUIC 219 transport protocol, drawing heavily on the design of HTTP/2. While 220 delegating stream lifetime and flow control issues to QUIC, a similar 221 binary framing is used on each stream. Some HTTP/2 features are 222 subsumed by QUIC, while other features are implemented atop QUIC. 224 QUIC is described in [QUIC-TRANSPORT]. For a full description of 225 HTTP/2, see [HTTP2]. 227 2. HTTP/3 Protocol Overview 229 HTTP/3 provides a transport for HTTP semantics using the QUIC 230 transport protocol and an internal framing layer similar to HTTP/2. 232 Once a client knows that an HTTP/3 server exists at a certain 233 endpoint, it opens a QUIC connection. QUIC provides protocol 234 negotiation, stream-based multiplexing, and flow control. Discovery 235 of an HTTP/3 endpoint is described in Section 3.2. 237 Within each stream, the basic unit of HTTP/3 communication is a frame 238 (Section 7.2). Each frame type serves a different purpose. For 239 example, HEADERS and DATA frames form the basis of HTTP requests and 240 responses (Section 4.1). 242 Multiplexing of requests is performed using the QUIC stream 243 abstraction, described in Section 2 of [QUIC-TRANSPORT]. Each 244 request-response pair consumes a single QUIC stream. Streams are 245 independent of each other, so one stream that is blocked or suffers 246 packet loss does not prevent progress on other streams. 248 Server push is an interaction mode introduced in HTTP/2 ([HTTP2]) 249 that permits a server to push a request-response exchange to a client 250 in anticipation of the client making the indicated request. This 251 trades off network usage against a potential latency gain. Several 252 HTTP/3 frames are used to manage server push, such as PUSH_PROMISE, 253 MAX_PUSH_ID, and CANCEL_PUSH. 255 As in HTTP/2, request and response fields are compressed for 256 transmission. Because HPACK ([HPACK]) relies on in-order 257 transmission of compressed field sections (a guarantee not provided 258 by QUIC), HTTP/3 replaces HPACK with QPACK ([QPACK]). QPACK uses 259 separate unidirectional streams to modify and track field table 260 state, while encoded field sections refer to the state of the table 261 without modifying it. 263 2.1. Document Organization 265 The following sections provide a detailed overview of the lifecycle 266 of an HTTP/3 connection: 268 * Connection Setup and Management (Section 3) covers how an HTTP/3 269 endpoint is discovered and an HTTP/3 connection is established. 271 * HTTP Request Lifecycle (Section 4) describes how HTTP semantics 272 are expressed using frames. 274 * Connection Closure (Section 5) describes how HTTP/3 connections 275 are terminated, either gracefully or abruptly. 277 The details of the wire protocol and interactions with the transport 278 are described in subsequent sections: 280 * Stream Mapping and Usage (Section 6) describes the way QUIC 281 streams are used. 283 * HTTP Framing Layer (Section 7) describes the frames used on most 284 streams. 286 * Error Handling (Section 8) describes how error conditions are 287 handled and expressed, either on a particular stream or for the 288 connection as a whole. 290 Additional resources are provided in the final sections: 292 * Extensions to HTTP/3 (Section 9) describes how new capabilities 293 can be added in future documents. 295 * A more detailed comparison between HTTP/2 and HTTP/3 can be found 296 in Appendix A. 298 2.2. Conventions and Terminology 300 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 301 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 302 "OPTIONAL" in this document are to be interpreted as described in 303 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 304 capitals, as shown here. 306 This document uses the variable-length integer encoding from 307 [QUIC-TRANSPORT]. 309 The following terms are used: 311 abort: An abrupt termination of a connection or stream, possibly due 312 to an error condition. 314 client: The endpoint that initiates an HTTP/3 connection. Clients 315 send HTTP requests and receive HTTP responses. 317 connection: A transport-layer connection between two endpoints, 318 using QUIC as the transport protocol. 320 connection error: An error that affects the entire HTTP/3 321 connection. 323 endpoint: Either the client or server of the connection. 325 frame: The smallest unit of communication on a stream in HTTP/3, 326 consisting of a header and a variable-length sequence of bytes 327 structured according to the frame type. Protocol elements called 328 "frames" exist in both this document and [QUIC-TRANSPORT]. Where 329 frames from [QUIC-TRANSPORT] are referenced, the frame name will 330 be prefaced with "QUIC." For example, "QUIC CONNECTION_CLOSE 331 frames." References without this preface refer to frames defined 332 in Section 7.2. 334 HTTP/3 connection: A QUIC connection where the negotiated 335 application protocol is HTTP/3. 337 peer: An endpoint. When discussing a particular endpoint, "peer" 338 refers to the endpoint that is remote to the primary subject of 339 discussion. 341 receiver: An endpoint that is receiving frames. 343 sender: An endpoint that is transmitting frames. 345 server: The endpoint that accepts an HTTP/3 connection. Servers 346 receive HTTP requests and send HTTP responses. 348 stream: A bidirectional or unidirectional bytestream provided by the 349 QUIC transport. 351 stream error: An error on the individual HTTP/3 stream. 353 The term "payload body" is defined in Section 5.5.4 of [SEMANTICS]. 355 Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" 356 are defined in Section 3.7 of [SEMANTICS]. Intermediaries act as 357 both client and server at different times. 359 Packet diagrams in this document use the format defined in 360 Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of 361 fields. 363 3. Connection Setup and Management 365 3.1. Draft Version Identification 367 *RFC Editor's Note:* Please remove this section prior to 368 publication of a final version of this document. 370 HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc. 371 Only implementations of the final, published RFC can identify 372 themselves as "h3". Until such an RFC exists, implementations MUST 373 NOT identify themselves using this string. 375 Implementations of draft versions of the protocol MUST add the string 376 "-" and the corresponding draft number to the identifier. For 377 example, draft-ietf-quic-http-01 is identified using the string 378 "h3-01". 380 Draft versions MUST use the corresponding draft transport version as 381 their transport. For example, the application protocol defined in 382 draft-ietf-quic-http-25 uses the transport defined in draft-ietf- 383 quic-transport-25. 385 Non-compatible experiments that are based on these draft versions 386 MUST append the string "-" and an experiment name to the identifier. 387 For example, an experimental implementation based on draft-ietf-quic- 388 http-09 that reserves an extra stream for unsolicited transmission of 389 1980s pop music might identify itself as "h3-09-rickroll". Note that 390 any label MUST conform to the "token" syntax defined in Section 5.7.2 391 of [SEMANTICS]. Experimenters are encouraged to coordinate their 392 experiments on the quic@ietf.org mailing list. 394 3.2. Discovering an HTTP/3 Endpoint 396 HTTP relies on the notion of an authoritative response: a response 397 that has been determined to be the most appropriate response for that 398 request given the state of the target resource at the time of 399 response message origination by (or at the direction of) the origin 400 server identified within the target URI. Locating an authoritative 401 server for an HTTP URL is discussed in Section 4.3 of [SEMANTICS]. 403 The "https" scheme associates authority with possession of a 404 certificate that the client considers to be trustworthy for the host 405 identified by the authority component of the URL. If a server 406 presents a certificate and proof that it controls the corresponding 407 private key, then a client will accept a secured TLS session with 408 that server as being authoritative for all origins with the "https" 409 scheme and a host identified in the certificate. 411 A client MAY attempt access to a resource with an "https" URI by 412 resolving the host identifier to an IP address, establishing a QUIC 413 connection to that address on the indicated port, and sending an 414 HTTP/3 request message targeting the URI to the server over that 415 secured connection. Unless some other mechanism is used to select 416 HTTP/3, the token "h3" is used in the Application Layer Protocol 417 Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake. 419 Connectivity problems (e.g., blocking UDP) can result in QUIC 420 connection establishment failure; clients SHOULD attempt to use TCP- 421 based versions of HTTP in this case. 423 Servers MAY serve HTTP/3 on any UDP port; an alternative service 424 advertisement always includes an explicit port, and URLs contain 425 either an explicit port or a default port associated with the scheme. 427 3.2.1. HTTP Alternative Services 429 An HTTP origin advertises the availability of an equivalent HTTP/3 430 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 431 ALTSVC frame ([ALTSVC]), using the "h3" ALPN token. 433 For example, an origin could indicate in an HTTP response that HTTP/3 434 was available on UDP port 50781 at the same hostname by including the 435 following header field: 437 Alt-Svc: h3=":50781" 439 On receipt of an Alt-Svc record indicating HTTP/3 support, a client 440 MAY attempt to establish a QUIC connection to the indicated host and 441 port; if this connection is successful, the client can send HTTP 442 requests using the mapping described in this document. 444 3.2.2. Other Schemes 446 Although HTTP is independent of the transport protocol, the "http" 447 scheme associates authority with the ability to receive TCP 448 connections on the indicated port of whatever host is identified 449 within the authority component. Because HTTP/3 does not use TCP, 450 HTTP/3 cannot be used for direct access to the authoritative server 451 for a resource identified by an "http" URI. However, protocol 452 extensions such as [ALTSVC] permit the authoritative server to 453 identify other services that are also authoritative and that might be 454 reachable over HTTP/3. 456 Prior to making requests for an origin whose scheme is not "https", 457 the client MUST ensure the server is willing to serve that scheme. 458 For origins whose scheme is "http", an experimental method to 459 accomplish this is described in [RFC8164]. Other mechanisms might be 460 defined for various schemes in the future. 462 3.3. Connection Establishment 464 HTTP/3 relies on QUIC version 1 as the underlying transport. The use 465 of other QUIC transport versions with HTTP/3 MAY be defined by future 466 specifications. 468 QUIC version 1 uses TLS version 1.3 or greater as its handshake 469 protocol. HTTP/3 clients MUST support a mechanism to indicate the 470 target host to the server during the TLS handshake. If the server is 471 identified by a DNS name, clients MUST send the Server Name 472 Indication (SNI; [RFC6066]) TLS extension unless an alternative 473 mechanism to indicate the target host is used. 475 QUIC connections are established as described in [QUIC-TRANSPORT]. 476 During connection establishment, HTTP/3 support is indicated by 477 selecting the ALPN token "h3" in the TLS handshake. Support for 478 other application-layer protocols MAY be offered in the same 479 handshake. 481 While connection-level options pertaining to the core QUIC protocol 482 are set in the initial crypto handshake, HTTP/3-specific settings are 483 conveyed in the SETTINGS frame. After the QUIC connection is 484 established, a SETTINGS frame (Section 7.2.4) MUST be sent by each 485 endpoint as the initial frame of their respective HTTP control 486 stream; see Section 6.2.1. 488 3.4. Connection Reuse 490 HTTP/3 connections are persistent across multiple requests. For best 491 performance, it is expected that clients will not close connections 492 until it is determined that no further communication with a server is 493 necessary (for example, when a user navigates away from a particular 494 web page) or until the server closes the connection. 496 Once a connection exists to a server endpoint, this connection MAY be 497 reused for requests with multiple different URI authority components. 498 In general, a server is considered authoritative for all URIs with 499 the "https" scheme for which the hostname in the URI is present in 500 the authenticated certificate provided by the server, either as the 501 CN field of the certificate subject or as a dNSName in the 502 subjectAltName field of the certificate; see [RFC6125]. For a host 503 that is an IP address, the client MUST verify that the address 504 appears as an iPAddress in the subjectAltName field of the 505 certificate. If the hostname or address is not present in the 506 certificate, the client MUST NOT consider the server authoritative 507 for origins containing that hostname or address. See Section 4.3 of 508 [SEMANTICS] for more detail on authoritative access. 510 Clients SHOULD NOT open more than one HTTP/3 connection to a given 511 host and port pair, where the host is derived from a URI, a selected 512 alternative service ([ALTSVC]), or a configured proxy. A client MAY 513 open multiple HTTP/3 connections to the same IP address and UDP port 514 using different transport or TLS configurations but SHOULD avoid 515 creating multiple connections with the same configuration. 517 Servers are encouraged to maintain open HTTP/3 connections for as 518 long as possible but are permitted to terminate idle connections if 519 necessary. When either endpoint chooses to close the HTTP/3 520 connection, the terminating endpoint SHOULD first send a GOAWAY frame 521 (Section 5.2) so that both endpoints can reliably determine whether 522 previously sent frames have been processed and gracefully complete or 523 terminate any necessary remaining tasks. 525 A server that does not wish clients to reuse HTTP/3 connections for a 526 particular origin can indicate that it is not authoritative for a 527 request by sending a 421 (Misdirected Request) status code in 528 response to the request; see Section 9.1.2 of [HTTP2]. 530 4. HTTP Request Lifecycle 532 4.1. HTTP Message Exchanges 534 A client sends an HTTP request on a client-initiated bidirectional 535 QUIC stream. A client MUST send only a single request on a given 536 stream. A server sends zero or more interim HTTP responses on the 537 same stream as the request, followed by a single final HTTP response, 538 as detailed below. See Section 14 of [SEMANTICS] for a description 539 of interim and final HTTP responses. 541 Pushed responses are sent on a server-initiated unidirectional QUIC 542 stream; see Section 6.2.2. A server sends zero or more interim HTTP 543 responses, followed by a single final HTTP response, in the same 544 manner as a standard response. Push is described in more detail in 545 Section 4.4. 547 On a given stream, receipt of multiple requests or receipt of an 548 additional HTTP response following a final HTTP response MUST be 549 treated as malformed (Section 4.1.3). 551 An HTTP message (request or response) consists of: 553 1. the header field section, sent as a single HEADERS frame (see 554 Section 7.2.2), 556 2. optionally, the payload body, if present, sent as a series of 557 DATA frames (see Section 7.2.1), and 559 3. optionally, the trailer field section, if present, sent as a 560 single HEADERS frame. 562 Header and trailer field sections are described in Sections 5.4 and 563 5.6 of [SEMANTICS]; the payload body is described in Section 5.5.4 of 564 [SEMANTICS]. 566 Receipt of an invalid sequence of frames MUST be treated as a 567 connection error of type H3_FRAME_UNEXPECTED (Section 8). In 568 particular, a DATA frame before any HEADERS frame, or a HEADERS or 569 DATA frame after the trailing HEADERS frame is considered invalid. 570 Other frame types, especially unknown frame types, might be permitted 571 subject to their own rules; see Section 9. 573 A server MAY send one or more PUSH_PROMISE frames (Section 7.2.5) 574 before, after, or interleaved with the frames of a response message. 575 These PUSH_PROMISE frames are not part of the response; see 576 Section 4.4 for more details. PUSH_PROMISE frames are not permitted 577 on push streams; a pushed response that includes PUSH_PROMISE frames 578 MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. 580 Frames of unknown types (Section 9), including reserved frames 581 (Section 7.2.8) MAY be sent on a request or push stream before, 582 after, or interleaved with other frames described in this section. 584 The HEADERS and PUSH_PROMISE frames might reference updates to the 585 QPACK dynamic table. While these updates are not directly part of 586 the message exchange, they must be received and processed before the 587 message can be consumed. See Section 4.1.1 for more details. 589 The "chunked" transfer encoding defined in Section 7.1 of [HTTP11] 590 MUST NOT be used. 592 A response MAY consist of multiple messages when and only when one or 593 more interim responses (1xx; see Section 14.2 of [SEMANTICS]) precede 594 a final response to the same request. Interim responses do not 595 contain a payload body or trailers. 597 An HTTP request/response exchange fully consumes a client-initiated 598 bidirectional QUIC stream. After sending a request, a client MUST 599 close the stream for sending. Unless using the CONNECT method (see 600 Section 4.2), clients MUST NOT make stream closure dependent on 601 receiving a response to their request. After sending a final 602 response, the server MUST close the stream for sending. At this 603 point, the QUIC stream is fully closed. 605 When a stream is closed, this indicates the end of the final HTTP 606 message. Because some messages are large or unbounded, endpoints 607 SHOULD begin processing partial HTTP messages once enough of the 608 message has been received to make progress. If a client-initiated 609 stream terminates without enough of the HTTP message to provide a 610 complete response, the server SHOULD abort its response with the 611 error code H3_REQUEST_INCOMPLETE. 613 A server can send a complete response prior to the client sending an 614 entire request if the response does not depend on any portion of the 615 request that has not been sent and received. When the server does 616 not need to receive the remainder of the request, it MAY abort 617 reading the request stream, send a complete response, and cleanly 618 close the sending part of the stream. The error code H3_NO_ERROR 619 SHOULD be used when requesting that the client stop sending on the 620 request stream. Clients MUST NOT discard complete responses as a 621 result of having their request terminated abruptly, though clients 622 can always discard responses at their discretion for other reasons. 623 If the server sends a partial or complete response but does not abort 624 reading the request, clients SHOULD continue sending the body of the 625 request and close the stream normally. 627 4.1.1. Field Formatting and Compression 629 HTTP messages carry metadata as a series of key-value pairs, called 630 HTTP fields. For a listing of registered HTTP fields, see the 631 "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained 632 at https://www.iana.org/assignments/http-fields/. 634 *Note:* This registry will not exist until [SEMANTICS] is 635 approved. *RFC Editor*, please remove this note prior to 636 publication. 638 As in previous versions of HTTP, field names are strings containing a 639 subset of ASCII characters that are compared in a case-insensitive 640 fashion. Properties of HTTP field names and values are discussed in 641 more detail in Section 5.4.3 of [SEMANTICS]. As in HTTP/2, 642 characters in field names MUST be converted to lowercase prior to 643 their encoding. A request or response containing uppercase 644 characters in field names MUST be treated as malformed 645 (Section 4.1.3). 647 Like HTTP/2, HTTP/3 does not use the Connection header field to 648 indicate connection-specific fields; in this protocol, connection- 649 specific metadata is conveyed by other means. An endpoint MUST NOT 650 generate an HTTP/3 field section containing connection-specific 651 fields; any message containing connection-specific fields MUST be 652 treated as malformed (Section 4.1.3). 654 The only exception to this is the TE header field, which MAY be 655 present in an HTTP/3 request header; when it is, it MUST NOT contain 656 any value other than "trailers". 658 This means that an intermediary transforming an HTTP/1.x message to 659 HTTP/3 will need to remove any fields nominated by the Connection 660 field, along with the Connection field itself. Such intermediaries 661 SHOULD also remove other connection-specific fields, such as Keep- 662 Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they 663 are not nominated by the Connection field. 665 4.1.1.1. Pseudo-Header Fields 667 Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where 668 the field name begins with the ':' character (ASCII 0x3a). These 669 pseudo-header fields convey the target URI, the method of the 670 request, and the status code for the response. 672 Pseudo-header fields are not HTTP fields. Endpoints MUST NOT 673 generate pseudo-header fields other than those defined in this 674 document; however, an extension could negotiate a modification of 675 this restriction; see Section 9. 677 Pseudo-header fields are only valid in the context in which they are 678 defined. Pseudo-header fields defined for requests MUST NOT appear 679 in responses; pseudo-header fields defined for responses MUST NOT 680 appear in requests. Pseudo-header fields MUST NOT appear in 681 trailers. Endpoints MUST treat a request or response that contains 682 undefined or invalid pseudo-header fields as malformed 683 (Section 4.1.3). 685 All pseudo-header fields MUST appear in the header field section 686 before regular header fields. Any request or response that contains 687 a pseudo-header field that appears in a header field section after a 688 regular header field MUST be treated as malformed (Section 4.1.3). 690 The following pseudo-header fields are defined for requests: 692 ":method": Contains the HTTP method (Section 8 of [SEMANTICS]) 694 ":scheme": Contains the scheme portion of the target URI 695 (Section 3.1 of [URI]) 697 ":scheme" is not restricted to "http" and "https" schemed URIs. A 698 proxy or gateway can translate requests for non-HTTP schemes, 699 enabling the use of HTTP to interact with non-HTTP services. 701 ":authority": Contains the authority portion of the target URI 702 (Section 3.2 of [URI]). The authority MUST NOT include the 703 deprecated "userinfo" subcomponent for "http" or "https" schemed 704 URIs. 706 To ensure that the HTTP/1.1 request line can be reproduced 707 accurately, this pseudo-header field MUST be omitted when 708 translating from an HTTP/1.1 request that has a request target in 709 origin or asterisk form; see Section 3.2 of [HTTP11]. Clients 710 that generate HTTP/3 requests directly SHOULD use the ":authority" 711 pseudo-header field instead of the Host field. An intermediary 712 that converts an HTTP/3 request to HTTP/1.1 MUST create a Host 713 field if one is not present in a request by copying the value of 714 the ":authority" pseudo-header field. 716 ":path": Contains the path and query parts of the target URI (the 717 "path-absolute" production and optionally a '?' character followed 718 by the "query" production; see Sections 3.3 and 3.4 of [URI]. A 719 request in asterisk form includes the value '*' for the ":path" 720 pseudo-header field. 722 This pseudo-header field MUST NOT be empty for "http" or "https" 723 URIs; "http" or "https" URIs that do not contain a path component 724 MUST include a value of '/'. The exception to this rule is an 725 OPTIONS request for an "http" or "https" URI that does not include 726 a path component; these MUST include a ":path" pseudo-header field 727 with a value of '*'; see Section 3.2.4 of [HTTP11]. 729 All HTTP/3 requests MUST include exactly one value for the ":method", 730 ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT 731 request; see Section 4.2. 733 If the ":scheme" pseudo-header field identifies a scheme that has a 734 mandatory authority component (including "http" and "https"), the 735 request MUST contain either an ":authority" pseudo-header field or a 736 "Host" header field. If these fields are present, they MUST NOT be 737 empty. If both fields are present, they MUST contain the same value. 738 If the scheme does not have a mandatory authority component and none 739 is provided in the request target, the request MUST NOT contain the 740 ":authority" pseudo-header or "Host" header fields. 742 An HTTP request that omits mandatory pseudo-header fields or contains 743 invalid values for those pseudo-header fields is malformed 744 (Section 4.1.3). 746 HTTP/3 does not define a way to carry the version identifier that is 747 included in the HTTP/1.1 request line. 749 For responses, a single ":status" pseudo-header field is defined that 750 carries the HTTP status code; see Section 14 of [SEMANTICS]. This 751 pseudo-header field MUST be included in all responses; otherwise, the 752 response is malformed (Section 4.1.3). 754 HTTP/3 does not define a way to carry the version or reason phrase 755 that is included in an HTTP/1.1 status line. 757 4.1.1.2. Field Compression 759 HTTP/3 uses QPACK field compression as described in [QPACK], a 760 variation of HPACK that allows the flexibility to avoid compression- 761 induced head-of-line blocking. See that document for additional 762 details. 764 To allow for better compression efficiency, the "Cookie" field 765 ([RFC6265]) MAY be split into separate field lines, each with one or 766 more cookie-pairs, before compression. If a decompressed field 767 section contains multiple cookie field lines, these MUST be 768 concatenated into a single octet string using the two-octet delimiter 769 of 0x3b, 0x20 (the ASCII string "; ") before being passed into a 770 context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, 771 or a generic HTTP server application. 773 4.1.1.3. Header Size Constraints 775 An HTTP/3 implementation MAY impose a limit on the maximum size of 776 the message header it will accept on an individual HTTP message. A 777 server that receives a larger header section than it is willing to 778 handle can send an HTTP 431 (Request Header Fields Too Large) status 779 code ([RFC6585]). A client can discard responses that it cannot 780 process. The size of a field list is calculated based on the 781 uncompressed size of fields, including the length of the name and 782 value in bytes plus an overhead of 32 bytes for each field. 784 If an implementation wishes to advise its peer of this limit, it can 785 be conveyed as a number of bytes in the 786 SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that 787 has received this parameter SHOULD NOT send an HTTP message header 788 that exceeds the indicated size, as the peer will likely refuse to 789 process it. However, because this limit is applied at each hop, 790 messages below this limit are not guaranteed to be accepted. 792 4.1.2. Request Cancellation and Rejection 794 Once a request stream has been opened, the request MAY be cancelled 795 by either endpoint. Clients cancel requests if the response is no 796 longer of interest; servers cancel requests if they are unable to or 797 choose not to respond. When possible, it is RECOMMENDED that servers 798 send an HTTP response with an appropriate status code rather than 799 canceling a request it has already begun processing. 801 Implementations SHOULD cancel requests by abruptly terminating any 802 directions of a stream that are still open. This means resetting the 803 sending parts of streams and aborting reading on receiving parts of 804 streams; see Section 2.4 of [QUIC-TRANSPORT]. 806 When the server cancels a request without performing any application 807 processing, the request is considered "rejected." The server SHOULD 808 abort its response stream with the error code H3_REQUEST_REJECTED. 809 In this context, "processed" means that some data from the stream was 810 passed to some higher layer of software that might have taken some 811 action as a result. The client can treat requests rejected by the 812 server as though they had never been sent at all, thereby allowing 813 them to be retried later. 815 Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests 816 that were partially or fully processed. When a server abandons a 817 response after partial processing, it SHOULD abort its response 818 stream with the error code H3_REQUEST_CANCELLED. 820 Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel 821 requests. Upon receipt of this error code, a server MAY abruptly 822 terminate the response using the error code H3_REQUEST_REJECTED if no 823 processing was performed. Clients MUST NOT use the 824 H3_REQUEST_REJECTED error code, except when a server has requested 825 closure of the request stream with this error code. 827 If a stream is canceled after receiving a complete response, the 828 client MAY ignore the cancellation and use the response. However, if 829 a stream is cancelled after receiving a partial response, the 830 response SHOULD NOT be used. Automatically retrying such requests is 831 not possible, unless this is otherwise permitted (e.g., idempotent 832 actions like GET, PUT, or DELETE). 834 4.1.3. Malformed Requests and Responses 836 A malformed request or response is one that is an otherwise valid 837 sequence of frames but is invalid due to: 839 * the presence of prohibited fields or pseudo-header fields, 841 * the absence of mandatory pseudo-header fields, 843 * invalid values for pseudo-header fields, 845 * pseudo-header fields after fields, 847 * an invalid sequence of HTTP messages, 848 * the inclusion of uppercase field names, or 850 * the inclusion of invalid characters in field names or values 852 A request or response that includes a payload body can include a 853 Content-Length header field. A request or response is also malformed 854 if the value of a content-length header field does not equal the sum 855 of the DATA frame payload lengths that form the body. A response 856 that is defined to have no payload, as described in Section 5.5.4 of 857 [SEMANTICS], can have a non-zero content-length field, even though no 858 content is included in DATA frames. 860 Intermediaries that process HTTP requests or responses (i.e., any 861 intermediary not acting as a tunnel) MUST NOT forward a malformed 862 request or response. Malformed requests or responses that are 863 detected MUST be treated as a stream error (Section 8) of type 864 H3_GENERAL_PROTOCOL_ERROR. 866 For malformed requests, a server MAY send an HTTP response indicating 867 the error prior to closing or resetting the stream. Clients MUST NOT 868 accept a malformed response. Note that these requirements are 869 intended to protect against several types of common attacks against 870 HTTP; they are deliberately strict because being permissive can 871 expose implementations to these vulnerabilities. 873 4.2. The CONNECT Method 875 The CONNECT method requests that the recipient establish a tunnel to 876 the destination origin server identified by the request-target 877 (Section 3.2 of [HTTP11]). It is primarily used with HTTP proxies to 878 establish a TLS session with an origin server for the purposes of 879 interacting with "https" resources. 881 In HTTP/1.x, CONNECT is used to convert an entire HTTP connection 882 into a tunnel to a remote host. In HTTP/2 and HTTP/3, the CONNECT 883 method is used to establish a tunnel over a single stream. 885 A CONNECT request MUST be constructed as follows: 887 * The ":method" pseudo-header field is set to "CONNECT" 889 * The ":scheme" and ":path" pseudo-header fields are omitted 891 * The ":authority" pseudo-header field contains the host and port to 892 connect to (equivalent to the authority-form of the request-target 893 of CONNECT requests; see Section 3.2.3 of [HTTP11]) 895 The request stream remains open at the end of the request to carry 896 the data to be transferred. A CONNECT request that does not conform 897 to these restrictions is malformed; see Section 4.1.3. 899 A proxy that supports CONNECT establishes a TCP connection 900 ([RFC0793]) to the server identified in the ":authority" pseudo- 901 header field. Once this connection is successfully established, the 902 proxy sends a HEADERS frame containing a 2xx series status code to 903 the client, as defined in Section 14.3 of [SEMANTICS]. 905 All DATA frames on the stream correspond to data sent or received on 906 the TCP connection. The payload of any DATA frame sent by the client 907 is transmitted by the proxy to the TCP server; data received from the 908 TCP server is packaged into DATA frames by the proxy. Note that the 909 size and number of TCP segments is not guaranteed to map predictably 910 to the size and number of HTTP DATA or QUIC STREAM frames. 912 Once the CONNECT method has completed, only DATA frames are permitted 913 to be sent on the stream. Extension frames MAY be used if 914 specifically permitted by the definition of the extension. Receipt 915 of any other known frame type MUST be treated as a connection error 916 of type H3_FRAME_UNEXPECTED. 918 The TCP connection can be closed by either peer. When the client 919 ends the request stream (that is, the receive stream at the proxy 920 enters the "Data Recvd" state), the proxy will set the FIN bit on its 921 connection to the TCP server. When the proxy receives a packet with 922 the FIN bit set, it will close the send stream that it sends to the 923 client. TCP connections that remain half-closed in a single 924 direction are not invalid, but are often handled poorly by servers, 925 so clients SHOULD NOT close a stream for sending while they still 926 expect to receive data from the target of the CONNECT. 928 A TCP connection error is signaled by abruptly terminating the 929 stream. A proxy treats any error in the TCP connection, which 930 includes receiving a TCP segment with the RST bit set, as a stream 931 error of type H3_CONNECT_ERROR (Section 8.1). Correspondingly, if a 932 proxy detects an error with the stream or the QUIC connection, it 933 MUST close the TCP connection. If the underlying TCP implementation 934 permits it, the proxy SHOULD send a TCP segment with the RST bit set. 936 4.3. HTTP Upgrade 938 HTTP/3 does not support the HTTP Upgrade mechanism (Section 6.6 of 939 [SEMANTICS]) or 101 (Switching Protocols) informational status code 940 (Section 14.2.2 of [SEMANTICS]). 942 4.4. Server Push 944 Server push is an interaction mode that permits a server to push a 945 request-response exchange to a client in anticipation of the client 946 making the indicated request. This trades off network usage against 947 a potential latency gain. HTTP/3 server push is similar to what is 948 described in Section 8.2 of [HTTP2], but uses different mechanisms. 950 Each server push is assigned a unique Push ID by the server. The 951 Push ID is used to refer to the push in various contexts throughout 952 the lifetime of the HTTP/3 connection. 954 The Push ID space begins at zero, and ends at a maximum value set by 955 the MAX_PUSH_ID frame; see Section 7.2.7. In particular, a server is 956 not able to push until after the client sends a MAX_PUSH_ID frame. A 957 client sends MAX_PUSH_ID frames to control the number of pushes that 958 a server can promise. A server SHOULD use Push IDs sequentially, 959 beginning from zero. A client MUST treat receipt of a push stream as 960 a connection error of type H3_ID_ERROR when no MAX_PUSH_ID frame has 961 been sent or when the stream references a Push ID that is greater 962 than the maximum Push ID. 964 The Push ID is used in one or more PUSH_PROMISE frames 965 (Section 7.2.5) that carry the header section of the request message. 966 These frames are sent on the request stream that generated the push. 967 This allows the server push to be associated with a client request. 968 When the same Push ID is promised on multiple request streams, the 969 decompressed request field sections MUST contain the same fields in 970 the same order, and both the name and the value in each field MUST be 971 identical. 973 The Push ID is then included with the push stream that ultimately 974 fulfills those promises; see Section 6.2.2. The push stream 975 identifies the Push ID of the promise that it fulfills, then contains 976 a response to the promised request as described in Section 4.1. 978 Finally, the Push ID can be used in CANCEL_PUSH frames; see 979 Section 7.2.3. Clients use this frame to indicate they do not wish 980 to receive a promised resource. Servers use this frame to indicate 981 they will not be fulfilling a previous promise. 983 Not all requests can be pushed. A server MAY push requests that have 984 the following properties: 986 * cacheable; see Section 8.2.3 of [SEMANTICS] 988 * safe; see Section 8.2.1 of [SEMANTICS] 989 * does not include a request body or trailer section 991 The server MUST include a value in the ":authority" pseudo-header 992 field for which the server is authoritative; see Section 3.4. 994 Clients SHOULD send a CANCEL_PUSH frame upon receipt of a 995 PUSH_PROMISE frame carrying a request that is not cacheable, is not 996 known to be safe, that indicates the presence of a request body, or 997 for which it does not consider the server authoritative. Any 998 corresponding responses MUST NOT be used or cached. 1000 Each pushed response is associated with one or more client requests. 1001 The push is associated with the request stream on which the 1002 PUSH_PROMISE frame was received. The same server push can be 1003 associated with additional client requests using a PUSH_PROMISE frame 1004 with the same Push ID on multiple request streams. These 1005 associations do not affect the operation of the protocol, but MAY be 1006 considered by user agents when deciding how to use pushed resources. 1008 Ordering of a PUSH_PROMISE frame in relation to certain parts of the 1009 response is important. The server SHOULD send PUSH_PROMISE frames 1010 prior to sending HEADERS or DATA frames that reference the promised 1011 responses. This reduces the chance that a client requests a resource 1012 that will be pushed by the server. 1014 Due to reordering, push stream data can arrive before the 1015 corresponding PUSH_PROMISE frame. When a client receives a new push 1016 stream with an as-yet-unknown Push ID, both the associated client 1017 request and the pushed request header fields are unknown. The client 1018 can buffer the stream data in expectation of the matching 1019 PUSH_PROMISE. The client can use stream flow control (see section 1020 4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server may 1021 commit to the pushed stream. 1023 Push stream data can also arrive after a client has canceled a push. 1024 In this case, the client can abort reading the stream with an error 1025 code of H3_REQUEST_CANCELLED. This asks the server not to transfer 1026 additional data and indicates that it will be discarded upon receipt. 1028 Pushed responses that are cacheable (see Section 3 of [CACHING]) can 1029 be stored by the client, if it implements an HTTP cache. Pushed 1030 responses are considered successfully validated on the origin server 1031 (e.g., if the "no-cache" cache response directive is present; see 1032 Section 5.2.2.3 of [CACHING]) at the time the pushed response is 1033 received. 1035 Pushed responses that are not cacheable MUST NOT be stored by any 1036 HTTP cache. They MAY be made available to the application 1037 separately. 1039 5. Connection Closure 1041 Once established, an HTTP/3 connection can be used for many requests 1042 and responses over time until the connection is closed. Connection 1043 closure can happen in any of several different ways. 1045 5.1. Idle Connections 1047 Each QUIC endpoint declares an idle timeout during the handshake. If 1048 the QUIC connection remains idle (no packets received) for longer 1049 than this duration, the peer will assume that the connection has been 1050 closed. HTTP/3 implementations will need to open a new HTTP/3 1051 connection for new requests if the existing connection has been idle 1052 for longer than the server's advertised idle timeout, and SHOULD do 1053 so if approaching the idle timeout. 1055 HTTP clients are expected to request that the transport keep 1056 connections open while there are responses outstanding for requests 1057 or server pushes, as described in Section 10.1.2 of [QUIC-TRANSPORT]. 1058 If the client is not expecting a response from the server, allowing 1059 an idle connection to time out is preferred over expending effort 1060 maintaining a connection that might not be needed. A gateway MAY 1061 maintain connections in anticipation of need rather than incur the 1062 latency cost of connection establishment to servers. Servers SHOULD 1063 NOT actively keep connections open. 1065 5.2. Connection Shutdown 1067 Even when a connection is not idle, either endpoint can decide to 1068 stop using the connection and initiate a graceful connection close. 1069 Endpoints initiate the graceful shutdown of an HTTP/3 connection by 1070 sending a GOAWAY frame (Section 7.2.6). The GOAWAY frame contains an 1071 identifier that indicates to the receiver the range of requests or 1072 pushes that were or might be processed in this connection. The 1073 server sends a client-initiated bidirectional Stream ID; the client 1074 sends a Push ID (Section 4.4). Requests or pushes with the indicated 1075 identifier or greater are rejected (Section 4.1.2) by the sender of 1076 the GOAWAY. This identifier MAY be zero if no requests or pushes 1077 were processed. 1079 The information in the GOAWAY frame enables a client and server to 1080 agree on which requests or pushes were accepted prior to the shutdown 1081 of the HTTP/3 connection. Upon sending a GOAWAY frame, the endpoint 1082 SHOULD explicitly cancel (see Section 4.1.2 and Section 7.2.3) any 1083 requests or pushes that have identifiers greater than or equal to 1084 that indicated, in order to clean up transport state for the affected 1085 streams. The endpoint SHOULD continue to do so as more requests or 1086 pushes arrive. 1088 Endpoints MUST NOT initiate new requests or promise new pushes on the 1089 connection after receipt of a GOAWAY frame from the peer. Clients 1090 MAY establish a new connection to send additional requests. 1092 Some requests or pushes might already be in transit: 1094 * Upon receipt of a GOAWAY frame, if the client has already sent 1095 requests with a Stream ID greater than or equal to the identifier 1096 contained in the GOAWAY frame, those requests will not be 1097 processed. Clients can safely retry unprocessed requests on a 1098 different HTTP connection. A client that is unable to retry 1099 requests loses all requests that are in flight when the server 1100 closes the connection. 1102 Requests on Stream IDs less than the Stream ID in a GOAWAY frame 1103 from the server might have been processed; their status cannot be 1104 known until a response is received, the stream is reset 1105 individually, another GOAWAY is received, or the connection 1106 terminates. 1108 Servers MAY reject individual requests on streams below the 1109 indicated ID if these requests were not processed. 1111 * If a server receives a GOAWAY frame after having promised pushes 1112 with a Push ID greater than or equal to the identifier contained 1113 in the GOAWAY frame, those pushes will not be accepted. 1115 Servers SHOULD send a GOAWAY frame when the closing of a connection 1116 is known in advance, even if the advance notice is small, so that the 1117 remote peer can know whether a request has been partially processed 1118 or not. For example, if an HTTP client sends a POST at the same time 1119 that a server closes a QUIC connection, the client cannot know if the 1120 server started to process that POST request if the server does not 1121 send a GOAWAY frame to indicate what streams it might have acted on. 1123 An endpoint MAY send multiple GOAWAY frames indicating different 1124 identifiers, but the identifier in each frame MUST NOT be greater 1125 than the identifier in any previous frame, since clients might 1126 already have retried unprocessed requests on another HTTP connection. 1127 Receiving a GOAWAY containing a larger identifier than previously 1128 received MUST be treated as a connection error of type H3_ID_ERROR. 1130 An endpoint that is attempting to gracefully shut down a connection 1131 can send a GOAWAY frame with a value set to the maximum possible 1132 value (2^62-4 for servers, 2^62-1 for clients). This ensures that 1133 the peer stops creating new requests or pushes. After allowing time 1134 for any in-flight requests or pushes to arrive, the endpoint can send 1135 another GOAWAY frame indicating which requests or pushes it might 1136 accept before the end of the connection. This ensures that a 1137 connection can be cleanly shut down without losing requests. 1139 A client has more flexibility in the value it chooses for the Push ID 1140 in a GOAWAY that it sends. A value of 2^62 - 1 indicates that the 1141 server can continue fulfilling pushes that have already been 1142 promised. A smaller value indicates the client will reject pushes 1143 with Push IDs greater than or equal to this value. Like the server, 1144 the client MAY send subsequent GOAWAY frames so long as the specified 1145 Push ID is no greater than any previously sent value. 1147 Even when a GOAWAY indicates that a given request or push will not be 1148 processed or accepted upon receipt, the underlying transport 1149 resources still exist. The endpoint that initiated these requests 1150 can cancel them to clean up transport state. 1152 Once all accepted requests and pushes have been processed, the 1153 endpoint can permit the connection to become idle, or MAY initiate an 1154 immediate closure of the connection. An endpoint that completes a 1155 graceful shutdown SHOULD use the H3_NO_ERROR error code when closing 1156 the connection. 1158 If a client has consumed all available bidirectional stream IDs with 1159 requests, the server need not send a GOAWAY frame, since the client 1160 is unable to make further requests. 1162 5.3. Immediate Application Closure 1164 An HTTP/3 implementation can immediately close the QUIC connection at 1165 any time. This results in sending a QUIC CONNECTION_CLOSE frame to 1166 the peer indicating that the application layer has terminated the 1167 connection. The application error code in this frame indicates to 1168 the peer why the connection is being closed. See Section 8 for error 1169 codes that can be used when closing a connection in HTTP/3. 1171 Before closing the connection, a GOAWAY frame MAY be sent to allow 1172 the client to retry some requests. Including the GOAWAY frame in the 1173 same packet as the QUIC CONNECTION_CLOSE frame improves the chances 1174 of the frame being received by clients. 1176 5.4. Transport Closure 1178 For various reasons, the QUIC transport could indicate to the 1179 application layer that the connection has terminated. This might be 1180 due to an explicit closure by the peer, a transport-level error, or a 1181 change in network topology that interrupts connectivity. 1183 If a connection terminates without a GOAWAY frame, clients MUST 1184 assume that any request that was sent, whether in whole or in part, 1185 might have been processed. 1187 6. Stream Mapping and Usage 1189 A QUIC stream provides reliable in-order delivery of bytes, but makes 1190 no guarantees about order of delivery with regard to bytes on other 1191 streams. On the wire, data is framed into QUIC STREAM frames, but 1192 this framing is invisible to the HTTP framing layer. The transport 1193 layer buffers and orders received QUIC STREAM frames, exposing the 1194 data contained within as a reliable byte stream to the application. 1195 Although QUIC permits out-of-order delivery within a stream, HTTP/3 1196 does not make use of this feature. 1198 QUIC streams can be either unidirectional, carrying data only from 1199 initiator to receiver, or bidirectional. Streams can be initiated by 1200 either the client or the server. For more detail on QUIC streams, 1201 see Section 2 of [QUIC-TRANSPORT]. 1203 When HTTP fields and data are sent over QUIC, the QUIC layer handles 1204 most of the stream management. HTTP does not need to do any separate 1205 multiplexing when using QUIC - data sent over a QUIC stream always 1206 maps to a particular HTTP transaction or to the entire HTTP/3 1207 connection context. 1209 6.1. Bidirectional Streams 1211 All client-initiated bidirectional streams are used for HTTP requests 1212 and responses. A bidirectional stream ensures that the response can 1213 be readily correlated with the request. This means that the client's 1214 first request occurs on QUIC stream 0, with subsequent requests on 1215 stream 4, 8, and so on. In order to permit these streams to open, an 1216 HTTP/3 server SHOULD configure non-zero minimum values for the number 1217 of permitted streams and the initial stream flow control window. So 1218 as to not unnecessarily limit parallelism, at least 100 requests 1219 SHOULD be permitted at a time. 1221 HTTP/3 does not use server-initiated bidirectional streams, though an 1222 extension could define a use for these streams. Clients MUST treat 1223 receipt of a server-initiated bidirectional stream as a connection 1224 error of type H3_STREAM_CREATION_ERROR unless such an extension has 1225 been negotiated. 1227 6.2. Unidirectional Streams 1229 Unidirectional streams, in either direction, are used for a range of 1230 purposes. The purpose is indicated by a stream type, which is sent 1231 as a variable-length integer at the start of the stream. The format 1232 and structure of data that follows this integer is determined by the 1233 stream type. 1235 Unidirectional Stream Header { 1236 Stream Type (i), 1237 } 1239 Figure 1: Unidirectional Stream Header 1241 Two stream types are defined in this document: control streams 1242 (Section 6.2.1) and push streams (Section 6.2.2). [QPACK] defines 1243 two additional stream types. Other stream types can be defined by 1244 extensions to HTTP/3; see Section 9 for more details. Some stream 1245 types are reserved (Section 6.2.3). 1247 The performance of HTTP/3 connections in the early phase of their 1248 lifetime is sensitive to the creation and exchange of data on 1249 unidirectional streams. Endpoints that excessively restrict the 1250 number of streams or the flow control window of these streams will 1251 increase the chance that the remote peer reaches the limit early and 1252 becomes blocked. In particular, implementations should consider that 1253 remote peers may wish to exercise reserved stream behavior 1254 (Section 6.2.3) with some of the unidirectional streams they are 1255 permitted to use. To avoid blocking, the transport parameters sent 1256 by both clients and servers MUST allow the peer to create at least 1257 one unidirectional stream for the HTTP control stream plus the number 1258 of unidirectional streams required by mandatory extensions (three 1259 being the minimum number required for the base HTTP/3 protocol and 1260 QPACK), and SHOULD provide at least 1,024 bytes of flow control 1261 credit to each stream. 1263 Note that an endpoint is not required to grant additional credits to 1264 create more unidirectional streams if its peer consumes all the 1265 initial credits before creating the critical unidirectional streams. 1266 Endpoints SHOULD create the HTTP control stream as well as the 1267 unidirectional streams required by mandatory extensions (such as the 1268 QPACK encoder and decoder streams) first, and then create additional 1269 streams as allowed by their peer. 1271 If the stream header indicates a stream type that is not supported by 1272 the recipient, the remainder of the stream cannot be consumed as the 1273 semantics are unknown. Recipients of unknown stream types MAY abort 1274 reading of the stream with an error code of H3_STREAM_CREATION_ERROR 1275 or a reserved error code (Section 8.1), but MUST NOT consider such 1276 streams to be a connection error of any kind. 1278 Implementations MAY send stream types before knowing whether the peer 1279 supports them. However, stream types that could modify the state or 1280 semantics of existing protocol components, including QPACK or other 1281 extensions, MUST NOT be sent until the peer is known to support them. 1283 A sender can close or reset a unidirectional stream unless otherwise 1284 specified. A receiver MUST tolerate unidirectional streams being 1285 closed or reset prior to the reception of the unidirectional stream 1286 header. 1288 6.2.1. Control Streams 1290 A control stream is indicated by a stream type of 0x00. Data on this 1291 stream consists of HTTP/3 frames, as defined in Section 7.2. 1293 Each side MUST initiate a single control stream at the beginning of 1294 the connection and send its SETTINGS frame as the first frame on this 1295 stream. If the first frame of the control stream is any other frame 1296 type, this MUST be treated as a connection error of type 1297 H3_MISSING_SETTINGS. Only one control stream per peer is permitted; 1298 receipt of a second stream claiming to be a control stream MUST be 1299 treated as a connection error of type H3_STREAM_CREATION_ERROR. The 1300 sender MUST NOT close the control stream, and the receiver MUST NOT 1301 request that the sender close the control stream. If either control 1302 stream is closed at any point, this MUST be treated as a connection 1303 error of type H3_CLOSED_CRITICAL_STREAM. 1305 A pair of unidirectional streams is used rather than a single 1306 bidirectional stream. This allows either peer to send data as soon 1307 as it is able. Depending on whether 0-RTT is enabled on the QUIC 1308 connection, either client or server might be able to send stream data 1309 first after the cryptographic handshake completes. 1311 6.2.2. Push Streams 1313 Server push is an optional feature introduced in HTTP/2 that allows a 1314 server to initiate a response before a request has been made. See 1315 Section 4.4 for more details. 1317 A push stream is indicated by a stream type of 0x01, followed by the 1318 Push ID of the promise that it fulfills, encoded as a variable-length 1319 integer. The remaining data on this stream consists of HTTP/3 1320 frames, as defined in Section 7.2, and fulfills a promised server 1321 push by zero or more interim HTTP responses followed by a single 1322 final HTTP response, as defined in Section 4.1. Server push and Push 1323 IDs are described in Section 4.4. 1325 Only servers can push; if a server receives a client-initiated push 1326 stream, this MUST be treated as a connection error of type 1327 H3_STREAM_CREATION_ERROR. 1329 Push Stream Header { 1330 Stream Type (i) = 0x01, 1331 Push ID (i), 1332 } 1334 Figure 2: Push Stream Header 1336 Each Push ID MUST only be used once in a push stream header. If a 1337 push stream header includes a Push ID that was used in another push 1338 stream header, the client MUST treat this as a connection error of 1339 type H3_ID_ERROR. 1341 6.2.3. Reserved Stream Types 1343 Stream types of the format "0x1f * N + 0x21" for non-negative integer 1344 values of N are reserved to exercise the requirement that unknown 1345 types be ignored. These streams have no semantics, and can be sent 1346 when application-layer padding is desired. They MAY also be sent on 1347 connections where no data is currently being transferred. Endpoints 1348 MUST NOT consider these streams to have any meaning upon receipt. 1350 The payload and length of the stream are selected in any manner the 1351 sending implementation chooses. When sending a reserved stream type, 1352 the implementation MAY either terminate the stream cleanly or reset 1353 it. When resetting the stream, either the H3_NO_ERROR error code or 1354 a reserved error code (Section 8.1) SHOULD be used. 1356 7. HTTP Framing Layer 1358 HTTP frames are carried on QUIC streams, as described in Section 6. 1359 HTTP/3 defines three stream types: control stream, request stream, 1360 and push stream. This section describes HTTP/3 frame formats and 1361 their permitted stream types; see Table 1 for an overview. A 1362 comparison between HTTP/2 and HTTP/3 frames is provided in 1363 Appendix A.2. 1365 +==============+================+================+========+=========+ 1366 | Frame | Control Stream | Request | Push | Section | 1367 | | | Stream | Stream | | 1368 +==============+================+================+========+=========+ 1369 | DATA | No | Yes | Yes | Section | 1370 | | | | | 7.2.1 | 1371 +--------------+----------------+----------------+--------+---------+ 1372 | HEADERS | No | Yes | Yes | Section | 1373 | | | | | 7.2.2 | 1374 +--------------+----------------+----------------+--------+---------+ 1375 | CANCEL_PUSH | Yes | No | No | Section | 1376 | | | | | 7.2.3 | 1377 +--------------+----------------+----------------+--------+---------+ 1378 | SETTINGS | Yes (1) | No | No | Section | 1379 | | | | | 7.2.4 | 1380 +--------------+----------------+----------------+--------+---------+ 1381 | PUSH_PROMISE | No | Yes | No | Section | 1382 | | | | | 7.2.5 | 1383 +--------------+----------------+----------------+--------+---------+ 1384 | GOAWAY | Yes | No | No | Section | 1385 | | | | | 7.2.6 | 1386 +--------------+----------------+----------------+--------+---------+ 1387 | MAX_PUSH_ID | Yes | No | No | Section | 1388 | | | | | 7.2.7 | 1389 +--------------+----------------+----------------+--------+---------+ 1390 | Reserved | Yes | Yes | Yes | Section | 1391 | | | | | 7.2.8 | 1392 +--------------+----------------+----------------+--------+---------+ 1394 Table 1: HTTP/3 Frames and Stream Type Overview 1396 Certain frames can only occur as the first frame of a particular 1397 stream type; these are indicated in Table 1 with a (1). Specific 1398 guidance is provided in the relevant section. 1400 Note that, unlike QUIC frames, HTTP/3 frames can span multiple 1401 packets. 1403 7.1. Frame Layout 1405 All frames have the following format: 1407 HTTP/3 Frame Format { 1408 Type (i), 1409 Length (i), 1410 Frame Payload (..), 1411 } 1413 Figure 3: HTTP/3 Frame Format 1415 A frame includes the following fields: 1417 Type: A variable-length integer that identifies the frame type. 1419 Length: A variable-length integer that describes the length in bytes 1420 of the Frame Payload. 1422 Frame Payload: A payload, the semantics of which are determined by 1423 the Type field. 1425 Each frame's payload MUST contain exactly the fields identified in 1426 its description. A frame payload that contains additional bytes 1427 after the identified fields or a frame payload that terminates before 1428 the end of the identified fields MUST be treated as a connection 1429 error (Section 8) of type H3_FRAME_ERROR. 1431 When a stream terminates cleanly, if the last frame on the stream was 1432 truncated, this MUST be treated as a connection error (Section 8) of 1433 type H3_FRAME_ERROR. Streams that terminate abruptly may be reset at 1434 any point in a frame. 1436 7.2. Frame Definitions 1438 7.2.1. DATA 1440 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1441 bytes associated with an HTTP request or response payload body. 1443 DATA frames MUST be associated with an HTTP request or response. If 1444 a DATA frame is received on a control stream, the recipient MUST 1445 respond with a connection error (Section 8) of type 1446 H3_FRAME_UNEXPECTED. 1448 DATA Frame { 1449 Type (i) = 0x0, 1450 Length (i), 1451 Data (..), 1452 } 1454 Figure 4: DATA Frame 1456 7.2.2. HEADERS 1458 The HEADERS frame (type=0x1) is used to carry an HTTP field section, 1459 encoded using QPACK. See [QPACK] for more details. 1461 HEADERS Frame { 1462 Type (i) = 0x1, 1463 Length (i), 1464 Encoded Field Section (..), 1465 } 1467 Figure 5: HEADERS Frame 1469 HEADERS frames can only be sent on request or push streams. If a 1470 HEADERS frame is received on a control stream, the recipient MUST 1471 respond with a connection error (Section 8) of type 1472 H3_FRAME_UNEXPECTED. 1474 7.2.3. CANCEL_PUSH 1476 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a 1477 server push prior to the push stream being received. The CANCEL_PUSH 1478 frame identifies a server push by Push ID (see Section 4.4), encoded 1479 as a variable-length integer. 1481 When a client sends CANCEL_PUSH, it is indicating that it does not 1482 wish to receive the promised resource. The server SHOULD abort 1483 sending the resource, but the mechanism to do so depends on the state 1484 of the corresponding push stream. If the server has not yet created 1485 a push stream, it does not create one. If the push stream is open, 1486 the server SHOULD abruptly terminate that stream. If the push stream 1487 has already ended, the server MAY still abruptly terminate the stream 1488 or MAY take no action. 1490 A server sends CANCEL_PUSH to indicate that it will not be fulfilling 1491 a promise which was previously sent. The client cannot expect the 1492 corresponding promise to be fulfilled, unless it has already received 1493 and processed the promised response. Regardless of whether a push 1494 stream has been opened, a server SHOULD send a CANCEL_PUSH frame when 1495 it determines that promise will not be fulfilled. If a stream has 1496 already been opened, the server can abort sending on the stream with 1497 an error code of H3_REQUEST_CANCELLED. 1499 Sending a CANCEL_PUSH frame has no direct effect on the state of 1500 existing push streams. A client SHOULD NOT send a CANCEL_PUSH frame 1501 when it has already received a corresponding push stream. A push 1502 stream could arrive after a client has sent a CANCEL_PUSH frame, 1503 because a server might not have processed the CANCEL_PUSH. The 1504 client SHOULD abort reading the stream with an error code of 1505 H3_REQUEST_CANCELLED. 1507 A CANCEL_PUSH frame is sent on the control stream. Receiving a 1508 CANCEL_PUSH frame on a stream other than the control stream MUST be 1509 treated as a connection error of type H3_FRAME_UNEXPECTED. 1511 CANCEL_PUSH Frame { 1512 Type (i) = 0x3, 1513 Length (i), 1514 Push ID (..), 1515 } 1517 Figure 6: CANCEL_PUSH Frame 1519 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length 1520 integer. The Push ID identifies the server push that is being 1521 cancelled; see Section 4.4. If a CANCEL_PUSH frame is received that 1522 references a Push ID greater than currently allowed on the 1523 connection, this MUST be treated as a connection error of type 1524 H3_ID_ERROR. 1526 If the client receives a CANCEL_PUSH frame, that frame might identify 1527 a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due 1528 to reordering. If a server receives a CANCEL_PUSH frame for a Push 1529 ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST 1530 be treated as a connection error of type H3_ID_ERROR. 1532 7.2.4. SETTINGS 1534 The SETTINGS frame (type=0x4) conveys configuration parameters that 1535 affect how endpoints communicate, such as preferences and constraints 1536 on peer behavior. Individually, a SETTINGS parameter can also be 1537 referred to as a "setting"; the identifier and value of each setting 1538 parameter can be referred to as a "setting identifier" and a "setting 1539 value". 1541 SETTINGS frames always apply to an entire HTTP/3 connection, never a 1542 single stream. A SETTINGS frame MUST be sent as the first frame of 1543 each control stream (see Section 6.2.1) by each peer, and MUST NOT be 1544 sent subsequently. If an endpoint receives a second SETTINGS frame 1545 on the control stream, the endpoint MUST respond with a connection 1546 error of type H3_FRAME_UNEXPECTED. 1548 SETTINGS frames MUST NOT be sent on any stream other than the control 1549 stream. If an endpoint receives a SETTINGS frame on a different 1550 stream, the endpoint MUST respond with a connection error of type 1551 H3_FRAME_UNEXPECTED. 1553 SETTINGS parameters are not negotiated; they describe characteristics 1554 of the sending peer that can be used by the receiving peer. However, 1555 a negotiation can be implied by the use of SETTINGS - each peer uses 1556 SETTINGS to advertise a set of supported values. The definition of 1557 the setting would describe how each peer combines the two sets to 1558 conclude which choice will be used. SETTINGS does not provide a 1559 mechanism to identify when the choice takes effect. 1561 Different values for the same parameter can be advertised by each 1562 peer. For example, a client might be willing to consume a very large 1563 response field section, while servers are more cautious about request 1564 size. 1566 The same setting identifier MUST NOT occur more than once in the 1567 SETTINGS frame. A receiver MAY treat the presence of duplicate 1568 setting identifiers as a connection error of type H3_SETTINGS_ERROR. 1570 The payload of a SETTINGS frame consists of zero or more parameters. 1571 Each parameter consists of a setting identifier and a value, both 1572 encoded as QUIC variable-length integers. 1574 Setting { 1575 Identifier (i), 1576 Value (i), 1577 } 1579 SETTINGS Frame { 1580 Type (i) = 0x4, 1581 Length (i), 1582 Setting (..) ..., 1583 } 1585 Figure 7: SETTINGS Frame 1587 An implementation MUST ignore the contents for any SETTINGS 1588 identifier it does not understand. 1590 7.2.4.1. Defined SETTINGS Parameters 1592 The following settings are defined in HTTP/3: 1594 SETTINGS_MAX_FIELD_SECTION_SIZE (0x6): The default value is 1595 unlimited. See Section 4.1.1.3 for usage. 1597 Setting identifiers of the format "0x1f * N + 0x21" for non-negative 1598 integer values of N are reserved to exercise the requirement that 1599 unknown identifiers be ignored. Such settings have no defined 1600 meaning. Endpoints SHOULD include at least one such setting in their 1601 SETTINGS frame. Endpoints MUST NOT consider such settings to have 1602 any meaning upon receipt. 1604 Because the setting has no defined meaning, the value of the setting 1605 can be any value the implementation selects. 1607 Setting identifiers which were used in HTTP/2 where there is no 1608 corresponding HTTP/3 setting have also been reserved 1609 (Section 11.2.2). These settings MUST NOT be sent, and their receipt 1610 MUST be treated as a connection error of type H3_SETTINGS_ERROR. 1612 Additional settings can be defined by extensions to HTTP/3; see 1613 Section 9 for more details. 1615 7.2.4.2. Initialization 1617 An HTTP implementation MUST NOT send frames or requests that would be 1618 invalid based on its current understanding of the peer's settings. 1620 All settings begin at an initial value. Each endpoint SHOULD use 1621 these initial values to send messages before the peer's SETTINGS 1622 frame has arrived, as packets carrying the settings can be lost or 1623 delayed. When the SETTINGS frame arrives, any settings are changed 1624 to their new values. 1626 This removes the need to wait for the SETTINGS frame before sending 1627 messages. Endpoints MUST NOT require any data to be received from 1628 the peer prior to sending the SETTINGS frame; settings MUST be sent 1629 as soon as the transport is ready to send data. 1631 For servers, the initial value of each client setting is the default 1632 value. 1634 For clients using a 1-RTT QUIC connection, the initial value of each 1635 server setting is the default value. 1-RTT keys will always become 1636 available prior to the packet containing SETTINGS being processed by 1637 QUIC, even if the server sends SETTINGS immediately. Clients SHOULD 1638 NOT wait indefinitely for SETTINGS to arrive before sending requests, 1639 but SHOULD process received datagrams in order to increase the 1640 likelihood of processing SETTINGS before sending the first request. 1642 When a 0-RTT QUIC connection is being used, the initial value of each 1643 server setting is the value used in the previous session. Clients 1644 SHOULD store the settings the server provided in the HTTP/3 1645 connection where resumption information was provided, but MAY opt not 1646 to store settings in certain cases (e.g., if the session ticket is 1647 received before the SETTINGS frame). A client MUST comply with 1648 stored settings - or default values, if no values are stored - when 1649 attempting 0-RTT. Once a server has provided new settings, clients 1650 MUST comply with those values. 1652 A server can remember the settings that it advertised, or store an 1653 integrity-protected copy of the values in the ticket and recover the 1654 information when accepting 0-RTT data. A server uses the HTTP/3 1655 settings values in determining whether to accept 0-RTT data. If the 1656 server cannot determine that the settings remembered by a client are 1657 compatible with its current settings, it MUST NOT accept 0-RTT data. 1658 Remembered settings are compatible if a client complying with those 1659 settings would not violate the server's current settings. 1661 A server MAY accept 0-RTT and subsequently provide different settings 1662 in its SETTINGS frame. If 0-RTT data is accepted by the server, its 1663 SETTINGS frame MUST NOT reduce any limits or alter any values that 1664 might be violated by the client with its 0-RTT data. The server MUST 1665 include all settings that differ from their default values. If a 1666 server accepts 0-RTT but then sends settings that are not compatible 1667 with the previously specified settings, this MUST be treated as a 1668 connection error of type H3_SETTINGS_ERROR. If a server accepts 1669 0-RTT but then sends a SETTINGS frame that omits a setting value that 1670 the client understands (apart from reserved setting identifiers) that 1671 was previously specified to have a non-default value, this MUST be 1672 treated as a connection error of type H3_SETTINGS_ERROR. 1674 7.2.5. PUSH_PROMISE 1676 The PUSH_PROMISE frame (type=0x5) is used to carry a promised request 1677 header field section from server to client on a request stream, as in 1678 HTTP/2. 1680 PUSH_PROMISE Frame { 1681 Type (i) = 0x5, 1682 Length (i), 1683 Push ID (i), 1684 Encoded Field Section (..), 1685 } 1687 Figure 8: PUSH_PROMISE Frame 1689 The payload consists of: 1691 Push ID: A variable-length integer that identifies the server push 1692 operation. A Push ID is used in push stream headers (Section 4.4) 1693 and CANCEL_PUSH frames (Section 7.2.3). 1695 Encoded Field Section: QPACK-encoded request header fields for the 1696 promised response. See [QPACK] for more details. 1698 A server MUST NOT use a Push ID that is larger than the client has 1699 provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat 1700 receipt of a PUSH_PROMISE frame that contains a larger Push ID than 1701 the client has advertised as a connection error of H3_ID_ERROR. 1703 A server MAY use the same Push ID in multiple PUSH_PROMISE frames. 1704 If so, the decompressed request header sets MUST contain the same 1705 fields in the same order, and both the name and the value in each 1706 field MUST be exact matches. Clients SHOULD compare the request 1707 header sections for resources promised multiple times. If a client 1708 receives a Push ID that has already been promised and detects a 1709 mismatch, it MUST respond with a connection error of type 1710 H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sections match 1711 exactly, the client SHOULD associate the pushed content with each 1712 stream on which a PUSH_PROMISE frame was received. 1714 Allowing duplicate references to the same Push ID is primarily to 1715 reduce duplication caused by concurrent requests. A server SHOULD 1716 avoid reusing a Push ID over a long period. Clients are likely to 1717 consume server push responses and not retain them for reuse over 1718 time. Clients that see a PUSH_PROMISE frame that uses a Push ID that 1719 they have already consumed and discarded are forced to ignore the 1720 promise. 1722 If a PUSH_PROMISE frame is received on the control stream, the client 1723 MUST respond with a connection error (Section 8) of type 1724 H3_FRAME_UNEXPECTED. 1726 A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the 1727 receipt of a PUSH_PROMISE frame as a connection error of type 1728 H3_FRAME_UNEXPECTED. 1730 See Section 4.4 for a description of the overall server push 1731 mechanism. 1733 7.2.6. GOAWAY 1735 The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of 1736 an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint 1737 to stop accepting new requests or pushes while still finishing 1738 processing of previously received requests and pushes. This enables 1739 administrative actions, like server maintenance. GOAWAY by itself 1740 does not close a connection. 1742 GOAWAY Frame { 1743 Type (i) = 0x7, 1744 Length (i), 1745 Stream ID/Push ID (..), 1746 } 1748 Figure 9: GOAWAY Frame 1750 The GOAWAY frame is always sent on the control stream. In the server 1751 to client direction, it carries a QUIC Stream ID for a client- 1752 initiated bidirectional stream encoded as a variable-length integer. 1753 A client MUST treat receipt of a GOAWAY frame containing a Stream ID 1754 of any other type as a connection error of type H3_ID_ERROR. 1756 In the client to server direction, the GOAWAY frame carries a Push ID 1757 encoded as a variable-length integer. 1759 The GOAWAY frame applies to the entire connection, not a specific 1760 stream. A client MUST treat a GOAWAY frame on a stream other than 1761 the control stream as a connection error (Section 8) of type 1762 H3_FRAME_UNEXPECTED. 1764 See Section 5.2 for more information on the use of the GOAWAY frame. 1766 7.2.7. MAX_PUSH_ID 1768 The MAX_PUSH_ID frame (type=0xd) is used by clients to control the 1769 number of server pushes that the server can initiate. This sets the 1770 maximum value for a Push ID that the server can use in PUSH_PROMISE 1771 and CANCEL_PUSH frames. Consequently, this also limits the number of 1772 push streams that the server can initiate in addition to the limit 1773 maintained by the QUIC transport. 1775 The MAX_PUSH_ID frame is always sent on the control stream. Receipt 1776 of a MAX_PUSH_ID frame on any other stream MUST be treated as a 1777 connection error of type H3_FRAME_UNEXPECTED. 1779 A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the 1780 receipt of a MAX_PUSH_ID frame as a connection error of type 1781 H3_FRAME_UNEXPECTED. 1783 The maximum Push ID is unset when an HTTP/3 connection is created, 1784 meaning that a server cannot push until it receives a MAX_PUSH_ID 1785 frame. A client that wishes to manage the number of promised server 1786 pushes can increase the maximum Push ID by sending MAX_PUSH_ID frames 1787 as the server fulfills or cancels server pushes. 1789 MAX_PUSH_ID Frame { 1790 Type (i) = 0xd, 1791 Length (i), 1792 Push ID (i), 1793 } 1795 Figure 10: MAX_PUSH_ID Frame 1797 The MAX_PUSH_ID frame carries a single variable-length integer that 1798 identifies the maximum value for a Push ID that the server can use; 1799 see Section 4.4. A MAX_PUSH_ID frame cannot reduce the maximum Push 1800 ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than 1801 previously received MUST be treated as a connection error of type 1802 H3_ID_ERROR. 1804 7.2.8. Reserved Frame Types 1806 Frame types of the format "0x1f * N + 0x21" for non-negative integer 1807 values of N are reserved to exercise the requirement that unknown 1808 types be ignored (Section 9). These frames have no semantics, and 1809 MAY be sent on any stream where frames are allowed to be sent. This 1810 enables their use for application-layer padding. Endpoints MUST NOT 1811 consider these frames to have any meaning upon receipt. 1813 The payload and length of the frames are selected in any manner the 1814 implementation chooses. 1816 Frame types that were used in HTTP/2 where there is no corresponding 1817 HTTP/3 frame have also been reserved (Section 11.2.1). These frame 1818 types MUST NOT be sent, and their receipt MUST be treated as a 1819 connection error of type H3_FRAME_UNEXPECTED. 1821 8. Error Handling 1823 QUIC allows the application to abruptly terminate (reset) individual 1824 streams or the entire connection; see Sections 2.4 and 5.3 of 1825 [QUIC-TRANSPORT]. These are referred to as "stream errors" or 1826 "connection errors" (see Section 11 of [QUIC-TRANSPORT]) and have 1827 associated error codes, but do not necessarily indicate a problem 1828 with the connection or either implementation. For example, a stream 1829 can be reset if the requested resource is no longer needed. 1831 An endpoint MAY choose to treat a stream error as a connection error 1832 under certain circumstances. Implementations need to consider the 1833 impact on outstanding requests before making this choice. 1835 Because new error codes can be defined without negotiation (see 1836 Section 9), use of an error code in an unexpected context or receipt 1837 of an unknown error code MUST be treated as equivalent to 1838 H3_NO_ERROR. However, closing a stream can have other effects 1839 regardless of the error code; for example, see Section 4.1. 1841 This section describes HTTP/3-specific error codes that can be used 1842 to express the cause of a connection or stream error. 1844 8.1. HTTP/3 Error Codes 1846 The following error codes are defined for use when abruptly 1847 terminating streams, aborting reading of streams, or immediately 1848 closing HTTP/3 connections. 1850 H3_NO_ERROR (0x100): No error. This is used when the connection or 1851 stream needs to be closed, but there is no error to signal. 1853 H3_GENERAL_PROTOCOL_ERROR (0x101): Peer violated protocol 1854 requirements in a way that does not match a more specific error 1855 code, or endpoint declines to use the more specific error code. 1857 H3_INTERNAL_ERROR (0x102): An internal error has occurred in the 1858 HTTP stack. 1860 H3_STREAM_CREATION_ERROR (0x103): The endpoint detected that its 1861 peer created a stream that it will not accept. 1863 H3_CLOSED_CRITICAL_STREAM (0x104): A stream required by the HTTP/3 1864 connection was closed or reset. 1866 H3_FRAME_UNEXPECTED (0x105): A frame was received that was not 1867 permitted in the current state or on the current stream. 1869 H3_FRAME_ERROR (0x106): A frame that fails to satisfy layout 1870 requirements or with an invalid size was received. 1872 H3_EXCESSIVE_LOAD (0x107): The endpoint detected that its peer is 1873 exhibiting a behavior that might be generating excessive load. 1875 H3_ID_ERROR (0x108): A Stream ID or Push ID was used incorrectly, 1876 such as exceeding a limit, reducing a limit, or being reused. 1878 H3_SETTINGS_ERROR (0x109): An endpoint detected an error in the 1879 payload of a SETTINGS frame. 1881 H3_MISSING_SETTINGS (0x10a): No SETTINGS frame was received at the 1882 beginning of the control stream. 1884 H3_REQUEST_REJECTED (0x10b): A server rejected a request without 1885 performing any application processing. 1887 H3_REQUEST_CANCELLED (0x10c): The request or its response (including 1888 pushed response) is cancelled. 1890 H3_REQUEST_INCOMPLETE (0x10d): The client's stream terminated 1891 without containing a fully-formed request. 1893 H3_CONNECT_ERROR (0x10f): The TCP connection established in response 1894 to a CONNECT request was reset or abnormally closed. 1896 H3_VERSION_FALLBACK (0x110): The requested operation cannot be 1897 served over HTTP/3. The peer should retry over HTTP/1.1. 1899 Error codes of the format "0x1f * N + 0x21" for non-negative integer 1900 values of N are reserved to exercise the requirement that unknown 1901 error codes be treated as equivalent to H3_NO_ERROR (Section 9). 1902 Implementations SHOULD select an error code from this space with some 1903 probability when they would have sent H3_NO_ERROR. 1905 9. Extensions to HTTP/3 1907 HTTP/3 permits extension of the protocol. Within the limitations 1908 described in this section, protocol extensions can be used to provide 1909 additional services or alter any aspect of the protocol. Extensions 1910 are effective only within the scope of a single HTTP/3 connection. 1912 This applies to the protocol elements defined in this document. This 1913 does not affect the existing options for extending HTTP, such as 1914 defining new methods, status codes, or fields. 1916 Extensions are permitted to use new frame types (Section 7.2), new 1917 settings (Section 7.2.4.1), new error codes (Section 8), or new 1918 unidirectional stream types (Section 6.2). Registries are 1919 established for managing these extension points: frame types 1920 (Section 11.2.1), settings (Section 11.2.2), error codes 1921 (Section 11.2.3), and stream types (Section 11.2.4). 1923 Implementations MUST ignore unknown or unsupported values in all 1924 extensible protocol elements. Implementations MUST discard frames 1925 and unidirectional streams that have unknown or unsupported types. 1926 This means that any of these extension points can be safely used by 1927 extensions without prior arrangement or negotiation. However, where 1928 a known frame type is required to be in a specific location, such as 1929 the SETTINGS frame as the first frame of the control stream (see 1930 Section 6.2.1), an unknown frame type does not satisfy that 1931 requirement and SHOULD be treated as an error. 1933 Extensions that could change the semantics of existing protocol 1934 components MUST be negotiated before being used. For example, an 1935 extension that changes the layout of the HEADERS frame cannot be used 1936 until the peer has given a positive signal that this is acceptable. 1937 Coordinating when such a revised layout comes into effect could prove 1938 complex. As such, allocating new identifiers for new definitions of 1939 existing protocol elements is likely to be more effective. 1941 This document does not mandate a specific method for negotiating the 1942 use of an extension but notes that a setting (Section 7.2.4.1) could 1943 be used for that purpose. If both peers set a value that indicates 1944 willingness to use the extension, then the extension can be used. If 1945 a setting is used for extension negotiation, the default value MUST 1946 be defined in such a fashion that the extension is disabled if the 1947 setting is omitted. 1949 10. Security Considerations 1951 The security considerations of HTTP/3 should be comparable to those 1952 of HTTP/2 with TLS. However, many of the considerations from 1953 Section 10 of [HTTP2] apply to [QUIC-TRANSPORT] and are discussed in 1954 that document. 1956 10.1. Server Authority 1958 HTTP/3 relies on the HTTP definition of authority. The security 1959 considerations of establishing authority are discussed in 1960 Section 16.1 of [SEMANTICS]. 1962 10.2. Cross-Protocol Attacks 1964 The use of ALPN in the TLS and QUIC handshakes establishes the target 1965 application protocol before application-layer bytes are processed. 1966 Because all QUIC packets are encrypted, it is difficult for an 1967 attacker to control the plaintext bytes of an HTTP/3 connection, 1968 which could be used in a cross-protocol attack on a plaintext 1969 protocol. 1971 10.3. Intermediary Encapsulation Attacks 1973 The HTTP/3 field encoding allows the expression of names that are not 1974 valid field names in the syntax used by HTTP (Section 5.4.3 of 1975 [SEMANTICS]). Requests or responses containing invalid field names 1976 MUST be treated as malformed (Section 4.1.3). An intermediary 1977 therefore cannot translate an HTTP/3 request or response containing 1978 an invalid field name into an HTTP/1.1 message. 1980 Similarly, HTTP/3 can transport field values that are not valid. 1981 While most values that can be encoded will not alter field parsing, 1982 carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the 1983 zero character (NUL, ASCII 0x0) might be exploited by an attacker if 1984 they are translated verbatim. Any request or response that contains 1985 a character not permitted in a field value MUST be treated as 1986 malformed (Section 4.1.3). Valid characters are defined by the 1987 "field-content" ABNF rule in Section 5.4.4 of [SEMANTICS]. 1989 10.4. Cacheability of Pushed Responses 1991 Pushed responses do not have an explicit request from the client; the 1992 request is provided by the server in the PUSH_PROMISE frame. 1994 Caching responses that are pushed is possible based on the guidance 1995 provided by the origin server in the Cache-Control header field. 1996 However, this can cause issues if a single server hosts more than one 1997 tenant. For example, a server might offer multiple users each a 1998 small portion of its URI space. 2000 Where multiple tenants share space on the same server, that server 2001 MUST ensure that tenants are not able to push representations of 2002 resources that they do not have authority over. Failure to enforce 2003 this would allow a tenant to provide a representation that would be 2004 served out of cache, overriding the actual representation that the 2005 authoritative tenant provides. 2007 Clients are required to reject pushed responses for which an origin 2008 server is not authoritative; see Section 4.4. 2010 10.5. Denial-of-Service Considerations 2012 An HTTP/3 connection can demand a greater commitment of resources to 2013 operate than an HTTP/1.1 or HTTP/2 connection. The use of field 2014 compression and flow control depend on a commitment of resources for 2015 storing a greater amount of state. Settings for these features 2016 ensure that memory commitments for these features are strictly 2017 bounded. 2019 The number of PUSH_PROMISE frames is constrained in a similar 2020 fashion. A client that accepts server push SHOULD limit the number 2021 of Push IDs it issues at a time. 2023 Processing capacity cannot be guarded as effectively as state 2024 capacity. 2026 The ability to send undefined protocol elements that the peer is 2027 required to ignore can be abused to cause a peer to expend additional 2028 processing time. This might be done by setting multiple undefined 2029 SETTINGS parameters, unknown frame types, or unknown stream types. 2030 Note, however, that some uses are entirely legitimate, such as 2031 optional-to-understand extensions and padding to increase resistance 2032 to traffic analysis. 2034 Compression of field sections also offers some opportunities to waste 2035 processing resources; see Section 7 of [QPACK] for more details on 2036 potential abuses. 2038 All these features - i.e., server push, unknown protocol elements, 2039 field compression - have legitimate uses. These features become a 2040 burden only when they are used unnecessarily or to excess. 2042 An endpoint that does not monitor this behavior exposes itself to a 2043 risk of denial-of-service attack. Implementations SHOULD track the 2044 use of these features and set limits on their use. An endpoint MAY 2045 treat activity that is suspicious as a connection error (Section 8) 2046 of type H3_EXCESSIVE_LOAD, but false positives will result in 2047 disrupting valid connections and requests. 2049 10.5.1. Limits on Field Section Size 2051 A large field section (Section 4.1) can cause an implementation to 2052 commit a large amount of state. Header fields that are critical for 2053 routing can appear toward the end of a header field section, which 2054 prevents streaming of the header field section to its ultimate 2055 destination. This ordering and other reasons, such as ensuring cache 2056 correctness, mean that an endpoint likely needs to buffer the entire 2057 header field section. Since there is no hard limit to the size of a 2058 field section, some endpoints could be forced to commit a large 2059 amount of available memory for header fields. 2061 An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE 2062 (Section 4.1.1.3) setting to advise peers of limits that might apply 2063 on the size of field sections. This setting is only advisory, so 2064 endpoints MAY choose to send field sections that exceed this limit 2065 and risk having the request or response being treated as malformed. 2066 This setting is specific to an HTTP/3 connection, so any request or 2067 response could encounter a hop with a lower, unknown limit. An 2068 intermediary can attempt to avoid this problem by passing on values 2069 presented by different peers, but they are not obligated to do so. 2071 A server that receives a larger field section than it is willing to 2072 handle can send an HTTP 431 (Request Header Fields Too Large) status 2073 code ([RFC6585]). A client can discard responses that it cannot 2074 process. 2076 10.5.2. CONNECT Issues 2078 The CONNECT method can be used to create disproportionate load on a 2079 proxy, since stream creation is relatively inexpensive when compared 2080 to the creation and maintenance of a TCP connection. A proxy might 2081 also maintain some resources for a TCP connection beyond the closing 2082 of the stream that carries the CONNECT request, since the outgoing 2083 TCP connection remains in the TIME_WAIT state. Therefore, a proxy 2084 cannot rely on QUIC stream limits alone to control the resources 2085 consumed by CONNECT requests. 2087 10.6. Use of Compression 2089 Compression can allow an attacker to recover secret data when it is 2090 compressed in the same context as data under attacker control. 2091 HTTP/3 enables compression of fields (Section 4.1.1); the following 2092 concerns also apply to the use of HTTP compressed content-codings; 2093 see Section 7.5.1 of [SEMANTICS]. 2095 There are demonstrable attacks on compression that exploit the 2096 characteristics of the web (e.g., [BREACH]). The attacker induces 2097 multiple requests containing varying plaintext, observing the length 2098 of the resulting ciphertext in each, which reveals a shorter length 2099 when a guess about the secret is correct. 2101 Implementations communicating on a secure channel MUST NOT compress 2102 content that includes both confidential and attacker-controlled data 2103 unless separate compression contexts are used for each source of 2104 data. Compression MUST NOT be used if the source of data cannot be 2105 reliably determined. 2107 Further considerations regarding the compression of fields sections 2108 are described in [QPACK]. 2110 10.7. Padding and Traffic Analysis 2112 Padding can be used to obscure the exact size of frame content and is 2113 provided to mitigate specific attacks within HTTP, for example, 2114 attacks where compressed content includes both attacker-controlled 2115 plaintext and secret data (e.g., [BREACH]). 2117 Where HTTP/2 employs PADDING frames and Padding fields in other 2118 frames to make a connection more resistant to traffic analysis, 2119 HTTP/3 can either rely on transport-layer padding or employ the 2120 reserved frame and stream types discussed in Section 7.2.8 and 2121 Section 6.2.3. These methods of padding produce different results in 2122 terms of the granularity of padding, how padding is arranged in 2123 relation to the information that is being protected, whether padding 2124 is applied in the case of packet loss, and how an implementation 2125 might control padding. 2127 Reserved stream types can be used to give the appearance of sending 2128 traffic even when the connection is idle. Because HTTP traffic often 2129 occurs in bursts, apparent traffic can be used to obscure the timing 2130 or duration of such bursts, even to the point of appearing to send a 2131 constant stream of data. However, as such traffic is still flow 2132 controlled by the receiver, a failure to promptly drain such streams 2133 and provide additional flow control credit can limit the sender's 2134 ability to send real traffic. 2136 To mitigate attacks that rely on compression, disabling or limiting 2137 compression might be preferable to padding as a countermeasure. 2139 Use of padding can result in less protection than might seem 2140 immediately obvious. Redundant padding could even be 2141 counterproductive. At best, padding only makes it more difficult for 2142 an attacker to infer length information by increasing the number of 2143 frames an attacker has to observe. Incorrectly implemented padding 2144 schemes can be easily defeated. In particular, randomized padding 2145 with a predictable distribution provides very little protection; 2146 similarly, padding payloads to a fixed size exposes information as 2147 payload sizes cross the fixed-sized boundary, which could be possible 2148 if an attacker can control plaintext. 2150 10.8. Frame Parsing 2152 Several protocol elements contain nested length elements, typically 2153 in the form of frames with an explicit length containing variable- 2154 length integers. This could pose a security risk to an incautious 2155 implementer. An implementation MUST ensure that the length of a 2156 frame exactly matches the length of the fields it contains. 2158 10.9. Early Data 2160 The use of 0-RTT with HTTP/3 creates an exposure to replay attack. 2161 The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when 2162 using HTTP/3 with 0-RTT. 2164 10.10. Migration 2166 Certain HTTP implementations use the client address for logging or 2167 access-control purposes. Since a QUIC client's address might change 2168 during a connection (and future versions might support simultaneous 2169 use of multiple addresses), such implementations will need to either 2170 actively retrieve the client's current address or addresses when they 2171 are relevant or explicitly accept that the original address might 2172 change. 2174 10.11. Privacy Considerations 2176 Several characteristics of HTTP/3 provide an observer an opportunity 2177 to correlate actions of a single client or server over time. These 2178 include the value of settings, the timing of reactions to stimulus, 2179 and the handling of any features that are controlled by settings. 2181 As far as these create observable differences in behavior, they could 2182 be used as a basis for fingerprinting a specific client. 2184 HTTP/3's preference for using a single QUIC connection allows 2185 correlation of a user's activity on a site. Reusing connections for 2186 different origins allows for correlation of activity across those 2187 origins. 2189 Several features of QUIC solicit immediate responses and can be used 2190 by an endpoint to measure latency to their peer; this might have 2191 privacy implications in certain scenarios. 2193 11. IANA Considerations 2195 This document registers a new ALPN protocol ID (Section 11.1) and 2196 creates new registries that manage the assignment of codepoints in 2197 HTTP/3. 2199 11.1. Registration of HTTP/3 Identification String 2201 This document creates a new registration for the identification of 2202 HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol 2203 IDs" registry established in [RFC7301]. 2205 The "h3" string identifies HTTP/3: 2207 Protocol: HTTP/3 2209 Identification Sequence: 0x68 0x33 ("h3") 2211 Specification: This document 2213 11.2. New Registries 2215 New registries created in this document operate under the QUIC 2216 registration policy documented in Section 22.1 of [QUIC-TRANSPORT]. 2217 These registries all include the common set of fields listed in 2218 Section 22.1.1 of [QUIC-TRANSPORT]. 2220 The initial allocations in these registries created in this document 2221 are all assigned permanent status and list a change controller of the 2222 IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). 2224 11.2.1. Frame Types 2226 This document establishes a registry for HTTP/3 frame type codes. 2227 The "HTTP/3 Frame Type" registry governs a 62-bit space. This 2228 registry follows the QUIC registry policy; see Section 11.2. 2229 Permanent registrations in this registry are assigned using the 2230 Specification Required policy ([RFC8126]), except for values between 2231 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 2232 Standards Action or IESG Approval as defined in Section 4.9 and 4.10 2233 of [RFC8126]. 2235 While this registry is separate from the "HTTP/2 Frame Type" registry 2236 defined in [HTTP2], it is preferable that the assignments parallel 2237 each other where the code spaces overlap. If an entry is present in 2238 only one registry, every effort SHOULD be made to avoid assigning the 2239 corresponding value to an unrelated operation. 2241 In addition to common fields as described in Section 11.2, permanent 2242 registrations in this registry MUST include the following field: 2244 Frame Type: A name or label for the frame type. 2246 Specifications of frame types MUST include a description of the frame 2247 layout and its semantics, including any parts of the frame that are 2248 conditionally present. 2250 The entries in Table 2 are registered by this document. 2252 +==============+=======+===============+ 2253 | Frame Type | Value | Specification | 2254 +==============+=======+===============+ 2255 | DATA | 0x0 | Section 7.2.1 | 2256 +--------------+-------+---------------+ 2257 | HEADERS | 0x1 | Section 7.2.2 | 2258 +--------------+-------+---------------+ 2259 | Reserved | 0x2 | N/A | 2260 +--------------+-------+---------------+ 2261 | CANCEL_PUSH | 0x3 | Section 7.2.3 | 2262 +--------------+-------+---------------+ 2263 | SETTINGS | 0x4 | Section 7.2.4 | 2264 +--------------+-------+---------------+ 2265 | PUSH_PROMISE | 0x5 | Section 7.2.5 | 2266 +--------------+-------+---------------+ 2267 | Reserved | 0x6 | N/A | 2268 +--------------+-------+---------------+ 2269 | GOAWAY | 0x7 | Section 7.2.6 | 2270 +--------------+-------+---------------+ 2271 | Reserved | 0x8 | N/A | 2272 +--------------+-------+---------------+ 2273 | Reserved | 0x9 | N/A | 2274 +--------------+-------+---------------+ 2275 | MAX_PUSH_ID | 0xd | Section 7.2.7 | 2276 +--------------+-------+---------------+ 2278 Table 2: Initial HTTP/3 Frame Types 2280 Additionally, each code of the format "0x1f * N + 0x21" for non- 2281 negative integer values of N (that is, 0x21, 0x40, ..., through 2282 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA. 2284 11.2.2. Settings Parameters 2286 This document establishes a registry for HTTP/3 settings. The 2287 "HTTP/3 Settings" registry governs a 62-bit space. This registry 2288 follows the QUIC registry policy; see Section 11.2. Permanent 2289 registrations in this registry are assigned using the Specification 2290 Required policy ([RFC8126]), except for values between 0x00 and 0x3f 2291 (in hexadecimal; inclusive), which are assigned using Standards 2292 Action or IESG Approval as defined in Section 4.9 and 4.10 of 2293 [RFC8126]. 2295 While this registry is separate from the "HTTP/2 Settings" registry 2296 defined in [HTTP2], it is preferable that the assignments parallel 2297 each other. If an entry is present in only one registry, every 2298 effort SHOULD be made to avoid assigning the corresponding value to 2299 an unrelated operation. 2301 In addition to common fields as described in Section 11.2, permanent 2302 registrations in this registry MUST include the following fields: 2304 Setting Name: A symbolic name for the setting. Specifying a setting 2305 name is optional. 2307 Default: The value of the setting unless otherwise indicated. A 2308 default SHOULD be the most restrictive possible value. 2310 The entries in Table 3 are registered by this document. 2312 +========================+=======+=================+===========+ 2313 | Setting Name | Value | Specification | Default | 2314 +========================+=======+=================+===========+ 2315 | Reserved | 0x2 | N/A | N/A | 2316 +------------------------+-------+-----------------+-----------+ 2317 | Reserved | 0x3 | N/A | N/A | 2318 +------------------------+-------+-----------------+-----------+ 2319 | Reserved | 0x4 | N/A | N/A | 2320 +------------------------+-------+-----------------+-----------+ 2321 | Reserved | 0x5 | N/A | N/A | 2322 +------------------------+-------+-----------------+-----------+ 2323 | MAX_FIELD_SECTION_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | 2324 +------------------------+-------+-----------------+-----------+ 2326 Table 3: Initial HTTP/3 Settings 2328 Additionally, each code of the format "0x1f * N + 0x21" for non- 2329 negative integer values of N (that is, 0x21, 0x40, ..., through 2330 0x3ffffffffffffffe) MUST NOT be assigned by IANA. 2332 11.2.3. Error Codes 2334 This document establishes a registry for HTTP/3 error codes. The 2335 "HTTP/3 Error Code" registry manages a 62-bit space. This registry 2336 follows the QUIC registry policy; see Section 11.2. Permanent 2337 registrations in this registry are assigned using the Specification 2338 Required policy ([RFC8126]), except for values between 0x00 and 0x3f 2339 (in hexadecimal; inclusive), which are assigned using Standards 2340 Action or IESG Approval as defined in Section 4.9 and 4.10 of 2341 [RFC8126]. 2343 Registrations for error codes are required to include a description 2344 of the error code. An expert reviewer is advised to examine new 2345 registrations for possible duplication with existing error codes. 2346 Use of existing registrations is to be encouraged, but not mandated. 2347 Use of values that are registered in the "HTTP/2 Error Code" registry 2348 is discouraged. 2350 In addition to common fields as described in Section 11.2, this 2351 registry includes two additional fields. Permanent registrations in 2352 this registry MUST include the following field: 2354 Name: A name for the error code. 2356 Description: A brief description of the error code semantics. 2358 The entries in Table 4 are registered by this document. These error 2359 codes were selected from the range that operates on a Specification 2360 Required policy to avoid collisions with HTTP/2 error codes. 2362 +===========================+========+==============+===============+ 2363 | Name | Value | Description | Specification | 2364 +===========================+========+==============+===============+ 2365 | H3_NO_ERROR | 0x0100 | No error | Section 8.1 | 2366 +---------------------------+--------+--------------+---------------+ 2367 | H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | Section 8.1 | 2368 | | | protocol | | 2369 | | | error | | 2370 +---------------------------+--------+--------------+---------------+ 2371 | H3_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 | 2372 | | | error | | 2373 +---------------------------+--------+--------------+---------------+ 2374 | H3_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 | 2375 | | | creation | | 2376 | | | error | | 2377 +---------------------------+--------+--------------+---------------+ 2378 | H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | Section 8.1 | 2379 | | | stream was | | 2380 | | | closed | | 2381 +---------------------------+--------+--------------+---------------+ 2382 | H3_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 | 2383 | | | permitted | | 2384 | | | in the | | 2385 | | | current | | 2386 | | | state | | 2387 +---------------------------+--------+--------------+---------------+ 2388 | H3_FRAME_ERROR | 0x0106 | Frame | Section 8.1 | 2389 | | | violated | | 2390 | | | layout or | | 2391 | | | size rules | | 2392 +---------------------------+--------+--------------+---------------+ 2393 | H3_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 | 2394 | | | generating | | 2395 | | | excessive | | 2396 | | | load | | 2397 +---------------------------+--------+--------------+---------------+ 2398 | H3_ID_ERROR | 0x0108 | An | Section 8.1 | 2399 | | | identifier | | 2400 | | | was used | | 2401 | | | incorrectly | | 2402 +---------------------------+--------+--------------+---------------+ 2403 | H3_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 | 2404 | | | frame | | 2405 | | | contained | | 2406 | | | invalid | | 2407 | | | values | | 2408 +---------------------------+--------+--------------+---------------+ 2409 | H3_MISSING_SETTINGS | 0x010a | No SETTINGS | Section 8.1 | 2410 | | | frame | | 2411 | | | received | | 2412 +---------------------------+--------+--------------+---------------+ 2413 | H3_REQUEST_REJECTED | 0x010b | Request not | Section 8.1 | 2414 | | | processed | | 2415 +---------------------------+--------+--------------+---------------+ 2416 | H3_REQUEST_CANCELLED | 0x010c | Data no | Section 8.1 | 2417 | | | longer | | 2418 | | | needed | | 2419 +---------------------------+--------+--------------+---------------+ 2420 | H3_REQUEST_INCOMPLETE | 0x010d | Stream | Section 8.1 | 2421 | | | terminated | | 2422 | | | early | | 2423 +---------------------------+--------+--------------+---------------+ 2424 | H3_CONNECT_ERROR | 0x010f | TCP reset | Section 8.1 | 2425 | | | or error on | | 2426 | | | CONNECT | | 2427 | | | request | | 2428 +---------------------------+--------+--------------+---------------+ 2429 | H3_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 | 2430 | | | HTTP/1.1 | | 2431 +---------------------------+--------+--------------+---------------+ 2433 Table 4: Initial HTTP/3 Error Codes 2435 Additionally, each code of the format "0x1f * N + 0x21" for non- 2436 negative integer values of N (that is, 0x21, 0x40, ..., through 2437 0x3ffffffffffffffe) MUST NOT be assigned by IANA. 2439 11.2.4. Stream Types 2441 This document establishes a registry for HTTP/3 unidirectional stream 2442 types. The "HTTP/3 Stream Type" registry governs a 62-bit space. 2443 This registry follows the QUIC registry policy; see Section 11.2. 2444 Permanent registrations in this registry are assigned using the 2445 Specification Required policy ([RFC8126]), except for values between 2446 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 2447 Standards Action or IESG Approval as defined in Section 4.9 and 4.10 2448 of [RFC8126]. 2450 In addition to common fields as described in Section 11.2, permanent 2451 registrations in this registry MUST include the following fields: 2453 Stream Type: A name or label for the stream type. 2455 Sender: Which endpoint on an HTTP/3 connection may initiate a stream 2456 of this type. Values are "Client", "Server", or "Both". 2458 Specifications for permanent registrations MUST include a description 2459 of the stream type, including the layout and semantics of the stream 2460 contents. 2462 The entries in the following table are registered by this document. 2464 +================+=======+===============+========+ 2465 | Stream Type | Value | Specification | Sender | 2466 +================+=======+===============+========+ 2467 | Control Stream | 0x00 | Section 6.2.1 | Both | 2468 +----------------+-------+---------------+--------+ 2469 | Push Stream | 0x01 | Section 4.4 | Server | 2470 +----------------+-------+---------------+--------+ 2472 Table 5 2474 Additionally, each code of the format "0x1f * N + 0x21" for non- 2475 negative integer values of N (that is, 0x21, 0x40, ..., through 2476 0x3ffffffffffffffe) MUST NOT be assigned by IANA. 2478 12. References 2480 12.1. Normative References 2482 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2483 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2484 April 2016, . 2486 [CACHING] Fielding, R., Nottingham, M., and J. Reschke, "HTTP 2487 Caching", Work in Progress, Internet-Draft, draft-ietf- 2488 httpbis-cache-12, 2 October 2020, . 2491 [HTTP-REPLAY] 2492 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 2493 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2494 2018, . 2496 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: 2497 Header Compression for HTTP over QUIC", Work in Progress, 2498 Internet-Draft, draft-ietf-quic-qpack-19, 20 October 2020, 2499 . 2501 [QUIC-TRANSPORT] 2502 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2503 Multiplexed and Secure Transport", Work in Progress, 2504 Internet-Draft, draft-ietf-quic-transport-31, 20 October 2505 2020, . 2508 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2509 RFC 793, DOI 10.17487/RFC0793, September 1981, 2510 . 2512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2513 Requirement Levels", BCP 14, RFC 2119, 2514 DOI 10.17487/RFC2119, March 1997, 2515 . 2517 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2518 Extensions: Extension Definitions", RFC 6066, 2519 DOI 10.17487/RFC6066, January 2011, 2520 . 2522 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2523 Verification of Domain-Based Application Service Identity 2524 within Internet Public Key Infrastructure Using X.509 2525 (PKIX) Certificates in the Context of Transport Layer 2526 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2527 2011, . 2529 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2530 DOI 10.17487/RFC6265, April 2011, 2531 . 2533 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2534 "Transport Layer Security (TLS) Application-Layer Protocol 2535 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2536 July 2014, . 2538 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2539 Writing an IANA Considerations Section in RFCs", BCP 26, 2540 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2541 . 2543 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2544 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2545 May 2017, . 2547 [SEMANTICS] 2548 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 2549 Semantics", Work in Progress, Internet-Draft, draft-ietf- 2550 httpbis-semantics-12, 2 October 2020, 2551 . 2554 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2555 Resource Identifier (URI): Generic Syntax", STD 66, 2556 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2557 . 2559 12.2. Informative References 2561 [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the 2562 CRIME Attack", July 2013, 2563 . 2566 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 2567 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 2568 . 2570 [HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1 2571 Messaging", Work in Progress, Internet-Draft, draft-ietf- 2572 httpbis-messaging-12, 2 October 2020, 2573 . 2576 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2577 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2578 DOI 10.17487/RFC7540, May 2015, 2579 . 2581 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 2582 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 2583 . 2585 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 2586 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 2587 . 2589 [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2590 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2591 . 2593 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2594 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2595 . 2597 Appendix A. Considerations for Transitioning from HTTP/2 2599 HTTP/3 is strongly informed by HTTP/2, and bears many similarities. 2600 This section describes the approach taken to design HTTP/3, points 2601 out important differences from HTTP/2, and describes how to map 2602 HTTP/2 extensions into HTTP/3. 2604 HTTP/3 begins from the premise that similarity to HTTP/2 is 2605 preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 2606 where QUIC differs from TCP, either to take advantage of QUIC 2607 features (like streams) or to accommodate important shortcomings 2608 (such as a lack of total ordering). These differences make HTTP/3 2609 similar to HTTP/2 in key aspects, such as the relationship of 2610 requests and responses to streams. However, the details of the 2611 HTTP/3 design are substantially different from HTTP/2. 2613 These departures are noted in this section. 2615 A.1. Streams 2617 HTTP/3 permits use of a larger number of streams (2^62-1) than 2618 HTTP/2. The same considerations about exhaustion of stream 2619 identifier space apply, though the space is significantly larger such 2620 that it is likely that other limits in QUIC are reached first, such 2621 as the limit on the connection flow control window. 2623 In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by 2624 QUIC. QUIC considers a stream closed when all data has been received 2625 and sent data has been acknowledged by the peer. HTTP/2 considers a 2626 stream closed when the frame containing the END_STREAM bit has been 2627 committed to the transport. As a result, the stream for an 2628 equivalent exchange could remain "active" for a longer period of 2629 time. HTTP/3 servers might choose to permit a larger number of 2630 concurrent client-initiated bidirectional streams to achieve 2631 equivalent concurrency to HTTP/2, depending on the expected usage 2632 patterns. 2634 Due to the presence of other unidirectional stream types, HTTP/3 does 2635 not rely exclusively on the number of concurrent unidirectional 2636 streams to control the number of concurrent in-flight pushes. 2637 Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the 2638 number of pushes received from an HTTP/3 server. 2640 A.2. HTTP Frame Types 2642 Many framing concepts from HTTP/2 can be elided on QUIC, because the 2643 transport deals with them. Because frames are already on a stream, 2644 they can omit the stream number. Because frames do not block 2645 multiplexing (QUIC's multiplexing occurs below this layer), the 2646 support for variable-maximum-length packets can be removed. Because 2647 stream termination is handled by QUIC, an END_STREAM flag is not 2648 required. This permits the removal of the Flags field from the 2649 generic frame layout. 2651 Frame payloads are largely drawn from [HTTP2]. However, QUIC 2652 includes many features (e.g., flow control) that are also present in 2653 HTTP/2. In these cases, the HTTP mapping does not re-implement them. 2654 As a result, several HTTP/2 frame types are not required in HTTP/3. 2655 Where an HTTP/2-defined frame is no longer used, the frame ID has 2656 been reserved in order to maximize portability between HTTP/2 and 2657 HTTP/3 implementations. However, even equivalent frames between the 2658 two mappings are not identical. 2660 Many of the differences arise from the fact that HTTP/2 provides an 2661 absolute ordering between frames across all streams, while QUIC 2662 provides this guarantee on each stream only. As a result, if a frame 2663 type makes assumptions that frames from different streams will still 2664 be received in the order sent, HTTP/3 will break them. 2666 Some examples of feature adaptations are described below, as well as 2667 general guidance to extension frame implementors converting an HTTP/2 2668 extension to HTTP/3. 2670 A.2.1. Prioritization Differences 2672 HTTP/2 specifies priority assignments in PRIORITY frames and 2673 (optionally) in HEADERS frames. HTTP/3 does not provide a means of 2674 signaling priority. 2676 Note that while there is no explicit signaling for priority, this 2677 does not mean that prioritization is not important for achieving good 2678 performance. 2680 A.2.2. Field Compression Differences 2682 HPACK was designed with the assumption of in-order delivery. A 2683 sequence of encoded field sections must arrive (and be decoded) at an 2684 endpoint in the same order in which they were encoded. This ensures 2685 that the dynamic state at the two endpoints remains in sync. 2687 Because this total ordering is not provided by QUIC, HTTP/3 uses a 2688 modified version of HPACK, called QPACK. QPACK uses a single 2689 unidirectional stream to make all modifications to the dynamic table, 2690 ensuring a total order of updates. All frames that contain encoded 2691 fields merely reference the table state at a given time without 2692 modifying it. 2694 [QPACK] provides additional details. 2696 A.2.3. Flow Control Differences 2698 HTTP/2 specifies a stream flow control mechanism. Although all 2699 HTTP/2 frames are delivered on streams, only the DATA frame payload 2700 is subject to flow control. QUIC provides flow control for stream 2701 data and all HTTP/3 frame types defined in this document are sent on 2702 streams. Therefore, all frame headers and payload are subject to 2703 flow control. 2705 A.2.4. Guidance for New Frame Type Definitions 2707 Frame type definitions in HTTP/3 often use the QUIC variable-length 2708 integer encoding. In particular, Stream IDs use this encoding, which 2709 allows for a larger range of possible values than the encoding used 2710 in HTTP/2. Some frames in HTTP/3 use an identifier rather than a 2711 Stream ID (e.g., Push IDs). Redefinition of the encoding of 2712 extension frame types might be necessary if the encoding includes a 2713 Stream ID. 2715 Because the Flags field is not present in generic HTTP/3 frames, 2716 those frames that depend on the presence of flags need to allocate 2717 space for flags as part of their frame payload. 2719 Other than these issues, frame type HTTP/2 extensions are typically 2720 portable to QUIC simply by replacing Stream 0 in HTTP/2 with a 2721 control stream in HTTP/3. HTTP/3 extensions will not assume 2722 ordering, but would not be harmed by ordering, and would be portable 2723 to HTTP/2 in the same manner. 2725 A.2.5. Mapping Between HTTP/2 and HTTP/3 Frame Types 2727 DATA (0x0): Padding is not defined in HTTP/3 frames. See 2728 Section 7.2.1. 2730 HEADERS (0x1): The PRIORITY region of HEADERS is not defined in 2731 HTTP/3 frames. Padding is not defined in HTTP/3 frames. See 2732 Section 7.2.2. 2734 PRIORITY (0x2): As described in Appendix A.2.1, HTTP/3 does not 2735 provide a means of signaling priority. 2737 RST_STREAM (0x3): RST_STREAM frames do not exist in HTTP/3, since 2738 QUIC provides stream lifecycle management. The same code point is 2739 used for the CANCEL_PUSH frame (Section 7.2.3). 2741 SETTINGS (0x4): SETTINGS frames are sent only at the beginning of 2742 the connection. See Section 7.2.4 and Appendix A.3. 2744 PUSH_PROMISE (0x5): The PUSH_PROMISE frame does not reference a 2745 stream; instead the push stream references the PUSH_PROMISE frame 2746 using a Push ID. See Section 7.2.5. 2748 PING (0x6): PING frames do not exist in HTTP/3, as QUIC provides 2749 equivalent functionality. 2751 GOAWAY (0x7): GOAWAY does not contain an error code. In the client 2752 to server direction, it carries a Push ID instead of a server 2753 initiated stream ID. See Section 7.2.6. 2755 WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist in HTTP/3, 2756 since QUIC provides flow control. 2758 CONTINUATION (0x9): CONTINUATION frames do not exist in HTTP/3; 2759 instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are 2760 permitted. 2762 Frame types defined by extensions to HTTP/2 need to be separately 2763 registered for HTTP/3 if still applicable. The IDs of frames defined 2764 in [HTTP2] have been reserved for simplicity. Note that the frame 2765 type space in HTTP/3 is substantially larger (62 bits versus 8 bits), 2766 so many HTTP/3 frame types have no equivalent HTTP/2 code points. 2767 See Section 11.2.1. 2769 A.3. HTTP/2 SETTINGS Parameters 2771 An important difference from HTTP/2 is that settings are sent once, 2772 as the first frame of the control stream, and thereafter cannot 2773 change. This eliminates many corner cases around synchronization of 2774 changes. 2776 Some transport-level options that HTTP/2 specifies via the SETTINGS 2777 frame are superseded by QUIC transport parameters in HTTP/3. The 2778 HTTP-level options that are retained in HTTP/3 have the same value as 2779 in HTTP/2. The superseded settings are reserved, and their receipt 2780 is an error. See Section 7.2.4.1 for discussion of both the retained 2781 and reserved values. 2783 Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: 2785 SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. 2787 SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID 2788 frame, which provides a more granular control over server push. 2789 Specifying a setting with the identifier 0x2 (corresponding to the 2790 SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame is an 2791 error. 2793 SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open 2794 Stream ID as part of its flow control logic. Specifying a setting 2795 with the identifier 0x3 (corresponding to the 2796 SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS 2797 frame is an error. 2799 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 2800 connection flow control window sizes to be specified in the 2801 initial transport handshake. Specifying a setting with the 2802 identifier 0x4 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE 2803 parameter) in the HTTP/3 SETTINGS frame is an error. 2805 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. 2806 Specifying a setting with the identifier 0x5 (corresponding to the 2807 SETTINGS_MAX_FRAME_SIZE parameter) in the HTTP/3 SETTINGS frame is 2808 an error. 2810 SETTINGS_MAX_HEADER_LIST_SIZE: This setting identifier has been 2811 renamed SETTINGS_MAX_FIELD_SECTION_SIZE. 2813 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 2814 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 2815 This will often produce a shorter encoding, but can produce a longer 2816 encoding for settings that use the full 32-bit space. Settings 2817 ported from HTTP/2 might choose to redefine their value to limit it 2818 to 30 bits for more efficient encoding, or to make use of the 62-bit 2819 space if more than 30 bits are required. 2821 Settings need to be defined separately for HTTP/2 and HTTP/3. The 2822 IDs of settings defined in [HTTP2] have been reserved for simplicity. 2823 Note that the settings identifier space in HTTP/3 is substantially 2824 larger (62 bits versus 16 bits), so many HTTP/3 settings have no 2825 equivalent HTTP/2 code point. See Section 11.2.2. 2827 As QUIC streams might arrive out of order, endpoints are advised not 2828 to wait for the peers' settings to arrive before responding to other 2829 streams. See Section 7.2.4.2. 2831 A.4. HTTP/2 Error Codes 2833 QUIC has the same concepts of "stream" and "connection" errors that 2834 HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 2835 mean that error codes are not directly portable between versions. 2837 The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map 2838 to the HTTP/3 error codes as follows: 2840 NO_ERROR (0x0): H3_NO_ERROR in Section 8.1. 2842 PROTOCOL_ERROR (0x1): This is mapped to H3_GENERAL_PROTOCOL_ERROR 2843 except in cases where more specific error codes have been defined. 2844 Such cases include H3_FRAME_UNEXPECTED and 2845 H3_CLOSED_CRITICAL_STREAM defined in Section 8.1. 2847 INTERNAL_ERROR (0x2): H3_INTERNAL_ERROR in Section 8.1. 2849 FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow 2850 control. 2852 SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of 2853 SETTINGS is defined. 2855 STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream 2856 management. 2858 FRAME_SIZE_ERROR (0x6): H3_FRAME_ERROR error code defined in 2859 Section 8.1. 2861 REFUSED_STREAM (0x7): H3_REQUEST_REJECTED (in Section 8.1) is used 2862 to indicate that a request was not processed. Otherwise, not 2863 applicable because QUIC handles stream management. 2865 CANCEL (0x8): H3_REQUEST_CANCELLED in Section 8.1. 2867 COMPRESSION_ERROR (0x9): Multiple error codes are defined in 2868 [QPACK]. 2870 CONNECT_ERROR (0xa): H3_CONNECT_ERROR in Section 8.1. 2872 ENHANCE_YOUR_CALM (0xb): H3_EXCESSIVE_LOAD in Section 8.1. 2874 INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to 2875 provide sufficient security on all connections. 2877 HTTP_1_1_REQUIRED (0xd): H3_VERSION_FALLBACK in Section 8.1. 2879 Error codes need to be defined for HTTP/2 and HTTP/3 separately. See 2880 Section 11.2.3. 2882 A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors 2884 An intermediary that converts between HTTP/2 and HTTP/3 may encounter 2885 error conditions from either upstream. It is useful to communicate 2886 the occurrence of error to the downstream but error codes largely 2887 reflect connection-local problems that generally do not make sense to 2888 propagate. 2890 An intermediary that encounters an error from an upstream origin can 2891 indicate this by sending an HTTP status code such as 502, which is 2892 suitable for a broad class of errors. 2894 There are some rare cases where it is beneficial to propagate the 2895 error by mapping it to the closest matching error type to the 2896 receiver. For example, an intermediary that receives an HTTP/2 2897 stream error of type REFUSED_STREAM from the origin has a clear 2898 signal that the request was not processed and that the request is 2899 safe to retry. Propagating this error condition to the client as an 2900 HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to 2901 take the action it deems most appropriate. In the reverse direction, 2902 the intermediary might deem it beneficial to pass on client request 2903 cancellations that are indicated by terminating a stream with 2904 H3_REQUEST_CANCELLED; see Section 4.1.2. 2906 Conversion between errors is described in the logical mapping. The 2907 error codes are defined in non-overlapping spaces in order to protect 2908 against accidental conversion that could result in the use of 2909 inappropriate or unknown error codes for the target version. An 2910 intermediary is permitted to promote stream errors to connection 2911 errors but they should be aware of the cost to the HTTP/3 connection 2912 for what might be a temporary or intermittent error. 2914 Appendix B. Change Log 2916 *RFC Editor's Note:* Please remove this section prior to 2917 publication of a final version of this document. 2919 B.1. Since draft-ietf-quic-http-31 2921 Editorial changes only. 2923 B.2. Since draft-ietf-quic-http-30 2925 Editorial changes only. 2927 B.3. Since draft-ietf-quic-http-29 2929 * Require a connection error if a reserved frame type that 2930 corresponds to a frame in HTTP/2 is received (#3991, #3993) 2932 * Require a connection error if a reserved setting that corresponds 2933 to a setting in HTTP/2 is received (#3954, #3955) 2935 B.4. Since draft-ietf-quic-http-28 2936 * CANCEL_PUSH is recommended even when the stream is reset (#3698, 2937 #3700) 2939 * Use H3_ID_ERROR when GOAWAY contains a larger identifier (#3631, 2940 #3634) 2942 B.5. Since draft-ietf-quic-http-27 2944 * Updated text to refer to latest HTTP revisions 2946 * Use the HTTP definition of authority for establishing and 2947 coalescing connections (#253, #2223, #3558) 2949 * Define use of GOAWAY from both endpoints (#2632, #3129) 2951 * Require either :authority or Host if the URI scheme has a 2952 mandatory authority component (#3408, #3475) 2954 B.6. Since draft-ietf-quic-http-26 2956 * No changes 2958 B.7. Since draft-ietf-quic-http-25 2960 * Require QUICv1 for HTTP/3 (#3117, #3323) 2962 * Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275, 2963 #3309) 2965 * Clarify the definition of "malformed" (#3352, #3345) 2967 B.8. Since draft-ietf-quic-http-24 2969 * Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended 2970 instead (#3130,#3208) 2972 * Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331) 2974 * Some error codes are reserved for greasing (#3325,#3360) 2976 B.9. Since draft-ietf-quic-http-23 2978 * Removed "quic" Alt-Svc parameter (#3061,#3118) 2980 * Clients need not persist unknown settings for use in 0-RTT 2981 (#3110,#3113) 2983 * Clarify error cases around CANCEL_PUSH (#2819,#3083) 2985 B.10. Since draft-ietf-quic-http-22 2987 * Removed priority signaling (#2922,#2924) 2989 * Further changes to error codes (#2662,#2551): 2991 - Error codes renumbered 2993 - HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR, 2994 HTTP_ID_ERROR, and others 2996 * Clarify how unknown frame types interact with required frame 2997 sequence (#2867,#2858) 2999 * Describe interactions with the transport in terms of defined 3000 interface terms (#2857,#2805) 3002 * Require the use of the "http-opportunistic" resource (RFC 8164) 3003 when scheme is "http" (#2439,#2973) 3005 * Settings identifiers cannot be duplicated (#2979) 3007 * Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945): 3009 - Servers must send all settings with non-default values in their 3010 SETTINGS frame, even when resuming 3012 - If a client doesn't have settings associated with a 0-RTT 3013 ticket, it uses the defaults 3015 - Servers can't accept early data if they cannot recover the 3016 settings the client will have remembered 3018 * Clarify that Upgrade and the 101 status code are prohibited 3019 (#2898,#2889) 3021 * Clarify that frame types reserved for greasing can occur on any 3022 stream, but frame types reserved due to HTTP/2 correspondence are 3023 prohibited (#2997,#2692,#2693) 3025 * Unknown error codes cannot be treated as errors (#2998,#2816) 3027 B.11. Since draft-ietf-quic-http-21 3029 No changes 3031 B.12. Since draft-ietf-quic-http-20 3032 * Prohibit closing the control stream (#2509, #2666) 3034 * Change default priority to use an orphan node (#2502, #2690) 3036 * Exclusive priorities are restored (#2754, #2781) 3038 * Restrict use of frames when using CONNECT (#2229, #2702) 3040 * Close and maybe reset streams if a connection error occurs for 3041 CONNECT (#2228, #2703) 3043 * Encourage provision of sufficient unidirectional streams for QPACK 3044 (#2100, #2529, #2762) 3046 * Allow extensions to use server-initiated bidirectional streams 3047 (#2711, #2773) 3049 * Clarify use of maximum header list size setting (#2516, #2774) 3051 * Extensive changes to error codes and conditions of their sending 3053 - Require connection errors for more error conditions (#2511, 3054 #2510) 3056 - Updated the error codes for illegal GOAWAY frames (#2714, 3057 #2707) 3059 - Specified error code for HEADERS on control stream (#2708) 3061 - Specified error code for servers receiving PUSH_PROMISE (#2709) 3063 - Specified error code for receiving DATA before HEADERS (#2715) 3065 - Describe malformed messages and their handling (#2410, #2764) 3067 - Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813) 3069 - Refactor Push ID related errors (#2818, #2820) 3071 - Rationalize HTTP/3 stream creation errors (#2821, #2822) 3073 B.13. Since draft-ietf-quic-http-19 3075 * SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530) 3077 * Non-zero bits in the Empty field of the PRIORITY frame MAY be 3078 treated as an error (#2501) 3080 B.14. Since draft-ietf-quic-http-18 3082 * Resetting streams following a GOAWAY is recommended, but not 3083 required (#2256,#2457) 3085 * Use variable-length integers throughout (#2437,#2233,#2253,#2275) 3087 - Variable-length frame types, stream types, and settings 3088 identifiers 3090 - Renumbered stream type assignments 3092 - Modified associated reserved values 3094 * Frame layout switched from Length-Type-Value to Type-Length-Value 3095 (#2395,#2235) 3097 * Specified error code for servers receiving DUPLICATE_PUSH (#2497) 3099 * Use connection error for invalid PRIORITY (#2507, #2508) 3101 B.15. Since draft-ietf-quic-http-17 3103 * HTTP_REQUEST_REJECTED is used to indicate a request can be retried 3104 (#2106, #2325) 3106 * Changed error code for GOAWAY on the wrong stream (#2231, #2343) 3108 B.16. Since draft-ietf-quic-http-16 3110 * Rename "HTTP/QUIC" to "HTTP/3" (#1973) 3112 * Changes to PRIORITY frame (#1865, #2075) 3114 - Permitted as first frame of request streams 3116 - Remove exclusive reprioritization 3118 - Changes to Prioritized Element Type bits 3120 * Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE 3121 (#2072) 3123 * Set defaults for settings, allow request before receiving SETTINGS 3124 (#1809, #1846, #2038) 3126 * Clarify message processing rules for streams that aren't closed 3127 (#1972, #2003) 3129 * Removed reservation of error code 0 and moved HTTP_NO_ERROR to 3130 this value (#1922) 3132 * Removed prohibition of zero-length DATA frames (#2098) 3134 B.17. Since draft-ietf-quic-http-15 3136 Substantial editorial reorganization; no technical changes. 3138 B.18. Since draft-ietf-quic-http-14 3140 * Recommend sensible values for QUIC transport parameters 3141 (#1720,#1806) 3143 * Define error for missing SETTINGS frame (#1697,#1808) 3145 * Setting values are variable-length integers (#1556,#1807) and do 3146 not have separate maximum values (#1820) 3148 * Expanded discussion of connection closure (#1599,#1717,#1712) 3150 * HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) 3152 B.19. Since draft-ietf-quic-http-13 3154 * Reserved some frame types for grease (#1333, #1446) 3156 * Unknown unidirectional stream types are tolerated, not errors; 3157 some reserved for grease (#1490, #1525) 3159 * Require settings to be remembered for 0-RTT, prohibit reductions 3160 (#1541, #1641) 3162 * Specify behavior for truncated requests (#1596, #1643) 3164 B.20. Since draft-ietf-quic-http-12 3166 * TLS SNI extension isn't mandatory if an alternative method is used 3167 (#1459, #1462, #1466) 3169 * Removed flags from HTTP/3 frames (#1388, #1398) 3171 * Reserved frame types and settings for use in preserving 3172 extensibility (#1333, #1446) 3174 * Added general error code (#1391, #1397) 3175 * Unidirectional streams carry a type byte and are extensible 3176 (#910,#1359) 3178 * Priority mechanism now uses explicit placeholders to enable 3179 persistent structure in the tree (#441,#1421,#1422) 3181 B.21. Since draft-ietf-quic-http-11 3183 * Moved QPACK table updates and acknowledgments to dedicated streams 3184 (#1121, #1122, #1238) 3186 B.22. Since draft-ietf-quic-http-10 3188 * Settings need to be remembered when attempting and accepting 0-RTT 3189 (#1157, #1207) 3191 B.23. Since draft-ietf-quic-http-09 3193 * Selected QCRAM for header compression (#228, #1117) 3195 * The server_name TLS extension is now mandatory (#296, #495) 3197 * Specified handling of unsupported versions in Alt-Svc (#1093, 3198 #1097) 3200 B.24. Since draft-ietf-quic-http-08 3202 * Clarified connection coalescing rules (#940, #1024) 3204 B.25. Since draft-ietf-quic-http-07 3206 * Changes for integer encodings in QUIC (#595,#905) 3208 * Use unidirectional streams as appropriate (#515, #240, #281, #886) 3210 * Improvement to the description of GOAWAY (#604, #898) 3212 * Improve description of server push usage (#947, #950, #957) 3214 B.26. Since draft-ietf-quic-http-06 3216 * Track changes in QUIC error code usage (#485) 3218 B.27. Since draft-ietf-quic-http-05 3220 * Made push ID sequential, add MAX_PUSH_ID, remove 3221 SETTINGS_ENABLE_PUSH (#709) 3223 * Guidance about keep-alive and QUIC PINGs (#729) 3225 * Expanded text on GOAWAY and cancellation (#757) 3227 B.28. Since draft-ietf-quic-http-04 3229 * Cite RFC 5234 (#404) 3231 * Return to a single stream per request (#245,#557) 3233 * Use separate frame type and settings registries from HTTP/2 (#81) 3235 * SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) 3237 * Restored GOAWAY (#696) 3239 * Identify server push using Push ID rather than a stream ID 3240 (#702,#281) 3242 * DATA frames cannot be empty (#700) 3244 B.29. Since draft-ietf-quic-http-03 3246 None. 3248 B.30. Since draft-ietf-quic-http-02 3250 * Track changes in transport draft 3252 B.31. Since draft-ietf-quic-http-01 3254 * SETTINGS changes (#181): 3256 - SETTINGS can be sent only once at the start of a connection; no 3257 changes thereafter 3259 - SETTINGS_ACK removed 3261 - Settings can only occur in the SETTINGS frame a single time 3263 - Boolean format updated 3265 * Alt-Svc parameter changed from "v" to "quic"; format updated 3266 (#229) 3268 * Closing the connection control stream or any message control 3269 stream is a fatal error (#176) 3271 * HPACK Sequence counter can wrap (#173) 3273 * 0-RTT guidance added 3275 * Guide to differences from HTTP/2 and porting HTTP/2 extensions 3276 added (#127,#242) 3278 B.32. Since draft-ietf-quic-http-00 3280 * Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) 3282 * Changed from using HTTP/2 framing within Stream 3 to new framing 3283 format and two-stream-per-request model (#71,#72,#73) 3285 * Adopted SETTINGS format from draft-bishop-httpbis-extended- 3286 settings-01 3288 * Reworked SETTINGS_ACK to account for indeterminate inter-stream 3289 order (#75) 3291 * Described CONNECT pseudo-method (#95) 3293 * Updated ALPN token and Alt-Svc guidance (#13,#87) 3295 * Application-layer-defined error codes (#19,#74) 3297 B.33. Since draft-shade-quic-http2-mapping-00 3299 * Adopted as base for draft-ietf-quic-http 3301 * Updated authors/editors list 3303 Acknowledgements 3305 The original authors of this specification were Robbie Shade and Mike 3306 Warres. 3308 The IETF QUIC Working Group received an enormous amount of support 3309 from many people. Among others, the following people provided 3310 substantial contributions to this document: 3312 * Bence Beky 3314 * Daan De Meyer 3316 * Martin Duke 3318 * Roy Fielding 3319 * Alan Frindell 3321 * Alessandro Ghedini 3323 * Nick Harper 3325 * Ryan Hamilton 3327 * Christian Huitema 3329 * Subodh Iyengar 3331 * Robin Marx 3333 * Patrick McManus 3335 * Luca Niccolini 3337 * 奥 一穂 (Kazuho Oku) 3339 * Lucas Pardue 3341 * Roberto Peon 3343 * Julian Reschke 3345 * Eric Rescorla 3347 * Martin Seemann 3349 * Ben Schwartz 3351 * Ian Swett 3353 * Willy Taureau 3355 * Martin Thomson 3357 * Dmitri Tikhonov 3359 * Tatsuhiro Tsujikawa 3361 A portion of Mike's contribution was supported by Microsoft during 3362 his employment there. 3364 Author's Address 3365 Mike Bishop (editor) 3366 Akamai 3368 Email: mbishop@evequefou.be