idnits 2.17.1 draft-ietf-httpbis-http2-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 3727 -- Looks like a reference, but probably isn't: '2' on line 3729 -- Looks like a reference, but probably isn't: '3' on line 3732 -- Looks like a reference, but probably isn't: '4' on line 2459 -- Looks like a reference, but probably isn't: '5' on line 3697 -- Looks like a reference, but probably isn't: '6' on line 3956 -- Looks like a reference, but probably isn't: '7' on line 3964 == Outdated reference: A later version (-12) exists of draft-ietf-httpbis-header-compression-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-04 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) == Outdated reference: A later version (-11) exists of draft-ietf-uta-tls-bcp-01 Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group M. Belshe 3 Internet-Draft Twist 4 Intended status: Standards Track R. Peon 5 Expires: April 30, 2015 Google, Inc 6 M. Thomson, Ed. 7 Mozilla 8 October 27, 2014 10 Hypertext Transfer Protocol version 2 11 draft-ietf-httpbis-http2-15 13 Abstract 15 This specification describes an optimized expression of the semantics 16 of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more 17 efficient use of network resources and a reduced perception of 18 latency by introducing header field compression and allowing multiple 19 concurrent messages on the same connection. It also introduces 20 unsolicited push of representations from servers to clients. 22 This specification is an alternative to, but does not obsolete, the 23 HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. 25 Editorial Note (To be removed by RFC Editor) 27 Discussion of this draft takes place on the HTTPBIS working group 28 mailing list (ietf-http-wg@w3.org), which is archived at [1]. 30 Working Group information can be found at [2]; that specific to 31 HTTP/2 are at [3]. 33 The changes in this draft are summarized in Appendix A. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 30, 2015. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. HTTP/2 Protocol Overview . . . . . . . . . . . . . . . . . . 5 70 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 71 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 72 3. Starting HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. HTTP/2 Version Identification . . . . . . . . . . . . . . 8 74 3.2. Starting HTTP/2 for "http" URIs . . . . . . . . . . . . . 9 75 3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10 76 3.3. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 11 77 3.4. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 11 78 3.5. HTTP/2 Connection Preface . . . . . . . . . . . . . . . . 11 79 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 12 81 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.3. Header Compression and Decompression . . . . . . . . . . 14 83 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 15 84 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16 85 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 21 86 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 21 87 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 22 88 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 22 89 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 23 90 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 24 91 5.3.1. Stream Dependencies . . . . . . . . . . . . . . . . . 24 92 5.3.2. Dependency Weighting . . . . . . . . . . . . . . . . 25 93 5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . 26 94 5.3.4. Prioritization State Management . . . . . . . . . . . 26 95 5.3.5. Default Priorities . . . . . . . . . . . . . . . . . 27 96 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 28 97 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 28 98 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 28 99 5.4.3. Connection Termination . . . . . . . . . . . . . . . 29 100 5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 29 101 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 30 102 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 34 105 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 35 106 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 36 107 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 37 108 6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 37 109 6.5.3. Settings Synchronization . . . . . . . . . . . . . . 38 110 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 39 111 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 41 112 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 42 113 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 45 114 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 46 115 6.9.2. Initial Flow Control Window Size . . . . . . . . . . 47 116 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 48 117 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 48 118 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49 119 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . 50 120 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . 51 121 8.1.1. Upgrading From HTTP/2 . . . . . . . . . . . . . . . . 52 122 8.1.2. HTTP Header Fields . . . . . . . . . . . . . . . . . 52 123 8.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 56 124 8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . 59 125 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 59 126 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 60 127 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . 61 128 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . 62 129 9. Additional HTTP Requirements/Considerations . . . . . . . . . 63 130 9.1. Connection Management . . . . . . . . . . . . . . . . . . 64 131 9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 64 132 9.1.2. The 421 (Misdirected Request) Status Code . . . . . . 65 133 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 65 134 9.2.1. TLS Features . . . . . . . . . . . . . . . . . . . . 66 135 9.2.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . 66 136 10. Security Considerations . . . . . . . . . . . . . . . . . . . 67 137 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 67 138 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 67 139 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 68 140 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 68 141 10.5. Denial of Service Considerations . . . . . . . . . . . . 68 142 10.5.1. Limits on Header Block Size . . . . . . . . . . . . 70 143 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 70 144 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 71 145 10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 71 146 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 147 11.1. Registration of HTTP/2 Identification Strings . . . . . 72 148 11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 72 149 11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 73 150 11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 74 151 11.5. HTTP2-Settings Header Field Registration . . . . . . . . 75 152 11.6. PRI Method Registration . . . . . . . . . . . . . . . . 76 153 11.7. The 421 (Misdirected Request) HTTP Status Code . . . . . 76 154 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76 155 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 156 13.1. Normative References . . . . . . . . . . . . . . . . . . 77 157 13.2. Informative References . . . . . . . . . . . . . . . . . 78 158 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 79 159 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 80 160 A.1. Since draft-ietf-httpbis-http2-14 . . . . . . . . . . . . 80 161 A.2. Since draft-ietf-httpbis-http2-13 . . . . . . . . . . . . 80 162 A.3. Since draft-ietf-httpbis-http2-12 . . . . . . . . . . . . 80 163 A.4. Since draft-ietf-httpbis-http2-11 . . . . . . . . . . . . 80 164 A.5. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 81 165 A.6. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 81 166 A.7. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 82 167 A.8. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 82 168 A.9. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 82 169 A.10. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 82 170 A.11. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 82 171 A.12. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 83 172 A.13. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 83 173 A.14. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 83 174 A.15. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 84 175 A.16. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 84 177 1. Introduction 179 The Hypertext Transfer Protocol (HTTP) is a wildly successful 180 protocol. However, the HTTP/1.1 message format ([RFC7230], 181 Section 3) has several characteristics that have a negative overall 182 effect on application performance today. 184 In particular, HTTP/1.0 allowed only one request to be outstanding at 185 a time on a given TCP connection. HTTP/1.1 added request pipelining, 186 but this only partially addressed request concurrency and still 187 suffers from head-of-line blocking. Therefore, HTTP/1.1 clients that 188 need to make many requests typically use multiple connections to a 189 server in order to achieve concurrency and thereby reduce latency. 191 Furthermore, HTTP header fields are often repetitive and verbose, 192 causing unnecessary network traffic, as well as causing the initial 193 TCP [TCP] congestion window to quickly fill. This can result in 194 excessive latency when multiple requests are made on a new TCP 195 connection. 197 HTTP/2 addresses these issues by defining an optimized mapping of 198 HTTP's semantics to an underlying connection. Specifically, it 199 allows interleaving of request and response messages on the same 200 connection and uses an efficient coding for HTTP header fields. It 201 also allows prioritization of requests, letting more important 202 requests complete more quickly, further improving performance. 204 The resulting protocol is more friendly to the network, because fewer 205 TCP connections can be used in comparison to HTTP/1.x. This means 206 less competition with other flows, and longer-lived connections, 207 which in turn leads to better utilization of available network 208 capacity. 210 Finally, HTTP/2 also enables more efficient processing of messages 211 through use of binary message framing. 213 2. HTTP/2 Protocol Overview 215 HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 216 supports all of the core features of HTTP/1.1, but aims to be more 217 efficient in several ways. 219 The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each 220 frame type serves a different purpose. For example, HEADERS and DATA 221 frames form the basis of HTTP requests and responses (Section 8.1); 222 other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are 223 used in support of other HTTP/2 features. 225 Multiplexing of requests is achieved by having each HTTP request- 226 response exchange associated with its own stream (Section 5). 227 Streams are largely independent of each other, so a blocked or 228 stalled request or response does not prevent progress on other 229 streams. 231 Flow control and prioritization ensure that it is possible to 232 efficiently use multiplexed streams. Flow control (Section 5.2) 233 helps to ensure that only data that can be used by a receiver is 234 transmitted. Prioritization (Section 5.3) ensures that limited 235 resources can be directed to the most important streams first. 237 HTTP/2 adds a new interaction mode, whereby a server can push 238 responses to a client (Section 8.2). Server push allows a server to 239 speculatively send data to a client that the server anticipates the 240 client will need, trading off some network usage against a potential 241 latency gain. The server does this by synthesizing a request, which 242 it sends as a PUSH_PROMISE frame. The server is then able to send a 243 response to the synthetic request on a separate stream. 245 Frames that contain HTTP header fields are compressed (Section 4.3). 246 HTTP requests can be highly redundant, so compression can reduce the 247 size of requests and responses significantly. 249 2.1. Document Organization 251 The HTTP/2 specification is split into four parts: 253 o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is 254 initiated. 256 o The framing (Section 4) and streams (Section 5) layers describe 257 the way HTTP/2 frames are structured and formed into multiplexed 258 streams. 260 o Frame (Section 6) and error (Section 7) definitions include 261 details of the frame and error types used in HTTP/2. 263 o HTTP mappings (Section 8) and additional requirements (Section 9) 264 describe how HTTP semantics are expressed using frames and 265 streams. 267 While some of the frame and stream layer concepts are isolated from 268 HTTP, this specification does not define a completely generic framing 269 layer. The framing and streams layers are tailored to the needs of 270 the HTTP protocol and server push. 272 2.2. Conventions and Terminology 274 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 275 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 276 document are to be interpreted as described in RFC 2119 [RFC2119]. 278 All numeric values are in network byte order. Values are unsigned 279 unless otherwise indicated. Literal values are provided in decimal 280 or hexadecimal as appropriate. Hexadecimal literals are prefixed 281 with "0x" to distinguish them from decimal literals. 283 The following terms are used: 285 client: The endpoint initiating the HTTP/2 connection. 287 connection: A transport-layer connection between two endpoints. 289 connection error: An error that affects the entire HTTP/2 290 connection. 292 endpoint: Either the client or server of the connection. 294 frame: The smallest unit of communication within an HTTP/2 295 connection, consisting of a header and a variable-length sequence 296 of octets structured according to the frame type. 298 peer: An endpoint. When discussing a particular endpoint, "peer" 299 refers to the endpoint that is remote to the primary subject of 300 discussion. 302 receiver: An endpoint that is receiving frames. 304 sender: An endpoint that is transmitting frames. 306 server: The endpoint which did not initiate the HTTP/2 connection. 308 stream: A bi-directional flow of frames across a virtual channel 309 within the HTTP/2 connection. 311 stream error: An error on the individual HTTP/2 stream. 313 Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" 314 are defined in Section 2.3 of [RFC7230]. 316 3. Starting HTTP/2 318 An HTTP/2 connection is an application layer protocol running on top 319 of a TCP connection ([TCP]). The client is the TCP connection 320 initiator. 322 HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1. 323 HTTP/2 shares the same default port numbers: 80 for "http" URIs and 324 443 for "https" URIs. As a result, implementations processing 325 requests for target resource URIs like "http://example.org/foo" or 326 "https://example.com/bar" are required to first discover whether the 327 upstream server (the immediate peer to which the client wishes to 328 establish a connection) supports HTTP/2. 330 The means by which support for HTTP/2 is determined is different for 331 "http" and "https" URIs. Discovery for "http" URIs is described in 332 Section 3.2. Discovery for "https" URIs is described in Section 3.3. 334 3.1. HTTP/2 Version Identification 336 The protocol defined in this document has two identifiers. 338 o The string "h2" identifies the protocol where HTTP/2 uses TLS 339 [TLS12]. This identifier is used in the TLS application layer 340 protocol negotiation extension (ALPN) [TLS-ALPN] field and in any 341 place where HTTP/2 over TLS is identified. 343 The "h2" string is serialized into an ALPN protocol identifier as 344 the two octet sequence: 0x68, 0x32. 346 o The string "h2c" identifies the protocol where HTTP/2 is run over 347 cleartext TCP. This identifier is used in the HTTP/1.1 Upgrade 348 header field and in any place where HTTP/2 over TCP is identified. 350 Negotiating "h2" or "h2c" implies the use of the transport, security, 351 framing and message semantics described in this document. 353 [[CREF1: RFC Editor's Note: please remove the remainder of this 354 section prior to the publication of a final version of this 355 document.]] 357 Only implementations of the final, published RFC can identify 358 themselves as "h2" or "h2c". Until such an RFC exists, 359 implementations MUST NOT identify themselves using these strings. 361 Examples and text throughout the rest of this document use "h2" as a 362 matter of editorial convenience only. Implementations of draft 363 versions MUST NOT identify using this string. 365 Implementations of draft versions of the protocol MUST add the string 366 "-" and the corresponding draft number to the identifier. For 367 example, draft-ietf-httpbis-http2-11 over TLS is identified using the 368 string "h2-11". 370 Non-compatible experiments that are based on these draft versions 371 MUST append the string "-" and an experiment name to the identifier. 372 For example, an experimental implementation of packet mood-based 373 encoding based on draft-ietf-httpbis-http2-09 might identify itself 374 as "h2-09-emo". Note that any label MUST conform to the "token" 375 syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are 376 encouraged to coordinate their experiments on the ietf-http-wg@w3.org 377 mailing list. 379 3.2. Starting HTTP/2 for "http" URIs 381 A client that makes a request for an "http" URI without prior 382 knowledge about support for HTTP/2 uses the HTTP Upgrade mechanism 383 (Section 6.7 of [RFC7230]). The client makes an HTTP/1.1 request 384 that includes an Upgrade header field identifying HTTP/2 with the 385 "h2c" token. The HTTP/1.1 request MUST include exactly one 386 HTTP2-Settings (Section 3.2.1) header field. 388 For example: 390 GET / HTTP/1.1 391 Host: server.example.com 392 Connection: Upgrade, HTTP2-Settings 393 Upgrade: h2c 394 HTTP2-Settings: 396 Requests that contain an entity body MUST be sent in their entirety 397 before the client can send HTTP/2 frames. This means that a large 398 request entity can block the use of the connection until it is 399 completely sent. 401 If concurrency of an initial request with subsequent requests is 402 important, an OPTIONS request can be used to perform the upgrade to 403 HTTP/2, at the cost of an additional round-trip. 405 A server that does not support HTTP/2 can respond to the request as 406 though the Upgrade header field were absent: 408 HTTP/1.1 200 OK 409 Content-Length: 243 410 Content-Type: text/html 412 ... 414 A server MUST ignore a "h2" token in an Upgrade header field. 415 Presence of a token with "h2" implies HTTP/2 over TLS, which is 416 instead negotiated as described in Section 3.3. 418 A server that supports HTTP/2 can accept the upgrade with a 101 419 (Switching Protocols) response. After the empty line that terminates 420 the 101 response, the server can begin sending HTTP/2 frames. These 421 frames MUST include a response to the request that initiated the 422 Upgrade. 424 For example: 426 HTTP/1.1 101 Switching Protocols 427 Connection: Upgrade 428 Upgrade: h2c 430 [ HTTP/2 connection ... 432 The first HTTP/2 frame sent by the server is a SETTINGS frame 433 (Section 6.5) as the server connection preface (Section 3.5). Upon 434 receiving the 101 response, the client sends a connection preface 435 (Section 3.5), which includes a SETTINGS frame. 437 The HTTP/1.1 request that is sent prior to upgrade is assigned stream 438 identifier 1 and is assigned default priority values (Section 5.3.5). 439 Stream 1 is implicitly half closed from the client toward the server, 440 since the request is completed as an HTTP/1.1 request. After 441 commencing the HTTP/2 connection, stream 1 is used for the response. 443 3.2.1. HTTP2-Settings Header Field 445 A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly 446 one "HTTP2-Settings" header field. The "HTTP2-Settings" header field 447 is a connection-specific header field that includes parameters that 448 govern the HTTP/2 connection, provided in anticipation of the server 449 accepting the request to upgrade. 451 HTTP2-Settings = token68 453 A server MUST NOT upgrade the connection to HTTP/2 if this header 454 field is not present, or if more than one is present. A server MUST 455 NOT send this header field. 457 The content of the "HTTP2-Settings" header field is the payload of a 458 SETTINGS frame (Section 6.5), encoded as a base64url string (that is, 459 the URL- and filename-safe Base64 encoding described in Section 5 of 460 [RFC4648], with any trailing '=' characters omitted). The ABNF 461 [RFC5234] production for "token68" is defined in Section 2.1 of 462 [RFC7235]. 464 Since the upgrade is only intended to apply to the immediate 465 connection, a client sending "HTTP2-Settings" MUST also send 466 "HTTP2-Settings" as a connection option in the "Connection" header 467 field to prevent it from being forwarded (see Section 6.1 of 468 [RFC7230]). 470 A server decodes and interprets these values as it would any other 471 SETTINGS frame. Acknowledgement of the SETTINGS parameters 472 (Section 6.5.3) is not necessary, since a 101 response serves as 473 implicit acknowledgment. Providing these values in the Upgrade 474 request gives a client an opportunity to provide parameters prior to 475 receiving any frames from the server. 477 3.3. Starting HTTP/2 for "https" URIs 479 A client that makes a request to an "https" URI uses TLS [TLS12] with 480 the application layer protocol negotiation extension [TLS-ALPN]. 482 HTTP/2 over TLS uses the "h2" application token. The "h2c" token 483 MUST NOT be sent by a client or selected by a server. 485 Once TLS negotiation is complete, both the client and the server send 486 a connection preface (Section 3.5). 488 3.4. Starting HTTP/2 with Prior Knowledge 490 A client can learn that a particular server supports HTTP/2 by other 491 means. For example, [ALT-SVC] describes a mechanism for advertising 492 this capability. 494 A client MAY immediately send HTTP/2 frames to a server that is known 495 to support HTTP/2, after the connection preface (Section 3.5); a 496 server can identify such a connection by the presence of the 497 connection preface. This only affects the establishment of HTTP/2 498 connections over cleartext TCP; implementations that support HTTP/2 499 over TLS MUST use protocol negotiation in TLS [TLS-ALPN]. 501 Without additional information, prior support for HTTP/2 is not a 502 strong signal that a given server will support HTTP/2 for future 503 connections. For example, it is possible for server configurations 504 to change, for configurations to differ between instances in 505 clustered servers, or for network conditions to change. 507 3.5. HTTP/2 Connection Preface 509 Upon establishment of a TCP connection and determination that HTTP/2 510 will be used by both peers, each endpoint MUST send a connection 511 preface as a final confirmation and to establish the initial SETTINGS 512 parameters for the HTTP/2 connection. The client and server each 513 send a different connection preface. 515 The client connection preface starts with a sequence of 24 octets, 516 which in hex notation are: 518 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 520 (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence is 521 followed by a SETTINGS frame (Section 6.5). The SETTINGS frame MAY 522 be empty. The client sends the client connection preface immediately 523 upon receipt of a 101 Switching Protocols response (indicating a 524 successful upgrade), or as the first application data octets of a TLS 525 connection. If starting an HTTP/2 connection with prior knowledge of 526 server support for the protocol, the client connection preface is 527 sent upon connection establishment. 529 The client connection preface is selected so that a large 530 proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do 531 not attempt to process further frames. Note that this does not 532 address the concerns raised in [TALKING]. 534 The server connection preface consists of a potentially empty 535 SETTINGS frame (Section 6.5) that MUST be the first frame the server 536 sends in the HTTP/2 connection. 538 The SETTINGS frames received from a peer as part of the connection 539 preface MUST be acknowledged (see Section 6.5.3) after sending the 540 connection preface. 542 To avoid unnecessary latency, clients are permitted to send 543 additional frames to the server immediately after sending the client 544 connection preface, without waiting to receive the server connection 545 preface. It is important to note, however, that the server 546 connection preface SETTINGS frame might include parameters that 547 necessarily alter how a client is expected to communicate with the 548 server. Upon receiving the SETTINGS frame, the client is expected to 549 honor any parameters established. In some configurations, it is 550 possible for the server to transmit SETTINGS before the client sends 551 additional frames, providing an opportunity to avoid this issue. 553 Clients and servers MUST treat an invalid connection preface as a 554 connection error (Section 5.4.1) of type PROTOCOL_ERROR. A GOAWAY 555 frame (Section 6.8) MAY be omitted in this case, since an invalid 556 preface indicates that the peer is not using HTTP/2. 558 4. HTTP Frames 560 Once the HTTP/2 connection is established, endpoints can begin 561 exchanging frames. 563 4.1. Frame Format 565 All frames begin with a fixed 9-octet header followed by a variable- 566 length payload. 568 0 1 2 3 569 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Length (24) | 572 +---------------+---------------+---------------+ 573 | Type (8) | Flags (8) | 574 +-+-+-----------+---------------+-------------------------------+ 575 |R| Stream Identifier (31) | 576 +=+=============================================================+ 577 | Frame Payload (0...) ... 578 +---------------------------------------------------------------+ 580 Figure 1: Frame Layout 582 The fields of the frame header are defined as: 584 Length: The length of the frame payload expressed as an unsigned 585 24-bit integer. Values greater than 2^14 (16,384) MUST NOT be 586 sent unless the receiver has set a larger value for 587 SETTINGS_MAX_FRAME_SIZE. 589 The 9 octets of the frame header are not included in this value. 591 Type: The 8-bit type of the frame. The frame type determines the 592 format and semantics of the frame. Implementations MUST ignore 593 and discard any frame that has a type that is unknown. 595 Flags: An 8-bit field reserved for frame-type specific boolean 596 flags. 598 Flags are assigned semantics specific to the indicated frame type. 599 Flags that have no defined semantics for a particular frame type 600 MUST be ignored, and MUST be left unset (0) when sending. 602 R: A reserved 1-bit field. The semantics of this bit are undefined 603 and the bit MUST remain unset (0) when sending and MUST be ignored 604 when receiving. 606 Stream Identifier: A 31-bit stream identifier (see Section 5.1.1). 607 The value 0 is reserved for frames that are associated with the 608 connection as a whole as opposed to an individual stream. 610 The structure and content of the frame payload is dependent entirely 611 on the frame type. 613 4.2. Frame Size 615 The size of a frame payload is limited by the maximum size that a 616 receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting. This 617 setting can have any value between 2^14 (16,384) and 2^24-1 618 (16,777,215) octets, inclusive. 620 All implementations MUST be capable of receiving and minimally 621 processing frames up to 2^14 octets in length, plus the 9 octet frame 622 header (Section 4.1). The size of the frame header is not included 623 when describing frame sizes. 625 Note: Certain frame types, such as PING (Section 6.7), impose 626 additional limits on the amount of payload data allowed. 628 An endpoint MUST send a FRAME_SIZE_ERROR error if a frame exceeds the 629 size defined in SETTINGS_MAX_FRAME_SIZE, any limit defined for the 630 frame type, or it is too small to contain mandatory frame data. A 631 frame size error in a frame that could alter the state of the entire 632 connection MUST be treated as a connection error (Section 5.4.1); 633 this includes any frame carrying a header block (Section 4.3) (that 634 is, HEADERS, PUSH_PROMISE, and CONTINUATION), SETTINGS, and any frame 635 with a stream identifier of 0. 637 Endpoints are not obligated to use all available space in a frame. 638 Responsiveness can be improved by using frames that are smaller than 639 the permitted maximum size. Sending large frames can result in 640 delays in sending time-sensitive frames (such RST_STREAM, 641 WINDOW_UPDATE, or PRIORITY) which if blocked by the transmission of a 642 large frame, could affect performance. 644 4.3. Header Compression and Decompression 646 Just as in HTTP/1, a header field in HTTP/2 is a name with one or 647 more associated values. They are used within HTTP request and 648 response messages as well as server push operations (see 649 Section 8.2). 651 Header lists are collections of zero or more header fields. When 652 transmitted over a connection, a header list is serialized into a 653 header block using HTTP Header Compression [COMPRESSION]. The 654 serialized header block is then divided into one or more octet 655 sequences, called header block fragments, and transmitted within the 656 payload of HEADERS (Section 6.2), PUSH_PROMISE (Section 6.6) or 657 CONTINUATION (Section 6.10) frames. 659 The Cookie header field [COOKIE] is treated specially by the HTTP 660 mapping (see Section 8.1.2.5). 662 A receiving endpoint reassembles the header block by concatenating 663 its fragments, then decompresses the block to reconstruct the header 664 list. 666 A complete header block consists of either: 668 o a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag 669 set, or 671 o a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared 672 and one or more CONTINUATION frames, where the last CONTINUATION 673 frame has the END_HEADERS flag set. 675 Header compression is stateful. One compression context and one 676 decompression context is used for the entire connection. Each header 677 block is processed as a discrete unit. Header blocks MUST be 678 transmitted as a contiguous sequence of frames, with no interleaved 679 frames of any other type or from any other stream. The last frame in 680 a sequence of HEADERS or CONTINUATION frames MUST have the 681 END_HEADERS flag set. The last frame in a sequence of PUSH_PROMISE 682 or CONTINUATION frames MUST have the END_HEADERS flag set. This 683 allows a header block to be logically equivalent to a single frame. 685 Header block fragments can only be sent as the payload of HEADERS, 686 PUSH_PROMISE or CONTINUATION frames, because these frames carry data 687 that can modify the compression context maintained by a receiver. An 688 endpoint receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST 689 reassemble header blocks and perform decompression even if the frames 690 are to be discarded. A receiver MUST terminate the connection with a 691 connection error (Section 5.4.1) of type COMPRESSION_ERROR if it does 692 not decompress a header block. 694 5. Streams and Multiplexing 696 A "stream" is an independent, bi-directional sequence of frames 697 exchanged between the client and server within an HTTP/2 connection. 698 Streams have several important characteristics: 700 o A single HTTP/2 connection can contain multiple concurrently open 701 streams, with either endpoint interleaving frames from multiple 702 streams. 704 o Streams can be established and used unilaterally or shared by 705 either the client or server. 707 o Streams can be closed by either endpoint. 709 o The order in which frames are sent on a stream is significant. 710 Recipients process frames in the order they are received. In 711 particular, the order of HEADERS, and DATA frames is semantically 712 significant. 714 o Streams are identified by an integer. Stream identifiers are 715 assigned to streams by the endpoint initiating the stream. 717 5.1. Stream States 719 The lifecycle of a stream is shown in Figure 2. 721 +--------+ 722 PP | | PP 723 ,--------| idle |--------. 724 / | | \ 725 v +--------+ v 726 +----------+ | +----------+ 727 | | | H | | 728 ,---| reserved | | | reserved |---. 729 | | (local) | v | (remote) | | 730 | +----------+ +--------+ +----------+ | 731 | | ES | | ES | | 732 | | H ,-------| open |-------. | H | 733 | | / | | \ | | 734 | v v +--------+ v v | 735 | +----------+ | +----------+ | 736 | | half | | | half | | 737 | | closed | | R | closed | | 738 | | (remote) | | | (local) | | 739 | +----------+ | +----------+ | 740 | | v | | 741 | | ES / R +--------+ ES / R | | 742 | `----------->| |<-----------' | 743 | R | closed | R | 744 `-------------------->| |<--------------------' 745 +--------+ 747 H: HEADERS frame (with implied CONTINUATIONs) 748 PP: PUSH_PROMISE frame (with implied CONTINUATIONs) 749 ES: END_STREAM flag 750 R: RST_STREAM frame 752 Figure 2: Stream States 754 Note that this diagram shows stream state transitions and the frames 755 and flags that affect those transitions only. In this regard, 756 CONTINUATION frames do not result in state transitions; they are 757 effectively part of the HEADERS or PUSH_PROMISE that they follow. 758 For this purpose, the END_STREAM flag is processed as a separate 759 event to the frame that bears it; a HEADERS frame with the END_STREAM 760 flag set can cause two state transitions. 762 Both endpoints have a subjective view of the state of a stream that 763 could be different when frames are in transit. Endpoints do not 764 coordinate the creation of streams; they are created unilaterally by 765 either endpoint. The negative consequences of a mismatch in states 766 are limited to the "closed" state after sending RST_STREAM, where 767 frames might be received for some time after closing. 769 Streams have the following states: 771 idle: 772 All streams start in the "idle" state. In this state, no frames 773 have been exchanged. 775 The following transitions are valid from this state: 777 * Sending or receiving a HEADERS frame causes the stream to 778 become "open". The stream identifier is selected as described 779 in Section 5.1.1. The same HEADERS frame can also cause a 780 stream to immediately become "half closed". 782 * Sending a PUSH_PROMISE frame marks the associated stream for 783 later use. The stream state for the reserved stream 784 transitions to "reserved (local)". 786 * Receiving a PUSH_PROMISE frame marks the associated stream as 787 reserved by the remote peer. The state of the stream becomes 788 "reserved (remote)". 790 Receiving any frames other than HEADERS or PUSH_PROMISE on a 791 stream in this state MUST be treated as a connection error 792 (Section 5.4.1) of type PROTOCOL_ERROR. 794 reserved (local): 795 A stream in the "reserved (local)" state is one that has been 796 promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame 797 reserves an idle stream by associating the stream with an open 798 stream that was initiated by the remote peer (see Section 8.2). 800 In this state, only the following transitions are possible: 802 * The endpoint can send a HEADERS frame. This causes the stream 803 to open in a "half closed (remote)" state. 805 * Either endpoint can send a RST_STREAM frame to cause the stream 806 to become "closed". This releases the stream reservation. 808 An endpoint MUST NOT send any type of frame other than HEADERS or 809 RST_STREAM in this state. 811 A PRIORITY or WINDOW_UPDATE frame MAY be received in this state. 812 Receiving any type of frame other than RST_STREAM, PRIORITY or 813 WINDOW_UPDATE on a stream in this state MUST be treated as a 814 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 816 reserved (remote): 817 A stream in the "reserved (remote)" state has been reserved by a 818 remote peer. 820 In this state, only the following transitions are possible: 822 * Receiving a HEADERS frame causes the stream to transition to 823 "half closed (local)". 825 * Either endpoint can send a RST_STREAM frame to cause the stream 826 to become "closed". This releases the stream reservation. 828 An endpoint MAY send a PRIORITY frame in this state to 829 reprioritize the reserved stream. An endpoint MUST NOT send any 830 type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in 831 this state. 833 Receiving any type of frame other than HEADERS or RST_STREAM on a 834 stream in this state MUST be treated as a connection error 835 (Section 5.4.1) of type PROTOCOL_ERROR. 837 open: 838 A stream in the "open" state may be used by both peers to send 839 frames of any type. In this state, sending peers observe 840 advertised stream level flow control limits (Section 5.2). 842 From this state either endpoint can send a frame with an 843 END_STREAM flag set, which causes the stream to transition into 844 one of the "half closed" states: an endpoint sending an END_STREAM 845 flag causes the stream state to become "half closed (local)"; an 846 endpoint receiving an END_STREAM flag causes the stream state to 847 become "half closed (remote)". 849 Either endpoint can send a RST_STREAM frame from this state, 850 causing it to transition immediately to "closed". 852 half closed (local): 853 A stream that is in the "half closed (local)" state cannot be used 854 for sending frames. Only WINDOW_UPDATE, PRIORITY and RST_STREAM 855 frames can be sent in this state. 857 A stream transitions from this state to "closed" when a frame that 858 contains an END_STREAM flag is received, or when either peer sends 859 a RST_STREAM frame. 861 A receiver can ignore WINDOW_UPDATE frames in this state, which 862 might arrive for a short period after a frame bearing the 863 END_STREAM flag is sent. 865 PRIORITY frames received in this state are used to reprioritize 866 streams that depend on the current stream. 868 half closed (remote): 869 A stream that is "half closed (remote)" is no longer being used by 870 the peer to send frames. In this state, an endpoint is no longer 871 obligated to maintain a receiver flow control window if it 872 performs flow control. 874 If an endpoint receives additional frames for a stream that is in 875 this state, other than WINDOW_UPDATE, PRIORITY or RST_STREAM, it 876 MUST respond with a stream error (Section 5.4.2) of type 877 STREAM_CLOSED. 879 A stream that is "half closed (remote)" can be used by the 880 endpoint to send frames of any type. In this state, the endpoint 881 continues to observe advertised stream level flow control limits 882 (Section 5.2). 884 A stream can transition from this state to "closed" by sending a 885 frame that contains an END_STREAM flag, or when either peer sends 886 a RST_STREAM frame. 888 closed: 889 The "closed" state is the terminal state. 891 An endpoint MUST NOT send frames other than PRIORITY on a closed 892 stream. An endpoint that receives any frame other than PRIORITY 893 after receiving a RST_STREAM MUST treat that as a stream error 894 (Section 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint 895 that receives any frames after receiving a frame with the 896 END_STREAM flag set MUST treat that as a connection error 897 (Section 5.4.1) of type STREAM_CLOSED, unless the frame is 898 permitted as described below. 900 WINDOW_UPDATE or RST_STREAM frames can be received in this state 901 for a short period after a DATA or HEADERS frame containing an 902 END_STREAM flag is sent. Until the remote peer receives and 903 processes RST_STREAM or the frame bearing the END_STREAM flag, it 904 might send frames of these types. Endpoints MUST ignore 905 WINDOW_UPDATE or RST_STREAM frames received in this state, though 906 endpoints MAY choose to treat frames that arrive a significant 907 time after sending END_STREAM as a connection error 908 (Section 5.4.1) of type PROTOCOL_ERROR. 910 PRIORITY frames can be sent on closed streams to prioritize 911 streams that are dependent on the closed stream. Endpoints SHOULD 912 process PRIORITY frames, though they can be ignored if the stream 913 has been removed from the dependency tree (see Section 5.3.4). 915 If this state is reached as a result of sending a RST_STREAM 916 frame, the peer that receives the RST_STREAM might have already 917 sent - or enqueued for sending - frames on the stream that cannot 918 be withdrawn. An endpoint MUST ignore frames that it receives on 919 closed streams after it has sent a RST_STREAM frame. An endpoint 920 MAY choose to limit the period over which it ignores frames and 921 treat frames that arrive after this time as being in error. 923 Flow controlled frames (i.e., DATA) received after sending 924 RST_STREAM are counted toward the connection flow control window. 925 Even though these frames might be ignored, because they are sent 926 before the sender receives the RST_STREAM, the sender will 927 consider the frames to count against the flow control window. 929 An endpoint might receive a PUSH_PROMISE frame after it sends 930 RST_STREAM. PUSH_PROMISE causes a stream to become "reserved" 931 even if the associated stream has been reset. Therefore, a 932 RST_STREAM is needed to close an unwanted promised stream. 934 In the absence of more specific guidance elsewhere in this document, 935 implementations SHOULD treat the receipt of a frame that is not 936 expressly permitted in the description of a state as a connection 937 error (Section 5.4.1) of type PROTOCOL_ERROR. Frame of unknown types 938 are ignored. 940 An example of the state transitions for an HTTP request/response 941 exchange can be found in Section 8.1. An example of the state 942 transitions for server push can be found in Section 8.2.1 and 943 Section 8.2.2. 945 5.1.1. Stream Identifiers 947 Streams are identified with an unsigned 31-bit integer. Streams 948 initiated by a client MUST use odd-numbered stream identifiers; those 949 initiated by the server MUST use even-numbered stream identifiers. A 950 stream identifier of zero (0x0) is used for connection control 951 messages; the stream identifier zero cannot be used to establish a 952 new stream. 954 HTTP/1.1 requests that are upgraded to HTTP/2 (see Section 3.2) are 955 responded to with a stream identifier of one (0x1). After the 956 upgrade completes, stream 0x1 is "half closed (local)" to the client. 957 Therefore, stream 0x1 cannot be selected as a new stream identifier 958 by a client that upgrades from HTTP/1.1. 960 The identifier of a newly established stream MUST be numerically 961 greater than all streams that the initiating endpoint has opened or 962 reserved. This governs streams that are opened using a HEADERS frame 963 and streams that are reserved using PUSH_PROMISE. An endpoint that 964 receives an unexpected stream identifier MUST respond with a 965 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 967 The first use of a new stream identifier implicitly closes all 968 streams in the "idle" state that might have been initiated by that 969 peer with a lower-valued stream identifier. For example, if a client 970 sends a HEADERS frame on stream 7 without ever sending a frame on 971 stream 5, then stream 5 transitions to the "closed" state when the 972 first frame for stream 7 is sent or received. 974 Stream identifiers cannot be reused. Long-lived connections can 975 result in an endpoint exhausting the available range of stream 976 identifiers. A client that is unable to establish a new stream 977 identifier can establish a new connection for new streams. A server 978 that is unable to establish a new stream identifier can send a GOAWAY 979 frame so that the client is forced to open a new connection for new 980 streams. 982 5.1.2. Stream Concurrency 984 A peer can limit the number of concurrently active streams using the 985 SETTINGS_MAX_CONCURRENT_STREAMS parameter (see Section 6.5.2) within 986 a SETTINGS frame. The maximum concurrent streams setting is specific 987 to each endpoint and applies only to the peer that receives the 988 setting. That is, clients specify the maximum number of concurrent 989 streams the server can initiate, and servers specify the maximum 990 number of concurrent streams the client can initiate. 992 Streams that are in the "open" state, or either of the "half closed" 993 states count toward the maximum number of streams that an endpoint is 994 permitted to open. Streams in any of these three states count toward 995 the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. 996 Streams in either of the "reserved" states do not count toward the 997 stream limit. 999 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1000 that receives a HEADERS frame that causes their advertised concurrent 1001 stream limit to be exceeded MUST treat this as a stream error 1002 (Section 5.4.2). An endpoint that wishes to reduce the value of 1003 SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current 1004 number of open streams can either close streams that exceed the new 1005 value or allow streams to complete. 1007 5.2. Flow Control 1009 Using streams for multiplexing introduces contention over use of the 1010 TCP connection, resulting in blocked streams. A flow control scheme 1011 ensures that streams on the same connection do not destructively 1012 interfere with each other. Flow control is used for both individual 1013 streams and for the connection as a whole. 1015 HTTP/2 provides for flow control through use of the WINDOW_UPDATE 1016 frame (Section 6.9). 1018 5.2.1. Flow Control Principles 1020 HTTP/2 stream flow control aims to allow a variety of flow control 1021 algorithms to be used without requiring protocol changes. Flow 1022 control in HTTP/2 has the following characteristics: 1024 1. Flow control is specific to a connection; i.e., it is "hop-by- 1025 hop", not "end-to-end". 1027 2. Flow control is based on window update frames. Receivers 1028 advertise how many octets they are prepared to receive on a 1029 stream and for the entire connection. This is a credit-based 1030 scheme. 1032 3. Flow control is directional with overall control provided by the 1033 receiver. A receiver MAY choose to set any window size that it 1034 desires for each stream and for the entire connection. A sender 1035 MUST respect flow control limits imposed by a receiver. Clients, 1036 servers and intermediaries all independently advertise their flow 1037 control window as a receiver and abide by the flow control limits 1038 set by their peer when sending. 1040 4. The initial value for the flow control window is 65,535 octets 1041 for both new streams and the overall connection. 1043 5. The frame type determines whether flow control applies to a 1044 frame. Of the frames specified in this document, only DATA 1045 frames are subject to flow control; all other frame types do not 1046 consume space in the advertised flow control window. This 1047 ensures that important control frames are not blocked by flow 1048 control. 1050 6. Flow control cannot be disabled. 1052 7. HTTP/2 defines only the format and semantics of the WINDOW_UPDATE 1053 frame (Section 6.9). This document does not stipulate how a 1054 receiver decides when to send this frame or the value that it 1055 sends, nor does it specify how a sender chooses to send packets. 1056 Implementations are able to select any algorithm that suits their 1057 needs. 1059 Implementations are also responsible for managing how requests and 1060 responses are sent based on priority; choosing how to avoid head of 1061 line blocking for requests; and managing the creation of new streams. 1062 Algorithm choices for these could interact with any flow control 1063 algorithm. 1065 5.2.2. Appropriate Use of Flow Control 1067 Flow control is defined to protect endpoints that are operating under 1068 resource constraints. For example, a proxy needs to share memory 1069 between many connections, and also might have a slow upstream 1070 connection and a fast downstream one. Flow control addresses cases 1071 where the receiver is unable to process data on one stream, yet wants 1072 to continue to process other streams in the same connection. 1074 Deployments that do not require this capability can advertise a flow 1075 control window of the maximum size, incrementing the available space 1076 when new data is received. This effectively disables flow control 1077 for that receiver. Conversely, a sender is always subject to the 1078 flow control window advertised by the receiver. 1080 Deployments with constrained resources (for example, memory) can 1081 employ flow control to limit the amount of memory a peer can consume. 1082 Note, however, that this can lead to suboptimal use of available 1083 network resources if flow control is enabled without knowledge of the 1084 bandwidth-delay product (see [RFC7323]). 1086 Even with full awareness of the current bandwidth-delay product, 1087 implementation of flow control can be difficult. When using flow 1088 control, the receiver MUST read from the TCP receive buffer in a 1089 timely fashion. Failure to do so could lead to a deadlock when 1090 critical frames, such as WINDOW_UPDATE, are not read and acted upon. 1092 5.3. Stream priority 1094 A client can assign a priority for a new stream by including 1095 prioritization information in the HEADERS frame (Section 6.2) that 1096 opens the stream. For an existing stream, the PRIORITY frame 1097 (Section 6.3) can be used to change the priority. 1099 The purpose of prioritization is to allow an endpoint to express how 1100 it would prefer its peer allocate resources when managing concurrent 1101 streams. Most importantly, priority can be used to select streams 1102 for transmitting frames when there is limited capacity for sending. 1104 Streams can be prioritized by marking them as dependent on the 1105 completion of other streams (Section 5.3.1). Each dependency is 1106 assigned a relative weight, a number that is used to determine the 1107 relative proportion of available resources that are assigned to 1108 streams dependent on the same stream. 1110 Explicitly setting the priority for a stream is input to a 1111 prioritization process. It does not guarantee any particular 1112 processing or transmission order for the stream relative to any other 1113 stream. An endpoint cannot force a peer to process concurrent 1114 streams in a particular order using priority. Expressing priority is 1115 therefore only ever a suggestion. 1117 Providing prioritization information is optional, so default values 1118 are used if no explicit indicator is provided (Section 5.3.5). 1120 5.3.1. Stream Dependencies 1122 Each stream can be given an explicit dependency on another stream. 1123 Including a dependency expresses a preference to allocate resources 1124 to the identified stream rather than to the dependent stream. 1126 A stream that is not dependent on any other stream is given a stream 1127 dependency of 0x0. In other words, the non-existent stream 0 forms 1128 the root of the tree. 1130 A stream that depends on another stream is a dependent stream. The 1131 stream upon which a stream is dependent is a parent stream. A 1132 dependency on a stream that is not currently in the tree - such as a 1133 stream in the "idle" state - results in that stream being given a 1134 default priority (Section 5.3.5). 1136 When assigning a dependency on another stream, the stream is added as 1137 a new dependency of the parent stream. Dependent streams that share 1138 the same parent are not ordered with respect to each other. For 1139 example, if streams B and C are dependent on stream A, and if stream 1140 D is created with a dependency on stream A, this results in a 1141 dependency order of A followed by B, C, and D in any order. 1143 A A 1144 / \ ==> /|\ 1145 B C B D C 1147 Figure 3: Example of Default Dependency Creation 1149 An exclusive flag allows for the insertion of a new level of 1150 dependencies. The exclusive flag causes the stream to become the 1151 sole dependency of its parent stream, causing other dependencies to 1152 become dependent on the exclusive stream. In the previous example, 1153 if stream D is created with an exclusive dependency on stream A, this 1154 results in D becoming the dependency parent of B and C. 1156 A 1157 A | 1158 / \ ==> D 1159 B C / \ 1160 B C 1162 Figure 4: Example of Exclusive Dependency Creation 1164 Inside the dependency tree, a dependent stream SHOULD only be 1165 allocated resources if all of the streams that it depends on (the 1166 chain of parent streams up to 0x0) are either closed, or it is not 1167 possible to make progress on them. 1169 A stream cannot depend on itself. An endpoint MUST treat this as a 1170 stream error (Section 5.4.2) of type PROTOCOL_ERROR. 1172 5.3.2. Dependency Weighting 1174 All dependent streams are allocated an integer weight between 1 and 1175 256 (inclusive). 1177 Streams with the same parent SHOULD be allocated resources 1178 proportionally based on their weight. Thus, if stream B depends on 1179 stream A with weight 4, and C depends on stream A with weight 12, and 1180 if no progress can be made on A, stream B ideally receives one third 1181 of the resources allocated to stream C. 1183 5.3.3. Reprioritization 1185 Stream priorities are changed using the PRIORITY frame. Setting a 1186 dependency causes a stream to become dependent on the identified 1187 parent stream. 1189 Dependent streams move with their parent stream if the parent is 1190 reprioritized. Setting a dependency with the exclusive flag for a 1191 reprioritized stream moves all the dependencies of the new parent 1192 stream to become dependent on the reprioritized stream. 1194 If a stream is made dependent on one of its own dependencies, the 1195 formerly dependent stream is first moved to be dependent on the 1196 reprioritized stream's previous parent. The moved dependency retains 1197 its weight. 1199 For example, consider an original dependency tree where B and C 1200 depend on A, D and E depend on C, and F depends on D. If A is made 1201 dependent on D, then D takes the place of A. All other dependency 1202 relationships stay the same, except for F, which becomes dependent on 1203 A if the reprioritization is exclusive. 1205 ? ? ? ? 1206 | / \ | | 1207 A D A D D 1208 / \ / / \ / \ | 1209 B C ==> F B C ==> F A OR A 1210 / \ | / \ /|\ 1211 D E E B C B C F 1212 | | | 1213 F E E 1214 (intermediate) (non-exclusive) (exclusive) 1216 Figure 5: Example of Dependency Reordering 1218 5.3.4. Prioritization State Management 1220 When a stream is removed from the dependency tree, its dependencies 1221 can be moved to become dependent on the parent of the closed stream. 1222 The weights of new dependencies are recalculated by distributing the 1223 weight of the dependency of the closed stream proportionally based on 1224 the weights of its dependencies. 1226 Streams that are removed from the dependency tree cause some 1227 prioritization information to be lost. Resources are shared between 1228 streams with the same parent stream, which means that if a stream in 1229 that set closes or becomes blocked, any spare capacity allocated to a 1230 stream is distributed to the immediate neighbors of the stream. 1232 However, if the common dependency is removed from the tree, those 1233 streams share resources with streams at the next highest level. 1235 For example, assume streams A and B share a parent, and streams C and 1236 D both depend on stream A. Prior to the removal of stream A, if 1237 streams A and D are unable to proceed, then stream C receives all the 1238 resources dedicated to stream A. If stream A is removed from the 1239 tree, the weight of stream A is divided between streams C and D. If 1240 stream D is still unable to proceed, this results in stream C 1241 receiving a reduced proportion of resources. For equal starting 1242 weights, C receives one third, rather than one half, of available 1243 resources. 1245 It is possible for a stream to become closed while prioritization 1246 information that creates a dependency on that stream is in transit. 1247 If a stream identified in a dependency has no associated priority 1248 information, then the dependent stream is instead assigned a default 1249 priority (Section 5.3.5). This potentially creates suboptimal 1250 prioritization, since the stream could be given a priority that is 1251 different to what is intended. 1253 To avoid these problems, an endpoint SHOULD retain stream 1254 prioritization state for a period after streams become closed. The 1255 longer state is retained, the lower the chance that streams are 1256 assigned incorrect or default priority values. 1258 This could create a large state burden for an endpoint, so this state 1259 MAY be limited. An endpoint MAY apply a fixed upper limit on the 1260 number of closed streams for which prioritization state is tracked to 1261 limit state exposure. The amount of additional state an endpoint 1262 maintains could be dependent on load; under high load, prioritization 1263 state can be discarded to limit resource commitments. In extreme 1264 cases, an endpoint could even discard prioritization state for active 1265 or reserved streams. If a fixed limit is applied, endpoints SHOULD 1266 maintain state for at least as many streams as allowed by their 1267 setting for SETTINGS_MAX_CONCURRENT_STREAMS. 1269 An endpoint receiving a PRIORITY frame that changes the priority of a 1270 closed stream SHOULD alter the dependencies of the streams that 1271 depend on it, if it has retained enough state to do so. 1273 5.3.5. Default Priorities 1275 Providing priority information is optional. Streams are assigned a 1276 non-exclusive dependency on stream 0x0 by default. Pushed streams 1277 (Section 8.2) initially depend on their associated stream. In both 1278 cases, streams are assigned a default weight of 16. 1280 5.4. Error Handling 1282 HTTP/2 framing permits two classes of error: 1284 o An error condition that renders the entire connection unusable is 1285 a connection error. 1287 o An error in an individual stream is a stream error. 1289 A list of error codes is included in Section 7. 1291 5.4.1. Connection Error Handling 1293 A connection error is any error which prevents further processing of 1294 the framing layer, or which corrupts any connection state. 1296 An endpoint that encounters a connection error SHOULD first send a 1297 GOAWAY frame (Section 6.8) with the stream identifier of the last 1298 stream that it successfully received from its peer. The GOAWAY frame 1299 includes an error code that indicates why the connection is 1300 terminating. After sending the GOAWAY frame for an error condition, 1301 the endpoint MUST close the TCP connection. 1303 It is possible that the GOAWAY will not be reliably received by the 1304 receiving endpoint (see [RFC7230], Section 6.6). In the event of a 1305 connection error, GOAWAY only provides a best effort attempt to 1306 communicate with the peer about why the connection is being 1307 terminated. 1309 An endpoint can end a connection at any time. In particular, an 1310 endpoint MAY choose to treat a stream error as a connection error. 1311 Endpoints SHOULD send a GOAWAY frame when ending a connection, 1312 providing that circumstances permit it. 1314 5.4.2. Stream Error Handling 1316 A stream error is an error related to a specific stream that does not 1317 affect processing of other streams. 1319 An endpoint that detects a stream error sends a RST_STREAM frame 1320 (Section 6.4) that contains the stream identifier of the stream where 1321 the error occurred. The RST_STREAM frame includes an error code that 1322 indicates the type of error. 1324 A RST_STREAM is the last frame that an endpoint can send on a stream. 1325 The peer that sends the RST_STREAM frame MUST be prepared to receive 1326 any frames that were sent or enqueued for sending by the remote peer. 1327 These frames can be ignored, except where they modify connection 1328 state (such as the state maintained for header compression 1329 (Section 4.3), or flow control). 1331 Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame 1332 for any stream. However, an endpoint MAY send additional RST_STREAM 1333 frames if it receives frames on a closed stream after more than a 1334 round-trip time. This behavior is permitted to deal with misbehaving 1335 implementations. 1337 An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM 1338 frame, to avoid looping. 1340 5.4.3. Connection Termination 1342 If the TCP connection is closed or reset while streams remain in open 1343 or half closed states, then the endpoint MUST assume that those 1344 streams were abnormally interrupted and could be incomplete. 1346 5.5. Extending HTTP/2 1348 HTTP/2 permits extension of the protocol. Protocol extensions can be 1349 used to provide additional services or alter any aspect of the 1350 protocol, within the limitations described in this section. 1351 Extensions are effective only within the scope of a single HTTP/2 1352 connection. 1354 Extensions are permitted to use new frame types (Section 4.1), new 1355 settings (Section 6.5.2), or new error codes (Section 7). Registries 1356 are established for managing these extension points: frame types 1357 (Section 11.2), settings (Section 11.3) and error codes 1358 (Section 11.4). 1360 Implementations MUST ignore unknown or unsupported values in all 1361 extensible protocol elements. Implementations MUST discard frames 1362 that have unknown or unsupported types. This means that any of these 1363 extension points can be safely used by extensions without prior 1364 arrangement or negotiation. However, extension frames that appear in 1365 the middle of a header block (Section 4.3) are not permitted; these 1366 MUST be treated as a connection error (Section 5.4.1) of type 1367 PROTOCOL_ERROR. 1369 However, extensions that could change the semantics of existing 1370 protocol components MUST be negotiated before being used. For 1371 example, an extension that changes the layout of the HEADERS frame 1372 cannot be used until the peer has given a positive signal that this 1373 is acceptable. In this case, it could also be necessary to 1374 coordinate when the revised layout comes into effect. Note that 1375 treating any frame other than DATA frames as flow controlled is such 1376 a change in semantics, and can only be done through negotiation. 1378 This document doesn't mandate a specific method for negotiating the 1379 use of an extension, but notes that a setting (Section 6.5.2) could 1380 be used for that purpose. If both peers set a value that indicates 1381 willingness to use the extension, then the extension can be used. If 1382 a setting is used for extension negotiation, the initial value MUST 1383 be defined in such a fashion that the extension is initially 1384 disabled. 1386 6. Frame Definitions 1388 This specification defines a number of frame types, each identified 1389 by a unique 8-bit type code. Each frame type serves a distinct 1390 purpose either in the establishment and management of the connection 1391 as a whole, or of individual streams. 1393 The transmission of specific frame types can alter the state of a 1394 connection. If endpoints fail to maintain a synchronized view of the 1395 connection state, successful communication within the connection will 1396 no longer be possible. Therefore, it is important that endpoints 1397 have a shared comprehension of how the state is affected by the use 1398 any given frame. 1400 6.1. DATA 1402 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1403 octets associated with a stream. One or more DATA frames are used, 1404 for instance, to carry HTTP request or response payloads. 1406 DATA frames MAY also contain arbitrary padding. Padding can be added 1407 to DATA frames to obscure the size of messages. 1409 0 1 2 3 1410 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 |Pad Length? (8)| 1413 +---------------+-----------------------------------------------+ 1414 | Data (*) ... 1415 +---------------------------------------------------------------+ 1416 | Padding (*) ... 1417 +---------------------------------------------------------------+ 1419 Figure 6: DATA Frame Payload 1421 The DATA frame contains the following fields: 1423 Pad Length: An 8-bit field containing the length of the frame 1424 padding in units of octets. This field is optional and is only 1425 present if the PADDED flag is set. 1427 Data: Application data. The amount of data is the remainder of the 1428 frame payload after subtracting the length of the other fields 1429 that are present. 1431 Padding: Padding octets that contain no application semantic value. 1432 Padding octets MUST be set to zero when sending. A receiver is 1433 not obligated to verify padding, but MAY treat non-zero padding as 1434 a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 1436 The DATA frame defines the following flags: 1438 END_STREAM (0x1): Bit 0 being set indicates that this frame is the 1439 last that the endpoint will send for the identified stream. 1440 Setting this flag causes the stream to enter one of the "half 1441 closed" states or the "closed" state (Section 5.1). 1443 PADDED (0x8): Bit 3 being set indicates that the Pad Length field 1444 and any padding that it describes is present. 1446 DATA frames MUST be associated with a stream. If a DATA frame is 1447 received whose stream identifier field is 0x0, the recipient MUST 1448 respond with a connection error (Section 5.4.1) of type 1449 PROTOCOL_ERROR. 1451 DATA frames are subject to flow control and can only be sent when a 1452 stream is in the "open" or "half closed (remote)" states. The entire 1453 DATA frame payload is included in flow control, including Pad Length 1454 and Padding fields if present. If a DATA frame is received whose 1455 stream is not in "open" or "half closed (local)" state, the recipient 1456 MUST respond with a stream error (Section 5.4.2) of type 1457 STREAM_CLOSED. 1459 The total number of padding octets is determined by the value of the 1460 Pad Length field. If the length of the padding is the length of the 1461 frame payload or greater, the recipient MUST treat this as a 1462 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 1464 Note: A frame can be increased in size by one octet by including a 1465 Pad Length field with a value of zero. 1467 Padding is a security feature; see Section 10.7. 1469 6.2. HEADERS 1471 The HEADERS frame (type=0x1) is used to open a stream (Section 5.1), 1472 and additionally carries a header block fragment. HEADERS frames can 1473 be sent on a stream in the "open" or "half closed (remote)" states. 1475 0 1 2 3 1476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 |Pad Length? (8)| 1479 +-+-------------+-----------------------------------------------+ 1480 |E| Stream Dependency? (31) | 1481 +-+-------------+-----------------------------------------------+ 1482 | Weight? (8) | 1483 +-+-------------+-----------------------------------------------+ 1484 | Header Block Fragment (*) ... 1485 +---------------------------------------------------------------+ 1486 | Padding (*) ... 1487 +---------------------------------------------------------------+ 1489 Figure 7: HEADERS Frame Payload 1491 The HEADERS frame payload has the following fields: 1493 Pad Length: An 8-bit field containing the length of the frame 1494 padding in units of octets. This field is only present if the 1495 PADDED flag is set. 1497 E: A single bit flag indicates that the stream dependency is 1498 exclusive, see Section 5.3. This field is only present if the 1499 PRIORITY flag is set. 1501 Stream Dependency: A 31-bit stream identifier for the stream that 1502 this stream depends on, see Section 5.3. This field is only 1503 present if the PRIORITY flag is set. 1505 Weight: An 8-bit weight for the stream, see Section 5.3. Add one to 1506 the value to obtain a weight between 1 and 256. This field is 1507 only present if the PRIORITY flag is set. 1509 Header Block Fragment: A header block fragment (Section 4.3). 1511 Padding: Padding octets that contain no application semantic value. 1512 Padding octets MUST be set to zero when sending and ignored when 1513 receiving. 1515 The HEADERS frame defines the following flags: 1517 END_STREAM (0x1): Bit 0 being set indicates that the header block 1518 (Section 4.3) is the last that the endpoint will send for the 1519 identified stream. Setting this flag causes the stream to enter 1520 one of "half closed" states (Section 5.1). 1522 A HEADERS frame carries the END_STREAM flag that signals the end 1523 of a stream. However, a HEADERS frame with the END_STREAM flag 1524 set can be followed by CONTINUATION frames on the same stream. 1525 Logically, the CONTINUATION frames are part of the HEADERS frame. 1527 END_HEADERS (0x4): Bit 2 being set indicates that this frame 1528 contains an entire header block (Section 4.3) and is not followed 1529 by any CONTINUATION frames. 1531 A HEADERS frame without the END_HEADERS flag set MUST be followed 1532 by a CONTINUATION frame for the same stream. A receiver MUST 1533 treat the receipt of any other type of frame or a frame on a 1534 different stream as a connection error (Section 5.4.1) of type 1535 PROTOCOL_ERROR. 1537 PADDED (0x8): Bit 3 being set indicates that the Pad Length field 1538 and any padding that it describes is present. 1540 PRIORITY (0x20): Bit 5 being set indicates that the Exclusive Flag 1541 (E), Stream Dependency, and Weight fields are present; see 1542 Section 5.3. 1544 The payload of a HEADERS frame contains a header block fragment 1545 (Section 4.3). A header block that does not fit within a HEADERS 1546 frame is continued in a CONTINUATION frame (Section 6.10). 1548 HEADERS frames MUST be associated with a stream. If a HEADERS frame 1549 is received whose stream identifier field is 0x0, the recipient MUST 1550 respond with a connection error (Section 5.4.1) of type 1551 PROTOCOL_ERROR. 1553 The HEADERS frame changes the connection state as described in 1554 Section 4.3. 1556 The HEADERS frame includes optional padding. Padding fields and 1557 flags are identical to those defined for DATA frames (Section 6.1). 1559 Prioritization information in a HEADERS frame is logically equivalent 1560 to a separate PRIORITY frame, but inclusion in HEADERS avoids the 1561 potential for churn in stream prioritization when new streams are 1562 created. Priorization fields in HEADERS frames subsequent to the 1563 first on a stream reprioritize the stream (Section 5.3.3). 1565 6.3. PRIORITY 1567 The PRIORITY frame (type=0x2) specifies the sender-advised priority 1568 of a stream (Section 5.3). It can be sent at any time for an 1569 existing stream, including closed streams. This enables 1570 reprioritization of existing streams. 1572 0 1 2 3 1573 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 |E| Stream Dependency (31) | 1576 +-+-------------+-----------------------------------------------+ 1577 | Weight (8) | 1578 +-+-------------+ 1580 Figure 8: PRIORITY Frame Payload 1582 The payload of a PRIORITY frame contains the following fields: 1584 E: A single bit flag indicates that the stream dependency is 1585 exclusive, see Section 5.3. 1587 Stream Dependency: A 31-bit stream identifier for the stream that 1588 this stream depends on, see Section 5.3. 1590 Weight: An 8-bit weight for the identified stream dependency, see 1591 Section 5.3. Add one to the value to obtain a weight between 1 1592 and 256. 1594 The PRIORITY frame does not define any flags. 1596 The PRIORITY frame is associated with an existing stream. If a 1597 PRIORITY frame is received with a stream identifier of 0x0, the 1598 recipient MUST respond with a connection error (Section 5.4.1) of 1599 type PROTOCOL_ERROR. 1601 The PRIORITY frame can be sent on a stream in any of the "reserved 1602 (remote)", "open", "half closed (local)", "half closed (remote)", or 1603 "closed" states, though it cannot be sent between consecutive frames 1604 that comprise a single header block (Section 4.3). Note that this 1605 frame could arrive after processing or frame sending has completed, 1606 which would cause it to have no effect on the current stream. For a 1607 stream that is in the "half closed (remote)" or "closed" - state, 1608 this frame can only affect processing of the current stream and not 1609 frame transmission. 1611 The PRIORITY frame is the only frame that can be sent for a stream in 1612 the "closed" state. This allows for the reprioritization of a group 1613 of dependent streams by altering the priority of a parent stream, 1614 which might be closed. However, a PRIORITY frame sent on a closed 1615 stream risks being ignored due to the peer having discarded priority 1616 state information for that stream. 1618 A PRIORITY frame with a length other than 5 octets MUST be treated as 1619 a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR. 1621 6.4. RST_STREAM 1623 The RST_STREAM frame (type=0x3) allows for immediate termination of a 1624 stream. RST_STREAM is sent to request cancellation of a stream, or 1625 to indicate that an error condition has occurred. 1627 0 1 2 3 1628 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Error Code (32) | 1631 +---------------------------------------------------------------+ 1633 Figure 9: RST_STREAM Frame Payload 1635 The RST_STREAM frame contains a single unsigned, 32-bit integer 1636 identifying the error code (Section 7). The error code indicates why 1637 the stream is being terminated. 1639 The RST_STREAM frame does not define any flags. 1641 The RST_STREAM frame fully terminates the referenced stream and 1642 causes it to enter the closed state. After receiving a RST_STREAM on 1643 a stream, the receiver MUST NOT send additional frames for that 1644 stream, with the exception of PRIORITY. However, after sending the 1645 RST_STREAM, the sending endpoint MUST be prepared to receive and 1646 process additional frames sent on the stream that might have been 1647 sent by the peer prior to the arrival of the RST_STREAM. 1649 RST_STREAM frames MUST be associated with a stream. If a RST_STREAM 1650 frame is received with a stream identifier of 0x0, the recipient MUST 1651 treat this as a connection error (Section 5.4.1) of type 1652 PROTOCOL_ERROR. 1654 RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. 1655 If a RST_STREAM frame identifying an idle stream is received, the 1656 recipient MUST treat this as a connection error (Section 5.4.1) of 1657 type PROTOCOL_ERROR. 1659 A RST_STREAM frame with a length other than 4 octets MUST be treated 1660 as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR. 1662 6.5. SETTINGS 1664 The SETTINGS frame (type=0x4) conveys configuration parameters that 1665 affect how endpoints communicate, such as preferences and constraints 1666 on peer behavior. The SETTINGS frame is also used to acknowledge the 1667 receipt of those parameters. Individually, a SETTINGS parameter can 1668 also be referred to as a "setting". 1670 SETTINGS parameters are not negotiated; they describe characteristics 1671 of the sending peer, which are used by the receiving peer. Different 1672 values for the same parameter can be advertised by each peer. For 1673 example, a client might set a high initial flow control window, 1674 whereas a server might set a lower value to conserve resources. 1676 A SETTINGS frame MUST be sent by both endpoints at the start of a 1677 connection, and MAY be sent at any other time by either endpoint over 1678 the lifetime of the connection. Implementations MUST support all of 1679 the parameters defined by this specification. 1681 Each parameter in a SETTINGS frame replaces any existing value for 1682 that parameter. Parameters are processed in the order in which they 1683 appear, and a receiver of a SETTINGS frame does not need to maintain 1684 any state other than the current value of its parameters. Therefore, 1685 the value of a SETTINGS parameter is the last value that is seen by a 1686 receiver. 1688 SETTINGS parameters are acknowledged by the receiving peer. To 1689 enable this, the SETTINGS frame defines the following flag: 1691 ACK (0x1): Bit 0 being set indicates that this frame acknowledges 1692 receipt and application of the peer's SETTINGS frame. When this 1693 bit is set, the payload of the SETTINGS frame MUST be empty. 1694 Receipt of a SETTINGS frame with the ACK flag set and a length 1695 field value other than 0 MUST be treated as a connection error 1696 (Section 5.4.1) of type FRAME_SIZE_ERROR. For more info, see 1697 Settings Synchronization (Section 6.5.3). 1699 SETTINGS frames always apply to a connection, never a single stream. 1700 The stream identifier for a SETTINGS frame MUST be zero (0x0). If an 1701 endpoint receives a SETTINGS frame whose stream identifier field is 1702 anything other than 0x0, the endpoint MUST respond with a connection 1703 error (Section 5.4.1) of type PROTOCOL_ERROR. 1705 The SETTINGS frame affects connection state. A badly formed or 1706 incomplete SETTINGS frame MUST be treated as a connection error 1707 (Section 5.4.1) of type PROTOCOL_ERROR. 1709 A SETTINGS frame with a length other than a multiple of 6 octets MUST 1710 be treated as a connection error (Section 5.4.1) of type 1711 FRAME_SIZE_ERROR. 1713 6.5.1. SETTINGS Format 1715 The payload of a SETTINGS frame consists of zero or more parameters, 1716 each consisting of an unsigned 16-bit setting identifier and an 1717 unsigned 32-bit value. 1719 0 1 2 3 1720 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Identifier (16) | 1723 +-------------------------------+-------------------------------+ 1724 | Value (32) | 1725 +---------------------------------------------------------------+ 1727 Figure 10: Setting Format 1729 6.5.2. Defined SETTINGS Parameters 1731 The following parameters are defined: 1733 SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the 1734 remote endpoint of the maximum size of the header compression 1735 table used to decode header blocks, in octets. The encoder can 1736 select any size equal to or less than this value by using 1737 signaling specific to the header compression format inside a 1738 header block. The initial value is 4,096 octets. 1740 SETTINGS_ENABLE_PUSH (0x2): This setting can be use to disable 1741 server push (Section 8.2). An endpoint MUST NOT send a 1742 PUSH_PROMISE frame if it receives this parameter set to a value of 1743 0. An endpoint that has both set this parameter to 0 and had it 1744 acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a 1745 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 1747 The initial value is 1, which indicates that server push is 1748 permitted. Any value other than 0 or 1 MUST be treated as a 1749 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 1751 SETTINGS_MAX_CONCURRENT_STREAMS (0x3): Indicates the maximum number 1752 of concurrent streams that the sender will allow. This limit is 1753 directional: it applies to the number of streams that the sender 1754 permits the receiver to create. Initially there is no limit to 1755 this value. It is recommended that this value be no smaller than 1756 100, so as to not unnecessarily limit parallelism. 1758 A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be 1759 treated as special by endpoints. A zero value does prevent the 1760 creation of new streams, however this can also happen for any 1761 limit that is exhausted with active streams. Servers SHOULD only 1762 set a zero value for short durations; if a server does not wish to 1763 accept requests, closing the connection could be preferable. 1765 SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial 1766 window size (in octets) for stream level flow control. The 1767 initial value is 2^16-1 (65,535) octets. 1769 This setting affects the window size of all streams, including 1770 existing streams, see Section 6.9.2. 1772 Values above the maximum flow control window size of 2^31-1 MUST 1773 be treated as a connection error (Section 5.4.1) of type 1774 FLOW_CONTROL_ERROR. 1776 SETTINGS_MAX_FRAME_SIZE (0x5): Indicates the size of the largest 1777 frame payload that the sender is willing to receive, in octets. 1779 The initial value is 2^14 (16,384) octets. The value advertised 1780 by an endpoint MUST be between this initial value and the maximum 1781 allowed frame size (2^24-1 or 16,777,215 octets), inclusive. 1782 Values outside this range MUST be treated as a connection error 1783 (Section 5.4.1) of type PROTOCOL_ERROR. 1785 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a 1786 peer of the maximum size of header list that the sender is 1787 prepared to accept, in octets. The value is based on the 1788 uncompressed size of header fields, including the length of the 1789 name and value in octets plus an overhead of 32 octets for each 1790 header field. 1792 For any given request, a lower limit than what is advertised MAY 1793 be enforced. The initial value of this setting is unlimited. 1795 An endpoint that receives a SETTINGS frame with any unknown or 1796 unsupported identifier MUST ignore that setting. 1798 6.5.3. Settings Synchronization 1800 Most values in SETTINGS benefit from or require an understanding of 1801 when the peer has received and applied the changed parameter values. 1802 In order to provide such synchronization timepoints, the recipient of 1803 a SETTINGS frame in which the ACK flag is not set MUST apply the 1804 updated parameters as soon as possible upon receipt. 1806 The values in the SETTINGS frame MUST be processed in the order they 1807 appear, with no other frame processing between values. Unsupported 1808 parameters MUST be ignored. Once all values have been processed, the 1809 recipient MUST immediately emit a SETTINGS frame with the ACK flag 1810 set. Upon receiving a SETTINGS frame with the ACK flag set, the 1811 sender of the altered parameters can rely on the setting having been 1812 applied. 1814 If the sender of a SETTINGS frame does not receive an acknowledgement 1815 within a reasonable amount of time, it MAY issue a connection error 1816 (Section 5.4.1) of type SETTINGS_TIMEOUT. 1818 6.6. PUSH_PROMISE 1820 The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint 1821 in advance of streams the sender intends to initiate. The 1822 PUSH_PROMISE frame includes the unsigned 31-bit identifier of the 1823 stream the endpoint plans to create along with a set of headers that 1824 provide additional context for the stream. Section 8.2 contains a 1825 thorough description of the use of PUSH_PROMISE frames. 1827 0 1 2 3 1828 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 |Pad Length? (8)| 1831 +-+-------------+-----------------------------------------------+ 1832 |R| Promised Stream ID (31) | 1833 +-+-----------------------------+-------------------------------+ 1834 | Header Block Fragment (*) ... 1835 +---------------------------------------------------------------+ 1836 | Padding (*) ... 1837 +---------------------------------------------------------------+ 1839 Figure 11: PUSH_PROMISE Payload Format 1841 The PUSH_PROMISE frame payload has the following fields: 1843 Pad Length: An 8-bit field containing the length of the frame 1844 padding in units of octets. This field is only present if the 1845 PADDED flag is set. 1847 R: A single reserved bit. 1849 Promised Stream ID: An unsigned 31-bit integer that identifies the 1850 stream that is reserved by the PUSH_PROMISE. The promised stream 1851 identifier MUST be a valid choice for the next stream sent by the 1852 sender (see new stream identifier (Section 5.1.1)). 1854 Header Block Fragment: A header block fragment (Section 4.3) 1855 containing request header fields. 1857 Padding: Padding octets. 1859 The PUSH_PROMISE frame defines the following flags: 1861 END_HEADERS (0x4): Bit 2 being set indicates that this frame 1862 contains an entire header block (Section 4.3) and is not followed 1863 by any CONTINUATION frames. 1865 A PUSH_PROMISE frame without the END_HEADERS flag set MUST be 1866 followed by a CONTINUATION frame for the same stream. A receiver 1867 MUST treat the receipt of any other type of frame or a frame on a 1868 different stream as a connection error (Section 5.4.1) of type 1869 PROTOCOL_ERROR. 1871 PADDED (0x8): Bit 3 being set indicates that the Pad Length field 1872 and any padding that it describes is present. 1874 PUSH_PROMISE frames MUST be associated with an existing, peer- 1875 initiated stream. The stream identifier of a PUSH_PROMISE frame 1876 indicates the stream it is associated with. If the stream identifier 1877 field specifies the value 0x0, a recipient MUST respond with a 1878 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 1880 Promised streams are not required to be used in the order they are 1881 promised. The PUSH_PROMISE only reserves stream identifiers for 1882 later use. 1884 PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of 1885 the peer endpoint is set to 0. An endpoint that has set this setting 1886 and has received acknowledgement MUST treat the receipt of a 1887 PUSH_PROMISE frame as a connection error (Section 5.4.1) of type 1888 PROTOCOL_ERROR. 1890 Recipients of PUSH_PROMISE frames can choose to reject promised 1891 streams by returning a RST_STREAM referencing the promised stream 1892 identifier back to the sender of the PUSH_PROMISE. 1894 A PUSH_PROMISE frame modifies the connection state in two ways. The 1895 inclusion of a header block (Section 4.3) potentially modifies the 1896 state maintained for header compression. PUSH_PROMISE also reserves 1897 a stream for later use, causing the promised stream to enter the 1898 "reserved" state. A sender MUST NOT send a PUSH_PROMISE on a stream 1899 unless that stream is either "open" or "half closed (remote)"; the 1900 sender MUST ensure that the promised stream is a valid choice for a 1901 new stream identifier (Section 5.1.1) (that is, the promised stream 1902 MUST be in the "idle" state). 1904 Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame 1905 causes the stream state to become indeterminate. A receiver MUST 1906 treat the receipt of a PUSH_PROMISE on a stream that is neither 1907 "open" nor "half closed (local)" as a connection error 1908 (Section 5.4.1) of type PROTOCOL_ERROR. However, an endpoint that 1909 has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE 1910 frames that might have been created before the RST_STREAM frame is 1911 received and processed. 1913 A receiver MUST treat the receipt of a PUSH_PROMISE that promises an 1914 illegal stream identifier (Section 5.1.1) (that is, an identifier for 1915 a stream that is not currently in the "idle" state) as a connection 1916 error (Section 5.4.1) of type PROTOCOL_ERROR. 1918 The PUSH_PROMISE frame includes optional padding. Padding fields and 1919 flags are identical to those defined for DATA frames (Section 6.1). 1921 6.7. PING 1923 The PING frame (type=0x6) is a mechanism for measuring a minimal 1924 round trip time from the sender, as well as determining whether an 1925 idle connection is still functional. PING frames can be sent from 1926 any endpoint. 1928 0 1 2 3 1929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | | 1932 | Opaque Data (64) | 1933 | | 1934 +---------------------------------------------------------------+ 1936 Figure 12: PING Payload Format 1938 In addition to the frame header, PING frames MUST contain 8 octets of 1939 data in the payload. A sender can include any value it chooses and 1940 use those octets in any fashion. 1942 Receivers of a PING frame that does not include an ACK flag MUST send 1943 a PING frame with the ACK flag set in response, with an identical 1944 payload. PING responses SHOULD be given higher priority than any 1945 other frame. 1947 The PING frame defines the following flags: 1949 ACK (0x1): Bit 0 being set indicates that this PING frame is a PING 1950 response. An endpoint MUST set this flag in PING responses. An 1951 endpoint MUST NOT respond to PING frames containing this flag. 1953 PING frames are not associated with any individual stream. If a PING 1954 frame is received with a stream identifier field value other than 1955 0x0, the recipient MUST respond with a connection error 1956 (Section 5.4.1) of type PROTOCOL_ERROR. 1958 Receipt of a PING frame with a length field value other than 8 MUST 1959 be treated as a connection error (Section 5.4.1) of type 1960 FRAME_SIZE_ERROR. 1962 6.8. GOAWAY 1964 The GOAWAY frame (type=0x7) informs the remote peer to stop creating 1965 streams on this connection. GOAWAY can be sent by either the client 1966 or the server. Once sent, the sender will ignore frames sent on any 1967 new streams with identifiers higher than the included last stream 1968 identifier. Receivers of a GOAWAY frame MUST NOT open additional 1969 streams on the connection, although a new connection can be 1970 established for new streams. 1972 The purpose of this frame is to allow an endpoint to gracefully stop 1973 accepting new streams, while still finishing processing of previously 1974 established streams. This enables administrative actions, like 1975 server maintainance. 1977 There is an inherent race condition between an endpoint starting new 1978 streams and the remote sending a GOAWAY frame. To deal with this 1979 case, the GOAWAY contains the stream identifier of the last peer- 1980 initiated stream which was or might be processed on the sending 1981 endpoint in this connection. For instance, if the server sends a 1982 GOAWAY frame, the identified stream is the highest numbered stream 1983 initiated by the client. 1985 If the receiver of the GOAWAY has sent data on streams with a higher 1986 stream identifier than what is indicated in the GOAWAY frame, those 1987 streams are not or will not be processed. The receiver of the GOAWAY 1988 frame can treat the streams as though they had never been created at 1989 all, thereby allowing those streams to be retried later on a new 1990 connection. 1992 Endpoints SHOULD always send a GOAWAY frame before closing a 1993 connection so that the remote can know whether a stream has been 1994 partially processed or not. For example, if an HTTP client sends a 1995 POST at the same time that a server closes a connection, the client 1996 cannot know if the server started to process that POST request if the 1997 server does not send a GOAWAY frame to indicate what streams it might 1998 have acted on. 2000 An endpoint might choose to close a connection without sending GOAWAY 2001 for misbehaving peers. 2003 0 1 2 3 2004 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 |R| Last-Stream-ID (31) | 2007 +-+-------------------------------------------------------------+ 2008 | Error Code (32) | 2009 +---------------------------------------------------------------+ 2010 | Additional Debug Data (*) | 2011 +---------------------------------------------------------------+ 2013 Figure 13: GOAWAY Payload Format 2015 The GOAWAY frame does not define any flags. 2017 The GOAWAY frame applies to the connection, not a specific stream. 2018 An endpoint MUST treat a GOAWAY frame with a stream identifier other 2019 than 0x0 as a connection error (Section 5.4.1) of type 2020 PROTOCOL_ERROR. 2022 The last stream identifier in the GOAWAY frame contains the highest 2023 numbered stream identifier for which the sender of the GOAWAY frame 2024 might have taken some action on, or might yet take action on. All 2025 streams up to and including the identified stream might have been 2026 processed in some way. The last stream identifier can be set to 0 if 2027 no streams were processed. 2029 Note: In this context, "processed" means that some data from the 2030 stream was passed to some higher layer of software that might have 2031 taken some action as a result. 2033 If a connection terminates without a GOAWAY frame, the last stream 2034 identifier is effectively the highest possible stream identifier. 2036 On streams with lower or equal numbered identifiers that were not 2037 closed completely prior to the connection being closed, re-attempting 2038 requests, transactions, or any protocol activity is not possible, 2039 with the exception of idempotent actions like HTTP GET, PUT, or 2040 DELETE. Any protocol activity that uses higher numbered streams can 2041 be safely retried using a new connection. 2043 Activity on streams numbered lower or equal to the last stream 2044 identifier might still complete successfully. The sender of a GOAWAY 2045 frame might gracefully shut down a connection by sending a GOAWAY 2046 frame, maintaining the connection in an open state until all in- 2047 progress streams complete. 2049 An endpoint MAY send multiple GOAWAY frames if circumstances change. 2050 For instance, an endpoint that sends GOAWAY with NO_ERROR during 2051 graceful shutdown could subsequently encounter an condition that 2052 requires immediate termination of the connection. The last stream 2053 identifier from the last GOAWAY frame received indicates which 2054 streams could have been acted upon. Endpoints MUST NOT increase the 2055 value they send in the last stream identifier, since the peers might 2056 already have retried unprocessed requests on another connection. 2058 A client that is unable to retry requests loses all requests that are 2059 in flight when the server closes the connection. This is especially 2060 true for intermediaries that might not be serving clients using 2061 HTTP/2. A server that is attempting to gracefully shut down a 2062 connection SHOULD send an initial GOAWAY frame with the last stream 2063 identifier set to 2^31-1 and a NO_ERROR code. This signals to the 2064 client that a shutdown is imminent and that no further requests can 2065 be initiated. After waiting at least one round trip time, the server 2066 can send another GOAWAY frame with an updated last stream identifier. 2067 This ensures that a connection can be cleanly shut down without 2068 losing requests. 2070 After sending a GOAWAY frame, the sender can discard frames for 2071 streams with identifiers higher than the identified last stream. 2072 However, any frames that alter connection state cannot be completely 2073 ignored. For instance, HEADERS, PUSH_PROMISE and CONTINUATION frames 2074 MUST be minimally processed to ensure the state maintained for header 2075 compression is consistent (see Section 4.3); similarly DATA frames 2076 MUST be counted toward the connection flow control window. Failure 2077 to process these frames can cause flow control or header compression 2078 state to become unsynchronized. 2080 The GOAWAY frame also contains a 32-bit error code (Section 7) that 2081 contains the reason for closing the connection. 2083 Endpoints MAY append opaque data to the payload of any GOAWAY frame. 2084 Additional debug data is intended for diagnostic purposes only and 2085 carries no semantic value. Debug information could contain security- 2086 or privacy-sensitive data. Logged or otherwise persistently stored 2087 debug data MUST have adequate safeguards to prevent unauthorized 2088 access. 2090 6.9. WINDOW_UPDATE 2092 The WINDOW_UPDATE frame (type=0x8) is used to implement flow control; 2093 see Section 5.2 for an overview. 2095 Flow control operates at two levels: on each individual stream and on 2096 the entire connection. 2098 Both types of flow control are hop-by-hop; that is, only between the 2099 two endpoints. Intermediaries do not forward WINDOW_UPDATE frames 2100 between dependent connections. However, throttling of data transfer 2101 by any receiver can indirectly cause the propagation of flow control 2102 information toward the original sender. 2104 Flow control only applies to frames that are identified as being 2105 subject to flow control. Of the frame types defined in this 2106 document, this includes only DATA frames. Frames that are exempt 2107 from flow control MUST be accepted and processed, unless the receiver 2108 is unable to assign resources to handling the frame. A receiver MAY 2109 respond with a stream error (Section 5.4.2) or connection error 2110 (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept 2111 a frame. 2113 0 1 2 3 2114 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |R| Window Size Increment (31) | 2117 +-+-------------------------------------------------------------+ 2119 Figure 14: WINDOW_UPDATE Payload Format 2121 The payload of a WINDOW_UPDATE frame is one reserved bit, plus an 2122 unsigned 31-bit integer indicating the number of octets that the 2123 sender can transmit in addition to the existing flow control window. 2124 The legal range for the increment to the flow control window is 1 to 2125 2^31-1 (2,147,483,647) octets. 2127 The WINDOW_UPDATE frame does not define any flags. 2129 The WINDOW_UPDATE frame can be specific to a stream or to the entire 2130 connection. In the former case, the frame's stream identifier 2131 indicates the affected stream; in the latter, the value "0" indicates 2132 that the entire connection is the subject of the frame. 2134 A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an 2135 flow control window increment of 0 as a stream error (Section 5.4.2) 2136 of type PROTOCOL_ERROR; errors on the connection flow control window 2137 MUST be treated as a connection error (Section 5.4.1). 2139 WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the 2140 END_STREAM flag. This means that a receiver could receive a 2141 WINDOW_UPDATE frame on a "half closed (remote)" or "closed" stream. 2142 A receiver MUST NOT treat this as an error, see Section 5.1. 2144 A receiver that receives a flow controlled frame MUST always account 2145 for its contribution against the connection flow control window, 2146 unless the receiver treats this as a connection error 2147 (Section 5.4.1). This is necessary even if the frame is in error. 2148 Since the sender counts the frame toward the flow control window, if 2149 the receiver does not, the flow control window at sender and receiver 2150 can become different. 2152 A WINDOW_UPDATE frame with a length other than 4 octets MUST be 2153 treated as a connection error (Section 5.4.1) of type 2154 FRAME_SIZE_ERROR. 2156 6.9.1. The Flow Control Window 2158 Flow control in HTTP/2 is implemented using a window kept by each 2159 sender on every stream. The flow control window is a simple integer 2160 value that indicates how many octets of data the sender is permitted 2161 to transmit; as such, its size is a measure of the buffering capacity 2162 of the receiver. 2164 Two flow control windows are applicable: the stream flow control 2165 window and the connection flow control window. The sender MUST NOT 2166 send a flow controlled frame with a length that exceeds the space 2167 available in either of the flow control windows advertised by the 2168 receiver. Frames with zero length with the END_STREAM flag set (that 2169 is, an empty DATA frame) MAY be sent if there is no available space 2170 in either flow control window. 2172 For flow control calculations, the 9 octet frame header is not 2173 counted. 2175 After sending a flow controlled frame, the sender reduces the space 2176 available in both windows by the length of the transmitted frame. 2178 The receiver of a frame sends a WINDOW_UPDATE frame as it consumes 2179 data and frees up space in flow control windows. Separate 2180 WINDOW_UPDATE frames are sent for the stream and connection level 2181 flow control windows. 2183 A sender that receives a WINDOW_UPDATE frame updates the 2184 corresponding window by the amount specified in the frame. 2186 A sender MUST NOT allow a flow control window to exceed 2^31-1 2187 octets. If a sender receives a WINDOW_UPDATE that causes a flow 2188 control window to exceed this maximum it MUST terminate either the 2189 stream or the connection, as appropriate. For streams, the sender 2190 sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code; 2191 for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code. 2193 Flow controlled frames from the sender and WINDOW_UPDATE frames from 2194 the receiver are completely asynchronous with respect to each other. 2195 This property allows a receiver to aggressively update the window 2196 size kept by the sender to prevent streams from stalling. 2198 6.9.2. Initial Flow Control Window Size 2200 When an HTTP/2 connection is first established, new streams are 2201 created with an initial flow control window size of 65,535 octets. 2202 The connection flow control window is 65,535 octets. Both endpoints 2203 can adjust the initial window size for new streams by including a 2204 value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that 2205 forms part of the connection preface. The connection flow control 2206 window can only be changed using WINDOW_UPDATE frames. 2208 Prior to receiving a SETTINGS frame that sets a value for 2209 SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default 2210 initial window size when sending flow controlled frames. Similarly, 2211 the connection flow control window is set to the default initial 2212 window size until a WINDOW_UPDATE frame is received. 2214 A SETTINGS frame can alter the initial flow control window size for 2215 all current streams. When the value of SETTINGS_INITIAL_WINDOW_SIZE 2216 changes, a receiver MUST adjust the size of all stream flow control 2217 windows that it maintains by the difference between the new value and 2218 the old value. 2220 A change to SETTINGS_INITIAL_WINDOW_SIZE can cause the available 2221 space in a flow control window to become negative. A sender MUST 2222 track the negative flow control window, and MUST NOT send new flow 2223 controlled frames until it receives WINDOW_UPDATE frames that cause 2224 the flow control window to become positive. 2226 For example, if the client sends 60KB immediately on connection 2227 establishment, and the server sets the initial window size to be 2228 16KB, the client will recalculate the available flow control window 2229 to be -44KB on receipt of the SETTINGS frame. The client retains a 2230 negative flow control window until WINDOW_UPDATE frames restore the 2231 window to being positive, after which the client can resume sending. 2233 A SETTINGS frame cannot alter the connection flow control window. 2235 An endpoint MUST treat a change to SETTINGS_INITIAL_WINDOW_SIZE that 2236 causes any flow control window to exceed the maximum size as a 2237 connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR. 2239 6.9.3. Reducing the Stream Window Size 2241 A receiver that wishes to use a smaller flow control window than the 2242 current size can send a new SETTINGS frame. However, the receiver 2243 MUST be prepared to receive data that exceeds this window size, since 2244 the sender might send data that exceeds the lower limit prior to 2245 processing the SETTINGS frame. 2247 After sending a SETTINGS frame that reduces the initial flow control 2248 window size, a receiver has two options for handling streams that 2249 exceed flow control limits: 2251 1. The receiver can immediately send RST_STREAM with 2252 FLOW_CONTROL_ERROR error code for the affected streams. 2254 2. The receiver can accept the streams and tolerate the resulting 2255 head of line blocking, sending WINDOW_UPDATE frames as it 2256 consumes data. 2258 6.10. CONTINUATION 2260 The CONTINUATION frame (type=0x9) is used to continue a sequence of 2261 header block fragments (Section 4.3). Any number of CONTINUATION 2262 frames can be sent on an existing stream, as long as the preceding 2263 frame is on the same stream and is a HEADERS, PUSH_PROMISE or 2264 CONTINUATION frame without the END_HEADERS flag set. 2266 0 1 2 3 2267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | Header Block Fragment (*) ... 2270 +---------------------------------------------------------------+ 2272 Figure 15: CONTINUATION Frame Payload 2274 The CONTINUATION frame payload contains a header block fragment 2275 (Section 4.3). 2277 The CONTINUATION frame defines the following flag: 2279 END_HEADERS (0x4): Bit 2 being set indicates that this frame ends a 2280 header block (Section 4.3). 2282 If the END_HEADERS bit is not set, this frame MUST be followed by 2283 another CONTINUATION frame. A receiver MUST treat the receipt of 2284 any other type of frame or a frame on a different stream as a 2285 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 2287 The CONTINUATION frame changes the connection state as defined in 2288 Section 4.3. 2290 CONTINUATION frames MUST be associated with a stream. If a 2291 CONTINUATION frame is received whose stream identifier field is 0x0, 2292 the recipient MUST respond with a connection error (Section 5.4.1) of 2293 type PROTOCOL_ERROR. 2295 A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or 2296 CONTINUATION frame without the END_HEADERS flag set. A recipient 2297 that observes violation of this rule MUST respond with a connection 2298 error (Section 5.4.1) of type PROTOCOL_ERROR. 2300 7. Error Codes 2302 Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY 2303 frames to convey the reasons for the stream or connection error. 2305 Error codes share a common code space. Some error codes apply only 2306 to either streams or the entire connection and have no defined 2307 semantics in the other context. 2309 The following error codes are defined: 2311 NO_ERROR (0x0): The associated condition is not as a result of an 2312 error. For example, a GOAWAY might include this code to indicate 2313 graceful shutdown of a connection. 2315 PROTOCOL_ERROR (0x1): The endpoint detected an unspecific protocol 2316 error. This error is for use when a more specific error code is 2317 not available. 2319 INTERNAL_ERROR (0x2): The endpoint encountered an unexpected 2320 internal error. 2322 FLOW_CONTROL_ERROR (0x3): The endpoint detected that its peer 2323 violated the flow control protocol. 2325 SETTINGS_TIMEOUT (0x4): The endpoint sent a SETTINGS frame, but did 2326 not receive a response in a timely manner. See Settings 2327 Synchronization (Section 6.5.3). 2329 STREAM_CLOSED (0x5): The endpoint received a frame after a stream 2330 was half closed. 2332 FRAME_SIZE_ERROR (0x6): The endpoint received a frame with an 2333 invalid size. 2335 REFUSED_STREAM (0x7): The endpoint refuses the stream prior to 2336 performing any application processing, see Section 8.1.4 for 2337 details. 2339 CANCEL (0x8): Used by the endpoint to indicate that the stream is no 2340 longer needed. 2342 COMPRESSION_ERROR (0x9): The endpoint is unable to maintain the 2343 header compression context for the connection. 2345 CONNECT_ERROR (0xa): The connection established in response to a 2346 CONNECT request (Section 8.3) was reset or abnormally closed. 2348 ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is 2349 exhibiting a behavior that might be generating excessive load. 2351 INADEQUATE_SECURITY (0xc): The underlying transport has properties 2352 that do not meet minimum security requirements (see Section 9.2). 2354 HTTP_1_1_REQUIRED (0xd): The endpoint requires that HTTP/1.1 be used 2355 instead of HTTP/2. 2357 Unknown or unsupported error codes MUST NOT trigger any special 2358 behavior. These MAY be treated by an implementation as being 2359 equivalent to INTERNAL_ERROR. 2361 8. HTTP Message Exchanges 2363 HTTP/2 is intended to be as compatible as possible with current uses 2364 of HTTP. This means that, from the application perspective, the 2365 features of the protocol are largely unchanged. To achieve this, all 2366 request and response semantics are preserved, although the syntax of 2367 conveying those semantics has changed. 2369 Thus, the specification and requirements of HTTP/1.1 Semantics and 2370 Content [RFC7231], Conditional Requests [RFC7232], Range Requests 2371 [RFC7233], Caching [RFC7234] and Authentication [RFC7235] are 2372 applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax 2373 and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are 2374 also applicable in HTTP/2, but the expression of those semantics for 2375 this protocol are defined in the sections below. 2377 8.1. HTTP Request/Response Exchange 2379 A client sends an HTTP request on a new stream, using a previously 2380 unused stream identifier (Section 5.1.1). A server sends an HTTP 2381 response on the same stream as the request. 2383 An HTTP message (request or response) consists of: 2385 1. for a response only, zero or more HEADERS frames (each followed 2386 by zero or more CONTINUATION frames) containing the message 2387 headers of informational (1xx) HTTP responses (see [RFC7230], 2388 Section 3.2 and [RFC7231], Section 6.2), and 2390 2. one HEADERS frame (followed by zero or more CONTINUATION frames) 2391 containing the message headers (see [RFC7230], Section 3.2), and 2393 3. zero or more DATA frames containing the message payload (see 2394 [RFC7230], Section 3.3), and 2396 4. optionally, one HEADERS frame, followed by zero or more 2397 CONTINUATION frames containing the trailer-part, if present (see 2398 [RFC7230], Section 4.1.2). 2400 The last frame in the sequence bears an END_STREAM flag, noting that 2401 a HEADERS frame bearing the END_STREAM flag can be followed by 2402 CONTINUATION frames that carry any remaining portions of the header 2403 block. 2405 Other frames (from any stream) MUST NOT occur between either HEADERS 2406 frame and any CONTINUATION frames that might follow. 2408 HTTP/2 uses DATA frames to carry message payloads. The "chunked" 2409 transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be 2410 used in HTTP/2. 2412 Trailing header fields are carried in a header block that also 2413 terminates the stream. Such a header block is a sequence starting 2414 with a HEADERS frame, followed by zero or more CONTINUATION frames, 2415 where the HEADERS frame bears an END_STREAM flag. Header blocks 2416 after the first that do not terminate the stream are not part of an 2417 HTTP request or response. 2419 A HEADERS frame (and associated CONTINUATION frames) can only appear 2420 at the start or end of a stream. An endpoint that receives a HEADERS 2421 frame without the END_STREAM flag set after receiving a final (non- 2422 informational) status code MUST treat the corresponding request or 2423 response as malformed (Section 8.1.2.6). 2425 An HTTP request/response exchange fully consumes a single stream. A 2426 request starts with the HEADERS frame that puts the stream into an 2427 "open" state. The request ends with a frame bearing END_STREAM, 2428 which causes the stream to become "half closed (local)" for the 2429 client and "half closed (remote)" for the server. A response starts 2430 with a HEADERS frame and ends with a frame bearing END_STREAM, which 2431 places the stream in the "closed" state. 2433 An HTTP response is complete after the server sends - or the client 2434 receives - a frame with the END_STREAM flag set (including any 2435 CONTINUATION frames needed to complete a header block). A server can 2436 send a complete response prior to the client sending an entire 2437 request if the response does not depend on any portion of the request 2438 that has not been sent and received. When this is true, a server MAY 2439 request that the client abort transmission of a request without error 2440 by sending a RST_STREAM with an error code of NO_ERROR after sending 2441 a complete response (i.e., a frame with the END_STREAM flag). 2442 Clients MUST NOT discard responses as a result of receiving such a 2443 RST_STREAM, though clients can always discard responses at their 2444 discretion for other reasons. 2446 8.1.1. Upgrading From HTTP/2 2448 HTTP/2 removes support for the 101 (Switching Protocols) 2449 informational status code ([RFC7231], Section 6.2.2). 2451 The semantics of 101 (Switching Protocols) aren't applicable to a 2452 multiplexed protocol. Alternative protocols are able to use the same 2453 mechanisms that HTTP/2 uses to negotiate their use (see Section 3). 2455 8.1.2. HTTP Header Fields 2457 HTTP header fields carry information as a series of key-value pairs. 2458 For a listing of registered HTTP headers, see the Message Header 2459 Field Registry maintained at [4]. 2461 8.1.2.1. Pseudo-Header Fields 2463 While HTTP/1.x used the message start-line (see [RFC7230], 2464 Section 3.1) to convey the target URI and method of the request, and 2465 the status code for the response, HTTP/2 uses special pseudo-header 2466 fields beginning with ':' character (ASCII 0x3a) for this purpose. 2468 Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT 2469 generate pseudo-header fields other than those defined in this 2470 document. 2472 Pseudo-header fields are only valid in the context in which they are 2473 defined. Pseudo-header fields defined for requests MUST NOT appear 2474 in responses; pseudo-header fields defined for responses MUST NOT 2475 appear in requests. Pseudo-header fields MUST NOT appear in 2476 trailers. Endpoints MUST treat a request or response that contains 2477 undefined or invalid pseudo-header fields as malformed 2478 (Section 8.1.2.6). 2480 Just as in HTTP/1.x, header field names are strings of ASCII 2481 characters that are compared in a case-insensitive fashion. However, 2482 header field names MUST be converted to lowercase prior to their 2483 encoding in HTTP/2. A request or response containing uppercase 2484 header field names MUST be treated as malformed (Section 8.1.2.6). 2486 All pseudo-header fields MUST appear in the header block before 2487 regular header fields. Any request or response that contains a 2488 pseudo-header field that appears in a header block after a regular 2489 header field MUST be treated as malformed (Section 8.1.2.6). 2491 8.1.2.2. Connection-Specific Header Fields 2493 HTTP/2 does not use the "Connection" header field to indicate 2494 connection-specific header fields; in this protocol, connection- 2495 specific metadata is conveyed by other means. An endpoint MUST NOT 2496 generate an HTTP/2 message containing connection-specific header 2497 fields; any message containing connection-specific header fields MUST 2498 be treated as malformed (Section 8.1.2.6). 2500 This means that an intermediary transforming an HTTP/1.x message to 2501 HTTP/2 will need to remove any header fields nominated by the 2502 Connection header field, along with the Connection header field 2503 itself. Such intermediaries SHOULD also remove other connection- 2504 specific header fields, such as Keep-Alive, Proxy-Connection, 2505 Transfer-Encoding and Upgrade, even if they are not nominated by 2506 Connection. 2508 One exception to this is the TE header field, which MAY be present in 2509 an HTTP/2 request, but when it is, it MUST NOT contain any value 2510 other than "trailers". 2512 Note: HTTP/2 purposefully does not support upgrade to another 2513 protocol. The handshake methods described in Section 3 are 2514 believed sufficient to negotiate the use of alternative protocols. 2516 8.1.2.3. Request Pseudo-Header Fields 2518 The following pseudo-header fields are defined for HTTP/2 requests: 2520 o The ":method" pseudo-header field includes the HTTP method 2521 ([RFC7231], Section 4). 2523 o The ":scheme" pseudo-header field includes the scheme portion of 2524 the target URI ([RFC3986], Section 3.1). 2526 ":scheme" is not restricted to "http" and "https" schemed URIs. A 2527 proxy or gateway can translate requests for non-HTTP schemes, 2528 enabling the use of HTTP to interact with non-HTTP services. 2530 o The ":authority" pseudo-header field includes the authority 2531 portion of the target URI ([RFC3986], Section 3.2). The authority 2532 MUST NOT include the deprecated "userinfo" subcomponent for "http" 2533 or "https" schemed URIs. 2535 To ensure that the HTTP/1.1 request line can be reproduced 2536 accurately, this pseudo-header field MUST be omitted when 2537 translating from an HTTP/1.1 request that has a request target in 2538 origin or asterisk form (see [RFC7230], Section 5.3). Clients 2539 that generate HTTP/2 requests directly SHOULD use the _:authority_ 2540 pseudo-header field instead of the "Host" header field. An 2541 intermediary that converts an HTTP/2 request to HTTP/1.1 MUST 2542 create a "Host" header field if one is not present in a request by 2543 copying the value of the ":authority" pseudo-header field. 2545 o The ":path" pseudo-header field includes the path and query parts 2546 of the target URI (the "path-absolute" production from [RFC3986] 2547 and optionally a '?' character followed by the "query" production, 2548 see [RFC3986], Section 3.3 and [RFC3986], Section 3.4). A request 2549 in asterisk form includes the value '*' for the ":path" pseudo- 2550 header field. 2552 This pseudo-header field MUST NOT be empty for "http" or "https" 2553 URIs; "http" or "https" URIs that do not contain a path component 2554 MUST include a value of '/'. The exception to this rule is an 2555 OPTIONS request for an "http" or "https" URI that does not include 2556 a path component; these MUST include a ":path" pseudo-header field 2557 with a value of '*' (see [RFC7230], Section 5.3.4). 2559 All HTTP/2 requests MUST include exactly one valid value for the 2560 ":method", ":scheme", and ":path" pseudo-header fields, unless it is 2561 a CONNECT request (Section 8.3). An HTTP request that omits 2562 mandatory pseudo-header fields is malformed (Section 8.1.2.6). 2564 HTTP/2 does not define a way to carry the version identifier that is 2565 included in the HTTP/1.1 request line. 2567 8.1.2.4. Response Pseudo-Header Fields 2569 For HTTP/2 responses, a single ":status" pseudo-header field is 2570 defined that carries the HTTP status code field (see [RFC7231], 2571 Section 6). This pseudo-header field MUST be included in all 2572 responses, otherwise the response is malformed (Section 8.1.2.6). 2574 HTTP/2 does not define a way to carry the version or reason phrase 2575 that is included in an HTTP/1.1 status line. 2577 8.1.2.5. Compressing the Cookie Header Field 2579 The Cookie header field [COOKIE] can carry a significant amount of 2580 redundant data. 2582 The Cookie header field uses a semi-colon (";") to delimit cookie- 2583 pairs (or "crumbs"). This header field doesn't follow the list 2584 construction rules in HTTP (see [RFC7230], Section 3.2.2), which 2585 prevents cookie-pairs from being separated into different name-value 2586 pairs. This can significantly reduce compression efficiency as 2587 individual cookie-pairs are updated. 2589 To allow for better compression efficiency, the Cookie header field 2590 MAY be split into separate header fields, each with one or more 2591 cookie-pairs. If there are multiple Cookie header fields after 2592 decompression, these MUST be concatenated into a single octet string 2593 using the two octet delimiter of 0x3B, 0x20 (the ASCII string "; ") 2594 before being passed into a non-HTTP/2 context, such as an HTTP/1.1 2595 connection, or a generic HTTP server application. 2597 Therefore, the following two lists of Cookie header fields are 2598 semantically equivalent. 2600 cookie: a=b; c=d; e=f 2602 cookie: a=b 2603 cookie: c=d 2604 cookie: e=f 2606 8.1.2.6. Malformed Requests and Responses 2608 A malformed request or response is one that is an otherwise valid 2609 sequence of HTTP/2 frames, but is otherwise invalid due to the 2610 presence of extraneous frames, prohibited header fields, the absence 2611 of mandatory header fields, or the inclusion of uppercase header 2612 field names. 2614 A request or response that includes an entity body can include a 2615 "content-length" header field. A request or response is also 2616 malformed if the value of a "content-length" header field does not 2617 equal the sum of the DATA frame payload lengths that form the body. 2618 A response that is defined to have no payload, as described in 2619 [RFC7230], Section 3.3.2, can have a non-zero "content-length" header 2620 field, even though no content is included in DATA frames. 2622 Intermediaries that process HTTP requests or responses (i.e., any 2623 intermediary not acting as a tunnel) MUST NOT forward a malformed 2624 request or response. Malformed requests or responses that are 2625 detected MUST be treated as a stream error (Section 5.4.2) of type 2626 PROTOCOL_ERROR. 2628 For malformed requests, a server MAY send an HTTP response prior to 2629 closing or resetting the stream. Clients MUST NOT accept a malformed 2630 response. Note that these requirements are intended to protect 2631 against several types of common attacks against HTTP; they are 2632 deliberately strict, because being permissive can expose 2633 implementations to these vulnerabilities. 2635 8.1.3. Examples 2637 This section shows HTTP/1.1 requests and responses, with 2638 illustrations of equivalent HTTP/2 requests and responses. 2640 An HTTP GET request includes request header fields and no body and is 2641 therefore transmitted as a single HEADERS frame, followed by zero or 2642 more CONTINUATION frames containing the serialized block of request 2643 header fields. The HEADERS frame in the following has both the 2644 END_HEADERS and END_STREAM flags set; no CONTINUATION frames are 2645 sent: 2647 GET /resource HTTP/1.1 HEADERS 2648 Host: example.org ==> + END_STREAM 2649 Accept: image/jpeg + END_HEADERS 2650 :method = GET 2651 :scheme = https 2652 :path = /resource 2653 host = example.org 2654 accept = image/jpeg 2656 Similarly, a response that includes only response header fields is 2657 transmitted as a HEADERS frame (again, followed by zero or more 2658 CONTINUATION frames) containing the serialized block of response 2659 header fields. 2661 HTTP/1.1 304 Not Modified HEADERS 2662 ETag: "xyzzy" ==> + END_STREAM 2663 Expires: Thu, 23 Jan ... + END_HEADERS 2664 :status = 304 2665 etag = "xyzzy" 2666 expires = Thu, 23 Jan ... 2668 An HTTP POST request that includes request header fields and payload 2669 data is transmitted as one HEADERS frame, followed by zero or more 2670 CONTINUATION frames containing the request header fields, followed by 2671 one or more DATA frames, with the last CONTINUATION (or HEADERS) 2672 frame having the END_HEADERS flag set and the final DATA frame having 2673 the END_STREAM flag set: 2675 POST /resource HTTP/1.1 HEADERS 2676 Host: example.org ==> - END_STREAM 2677 Content-Type: image/jpeg - END_HEADERS 2678 Content-Length: 123 :method = POST 2679 :path = /resource 2680 {binary data} :scheme = https 2682 CONTINUATION 2683 + END_HEADERS 2684 content-type = image/jpeg 2685 host = example.org 2686 content-length = 123 2688 DATA 2689 + END_STREAM 2690 {binary data} 2692 Note that data contributing to any given header field could be spread 2693 between header block fragments. The allocation of header fields to 2694 frames in this example is illustrative only. 2696 A response that includes header fields and payload data is 2697 transmitted as a HEADERS frame, followed by zero or more CONTINUATION 2698 frames, followed by one or more DATA frames, with the last DATA frame 2699 in the sequence having the END_STREAM flag set: 2701 HTTP/1.1 200 OK HEADERS 2702 Content-Type: image/jpeg ==> - END_STREAM 2703 Content-Length: 123 + END_HEADERS 2704 :status = 200 2705 {binary data} content-type = image/jpeg 2706 content-length = 123 2708 DATA 2709 + END_STREAM 2710 {binary data} 2712 An informational response using a 1xx status code other than 101 is 2713 transmitted as a HEADERS frame, followed by zero or more CONTINUATION 2714 frames. 2716 Trailing header fields are sent as a header block after both the 2717 request or response header block and all the DATA frames have been 2718 sent. The HEADERS frame starting the trailers header block has the 2719 END_STREAM flag set. 2721 The following example includes both a 100 (Continue) status code, 2722 which is sent in response to a request containing a "100-continue" 2723 token in the Expect header field, and trailing header fields: 2725 HTTP/1.1 100 Continue HEADERS 2726 Extension-Field: bar ==> - END_STREAM 2727 + END_HEADERS 2728 :status = 100 2729 extension-field = bar 2731 HTTP/1.1 200 OK HEADERS 2732 Content-Type: image/jpeg ==> - END_STREAM 2733 Transfer-Encoding: chunked + END_HEADERS 2734 Trailer: Foo :status = 200 2735 content-length = 123 2736 123 content-type = image/jpeg 2737 {binary data} trailer = Foo 2738 0 2739 Foo: bar DATA 2740 - END_STREAM 2741 {binary data} 2743 HEADERS 2744 + END_STREAM 2745 + END_HEADERS 2746 foo = bar 2748 8.1.4. Request Reliability Mechanisms in HTTP/2 2750 In HTTP/1.1, an HTTP client is unable to retry a non-idempotent 2751 request when an error occurs, because there is no means to determine 2752 the nature of the error. It is possible that some server processing 2753 occurred prior to the error, which could result in undesirable 2754 effects if the request were reattempted. 2756 HTTP/2 provides two mechanisms for providing a guarantee to a client 2757 that a request has not been processed: 2759 o The GOAWAY frame indicates the highest stream number that might 2760 have been processed. Requests on streams with higher numbers are 2761 therefore guaranteed to be safe to retry. 2763 o The REFUSED_STREAM error code can be included in a RST_STREAM 2764 frame to indicate that the stream is being closed prior to any 2765 processing having occurred. Any request that was sent on the 2766 reset stream can be safely retried. 2768 Requests that have not been processed have not failed; clients MAY 2769 automatically retry them, even those with non-idempotent methods. 2771 A server MUST NOT indicate that a stream has not been processed 2772 unless it can guarantee that fact. If frames that are on a stream 2773 are passed to the application layer for any stream, then 2774 REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame 2775 MUST include a stream identifier that is greater than or equal to the 2776 given stream identifier. 2778 In addition to these mechanisms, the PING frame provides a way for a 2779 client to easily test a connection. Connections that remain idle can 2780 become broken as some middleboxes (for instance, network address 2781 translators, or load balancers) silently discard connection bindings. 2782 The PING frame allows a client to safely test whether a connection is 2783 still active without sending a request. 2785 8.2. Server Push 2787 HTTP/2 allows a server to pre-emptively send (or "push") responses 2788 (along with corresponding "promised" requests) to a client in 2789 association with a previous client-initiated request. This can be 2790 useful when the server knows the client will need to have those 2791 responses available in order to fully process the response to the 2792 original request. 2794 Pushing additional message exchanges in this fashion is optional, and 2795 is negotiated between individual endpoints. The SETTINGS_ENABLE_PUSH 2796 setting can be set to 0 to indicate that server push is disabled. 2798 Promised requests MUST be cacheable (see [RFC7231], Section 4.2.3), 2799 MUST be safe (see [RFC7231], Section 4.2.1) and MUST NOT include a 2800 request body. Clients that receive a promised request that is not 2801 cacheable, unsafe or that includes a request body MUST reset the 2802 stream with a stream error (Section 5.4.2) of type PROTOCOL_ERROR. 2804 Pushed responses that are cacheable (see [RFC7234], Section 3) can be 2805 stored by the client, if it implements an HTTP cache. Pushed 2806 responses are considered successfully validated on the origin server 2807 (e.g., if the "no-cache" cache response directive [RFC7234], 2808 Section 5.2.2 is present) while the stream identified by the promised 2809 stream ID is still open. 2811 Pushed responses that are not cacheable MUST NOT be stored by any 2812 HTTP cache. They MAY be made available to the application 2813 separately. 2815 An intermediary can receive pushes from the server and choose not to 2816 forward them on to the client. In other words, how to make use of 2817 the pushed information is up to that intermediary. Equally, the 2818 intermediary might choose to make additional pushes to the client, 2819 without any action taken by the server. 2821 A client cannot push. Thus, servers MUST treat the receipt of a 2822 PUSH_PROMISE frame as a connection error (Section 5.4.1) of type 2823 PROTOCOL_ERROR. Clients MUST reject any attempt to change the 2824 SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the 2825 message as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 2827 8.2.1. Push Requests 2829 Server push is semantically equivalent to a server responding to a 2830 request; however, in this case that request is also sent by the 2831 server, as a PUSH_PROMISE frame. 2833 The PUSH_PROMISE frame includes a header block that contains a 2834 complete set of request header fields that the server attributes to 2835 the request. It is not possible to push a response to a request that 2836 includes a request body. 2838 Pushed responses are always associated with an explicit request from 2839 the client. The PUSH_PROMISE frames sent by the server are sent on 2840 that explicit request's stream. The PUSH_PROMISE frame also includes 2841 a promised stream identifier, chosen from the stream identifiers 2842 available to the server (see Section 5.1.1). 2844 The header fields in PUSH_PROMISE and any subsequent CONTINUATION 2845 frames MUST be a valid and complete set of request header fields 2846 (Section 8.1.2.3). The server MUST include a method in the ":method" 2847 header field that is safe and cacheable. If a client receives a 2848 PUSH_PROMISE that does not include a complete and valid set of header 2849 fields, or the ":method" header field identifies a method that is not 2850 safe, it MUST respond with a stream error (Section 5.4.2) of type 2851 PROTOCOL_ERROR. 2853 The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to 2854 sending any frames that reference the promised responses. This 2855 avoids a race where clients issue requests prior to receiving any 2856 PUSH_PROMISE frames. 2858 For example, if the server receives a request for a document 2859 containing embedded links to multiple image files, and the server 2860 chooses to push those additional images to the client, sending push 2861 promises before the DATA frames that contain the image links ensures 2862 that the client is able to see the promises before discovering 2863 embedded links. Similarly, if the server pushes responses referenced 2864 by the header block (for instance, in Link header fields), sending 2865 the push promises before sending the header block ensures that 2866 clients do not request them. 2868 PUSH_PROMISE frames MUST NOT be sent by the client. 2870 PUSH_PROMISE frames can be sent by the server in response to any 2871 client-initiated stream, but the stream MUST be in either the "open" 2872 or "half closed (remote)" state with respect to the server. 2873 PUSH_PROMISE frames are interspersed with the frames that comprise a 2874 response, though they cannot be interspersed with HEADERS and 2875 CONTINUATION frames that comprise a single header block. 2877 Sending a PUSH_PROMISE frame creates a new stream and puts the stream 2878 into the "reserved (local)" state for the server and the "reserved 2879 (remote)" state for the client. 2881 8.2.2. Push Responses 2883 After sending the PUSH_PROMISE frame, the server can begin delivering 2884 the pushed response as a response (Section 8.1.2.4) on a server- 2885 initiated stream that uses the promised stream identifier. The 2886 server uses this stream to transmit an HTTP response, using the same 2887 sequence of frames as defined in Section 8.1. This stream becomes 2888 "half closed" to the client (Section 5.1) after the initial HEADERS 2889 frame is sent. 2891 Once a client receives a PUSH_PROMISE frame and chooses to accept the 2892 pushed response, the client SHOULD NOT issue any requests for the 2893 promised response until after the promised stream has closed. 2895 If the client determines, for any reason, that it does not wish to 2896 receive the pushed response from the server, or if the server takes 2897 too long to begin sending the promised response, the client can send 2898 an RST_STREAM frame, using either the CANCEL or REFUSED_STREAM codes, 2899 and referencing the pushed stream's identifier. 2901 A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit 2902 the number of responses that can be concurrently pushed by a server. 2903 Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables 2904 server push by preventing the server from creating the necessary 2905 streams. This does not prohibit a server from sending PUSH_PROMISE 2906 frames; clients need to reset any promised streams that are not 2907 wanted. 2909 Clients receiving a pushed response MUST validate that either the 2910 server is authoritative (see Section 10.1), or the proxy that 2911 provided the pushed response is configured for the corresponding 2912 request. For example, a server that offers a certificate for only 2913 the "example.com" DNS-ID or Common Name is not permitted to push a 2914 response for "https://www.example.org/doc". 2916 The response for a PUSH_PROMISE stream begins with a HEADERS frame, 2917 which immediately puts the stream into the "half closed (remote)" 2918 state for the server and "half closed (local)" state for the client, 2919 and ends with a frame bearing END_STREAM, which places the stream in 2920 the "closed" state. 2922 Note: The client never sends a frame with the END_STREAM flag for a 2923 server push. 2925 8.3. The CONNECT Method 2927 In HTTP/1.x, the pseudo-method CONNECT ([RFC7231], Section 4.3.6) is 2928 used to convert an HTTP connection into a tunnel to a remote host. 2929 CONNECT is primarily used with HTTP proxies to establish a TLS 2930 session with an origin server for the purposes of interacting with 2931 "https" resources. 2933 In HTTP/2, the CONNECT method is used to establish a tunnel over a 2934 single HTTP/2 stream to a remote host, for similar purposes. The 2935 HTTP header field mapping works as defined in Request Header Fields 2936 (Section 8.1.2.3), with a few differences. Specifically: 2938 o The ":method" header field is set to "CONNECT". 2940 o The ":scheme" and ":path" header fields MUST be omitted. 2942 o The ":authority" header field contains the host and port to 2943 connect to (equivalent to the authority-form of the request-target 2944 of CONNECT requests, see [RFC7230], Section 5.3). 2946 A proxy that supports CONNECT establishes a TCP connection [TCP] to 2947 the server identified in the ":authority" header field. Once this 2948 connection is successfully established, the proxy sends a HEADERS 2949 frame containing a 2xx series status code to the client, as defined 2950 in [RFC7231], Section 4.3.6. 2952 After the initial HEADERS frame sent by each peer, all subsequent 2953 DATA frames correspond to data sent on the TCP connection. The 2954 payload of any DATA frames sent by the client is transmitted by the 2955 proxy to the TCP server; data received from the TCP server is 2956 assembled into DATA frames by the proxy. Frame types other than DATA 2957 or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY) 2958 MUST NOT be sent on a connected stream, and MUST be treated as a 2959 stream error (Section 5.4.2) if received. 2961 The TCP connection can be closed by either peer. The END_STREAM flag 2962 on a DATA frame is treated as being equivalent to the TCP FIN bit. A 2963 client is expected to send a DATA frame with the END_STREAM flag set 2964 after receiving a frame bearing the END_STREAM flag. A proxy that 2965 receives a DATA frame with the END_STREAM flag set sends the attached 2966 data with the FIN bit set on the last TCP segment. A proxy that 2967 receives a TCP segment with the FIN bit set sends a DATA frame with 2968 the END_STREAM flag set. Note that the final TCP segment or DATA 2969 frame could be empty. 2971 A TCP connection error is signaled with RST_STREAM. A proxy treats 2972 any error in the TCP connection, which includes receiving a TCP 2973 segment with the RST bit set, as a stream error (Section 5.4.2) of 2974 type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment 2975 with the RST bit set if it detects an error with the stream or the 2976 HTTP/2 connection. 2978 9. Additional HTTP Requirements/Considerations 2980 This section outlines attributes of the HTTP protocol that improve 2981 interoperability, reduce exposure to known security vulnerabilities, 2982 or reduce the potential for implementation variation. 2984 9.1. Connection Management 2986 HTTP/2 connections are persistent. For best performance, it is 2987 expected clients will not close connections until it is determined 2988 that no further communication with a server is necessary (for 2989 example, when a user navigates away from a particular web page), or 2990 until the server closes the connection. 2992 Clients SHOULD NOT open more than one HTTP/2 connection to a given 2993 host and port pair, where host is derived from a URI, a selected 2994 alternative service [ALT-SVC], or a configured proxy. 2996 A client can create additional connections as replacements, either to 2997 replace connections that are near to exhausting the available stream 2998 identifier space (Section 5.1.1), to refresh the keying material for 2999 a TLS connection, or to replace connections that have encountered 3000 errors (Section 5.4.1). 3002 A client MAY open multiple connections to the same IP address and TCP 3003 port using different Server Name Indication [TLS-EXT] values or to 3004 provide different TLS client certificates, but SHOULD avoid creating 3005 multiple connections with the same configuration. 3007 Servers are encouraged to maintain open connections for as long as 3008 possible, but are permitted to terminate idle connections if 3009 necessary. When either endpoint chooses to close the transport-layer 3010 TCP connection, the terminating endpoint SHOULD first send a GOAWAY 3011 (Section 6.8) frame so that both endpoints can reliably determine 3012 whether previously sent frames have been processed and gracefully 3013 complete or terminate any necessary remaining tasks. 3015 9.1.1. Connection Reuse 3017 Connections that are made to an origin servers, either directly or 3018 through a tunnel created using the CONNECT method (Section 8.3) MAY 3019 be reused for requests with multiple different URI authority 3020 components. A connection can be reused as long as the origin server 3021 is authoritative (Section 10.1). For "http" resources, this depends 3022 on the host having resolved to the same IP address. 3024 For "https" resources, connection reuse additionally depends on 3025 having a certificate that is valid for the host in the URI. An 3026 origin server might offer a certificate with multiple 3027 "subjectAltName" attributes, or names with wildcards, one of which is 3028 valid for the authority in the URI. For example, a certificate with 3029 a "subjectAltName" of "*.example.com" might permit the use of the 3030 same connection for requests to URIs starting with 3031 "https://a.example.com/" and "https://b.example.com/". 3033 In some deployments, reusing a connection for multiple origins can 3034 result in requests being directed to the wrong origin server. For 3035 example, TLS termination might be performed by a middlebox that uses 3036 the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an 3037 origin server. This means that it is possible for clients to send 3038 confidential information to servers that might not be the intended 3039 target for the request, even though the server is otherwise 3040 authoritative. 3042 A server that does not wish clients to reuse connections can indicate 3043 that it is not authoritative for a request by sending a 421 3044 (Misdirected Request) status code in response to the request (see 3045 Section 9.1.2). 3047 A client that is configured to use a proxy over HTTP/2 directs 3048 requests to that proxy through a single connection. That is, all 3049 requests sent via a proxy reuse the connection to the proxy. 3051 9.1.2. The 421 (Misdirected Request) Status Code 3053 The 421 (Misdirected Request) status code indicates that the request 3054 was directed at a server that is not able to produce a response. 3055 This can be sent by a server that is not configured to produce 3056 responses for the combination of scheme and authority that are 3057 included in the request URI. 3059 Clients receiving a 421 (Misdirected Request) response from a server 3060 MAY retry the request - whether the request method is idempotent or 3061 not - over a different connection. This is possible if a connection 3062 is reused (Section 9.1.1) or if an alternative service is selected 3063 ([ALT-SVC]). 3065 This status code MUST NOT be generated by proxies. 3067 A 421 response is cacheable by default; i.e., unless otherwise 3068 indicated by the method definition or explicit cache controls (see 3069 Section 4.2.2 of [RFC7234]). 3071 9.2. Use of TLS Features 3073 Implementations of HTTP/2 MUST support TLS 1.2 [TLS12] for HTTP/2 3074 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be 3075 followed, with some additional restrictions that are specific to 3076 HTTP/2. 3078 An implementation of HTTP/2 over TLS MUST use TLS 1.2 or higher with 3079 the restrictions on feature set and cipher suite described in this 3080 section. Due to implementation limitations, it might not be possible 3081 to fail TLS negotiation. An endpoint MUST immediately terminate an 3082 HTTP/2 connection that does not meet these minimum requirements with 3083 a connection error (Section 5.4.1) of type INADEQUATE_SECURITY. 3085 9.2.1. TLS Features 3087 The TLS implementation MUST support the Server Name Indication (SNI) 3088 [TLS-EXT] extension to TLS. HTTP/2 clients MUST indicate the target 3089 domain name when negotiating TLS. 3091 The TLS implementation MUST disable compression. TLS compression can 3092 lead to the exposure of information that would not otherwise be 3093 revealed [RFC3749]. Generic compression is unnecessary since HTTP/2 3094 provides compression features that are more aware of context and 3095 therefore likely to be more appropriate for use for performance, 3096 security or other reasons. 3098 The TLS implementation MUST disable renegotiation. An endpoint MUST 3099 treat a TLS renegotiation as a connection error (Section 5.4.1) of 3100 type PROTOCOL_ERROR. Note that disabling renegotiation can result in 3101 long-lived connections becoming unusable due to limits on the number 3102 of messages the underlying cipher suite can encipher. 3104 A client MAY use renegotiation to provide confidentiality protection 3105 for client credentials offered in the handshake, but any 3106 renegotiation MUST occur prior to sending the connection preface. A 3107 server SHOULD request a client certificate if it sees a renegotiation 3108 request immediately after establishing a connection. 3110 This effectively prevents the use of renegotiation in response to a 3111 request for a specific protected resource. A future specification 3112 might provide a way to support this use case. Alternatively, a 3113 server might use a connection error (Section 5.4.1) of type 3114 HTTP_1_1_REQUIRED to request the client use a protocol which supports 3115 renegotiation. 3117 9.2.2. TLS Cipher Suites 3119 The set of TLS cipher suites that are permitted in HTTP/2 is 3120 restricted. HTTP/2 MUST only be used with cipher suites that have 3121 ephemeral key exchange, such as the ephemeral Diffie-Hellman (DHE) 3122 [TLS12] or the elliptic curve variant (ECDHE) [RFC4492]. Ephemeral 3123 key exchange MUST have a minimum size of 2048 bits for DHE or 3124 security level of 128 bits for ECDHE. Clients MUST accept DHE sizes 3125 of up to 4096 bits. HTTP MUST NOT be used with cipher suites that 3126 use stream or block ciphers. Authenticated Encryption with 3127 Additional Data (AEAD) modes, such as the Galois Counter Model (GCM) 3128 mode for AES [RFC5288] are acceptable. 3130 The effect of these restrictions is that TLS 1.2 implementations 3131 could have non-intersecting sets of available cipher suites, since 3132 these prevent the use of the cipher suite that TLS 1.2 makes 3133 mandatory. To avoid this problem, implementations of HTTP/2 that use 3134 TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 3135 [TLS-ECDHE] with P256 [FIPS186]. 3137 Clients MAY advertise support of cipher suites that are prohibited by 3138 the above restrictions in order to allow for connection to servers 3139 that do not support HTTP/2. This enables a fallback to protocols 3140 without these constraints without the additional latency imposed by 3141 using a separate connection for fallback. 3143 10. Security Considerations 3145 10.1. Server Authority 3147 HTTP/2 relies on the HTTP/1.1 definition of authority for determining 3148 whether a server is authoritative in providing a given response, see 3149 [RFC7230], Section 9.1. This relies on local name resolution for the 3150 "http" URI scheme, and the authenticated server identity for the 3151 "https" scheme (see [RFC2818], Section 3). 3153 10.2. Cross-Protocol Attacks 3155 In a cross-protocol attack, an attacker causes a client to initiate a 3156 transaction in one protocol toward a server that understands a 3157 different protocol. An attacker might be able to cause the 3158 transaction to appear as valid transaction in the second protocol. 3159 In combination with the capabilities of the web context, this can be 3160 used to interact with poorly protected servers in private networks. 3162 Completing a TLS handshake with an ALPN identifier for HTTP/2 can be 3163 considered sufficient protection against cross protocol attacks. 3164 ALPN provides a positive indication that a server is willing to 3165 proceed with HTTP/2, which prevents attacks on other TLS-based 3166 protocols. 3168 The encryption in TLS makes it difficult for attackers to control the 3169 data which could be used in a cross-protocol attack on a cleartext 3170 protocol. 3172 The cleartext version of HTTP/2 has minimal protection against cross- 3173 protocol attacks. The connection preface (Section 3.5) contains a 3174 string that is designed to confuse HTTP/1.1 servers, but no special 3175 protection is offered for other protocols. A server that is willing 3176 to ignore parts of an HTTP/1.1 request containing an Upgrade header 3177 field in addition to the client connection preface could be exposed 3178 to a cross-protocol attack. 3180 10.3. Intermediary Encapsulation Attacks 3182 The HTTP/2 header field encoding allows the expression of names that 3183 are not valid field names in the Internet Message Syntax used by 3184 HTTP/1.1. Requests or responses containing invalid header field 3185 names MUST be treated as malformed (Section 8.1.2.6). An 3186 intermediary therefore cannot translate an HTTP/2 request or response 3187 containing an invalid field name into an HTTP/1.1 message. 3189 Similarly, HTTP/2 allows header field values that are not valid. 3190 While most of the values that can be encoded will not alter header 3191 field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 3192 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by 3193 an attacker if they are translater verbatim. Any request or response 3194 that contains a character not permitted in a header field value MUST 3195 be treated as malformed (Section 8.1.2.6). Valid characters are 3196 defined by the "field-content" ABNF rule in Section 3.2 of [RFC7230]. 3198 10.4. Cacheability of Pushed Responses 3200 Pushed responses do not have an explicit request from the client; the 3201 request is provided by the server in the PUSH_PROMISE frame. 3203 Caching responses that are pushed is possible based on the guidance 3204 provided by the origin server in the Cache-Control header field. 3205 However, this can cause issues if a single server hosts more than one 3206 tenant. For example, a server might offer multiple users each a 3207 small portion of its URI space. 3209 Where multiple tenants share space on the same server, that server 3210 MUST ensure that tenants are not able to push representations of 3211 resources that they do not have authority over. Failure to enforce 3212 this would allow a tenant to provide a representation that would be 3213 served out of cache, overriding the actual representation that the 3214 authoritative tenant provides. 3216 Pushed responses for which an origin server is not authoritative (see 3217 Section 10.1) are never cached or used. 3219 10.5. Denial of Service Considerations 3221 An HTTP/2 connection can demand a greater commitment of resources to 3222 operate than a HTTP/1.1 connection. The use of header compression 3223 and flow control depend on a commitment of resources for storing a 3224 greater amount of state. Settings for these features ensure that 3225 memory commitments for these features are strictly bounded. 3227 The number of PUSH_PROMISE frames is not constrained in the same 3228 fashion. A client that accepts server push SHOULD limit the number 3229 of streams it allows to be in the "reserved (remote)" state. 3230 Excessive number of server push streams can be treated as a stream 3231 error (Section 5.4.2) of type ENHANCE_YOUR_CALM. 3233 Processing capacity cannot be guarded as effectively as state 3234 capacity. 3236 The SETTINGS frame can be abused to cause a peer to expend additional 3237 processing time. This might be done by pointlessly changing SETTINGS 3238 parameters, setting multiple undefined parameters, or changing the 3239 same setting multiple times in the same frame. WINDOW_UPDATE or 3240 PRIORITY frames can be abused to cause an unnecessary waste of 3241 resources. 3243 Large numbers of small or empty frames can be abused to cause a peer 3244 to expend time processing frame headers. Note however that some uses 3245 are entirely legitimate, such as the sending of an empty DATA or 3246 CONTINUATION frame at the end of a stream. 3248 Header compression also offers some opportunities to waste processing 3249 resources; see Section 8 of [COMPRESSION] for more details on 3250 potential abuses. 3252 Limits in SETTINGS parameters cannot be reduced instantaneously, 3253 which leaves an endpoint exposed to behavior from a peer that could 3254 exceed the new limits. In particular, immediately after establishing 3255 a connection, limits set by a server are not known to clients and 3256 could be exceeded without being an obvious protocol violation. 3258 All these features - i.e., SETTINGS changes, small frames, header 3259 compression - have legitimate uses. These features become a burden 3260 only when they are used unnecessarily or to excess. 3262 An endpoint that doesn't monitor this behavior exposes itself to a 3263 risk of denial of service attack. Implementations SHOULD track the 3264 use of these features and set limits on their use. An endpoint MAY 3265 treat activity that is suspicious as a connection error 3266 (Section 5.4.1) of type ENHANCE_YOUR_CALM. 3268 10.5.1. Limits on Header Block Size 3270 A large header block (Section 4.3) can cause an implementation to 3271 commit a large amount of state. Header fields that are critical for 3272 routing can appear toward the end of a header block, which prevents 3273 streaming of header fields to their ultimate destination. For this 3274 an other reasons, such as ensuring cache correctness, means that an 3275 endpoint might need to buffer the entire header block. Since there 3276 is no hard limit to the size of a header block, some endpoints could 3277 be forced commit a large amount of available memory for header 3278 fields. 3280 An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE to advise peers 3281 of limits that might apply on the size of header blocks. This 3282 setting is only advisory, so endpoints MAY choose to send header 3283 blocks that exceed this limit and risk having the request or response 3284 being treated as malformed. This setting specific to a connection, 3285 so any request or response could encounter a hop with a lower, 3286 unknown limit. An intermediary can attempt to avoid this problem by 3287 passing on values presented by different peers, but they are not 3288 obligated to do so. 3290 A server that receives a larger header block than it is willing to 3291 handle can send an HTTP 431 (Request Header Fields Too Large) status 3292 code [RFC6585]. A client can discard responses that it cannot 3293 process. The header block MUST be processed to ensure a consistent 3294 connection state, unless the connection is closed. 3296 10.6. Use of Compression 3298 HTTP/2 enables greater use of compression for both header fields 3299 (Section 4.3) and entity bodies. Compression can allow an attacker 3300 to recover secret data when it is compressed in the same context as 3301 data under attacker control. 3303 There are demonstrable attacks on compression that exploit the 3304 characteristics of the web (e.g., [BREACH]). The attacker induces 3305 multiple requests containing varying plaintext, observing the length 3306 of the resulting ciphertext in each, which reveals a shorter length 3307 when a guess about the secret is correct. 3309 Implementations communicating on a secure channel MUST NOT compress 3310 content that includes both confidential and attacker-controlled data 3311 unless separate compression dictionaries are used for each source of 3312 data. Compression MUST NOT be used if the source of data cannot be 3313 reliably determined. Generic stream compression, such as that 3314 provided by TLS MUST NOT be used with HTTP/2 (Section 9.2.1). 3316 Further considerations regarding the compression of header fields are 3317 described in [COMPRESSION]. 3319 10.7. Use of Padding 3321 Padding within HTTP/2 is not intended as a replacement for general 3322 purpose padding, such as might be provided by TLS [TLS12]. Redundant 3323 padding could even be counterproductive. Correct application can 3324 depend on having specific knowledge of the data that is being padded. 3326 To mitigate attacks that rely on compression, disabling or limiting 3327 compression might be preferable to padding as a countermeasure. 3329 Padding can be used to obscure the exact size of frame content, and 3330 is provided to mitigate specific attacks within HTTP. For example, 3331 attacks where compressed content includes both attacker-controlled 3332 plaintext and secret data (see for example, [BREACH]). 3334 Use of padding can result in less protection than might seem 3335 immediately obvious. At best, padding only makes it more difficult 3336 for an attacker to infer length information by increasing the number 3337 of frames an attacker has to observe. Incorrectly implemented 3338 padding schemes can be easily defeated. In particular, randomized 3339 padding with a predictable distribution provides very little 3340 protection; similarly, padding payloads to a fixed size exposes 3341 information as payload sizes cross the fixed size boundary, which 3342 could be possible if an attacker can control plaintext. 3344 Intermediaries SHOULD retain padding for DATA frames, but MAY drop 3345 padding for HEADERS and PUSH_PROMISE frames. A valid reason for an 3346 intermediary to change the amount of padding of frames is to improve 3347 the protections that padding provides. 3349 10.8. Privacy Considerations 3351 Several characteristics of HTTP/2 provide an observer an opportunity 3352 to correlate actions of a single client or server over time. This 3353 includes the value of settings, the manner in which flow control 3354 windows are managed, the way priorities are allocated to streams, 3355 timing of reactions to stimulus, and handling of any optional 3356 features. 3358 As far as this creates observable differences in behavior, they could 3359 be used as a basis for fingerprinting a specific client, as defined 3360 in Section 1.8 of [HTML5]. 3362 11. IANA Considerations 3364 A string for identifying HTTP/2 is entered into the "Application 3365 Layer Protocol Negotiation (ALPN) Protocol IDs" registry established 3366 in [TLS-ALPN]. 3368 This document establishes a registry for frame types, settings, and 3369 error codes. These new registries are entered into a new "Hypertext 3370 Transfer Protocol (HTTP) 2 Parameters" section. 3372 This document registers the "HTTP2-Settings" header field for use in 3373 HTTP; and the 421 (Misdirected Request) status code. 3375 This document registers the "PRI" method for use in HTTP, to avoid 3376 collisions with the connection preface (Section 3.5). 3378 11.1. Registration of HTTP/2 Identification Strings 3380 This document creates two registrations for the identification of 3381 HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol 3382 IDs" registry established in [TLS-ALPN]. 3384 The "h2" string identifies HTTP/2 when used over TLS: 3386 Protocol: HTTP/2 over TLS 3388 Identification Sequence: 0x68 0x32 ("h2") 3390 Specification: This document 3392 The "h2c" string identifies HTTP/2 when used over cleartext TCP: 3394 Protocol: HTTP/2 over TCP 3396 Identification Sequence: 0x68 0x32 0x63 ("h2c") 3398 Specification: This document 3400 11.2. Frame Type Registry 3402 This document establishes a registry for HTTP/2 frame type codes. 3403 The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 3404 Frame Type" registry operates under either of the "IETF Review" or 3405 "IESG Approval" policies [RFC5226] for values between 0x00 and 0xef, 3406 with values between 0xf0 and 0xff being reserved for experimental 3407 use. 3409 New entries in this registry require the following information: 3411 Frame Type: A name or label for the frame type. 3413 Code: The 8-bit code assigned to the frame type. 3415 Specification: A reference to a specification that includes a 3416 description of the frame layout, its semantics, and flags that the 3417 frame type uses, including any parts of the frame that are 3418 conditionally present based on the value of flags. 3420 The entries in the following table are registered by this document. 3422 +---------------+------+--------------+ 3423 | Frame Type | Code | Section | 3424 +---------------+------+--------------+ 3425 | DATA | 0x0 | Section 6.1 | 3426 | HEADERS | 0x1 | Section 6.2 | 3427 | PRIORITY | 0x2 | Section 6.3 | 3428 | RST_STREAM | 0x3 | Section 6.4 | 3429 | SETTINGS | 0x4 | Section 6.5 | 3430 | PUSH_PROMISE | 0x5 | Section 6.6 | 3431 | PING | 0x6 | Section 6.7 | 3432 | GOAWAY | 0x7 | Section 6.8 | 3433 | WINDOW_UPDATE | 0x8 | Section 6.9 | 3434 | CONTINUATION | 0x9 | Section 6.10 | 3435 +---------------+------+--------------+ 3437 11.3. Settings Registry 3439 This document establishes a registry for HTTP/2 settings. The 3440 "HTTP/2 Settings" registry manages a 16-bit space. The "HTTP/2 3441 Settings" registry operates under the "Expert Review" policy 3442 [RFC5226] for values in the range from 0x0000 to 0xefff, with values 3443 between and 0xf000 and 0xffff being reserved for experimental use. 3445 New registrations are advised to provide the following information: 3447 Name: A symbolic name for the setting. Specifying a setting name is 3448 optional. 3450 Code: The 16-bit code assigned to the setting. 3452 Initial Value: An initial value for the setting. 3454 Specification: An optional reference to a specification that 3455 describes the use of the setting. 3457 An initial set of setting registrations can be found in 3458 Section 6.5.2. 3460 +------------------------+------+---------------+---------------+ 3461 | Name | Code | Initial Value | Specification | 3462 +------------------------+------+---------------+---------------+ 3463 | HEADER_TABLE_SIZE | 0x1 | 4096 | Section 6.5.2 | 3464 | ENABLE_PUSH | 0x2 | 1 | Section 6.5.2 | 3465 | MAX_CONCURRENT_STREAMS | 0x3 | (infinite) | Section 6.5.2 | 3466 | INITIAL_WINDOW_SIZE | 0x4 | 65535 | Section 6.5.2 | 3467 | MAX_FRAME_SIZE | 0x5 | 16384 | Section 6.5.2 | 3468 | MAX_HEADER_LIST_SIZE | 0x6 | (infinite) | Section 6.5.2 | 3469 +------------------------+------+---------------+---------------+ 3471 11.4. Error Code Registry 3473 This document establishes a registry for HTTP/2 error codes. The 3474 "HTTP/2 Error Code" registry manages a 32-bit space. The "HTTP/2 3475 Error Code" registry operates under the "Expert Review" policy 3476 [RFC5226]. 3478 Registrations for error codes are required to include a description 3479 of the error code. An expert reviewer is advised to examine new 3480 registrations for possible duplication with existing error codes. 3481 Use of existing registrations is to be encouraged, but not mandated. 3483 New registrations are advised to provide the following information: 3485 Name: A name for the error code. Specifying an error code name is 3486 optional. 3488 Code: The 32-bit error code value. 3490 Description: A brief description of the error code semantics, longer 3491 if no detailed specification is provided. 3493 Specification: An optional reference for a specification that 3494 defines the error code. 3496 The entries in the following table are registered by this document. 3498 +---------------------+------+----------------------+---------------+ 3499 | Name | Code | Description | Specification | 3500 +---------------------+------+----------------------+---------------+ 3501 | NO_ERROR | 0x0 | Graceful shutdown | Section 7 | 3502 | PROTOCOL_ERROR | 0x1 | Protocol error | Section 7 | 3503 | | | detected | | 3504 | INTERNAL_ERROR | 0x2 | Implementation fault | Section 7 | 3505 | FLOW_CONTROL_ERROR | 0x3 | Flow control limits | Section 7 | 3506 | | | exceeded | | 3507 | SETTINGS_TIMEOUT | 0x4 | Settings not | Section 7 | 3508 | | | acknowledged | | 3509 | STREAM_CLOSED | 0x5 | Frame received for | Section 7 | 3510 | | | closed stream | | 3511 | FRAME_SIZE_ERROR | 0x6 | Frame size incorrect | Section 7 | 3512 | REFUSED_STREAM | 0x7 | Stream not processed | Section 7 | 3513 | CANCEL | 0x8 | Stream cancelled | Section 7 | 3514 | COMPRESSION_ERROR | 0x9 | Compression state | Section 7 | 3515 | | | not updated | | 3516 | CONNECT_ERROR | 0xa | TCP connection error | Section 7 | 3517 | | | for CONNECT method | | 3518 | ENHANCE_YOUR_CALM | 0xb | Processing capacity | Section 7 | 3519 | | | exceeded | | 3520 | INADEQUATE_SECURITY | 0xc | Negotiated TLS | Section 7 | 3521 | | | parameters not | | 3522 | | | acceptable | | 3523 | HTTP_1_1_REQUIRED | 0xc | Use HTTP/1.1 for the | Section 7 | 3524 | | | request | | 3525 +---------------------+------+----------------------+---------------+ 3527 11.5. HTTP2-Settings Header Field Registration 3529 This section registers the "HTTP2-Settings" header field in the 3530 Permanent Message Header Field Registry [BCP90]. 3532 Header field name: HTTP2-Settings 3534 Applicable protocol: http 3536 Status: standard 3538 Author/Change controller: IETF 3540 Specification document(s): Section 3.2.1 of this document 3542 Related information: This header field is only used by an HTTP/2 3543 client for Upgrade-based negotiation. 3545 11.6. PRI Method Registration 3547 This section registers the "PRI" method in the HTTP Method Registry 3548 ([RFC7231], Section 8.1). 3550 Method Name: PRI 3552 Safe No 3554 Idempotent No 3556 Specification document(s) Section 3.5 of this document 3558 Related information: This method is never used by an actual client. 3559 This method will appear to be used when an HTTP/1.1 server or 3560 intermediary attempts to parse an HTTP/2 connection preface. 3562 11.7. The 421 (Misdirected Request) HTTP Status Code 3564 This document registers the 421 (Misdirected Request) HTTP Status 3565 code in the Hypertext Transfer Protocol (HTTP) Status Code Registry 3566 ([RFC7231], Section 8.2). 3568 Status Code: 421 3570 Short Description: Misdirected Request 3572 Specification: Section 9.1.2 of this document 3574 12. Acknowledgements 3576 This document includes substantial input from the following 3577 individuals: 3579 o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa 3580 Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam 3581 Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, 3582 Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors). 3584 o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism). 3586 o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, 3587 Jitu Padhye, Roberto Peon, Rob Trace (Flow control). 3589 o Mike Bishop (Extensibility). 3591 o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike 3592 Bishop, Herve Ruellan (Substantial editorial contributions). 3594 o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp. 3596 o Alexey Melnikov was an editor of this document during 2013. 3598 o A substantial proportion of Martin's contribution was supported by 3599 Microsoft during his employment there. 3601 13. References 3603 13.1. Normative References 3605 [COMPRESSION] 3606 Ruellan, H. and R. Peon, "HPACK - Header Compression for 3607 HTTP/2", draft-ietf-httpbis-header-compression-09 (work in 3608 progress), July 2014. 3610 [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, 3611 April 2011. 3613 [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4, 3614 July 2013. 3616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3617 Requirement Levels", BCP 14, RFC 2119, March 1997. 3619 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3621 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3622 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3623 3986, January 2005. 3625 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3626 Encodings", RFC 4648, October 2006. 3628 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3629 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3630 May 2008. 3632 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3633 Specifications: ABNF", STD 68, RFC 5234, January 2008. 3635 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3636 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 3637 7230, June 2014. 3639 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3640 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 3641 June 2014. 3643 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3644 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 3645 2014. 3647 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 3648 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 3649 RFC 7233, June 2014. 3651 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 3652 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 3653 RFC 7234, June 2014. 3655 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3656 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. 3658 [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 3659 793, September 1981. 3661 [TLS-ALPN] 3662 Friedl, S., Popov, A., Langley, A., and E. Stephan, 3663 "Transport Layer Security (TLS) Application-Layer Protocol 3664 Negotiation Extension", RFC 7301, July 2014. 3666 [TLS-ECDHE] 3667 Rescorla, E., "TLS Elliptic Curve Cipher Suites with 3668 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 3669 August 2008. 3671 [TLS-EXT] Eastlake, D., "Transport Layer Security (TLS) Extensions: 3672 Extension Definitions", RFC 6066, January 2011. 3674 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 3675 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3677 13.2. Informative References 3679 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 3680 Alternative Services", draft-ietf-httpbis-alt-svc-04 (work 3681 in progress), October 2014. 3683 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3684 Procedures for Message Header Fields", BCP 90, RFC 3864, 3685 September 2004. 3687 [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the 3688 CRIME Attack", July 2013, . 3692 [HTML5] Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., 3693 O'Connor, E., and S. Pfeiffer, "HTML5", W3C Candidate 3694 Recommendation CR-html5-20140731, July 2014, 3695 . 3697 Latest version available at [5]. 3699 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 3700 Compression Methods", RFC 3749, May 2004. 3702 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 3703 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 3704 for Transport Layer Security (TLS)", RFC 4492, May 2006. 3706 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 3707 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 3708 August 2008. 3710 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 3711 Codes", RFC 6585, April 2012. 3713 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 3714 Scheffenegger, "TCP Extensions for High Performance", RFC 3715 7323, September 2014. 3717 [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. 3718 Jackson, "Talking to Yourself for Fun and Profit", 2011, 3719 . 3721 [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, 3722 "Recommendations for Secure Use of TLS and DTLS", draft- 3723 ietf-uta-tls-bcp-01 (work in progress), June 2014. 3725 13.3. URIs 3727 [1] https://www.iana.org/assignments/message-headers 3729 [2] https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/ 3730 cfUef2gL3iU 3732 [3] https://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc- 3733 principles-01 3735 Appendix A. Change Log 3737 This section is to be removed by RFC Editor before publication. 3739 A.1. Since draft-ietf-httpbis-http2-14 3741 Renamed Not Authoritative status code to Misdirected Request. 3743 A.2. Since draft-ietf-httpbis-http2-13 3745 Pseudo-header fields are now required to appear strictly before 3746 regular ones. 3748 Restored 1xx series status codes, except 101. 3750 Changed frame length field 24-bits. Expanded frame header to 9 3751 octets. Added a setting to limit the damage. 3753 Added a setting to advise peers of header set size limits. 3755 Removed segments. 3757 Made non-semantic-bearing HEADERS frames illegal in the HTTP mapping. 3759 A.3. Since draft-ietf-httpbis-http2-12 3761 Restored extensibility options. 3763 Restricting TLS cipher suites to AEAD only. 3765 Removing Content-Encoding requirements. 3767 Permitting the use of PRIORITY after stream close. 3769 Removed ALTSVC frame. 3771 Removed BLOCKED frame. 3773 Reducing the maximum padding size to 256 octets; removing padding 3774 from CONTINUATION frames. 3776 Removed per-frame GZIP compression. 3778 A.4. Since draft-ietf-httpbis-http2-11 3780 Added BLOCKED frame (at risk). 3782 Simplified priority scheme. 3784 Added DATA per-frame GZIP compression. 3786 A.5. Since draft-ietf-httpbis-http2-10 3788 Changed "connection header" to "connection preface" to avoid 3789 confusion. 3791 Added dependency-based stream prioritization. 3793 Added "h2c" identifier to distinguish between cleartext and secured 3794 HTTP/2. 3796 Adding missing padding to PUSH_PROMISE. 3798 Integrate ALTSVC frame and supporting text. 3800 Dropping requirement on "deflate" Content-Encoding. 3802 Improving security considerations around use of compression. 3804 A.6. Since draft-ietf-httpbis-http2-09 3806 Adding padding for data frames. 3808 Renumbering frame types, error codes, and settings. 3810 Adding INADEQUATE_SECURITY error code. 3812 Updating TLS usage requirements to 1.2; forbidding TLS compression. 3814 Removing extensibility for frames and settings. 3816 Changing setting identifier size. 3818 Removing the ability to disable flow control. 3820 Changing the protocol identification token to "h2". 3822 Changing the use of :authority to make it optional and to allow 3823 userinfo in non-HTTP cases. 3825 Allowing split on 0x0 for Cookie. 3827 Reserved PRI method in HTTP/1.1 to avoid possible future collisions. 3829 A.7. Since draft-ietf-httpbis-http2-08 3831 Added cookie crumbling for more efficient header compression. 3833 Added header field ordering with the value-concatenation mechanism. 3835 A.8. Since draft-ietf-httpbis-http2-07 3837 Marked draft for implementation. 3839 A.9. Since draft-ietf-httpbis-http2-06 3841 Adding definition for CONNECT method. 3843 Constraining the use of push to safe, cacheable methods with no 3844 request body. 3846 Changing from :host to :authority to remove any potential confusion. 3848 Adding setting for header compression table size. 3850 Adding settings acknowledgement. 3852 Removing unnecessary and potentially problematic flags from 3853 CONTINUATION. 3855 Added denial of service considerations. 3857 A.10. Since draft-ietf-httpbis-http2-05 3859 Marking the draft ready for implementation. 3861 Renumbering END_PUSH_PROMISE flag. 3863 Editorial clarifications and changes. 3865 A.11. Since draft-ietf-httpbis-http2-04 3867 Added CONTINUATION frame for HEADERS and PUSH_PROMISE. 3869 PUSH_PROMISE is no longer implicitly prohibited if 3870 SETTINGS_MAX_CONCURRENT_STREAMS is zero. 3872 Push expanded to allow all safe methods without a request body. 3874 Clarified the use of HTTP header fields in requests and responses. 3875 Prohibited HTTP/1.1 hop-by-hop header fields. 3877 Requiring that intermediaries not forward requests with missing or 3878 illegal routing :-headers. 3880 Clarified requirements around handling different frames after stream 3881 close, stream reset and GOAWAY. 3883 Added more specific prohibitions for sending of different frame types 3884 in various stream states. 3886 Making the last received setting value the effective value. 3888 Clarified requirements on TLS version, extension and ciphers. 3890 A.12. Since draft-ietf-httpbis-http2-03 3892 Committed major restructuring atrocities. 3894 Added reference to first header compression draft. 3896 Added more formal description of frame lifecycle. 3898 Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA. 3900 Removed HEADERS+PRIORITY, added optional priority to HEADERS frame. 3902 Added PRIORITY frame. 3904 A.13. Since draft-ietf-httpbis-http2-02 3906 Added continuations to frames carrying header blocks. 3908 Replaced use of "session" with "connection" to avoid confusion with 3909 other HTTP stateful concepts, like cookies. 3911 Removed "message". 3913 Switched to TLS ALPN from NPN. 3915 Editorial changes. 3917 A.14. Since draft-ietf-httpbis-http2-01 3919 Added IANA considerations section for frame types, error codes and 3920 settings. 3922 Removed data frame compression. 3924 Added PUSH_PROMISE. 3926 Added globally applicable flags to framing. 3928 Removed zlib-based header compression mechanism. 3930 Updated references. 3932 Clarified stream identifier reuse. 3934 Removed CREDENTIALS frame and associated mechanisms. 3936 Added advice against naive implementation of flow control. 3938 Added session header section. 3940 Restructured frame header. Removed distinction between data and 3941 control frames. 3943 Altered flow control properties to include session-level limits. 3945 Added note on cacheability of pushed resources and multiple tenant 3946 servers. 3948 Changed protocol label form based on discussions. 3950 A.15. Since draft-ietf-httpbis-http2-00 3952 Changed title throughout. 3954 Removed section on Incompatibilities with SPDY draft#2. 3956 Changed INTERNAL_ERROR on GOAWAY to have a value of 2 [6]. 3958 Replaced abstract and introduction. 3960 Added section on starting HTTP/2.0, including upgrade mechanism. 3962 Removed unused references. 3964 Added flow control principles (Section 5.2.1) based on [7]. 3966 A.16. Since draft-mbelshe-httpbis-spdy-00 3968 Adopted as base for draft-ietf-httpbis-http2. 3970 Updated authors/editors list. 3972 Added status note. 3974 Authors' Addresses 3976 Mike Belshe 3977 Twist 3979 EMail: mbelshe@chromium.org 3981 Roberto Peon 3982 Google, Inc 3984 EMail: fenix@google.com 3986 Martin Thomson (editor) 3987 Mozilla 3988 331 E Evelyn Street 3989 Mountain View, CA 94041 3990 US 3992 EMail: martin.thomson@gmail.com