idnits 2.17.1 draft-ietf-httpbis-http2-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3840 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) == Outdated reference: A later version (-12) exists of draft-ietf-httpbis-header-compression-04 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-24 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4346 (ref. 'TLS11') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-ietf-tls-applayerprotoneg-02 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 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 24, 2014 Google, Inc 6 M. Thomson, Ed. 7 Microsoft 8 A. Melnikov, Ed. 9 Isode Ltd 10 October 21, 2013 12 Hypertext Transfer Protocol version 2.0 13 draft-ietf-httpbis-http2-07 15 Abstract 17 This specification describes an optimized expression of the syntax of 18 the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more 19 efficient use of network resources and a reduced perception of 20 latency by introducing header field compression and allowing multiple 21 concurrent messages on the same connection. It also introduces 22 unsolicited push of representations from servers to clients. 24 This document is an alternative to, but does not obsolete, the 25 HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. 27 Editorial Note (To be removed by RFC Editor) 29 Discussion of this draft takes place on the HTTPBIS working group 30 mailing list (ietf-http-wg@w3.org), which is archived at 31 . 33 Working Group information and related documents can be found at 34 (Wiki) and 35 (source code and issues 36 tracker). 38 The changes in this draft are summarized in Appendix A.1. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 24, 2014. 57 Copyright Notice 59 Copyright (c) 2013 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.1. Document Organization . . . . . . . . . . . . . . . . . . 5 76 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 77 2. HTTP/2.0 Protocol Overview . . . . . . . . . . . . . . . . . . 6 78 2.1. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . 7 79 2.2. HTTP Multiplexing . . . . . . . . . . . . . . . . . . . . 7 80 2.3. HTTP Semantics . . . . . . . . . . . . . . . . . . . . . . 7 81 3. Starting HTTP/2.0 . . . . . . . . . . . . . . . . . . . . . . 7 82 3.1. HTTP/2.0 Version Identification . . . . . . . . . . . . . 7 83 3.2. Starting HTTP/2.0 for "http" URIs . . . . . . . . . . . . 8 84 3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10 85 3.3. Starting HTTP/2.0 for "https" URIs . . . . . . . . . . . . 10 86 3.4. Starting HTTP/2.0 with Prior Knowledge . . . . . . . . . . 10 87 3.5. HTTP/2.0 Connection Header . . . . . . . . . . . . . . . . 11 88 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 12 90 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 13 91 4.3. Header Compression and Decompression . . . . . . . . . . . 13 92 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14 93 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14 94 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19 95 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19 96 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20 97 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20 98 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21 99 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 22 100 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22 101 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 22 102 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23 103 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23 104 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 24 105 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 24 107 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 26 109 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 27 110 6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 28 111 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 29 112 6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 29 113 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 30 114 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 32 116 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 34 117 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 35 118 6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 36 119 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 37 120 6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 37 121 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 38 122 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 39 123 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 40 124 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 40 125 8.1.1. Informational Responses . . . . . . . . . . . . . . . 41 126 8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 41 127 8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 43 128 8.1.4. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 45 129 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 46 130 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 47 131 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 48 132 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 48 133 9. Additional HTTP Requirements/Considerations . . . . . . . . . 49 134 9.1. Connection Management . . . . . . . . . . . . . . . . . . 50 135 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 50 136 9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 51 137 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 138 10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 51 139 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 51 140 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 51 141 10.4. Cacheability of Pushed Resources . . . . . . . . . . . . . 52 142 10.5. Denial of Service Considerations . . . . . . . . . . . . . 52 143 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 53 144 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 145 12.1. Registration of HTTP/2.0 Identification String . . . . . . 54 146 12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54 147 12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55 148 12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55 149 12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56 150 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 151 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 152 14.1. Normative References . . . . . . . . . . . . . . . . . . . 57 153 14.2. Informative References . . . . . . . . . . . . . . . . . . 58 154 Appendix A. Change Log (to be removed by RFC Editor before 155 publication) . . . . . . . . . . . . . . . . . . . . 59 156 A.1. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59 157 A.2. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59 158 A.3. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59 159 A.4. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60 160 A.5. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60 161 A.6. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60 162 A.7. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61 163 A.8. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61 165 1. Introduction 167 The Hypertext Transfer Protocol (HTTP) is a wildly successful 168 protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section 169 3) is optimized for implementation simplicity and accessibility, not 170 application performance. As such it has several characteristics that 171 have a negative overall effect on application performance. 173 In particular, HTTP/1.0 only allows one request to be outstanding at 174 a time on a given connection. HTTP/1.1 pipelining only partially 175 addressed request concurrency and suffers from head-of-line blocking. 176 Therefore, clients that need to make many requests typically use 177 multiple connections to a server in order to reduce latency. 179 Furthermore, HTTP/1.1 header fields are often repetitive and verbose, 180 which, in addition to generating more or larger network packets, can 181 cause the small initial TCP congestion window to quickly fill. This 182 can result in excessive latency when multiple requests are made on a 183 single new TCP connection. 185 This document addresses these issues by defining an optimized mapping 186 of HTTP's semantics to an underlying connection. Specifically, it 187 allows interleaving of request and response messages on the same 188 connection and uses an efficient coding for HTTP header fields. It 189 also allows prioritization of requests, letting more important 190 requests complete more quickly, further improving performance. 192 The resulting protocol is designed to be more friendly to the 193 network, because fewer TCP connections can be used, in comparison to 194 HTTP/1.x. This means less competition with other flows, and longer- 195 lived connections, which in turn leads to better utilization of 196 available network capacity. 198 Finally, this encapsulation also enables more scalable processing of 199 messages through use of binary message framing. 201 1.1. Document Organization 203 The HTTP/2.0 Specification is split into three parts: starting 204 HTTP/2.0 (Section 3), which covers how a HTTP/2.0 connection is 205 initiated; a framing layer (Section 4), which multiplexes a single 206 TCP connection into independent frames of various types; and an HTTP 207 layer (Section 8), which specifies the mechanism for expressing HTTP 208 interactions using the framing layer. While some of the framing 209 layer concepts are isolated from HTTP, building a generic framing 210 layer has not been a goal. The framing layer is tailored to the 211 needs of the HTTP protocol and server push. 213 1.2. Conventions and Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in RFC 2119 [RFC2119]. 219 All numeric values are in network byte order. Values are unsigned 220 unless otherwise indicated. Literal values are provided in decimal 221 or hexadecimal as appropriate. Hexadecimal literals are prefixed 222 with "0x" to distinguish them from decimal literals. 224 The following terms are used: 226 client: The endpoint initiating the HTTP connection. 228 connection: A transport-level connection between two endpoints. 230 connection error: An error on the HTTP/2.0 connection. 232 endpoint: Either the client or server of the connection. 234 frame: The smallest unit of communication within an HTTP/2.0 235 connection, consisting of a header and a variable-length sequence 236 of bytes structured according to the frame type. 238 peer: An endpoint. When discussing a particular endpoint, "peer" 239 refers to the endpoint that is remote to the primary subject of 240 discussion. 242 receiver: An endpoint that is receiving frames. 244 sender: An endpoint that is transmitting frames. 246 server: The endpoint which did not initiate the HTTP connection. 248 stream: A bi-directional flow of frames across a virtual channel 249 within the HTTP/2.0 connection. 251 stream error: An error on the individual HTTP/2.0 stream. 253 2. HTTP/2.0 Protocol Overview 255 HTTP/2.0 provides an optimized transport for HTTP semantics. 257 An HTTP/2.0 connection is an application level protocol running on 258 top of a TCP connection ([TCP]). The client is the TCP connection 259 initiator. 261 This document describes the HTTP/2.0 protocol using a logical 262 structure that is formed of three parts: framing, streams, and 263 application mapping. This structure is provided primarily as an aid 264 to specification, implementations are free to diverge from this 265 structure as necessary. 267 2.1. HTTP Frames 269 HTTP/2.0 provides an efficient serialization of HTTP semantics. HTTP 270 requests and responses are encoded into length-prefixed frames (see 271 Section 4.1). 273 HTTP header fields are compressed into a series of frames that 274 contain header block fragments (see Section 4.3). 276 2.2. HTTP Multiplexing 278 HTTP/2.0 provides the ability to multiplex HTTP requests and 279 responses over a single connection. Multiple requests or responses 280 can be sent concurrently on a connection using streams (Section 5). 281 In order to maintain independent streams, flow control and 282 prioritization are necessary. 284 2.3. HTTP Semantics 286 HTTP/2.0 defines how HTTP requests and responses are mapped to 287 streams (see Section 8.1) and introduces a new interaction model, 288 server push (Section 8.2). 290 3. Starting HTTP/2.0 292 HTTP/2.0 uses the same "http" and "https" URI schemes used by 293 HTTP/1.1. HTTP/2.0 shares the same default port numbers: 80 for 294 "http" URIs and 443 for "https" URIs. As a result, implementations 295 processing requests for target resource URIs like 296 "http://example.org/foo" or "https://example.com/bar" are required to 297 first discover whether the upstream server (the immediate peer to 298 which the client wishes to establish a connection) supports HTTP/2.0. 300 The means by which support for HTTP/2.0 is determined is different 301 for "http" and "https" URIs. Discovery for "http" URIs is described 302 in Section 3.2. Discovery for "https" URIs is described in 303 Section 3.3. 305 3.1. HTTP/2.0 Version Identification 307 The protocol defined in this document is identified using the string 308 "HTTP/2.0". This identification is used in the HTTP/1.1 Upgrade 309 header field, in the TLS application layer protocol negotiation 310 extension [TLSALPN] field, and other places where protocol 311 identification is required. 313 Negotiating "HTTP/2.0" implies the use of the transport, security, 314 framing and message semantics described in this document. 316 [[anchor6: Editor's Note: please remove the remainder of this section 317 prior to the publication of a final version of this document.]] 319 Only implementations of the final, published RFC can identify 320 themselves as "HTTP/2.0". Until such an RFC exists, implementations 321 MUST NOT identify themselves using "HTTP/2.0". 323 Examples and text throughout the rest of this document use "HTTP/2.0" 324 as a matter of editorial convenience only. Implementations of draft 325 versions MUST NOT identify using this string. The exception to this 326 rule is the string included in the connection header sent by clients 327 immediately after establishing an HTTP/2.0 connection (see 328 Section 3.5); this fixed length sequence of octets does not change. 330 Implementations of draft versions of the protocol MUST add the string 331 "-draft-" and the corresponding draft number to the identifier before 332 the separator ('/'). For example, draft-ietf-httpbis-http2-03 is 333 identified using the string "HTTP-draft-03/2.0". 335 Non-compatible experiments that are based on these draft versions 336 MUST instead replace the string "draft" with a different identifier. 337 For example, an experimental implementation of packet mood-based 338 encoding based on draft-ietf-httpbis-http2-07 might identify itself 339 as "HTTP-emo-07/2.0". Note that any label MUST conform to the 340 "token" syntax defined in Section 3.2.6 of [HTTP-p1]. Experimenters 341 are encouraged to coordinate their experiments on the 342 ietf-http-wg@w3.org mailing list. 344 3.2. Starting HTTP/2.0 for "http" URIs 346 A client that makes a request to an "http" URI without prior 347 knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism 348 (Section 6.7 of [HTTP-p1]). The client makes an HTTP/1.1 request 349 that includes an Upgrade header field identifying HTTP/2.0. The 350 HTTP/1.1 request MUST include exactly one HTTP2-Settings 351 (Section 3.2.1) header field. 353 For example: 355 GET /default.htm HTTP/1.1 356 Host: server.example.com 357 Connection: Upgrade, HTTP2-Settings 358 Upgrade: HTTP/2.0 359 HTTP2-Settings: 361 Requests that contain an entity body MUST be sent in their entirety 362 before the client can send HTTP/2.0 frames. This means that a large 363 request entity can block the use of the connection until it is 364 completely sent. 366 If concurrency of an initial request with subsequent requests is 367 important, a small request can be used to perform the upgrade to 368 HTTP/2.0, at the cost of an additional round trip. 370 A server that does not support HTTP/2.0 can respond to the request as 371 though the Upgrade header field were absent: 373 HTTP/1.1 200 OK 374 Content-Length: 243 375 Content-Type: text/html 377 ... 379 A server that supports HTTP/2.0 can accept the upgrade with a 101 380 (Switching Protocols) response. After the empty line that terminates 381 the 101 response, the server can begin sending HTTP/2.0 frames. 382 These frames MUST include a response to the request that initiated 383 the Upgrade. 385 HTTP/1.1 101 Switching Protocols 386 Connection: Upgrade 387 Upgrade: HTTP/2.0 389 [ HTTP/2.0 connection ... 391 The first HTTP/2.0 frame sent by the server is a SETTINGS frame 392 (Section 6.5). Upon receiving the 101 response, the client sends a 393 connection header (Section 3.5), which includes a SETTINGS frame. 395 The HTTP/1.1 request that is sent prior to upgrade is assigned stream 396 identifier 1 and is assigned the highest possible priority. Stream 1 397 is implicitly half closed from the client toward the server, since 398 the request is completed as an HTTP/1.1 request. After commencing 399 the HTTP/2.0 connection, stream 1 is used for the response. 401 3.2.1. HTTP2-Settings Header Field 403 A request that upgrades from HTTP/1.1 to HTTP/2.0 MUST include 404 exactly one "HTTP2-Settings" header field. The "HTTP2-Settings" 405 header field is a hop-by-hop header field that includes settings that 406 govern the HTTP/2.0 connection, provided in anticipation of the 407 server accepting the request to upgrade. A server MUST reject an 408 attempt to upgrade if this header field is not present. 410 HTTP2-Settings = token68 412 The content of the "HTTP2-Settings" header field is the payload of a 413 SETTINGS frame (Section 6.5), encoded as a base64url string (that is, 414 the URL- and filename-safe Base64 encoding described in Section 5 of 415 [RFC4648], with any trailing '=' characters omitted). The ABNF 416 [RFC5234] production for "token68" is defined in Section 2.1 of 417 [HTTP-p7]. 419 The client MUST include values for the following settings 420 (Section 6.5.1): 422 o SETTINGS_MAX_CONCURRENT_STREAMS 424 o SETTINGS_INITIAL_WINDOW_SIZE 426 As a hop-by-hop header field, the "Connection" header field MUST 427 include a value of "HTTP2-Settings" in addition to "Upgrade" when 428 upgrading to HTTP/2.0. 430 A server decodes and interprets these values as it would any other 431 SETTINGS frame. Providing these values in the Upgrade request 432 ensures that the protocol does not require default values for the 433 above settings, and gives a client an opportunity to provide other 434 settings prior to receiving any frames from the server. 436 3.3. Starting HTTP/2.0 for "https" URIs 438 A client that makes a request to an "https" URI without prior 439 knowledge about support for HTTP/2.0 uses TLS [TLS12] with the 440 application layer protocol negotiation extension [TLSALPN]. 442 Once TLS negotiation is complete, both the client and the server send 443 a connection header (Section 3.5). 445 3.4. Starting HTTP/2.0 with Prior Knowledge 447 A client can learn that a particular server supports HTTP/2.0 by 448 other means. A client MAY immediately send HTTP/2.0 frames to a 449 server that is known to support HTTP/2.0, after the connection header 450 (Section 3.5). This only affects the resolution of "http" URIs; 451 servers supporting HTTP/2.0 are required to support protocol 452 negotiation in TLS [TLSALPN] for "https" URIs. 454 Prior support for HTTP/2.0 is not a strong signal that a given server 455 will support HTTP/2.0 for future connections. It is possible for 456 server configurations to change or for configurations to differ 457 between instances in clustered server. Interception proxies (a.k.a. 458 "transparent" proxies) are another source of variability. 460 3.5. HTTP/2.0 Connection Header 462 Upon establishment of a TCP connection and determination that 463 HTTP/2.0 will be used by both peers, each endpoint MUST send a 464 connection header as a final confirmation and to establish the 465 initial settings for the HTTP/2.0 connection. 467 The client connection header starts with a sequence of 24 octets, 468 which in hex notation are: 470 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 472 (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence is 473 followed by a SETTINGS frame (Section 6.5). The client sends the 474 client connection header immediately upon receipt of a 101 Switching 475 Protocols response (indicating a successful upgrade), or as the first 476 application data octets of a TLS connection. If starting an HTTP/2.0 477 connection with prior knowledge of server support for the protocol, 478 the client connection header is sent upon connection establishment. 480 The client connection header is selected so that a large 481 proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do 482 not attempt to process further frames. Note that this does not 483 address the concerns raised in [TALKING]. 485 The server connection header consists of just a SETTINGS frame 486 (Section 6.5) that MUST be the first frame the server sends in the 487 HTTP/2.0 connection. 489 To avoid unnecessary latency, clients are permitted to send 490 additional frames to the server immediately after sending the client 491 connection header, without waiting to receive the server connection 492 header. It is important to note, however, that the server connection 493 header SETTINGS frame might include parameters that necessarily alter 494 how a client is expected to communicate with the server. Upon 495 receiving the SETTINGS frame, the client is expected to honor any 496 parameters established. 498 Clients and servers MUST terminate the TCP connection if either peer 499 does not begin with a valid connection header. A GOAWAY frame 500 (Section 6.8) MAY be omitted if it is clear that the peer is not 501 using HTTP/2.0. 503 4. HTTP Frames 505 Once the HTTP/2.0 connection is established, endpoints can begin 506 exchanging frames. 508 4.1. Frame Format 510 All frames begin with an 8-octet header followed by a payload of 511 between 0 and 16383 octets. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | R | Length (14) | Type (8) | Flags (8) | 517 +-+-+-----------+---------------+-------------------------------+ 518 |R| Stream Identifier (31) | 519 +-+-------------------------------------------------------------+ 520 | Frame Payload (0...) ... 521 +---------------------------------------------------------------+ 523 Frame Header 525 The fields of the frame header are defined as: 527 R: A reserved 2-bit field. The semantics of these bits are undefined 528 and the bit MUST remain unset (0) when sending and MUST be ignored 529 when receiving. 531 Length: The length of the frame payload expressed as an unsigned 14- 532 bit integer. The 8 octets of the frame header are not included in 533 this value. 535 Type: The 8-bit type of the frame. The frame type determines how 536 the remainder of the frame header and payload are interpreted. 537 Implementations MUST ignore frames of unsupported or unrecognized 538 types. 540 Flags: An 8-bit field reserved for frame-type specific boolean 541 flags. 543 Flags are assigned semantics specific to the indicated frame type. 544 Flags that have no defined semantics for a particular frame type 545 MUST be ignored, and MUST be left unset (0) when sending. 547 R: A reserved 1-bit field. The semantics of this bit are undefined 548 and the bit MUST remain unset (0) when sending and MUST be ignored 549 when receiving. 551 Stream Identifier: A 31-bit stream identifier (see Section 5.1.1). 552 The value 0 is reserved for frames that are associated with the 553 connection as a whole as opposed to an individual stream. 555 The structure and content of the frame payload is dependent entirely 556 on the frame type. 558 4.2. Frame Size 560 The maximum size of a frame payload varies by frame type. The 561 absolute maximum size of a frame is 2^14-1 (16,383) octets. All 562 implementations SHOULD be capable of receiving and minimally 563 processing frames up to this maximum size. 565 Certain frame types, such as PING (see Section 6.7), impose 566 additional limits on the amount of payload data allowed. Likewise, 567 additional size limits can be set by specific application uses (see 568 Section 9). 570 If a frame size exceeds any defined limit, or is too small to contain 571 mandatory frame data, the endpoint MUST send a FRAME_SIZE_ERROR 572 error. Frame size errors in frames that affect connection-level 573 state MUST be treated as a connection error (Section 5.4.1). 575 4.3. Header Compression and Decompression 577 A header field in HTTP/2.0 is a name-value pair with one or more 578 associated values. They are used within HTTP request and response 579 messages as well as server push operations (see Section 8.2). 581 Header sets are logical collections of zero or more header fields 582 arranged at the application layer. When transmitted over a 583 connection, the header set is serialized into a header block using 584 HTTP Header Compression [COMPRESSION]. The serialized header block 585 is then divided into one or more octet sequences, called header block 586 fragments, and transmitted within the payload of HEADERS 587 (Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION 588 (Section 6.10) frames. The receiving endpoint reassembles the header 589 block by concatenating the individual fragments, then decompresses 590 the block to reconstruct the header set. 592 Header block fragments can only be sent as the payload of HEADERS, 593 PUSH_PROMISE or CONTINUATION frames. 595 A compressed and encoded header block is transmitted in a HEADERS or 596 PUSH_PROMISE frame, followed by zero or more CONTINUATION frames. If 597 the number of octets in the block is greater than the space remaining 598 in the frame, the block is divided into multiple fragments, which are 599 then transmitted in multiple frames. 601 Header blocks MUST be transmitted as a contiguous sequence of frames, 602 with no interleaved frames of any other type, or from any other 603 stream. The last frame in a sequence of HEADERS/CONTINUATION frames 604 MUST have the END_HEADERS flag set. The last frame in a sequence of 605 PUSH_PROMISE/CONTINUATION frames MUST have the END_PUSH_PROMISE/ 606 END_HEADERS flag set (respectively). 608 HEADERS, PUSH_PROMISE and CONTINUATION frames carry data that can 609 modify the compression context maintained by a receiver. An endpoint 610 receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST 611 reassemble header blocks and perform decompression even if the frames 612 are to be discarded. A receiver MUST terminate the connection with a 613 connection error (Section 5.4.1) of type COMPRESSION_ERROR, if it 614 does not decompress a header block. 616 5. Streams and Multiplexing 618 A "stream" is an independent, bi-directional sequence of HEADERS and 619 DATA frames exchanged between the client and server within an 620 HTTP/2.0 connection. Streams have several important characteristics: 622 o A single HTTP/2.0 connection can contain multiple concurrently 623 open streams, with either endpoint interleaving frames from 624 multiple streams. 626 o Streams can be established and used unilaterally or shared by 627 either the client or server. 629 o Streams can be closed by either endpoint. 631 o The order in which frames are sent within a stream is significant. 632 Recipients process frames in the order they are received. 634 o Streams are identified by an integer. Stream identifiers are 635 assigned to streams by the initiating endpoint. 637 5.1. Stream States 639 The lifecycle of a stream is shown in Figure 1. 641 +--------+ 642 PP | | PP 643 ,--------| idle |--------. 644 / | | \ 645 v +--------+ v 646 +----------+ | +----------+ 647 | | | H | | 648 ,---| reserved | | | reserved |---. 649 | | (local) | v | (remote) | | 650 | +----------+ +--------+ +----------+ | 651 | | ES | | ES | | 652 | | H ,-------| open |-------. | H | 653 | | / | | \ | | 654 | v v +--------+ v v | 655 | +----------+ | +----------+ | 656 | | half | | | half | | 657 | | closed | | R | closed | | 658 | | (remote) | | | (local) | | 659 | +----------+ | +----------+ | 660 | | v | | 661 | | ES / R +--------+ ES / R | | 662 | `----------->| |<-----------' | 663 | R | closed | R | 664 `-------------------->| |<--------------------' 665 +--------+ 667 Figure 1: Stream States 669 Both endpoints have a subjective view of the state of a stream that 670 could be different when frames are in transit. Endpoints do not 671 coordinate the creation of streams, they are created unilaterally by 672 either endpoint. The negative consequences of a mismatch in states 673 are limited to the "closed" state after sending RST_STREAM, where 674 frames might be received for some time after closing. 676 Streams have the following states: 678 idle: 679 All streams start in the "idle" state. In this state, no frames 680 have been exchanged. 682 The following transitions are valid from this state: 684 * Sending or receiving a HEADERS frame causes the stream to 685 become "open". The stream identifier is selected as described 686 in Section 5.1.1. The same HEADERS frame can also cause a 687 stream to immediately become "half closed". 689 * Sending a PUSH_PROMISE frame marks the associated stream for 690 later use. The stream state for the reserved stream 691 transitions to "reserved (local)". 693 * Receiving a PUSH_PROMISE frame marks the associated stream as 694 reserved by the remote peer. The state of the stream becomes 695 "reserved (remote)". 697 reserved (local): 698 A stream in the "reserved (local)" state is one that has been 699 promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame 700 reserves an idle stream by associating the stream with an open 701 stream that was initiated by the remote peer (see Section 8.2). 703 In this state, only the following transitions are possible: 705 * The endpoint can send a HEADERS frame. This causes the stream 706 to open in a "half closed (remote)" state. 708 * Either endpoint can send a RST_STREAM frame to cause the stream 709 to become "closed". This releases the stream reservation. 711 An endpoint MUST NOT send frames other than than HEADERS or 712 RST_STREAM in this state. 714 A PRIORITY frame MAY be received in this state. Receiving any 715 frame other than HEADERS, RST_STREAM, or PRIORITY MUST be treated 716 as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 718 reserved (remote): 719 A stream in the "reserved (remote)" state has been reserved by a 720 remote peer. 722 In this state, only the following transitions are possible: 724 * Receiving a HEADERS frame causes the stream to transition to 725 "half closed (local)". 727 * Either endpoint can send a RST_STREAM frame to cause the stream 728 to become "closed". This releases the stream reservation. 730 An endpoint MAY send a PRIORITY frame in this state to 731 reprioritize the reserved stream. An endpoint MUST NOT send any 732 other type of frame other than RST_STREAM or PRIORITY. 734 Receiving any other type of frame other than HEADERS or RST_STREAM 735 MUST be treated as a connection error (Section 5.4.1) of type 736 PROTOCOL_ERROR. 738 open: 739 A stream in the "open" state may be used by both peers to send 740 frames of any type. In this state, sending peers observe 741 advertised stream level flow control limits (Section 5.2). 743 From this state either endpoint can send a frame with an 744 END_STREAM flag set, which causes the stream to transition into 745 one of the "half closed" states: an endpoint sending an END_STREAM 746 flag causes the stream state to become "half closed (local)"; an 747 endpoint receiving an END_STREAM flag causes the stream state to 748 become "half closed (remote)". A HEADERS frame bearing an 749 END_STREAM flag can be followed by CONTINUATION frames. 751 Either endpoint can send a RST_STREAM frame from this state, 752 causing it to transition immediately to "closed". 754 half closed (local): 755 A stream that is in the "half closed (local)" state cannot be used 756 for sending frames. 758 A stream transitions from this state to "closed" when a frame that 759 contains an END_STREAM flag is received, or when either peer sends 760 a RST_STREAM frame. A HEADERS frame bearing an END_STREAM flag 761 can be followed by CONTINUATION frames. 763 A receiver can ignore WINDOW_UPDATE or PRIORITY frames in this 764 state. These frame types might arrive for a short period after a 765 frame bearing the END_STREAM flag is sent. 767 half closed (remote): 768 A stream that is "half closed (remote)" is no longer being used by 769 the peer to send frames. In this state, an endpoint is no longer 770 obligated to maintain a receiver flow control window if it 771 performs flow control. 773 If an endpoint receives additional frames for a stream that is in 774 this state, other than CONTINUATION frames, it MUST respond with a 775 stream error (Section 5.4.2) of type STREAM_CLOSED. 777 A stream can transition from this state to "closed" by sending a 778 frame that contains a END_STREAM flag, or when either peer sends a 779 RST_STREAM frame. 781 closed: 782 The "closed" state is the terminal state. 784 An endpoint MUST NOT send frames on a closed stream. An endpoint 785 that receives any frame after receiving a RST_STREAM MUST treat 786 that as a stream error (Section 5.4.2) of type STREAM_CLOSED. 787 Similarly, an endpoint that receives any frame after receiving a 788 DATA frame with the END_STREAM flag set, or any frame except a 789 CONTINUATION frame after receiving a HEADERS frame with a 790 END_STREAM flag set MUST treat that as a stream error 791 (Section 5.4.2) of type STREAM_CLOSED. 793 WINDOW_UPDATE, PRIORITY, or RST_STREAM frames can be received in 794 this state for a short period after a DATA or HEADERS frame 795 containing an END_STREAM flag is sent. Until the remote peer 796 receives and processes the frame bearing the END_STREAM flag, it 797 might send frame of any of these types. Endpoints MUST ignore 798 WINDOW_UPDATE, PRIORITY, or RST_STREAM frames received in this 799 state, though endpoints MAY choose to treat frames that arrive a 800 significant time after sending END_STREAM as a connection error 801 (Section 5.4.1) of type PROTOCOL_ERROR. 803 If this state is reached as a result of sending a RST_STREAM 804 frame, the peer that receives the RST_STREAM might have already 805 sent - or enqueued for sending - frames on the stream that cannot 806 be withdrawn. An endpoint MUST ignore frames that it receives on 807 closed streams after it has sent a RST_STREAM frame. An endpoint 808 MAY choose to limit the period over which it ignores frames and 809 treat frames that arrive after this time as being in error. 811 Flow controlled frames (i.e., DATA) received after sending 812 RST_STREAM are counted toward the connection flow control window. 813 Even though these frames might be ignored, because they are sent 814 before the sender receives the RST_STREAM, the sender will 815 consider the frames to count against the flow control window. 817 An endpoint might receive a PUSH_PROMISE frame after it sends 818 RST_STREAM. PUSH_PROMISE causes a stream to become "reserved". 819 The RST_STREAM does not cancel any promised stream. Therefore, if 820 promised streams are not desired, a RST_STREAM can be used to 821 close any of those streams. 823 In the absence of more specific guidance elsewhere in this document, 824 implementations SHOULD treat the receipt of a message that is not 825 expressly permitted in the description of a state as a connection 826 error (Section 5.4.1) of type PROTOCOL_ERROR. 828 5.1.1. Stream Identifiers 830 Streams are identified with an unsigned 31-bit integer. Streams 831 initiated by a client MUST use odd-numbered stream identifiers; those 832 initiated by the server MUST use even-numbered stream identifiers. A 833 stream identifier of zero (0x0) is used for connection control 834 message; the stream identifier zero MUST NOT be used to establish a 835 new stream. 837 A stream identifier of one (0x1) is used to respond to the HTTP/1.1 838 request which was specified during Upgrade (see Section 3.2). After 839 the upgrade completes, stream 0x1 is "half closed (local)" to the 840 client. Therefore, stream 0x1 cannot be selected as a new stream 841 identifier by a client that upgrades from HTTP/1.1. 843 The identifier of a newly established stream MUST be numerically 844 greater than all streams that the initiating endpoint has opened or 845 reserved. This governs streams that are opened using a HEADERS frame 846 and streams that are reserved using PUSH_PROMISE. An endpoint that 847 receives an unexpected stream identifier MUST respond with a 848 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 850 The first use of a new stream identifier implicitly closes all 851 streams in the "idle" state that might have been initiated by that 852 peer with a lower-valued stream identifier. For example, if a client 853 sends a HEADERS frame on stream 7 without ever sending a frame on 854 stream 5, then stream 5 transitions to the "closed" state when the 855 first frame for stream 7 is sent or received. 857 Stream identifiers cannot be reused. Long-lived connections can 858 result in endpoint exhausting the available range of stream 859 identifiers. A client that is unable to establish a new stream 860 identifier can establish a new connection for new streams. 862 5.1.2. Stream Concurrency 864 A peer can limit the number of concurrently active streams using the 865 SETTINGS_MAX_CONCURRENT_STREAMS parameters within a SETTINGS frame. 866 The maximum concurrent streams setting is specific to each endpoint 867 and applies only to the peer that receives the setting. That is, 868 clients specify the maximum number of concurrent streams the server 869 can initiate, and servers specify the maximum number of concurrent 870 streams the client can initiate. Endpoints MUST NOT exceed the limit 871 set by their peer. 873 Streams that are in the "open" state, or either of the "half closed" 874 states count toward the maximum number of streams that an endpoint is 875 permitted to open. Streams in any of these three states count toward 876 the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting 877 (see Section 6.5.2). 879 Streams in either of the "reserved" states do not count as open, even 880 if a small amount of application state is retained to ensure that the 881 promised stream can be successfully used. 883 5.2. Flow Control 885 Using streams for multiplexing introduces contention over use of the 886 TCP connection, resulting in blocked streams. A flow control scheme 887 ensures that streams on the same connection do not destructively 888 interfere with each other. Flow control is used for both individual 889 streams and for the connection as a whole. 891 HTTP/2.0 provides for flow control through use of the WINDOW_UPDATE 892 frame type. 894 5.2.1. Flow Control Principles 896 HTTP/2.0 stream flow control aims to allow for future improvements to 897 flow control algorithms without requiring protocol changes. Flow 898 control in HTTP/2.0 has the following characteristics: 900 1. Flow control is hop-by-hop, not end-to-end. 902 2. Flow control is based on window update frames. Receivers 903 advertise how many bytes they are prepared to receive on a stream 904 and for the entire connection. This is a credit-based scheme. 906 3. Flow control is directional with overall control provided by the 907 receiver. A receiver MAY choose to set any window size that it 908 desires for each stream and for the entire connection. A sender 909 MUST respect flow control limits imposed by a receiver. Clients, 910 servers and intermediaries all independently advertise their flow 911 control preferences as a receiver and abide by the flow control 912 limits set by their peer when sending. 914 4. The initial value for the flow control window is 65,535 bytes for 915 both new streams and the overall connection. 917 5. The frame type determines whether flow control applies to a 918 frame. Of the frames specified in this document, only DATA 919 frames are subject to flow control; all other frame types do not 920 consume space in the advertised flow control window. This 921 ensures that important control frames are not blocked by flow 922 control. 924 6. Flow control can be disabled by a receiver. A receiver can 925 choose to disable both forms of flow control by sending the 926 SETTINGS_FLOW_CONTROL_OPTIONS setting. See Ending Flow Control 927 (Section 6.9.4) for more details. 929 7. HTTP/2.0 standardizes only the format of the WINDOW_UPDATE frame 930 (Section 6.9). This does not stipulate how a receiver decides 931 when to send this frame or the value that it sends. Nor does it 932 specify how a sender chooses to send packets. Implementations 933 are able to select any algorithm that suits their needs. 935 Implementations are also responsible for managing how requests and 936 responses are sent based on priority; choosing how to avoid head of 937 line blocking for requests; and managing the creation of new streams. 938 Algorithm choices for these could interact with any flow control 939 algorithm. 941 5.2.2. Appropriate Use of Flow Control 943 Flow control is defined to protect endpoints that are operating under 944 resource constraints. For example, a proxy needs to share memory 945 between many connections, and also might have a slow upstream 946 connection and a fast downstream one. Flow control addresses cases 947 where the receiver is unable process data on one stream, yet wants to 948 continue to process other streams in the same connection. 950 Deployments that do not require this capability SHOULD disable flow 951 control for data that is being received. Note that flow control 952 cannot be disabled for sending. Sending data is always subject to 953 the flow control window advertised by the receiver. 955 Deployments with constrained resources (for example, memory) MAY 956 employ flow control to limit the amount of memory a peer can consume. 957 Note, however, that this can lead to suboptimal use of available 958 network resources if flow control is enabled without knowledge of the 959 bandwidth-delay product (see [RFC1323]). 961 Even with full awareness of the current bandwidth-delay product, 962 implementation of flow control can be difficult. When using flow 963 control, the receive MUST read from the TCP receive buffer in a 964 timely fashion. Failure to do so could lead to a deadlock when 965 critical frames, such as WINDOW_UPDATE, are not available to 966 HTTP/2.0. However, flow control can ensure that constrained 967 resources are protected without any reduction in connection 968 utilization. 970 5.3. Stream priority 972 The endpoint establishing a new stream can assign a priority for the 973 stream. Priority is represented as an unsigned 31-bit integer. 0 974 represents the highest priority and 2^31-1 represents the lowest 975 priority. 977 The purpose of this value is to allow an endpoint to express the 978 relative priority of a stream. An endpoint can use this information 979 to preferentially allocate resources to a stream. Within HTTP/2.0, 980 priority can be used to select streams for transmitting frames when 981 there is limited capacity for sending. For instance, an endpoint 982 might enqueue frames for all concurrently active streams. As 983 transmission capacity becomes available, frames from higher priority 984 streams might be sent before lower priority streams. 986 Explicitly setting the priority for a stream does not guarantee any 987 particular processing or transmission order for the stream relative 988 to any other stream. Nor is there any mechanism provided by which 989 the initiator of a stream can force or require a receiving endpoint 990 to process concurrent streams in a particular order. 992 Unless explicitly specified in the HEADERS frame (Section 6.2) during 993 stream creation, the default stream priority is 2^30. 995 Pushed streams (Section 8.2) have a lower priority than their 996 associated stream. The promised stream inherits the priority value 997 of the associated stream plus one, up to a maximum of 2^31-1. 999 5.4. Error Handling 1001 HTTP/2.0 framing permits two classes of error: 1003 o An error condition that renders the entire connection unusable is 1004 a connection error. 1006 o An error in an individual stream is a stream error. 1008 A list of error codes is included in Section 7. 1010 5.4.1. Connection Error Handling 1012 A connection error is any error which prevents further processing of 1013 the framing layer or which corrupts any connection state. 1015 An endpoint that encounters a connection error SHOULD first send a 1016 GOAWAY frame (Section 6.8) with the stream identifier of the last 1017 stream that it successfully received from its peer. The GOAWAY frame 1018 includes an error code that indicates why the connection is 1019 terminating. After sending the GOAWAY frame, the endpoint MUST close 1020 the TCP connection. 1022 It is possible that the GOAWAY will not be reliably received by the 1023 receiving endpoint. In the event of a connection error, GOAWAY only 1024 provides a best-effort attempt to communicate with the peer about why 1025 the connection is being terminated. 1027 An endpoint can end a connection at any time. In particular, an 1028 endpoint MAY choose to treat a stream error as a connection error. 1029 Endpoints SHOULD send a GOAWAY frame when ending a connection, as 1030 long as circumstances permit it. 1032 5.4.2. Stream Error Handling 1034 A stream error is an error related to a specific stream identifier 1035 that does not affect processing of other streams. 1037 An endpoint that detects a stream error sends a RST_STREAM frame 1038 (Section 6.4) that contains the stream identifier of the stream where 1039 the error occurred. The RST_STREAM frame includes an error code that 1040 indicates the type of error. 1042 A RST_STREAM is the last frame that an endpoint can send on a stream. 1043 The peer that sends the RST_STREAM frame MUST be prepared to receive 1044 any frames that were sent or enqueued for sending by the remote peer. 1045 These frames can be ignored, except where they modify connection 1046 state (such as the state maintained for header compression 1047 (Section 4.3)). 1049 Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame 1050 for any stream. However, an endpoint MAY send additional RST_STREAM 1051 frames if it receives frames on a closed stream after more than a 1052 round trip time. This behavior is permitted to deal with misbehaving 1053 implementations. 1055 An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM 1056 frame, to avoid looping. 1058 5.4.3. Connection Termination 1060 If the TCP connection is torn down while streams remain in open or 1061 half closed states, then the endpoint MUST assume that the stream was 1062 abnormally interrupted and could be incomplete. 1064 6. Frame Definitions 1066 This specification defines a number of frame types, each identified 1067 by a unique 8-bit type code. Each frame type serves a distinct 1068 purpose either in the establishment and management of the connection 1069 as a whole, or of individual streams. 1071 The transmission of specific frame types can alter the state of a 1072 connection. If endpoints fail to maintain a synchronized view of the 1073 connection state, successful communication within the connection will 1074 no longer be possible. Therefore, it is important that endpoints 1075 have a shared comprehension of how the state is affected by the use 1076 any given frame. Accordingly, while it is expected that new frame 1077 types will be introduced by extensions to this protocol, only frames 1078 defined by this document are permitted to alter the connection state. 1080 6.1. DATA 1082 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1083 octets associated with a stream. One or more DATA frames are used, 1084 for instance, to carry HTTP request or response payloads. 1086 The DATA frame defines the following flags: 1088 END_STREAM (0x1): Bit 1 being set indicates that this frame is the 1089 last that the endpoint will send for the identified stream. 1090 Setting this flag causes the stream to enter a "half closed" or 1091 "closed" state (Section 5.1). 1093 RESERVED (0x2): Bit 2 is reserved for future use. 1095 DATA frames MUST be associated with a stream. If a DATA frame is 1096 received whose stream identifier field is 0x0, the recipient MUST 1097 respond with a connection error (Section 5.4.1) of type 1098 PROTOCOL_ERROR. 1100 DATA frames are subject to flow control and can only be sent when a 1101 stream is in the "open" or "half closed (remote)" states. 1103 6.2. HEADERS 1105 The HEADERS frame (type=0x1) carries name-value pairs. It is used to 1106 open a stream (Section 5.1). HEADERS frames can be sent on a stream 1107 in the "open" or "half closed (remote)" states. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 |X| Priority (31) | 1113 +-+-------------------------------------------------------------+ 1114 | Header Block Fragment (*) ... 1115 +---------------------------------------------------------------+ 1117 HEADERS Frame Payload 1119 The HEADERS frame defines the following flags: 1121 END_STREAM (0x1): Bit 1 being set indicates that this frame is the 1122 last that the endpoint will send for the identified stream. 1123 Setting this flag causes the stream to enter a "half closed" state 1124 (Section 5.1). 1126 A HEADERS frame that is followed by CONTINUATION frames carries 1127 the flag that signals the end of a stream. A CONTINUATION frame 1128 cannot be used to terminate a stream. 1130 RESERVED (0x2): Bit 2 is reserved for future use. 1132 END_HEADERS (0x4): Bit 3 being set indicates that this frame ends 1133 the sequence of header block fragments necessary to provide a 1134 complete set of header fields. 1136 The payload for a complete header block is provided by a sequence 1137 of that starts with a HEADERS frame, followed by zero or more 1138 CONTINUATION frames. The sequence is terminated by a frame with 1139 the END_HEADERS flag set. Once the sequence terminates, the 1140 payload of all HEADERS and CONTINUATION frames are concatenated 1141 and interpreted as a single block. 1143 A HEADERS frame without the END_HEADERS flag set MUST be followed 1144 by a CONTINUATION frame for the same stream. A receiver MUST 1145 treat the receipt of any other type of frame or a frame on a 1146 different stream as a connection error (Section 5.4.1) of type 1147 PROTOCOL_ERROR. 1149 PRIORITY (0x8): Bit 4 being set indicates that the first four octets 1150 of this frame contain a single reserved bit and a 31-bit priority; 1151 see Section 5.3. If this bit is not set, the four bytes do not 1152 appear and the frame only contains a header block fragment. 1154 The payload of a HEADERS frame contains a header block fragment 1155 (Section 4.3). A header block that does not fit within a HEADERS 1156 frame is continued in a CONTINUATION frame (Section 6.10). 1158 HEADERS frames MUST be associated with a stream. If a HEADERS frame 1159 is received whose stream identifier field is 0x0, the recipient MUST 1160 respond with a connection error (Section 5.4.1) of type 1161 PROTOCOL_ERROR. 1163 The HEADERS frame changes the connection state as described in 1164 Section 4.3. 1166 6.3. PRIORITY 1168 The PRIORITY frame (type=0x2) specifies the sender-advised priority 1169 of a stream. It can be sent at any time for an existing stream. 1170 This enables reprioritisation of existing streams. 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 |X| Priority (31) | 1176 +-+-------------------------------------------------------------+ 1178 PRIORITY Frame Payload 1180 The payload of a PRIORITY frame contains a single reserved bit and a 1181 31-bit priority. 1183 The PRIORITY frame does not define any flags. 1185 The PRIORITY frame is associated with an existing stream. If a 1186 PRIORITY frame is received with a stream identifier of 0x0, the 1187 recipient MUST respond with a connection error (Section 5.4.1) of 1188 type PROTOCOL_ERROR. 1190 The PRIORITY frame can be sent on a stream in any of the "reserved 1191 (remote)", "open", "half-closed (local)", or "half closed (remote)" 1192 states, though it cannot be sent between consecutive frames that 1193 comprise a single header block (Section 4.3). Note that this frame 1194 could arrive after processing or frame sending has completed, which 1195 would cause it to have no effect. For a stream that is in the "half 1196 closed (remote)" state, this frame can only affect processing of the 1197 stream and not frame transmission. 1199 6.4. RST_STREAM 1201 The RST_STREAM frame (type=0x3) allows for abnormal termination of a 1202 stream. When sent by the initiator of a stream, it indicates that 1203 they wish to cancel the stream or that an error condition has 1204 occurred. When sent by the receiver of a stream, it indicates that 1205 either the receiver is rejecting the stream, requesting that the 1206 stream be cancelled or that an error condition has occurred. 1208 0 1 2 3 1209 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 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Error Code (32) | 1212 +---------------------------------------------------------------+ 1214 RST_STREAM Frame Payload 1216 The RST_STREAM frame contains a single unsigned, 32-bit integer 1217 identifying the error code (Section 7). The error code indicates why 1218 the stream is being terminated. 1220 The RST_STREAM frame does not define any flags. 1222 The RST_STREAM frame fully terminates the referenced stream and 1223 causes it to enter the closed state. After receiving a RST_STREAM on 1224 a stream, the receiver MUST NOT send additional frames for that 1225 stream. However, after sending the RST_STREAM, the sending endpoint 1226 MUST be prepared to receive and process additional frames sent on the 1227 stream that might have been sent by the peer prior to the arrival of 1228 the RST_STREAM. 1230 RST_STREAM frames MUST be associated with a stream. If a RST_STREAM 1231 frame is received with a stream identifier of 0x0, the recipient MUST 1232 treat this as a connection error (Section 5.4.1) of type 1233 PROTOCOL_ERROR. 1235 RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. 1236 If a RST_STREAM frame identifying an idle stream is received, the 1237 recipient MUST treat this as a connection error (Section 5.4.1) of 1238 type PROTOCOL_ERROR. 1240 6.5. SETTINGS 1242 The SETTINGS frame (type=0x4) conveys configuration parameters that 1243 affect how endpoints communicate. The parameters are either 1244 constraints on peer behavior or preferences. 1246 SETTINGS frames MUST be sent at the start of a connection, and MAY be 1247 sent at any other time by either endpoint over the lifetime of the 1248 connection. 1250 Implementations MUST support all of the settings defined by this 1251 specification and MAY support additional settings defined by 1252 extensions. Unsupported or unrecognized settings MUST be ignored. 1253 New settings MUST NOT be defined or implemented in a way that 1254 requires endpoints to understand them in order to communicate 1255 successfully. 1257 Each setting in a SETTINGS frame replaces the existing value for that 1258 setting. Settings are processed in the order in which they appear, 1259 and a receiver of a SETTINGS frame does not need to maintain any 1260 state other than the current value of settings. Therefore, the value 1261 of a setting is the last value that is seen by a receiver. This 1262 permits the inclusion of the same settings multiple times in the same 1263 SETTINGS frame, though doing so does nothing other than waste 1264 connection capacity. 1266 The SETTINGS frame defines the following flag: 1268 ACK (0x1): Bit 1 being set indicates that this frame acknowledges 1269 receipt and application of the peer's SETTINGS frame. When this 1270 bit is set, the payload of the SETTINGS frame MUST be empty. 1271 Receipt of a SETTINGS frame with the ACK flag set and a length 1272 field value other than 0 MUST be treated as a connection error 1273 (Section 5.4.1) of type FRAME_SIZE_ERROR. For more info, see 1274 Settings Synchronization (Section 6.5.3). 1276 SETTINGS frames always apply to a connection, never a single stream. 1277 The stream identifier for a settings frame MUST be zero. If an 1278 endpoint receives a SETTINGS frame whose stream identifier field is 1279 anything other than 0x0, the endpoint MUST respond with a connection 1280 error (Section 5.4.1) of type PROTOCOL_ERROR. 1282 The SETTINGS frame affects connection state. A badly formed or 1283 incomplete SETTINGS frame MUST be treated as a connection error 1284 (Section 5.4.1) of type PROTOCOL_ERROR. 1286 6.5.1. Setting Format 1288 The payload of a SETTINGS frame consists of zero or more settings. 1289 Each setting consists of an 8-bit reserved field, an unsigned 24-bit 1290 setting identifier, and an unsigned 32-bit value. 1292 0 1 2 3 1293 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 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Reserved (8) | Setting Identifier (24) | 1296 +---------------+-----------------------------------------------+ 1297 | Value (32) | 1298 +---------------------------------------------------------------+ 1300 Setting Format 1302 6.5.2. Defined Settings 1304 The following settings are defined: 1306 SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the 1307 remote endpoint of the size of the header compression table used 1308 to decode header blocks. The default value is 4096 bytes. 1310 SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server 1311 push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE 1312 frame if it receives this setting set to a value of 0. The 1313 default value is 1, which indicates that push is permitted. 1315 SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of 1316 concurrent streams that the sender will allow. This limit is 1317 directional: it applies to the number of streams that the sender 1318 permits the receiver to create. By default there is no limit. It 1319 is recommended that this value be no smaller than 100, so as to 1320 not unnecessarily limit parallelism. 1322 SETTINGS_INITIAL_WINDOW_SIZE (7): Indicates the sender's initial 1323 window size (in bytes) for stream level flow control. 1325 This settings affects the window size of all streams, including 1326 existing streams, see Section 6.9.2. 1328 SETTINGS_FLOW_CONTROL_OPTIONS (10): Indicates flow control options. 1329 The least significant bit (0x1) of the value is set to indicate 1330 that the sender has disabled all flow control. This bit cannot be 1331 cleared once set, see Section 6.9.4. 1333 All bits other than the least significant are reserved. 1335 6.5.3. Settings Synchronization 1337 Most values in SETTINGS benefit from or require an understanding of 1338 when the peer has received and applied the changed setting values. 1339 In order to provide such synchronization timepoints, the recipient of 1340 a SETTINGS frame in which the ACK flag is not set MUST apply the 1341 updated settings as soon as possible upon receipt. 1343 The values in the SETTINGS frame MUST be applied in sequence, with no 1344 other frame processing between values. Once all values have been 1345 applied, the recipient MUST immediately emit a SETTINGS frame with 1346 the ACK flag set. 1348 If the sender of a SETTINGS frame does not receive an acknowledgement 1349 within a reasonable amount of time, it MAY issue a connection error 1350 (Section 5.4.1) of type SETTINGS_TIMEOUT. 1352 6.6. PUSH_PROMISE 1354 The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint 1355 in advance of streams the sender intends to initiate. The 1356 PUSH_PROMISE frame includes the unsigned 31-bit identifier of the 1357 stream the endpoint plans to create along with a minimal set of 1358 headers that provide additional context for the stream. Section 8.2 1359 contains a thorough description of the use of PUSH_PROMISE frames. 1361 PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of 1362 the peer endpoint is set to 0. 1364 0 1 2 3 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 |X| Promised-Stream-ID (31) | 1368 +-+-------------------------------------------------------------+ 1369 | Header Block Fragment (*) ... 1370 +---------------------------------------------------------------+ 1372 PUSH_PROMISE Payload Format 1374 The payload of a PUSH_PROMISE includes a "Promised-Stream-ID". This 1375 unsigned 31-bit integer identifies the stream the endpoint intends to 1376 start sending frames for. The promised stream identifier MUST be a 1377 valid choice for the next stream sent by the sender (see new stream 1378 identifier (Section 5.1.1)). 1380 Following the "Promised-Stream-ID" is a header block fragment 1381 (Section 4.3). 1383 PUSH_PROMISE frames MUST be associated with an existing, peer- 1384 initiated stream. If the stream identifier field specifies the value 1385 0x0, a recipient MUST respond with a connection error (Section 5.4.1) 1386 of type PROTOCOL_ERROR. 1388 The PUSH_PROMISE frame defines the following flags: 1390 END_PUSH_PROMISE (0x4): The END_PUSH_PROMISE bit indicates that this 1391 frame ends the sequence of header block fragments necessary to 1392 provide a complete set of headers. 1394 The payload for a complete header block is provided by a sequence 1395 of frames that starts with a PUSH_PROMISE frame, followed by zero 1396 or more CONTINUATION frames. The sequence terminates by a 1397 PUSH_PROMISE frame with the END_PUSH_PROMISE flag set or a 1398 CONTINUATION frame with the END_HEADERS flag set. Once the 1399 sequence terminates, the payload of all frames in the sequence are 1400 concatenated and interpreted as a single block. 1402 A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be 1403 followed by a CONTINUATION frame for the same stream. A receiver 1404 MUST treat the receipt of any other type of frame or a frame on a 1405 different stream as a connection error (Section 5.4.1) of type 1406 PROTOCOL_ERROR. 1408 Promised streams are not required to be used in order promised. The 1409 PUSH_PROMISE only reserves stream identifiers for later use. 1411 Recipients of PUSH_PROMISE frames can choose to reject promised 1412 streams by returning a RST_STREAM referencing the promised stream 1413 identifier back to the sender of the PUSH_PROMISE. 1415 The PUSH_PROMISE frame modifies the connection state as defined in 1416 Section 4.3. 1418 A PUSH_PROMISE frame modifies the connection state in two ways. The 1419 inclusion of a header block (Section 4.3) potentially modifies the 1420 compression state. PUSH_PROMISE also reserves a stream for later 1421 use, causing the promised stream to enter the "reserved" state. A 1422 sender MUST NOT send a PUSH_PROMISE on a stream unless that stream is 1423 either "open" or "half closed (remote)"; the sender MUST ensure that 1424 the promised stream is a valid choice for a new stream identifier 1425 (Section 5.1.1) (that is, the promised stream MUST be in the "idle" 1426 state). 1428 Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame 1429 causes the stream state to become indeterminate. A receiver MUST 1430 treat the receipt of a PUSH_PROMISE on a stream that is neither 1431 "open" nor "half-closed (local)" as a connection error 1432 (Section 5.4.1) of type PROTOCOL_ERROR. Similarly, a receiver MUST 1433 treat the receipt of a PUSH_PROMISE that promises an illegal stream 1434 identifier (Section 5.1.1) (that is, an identifier for a stream that 1435 is not currently in the "idle" state) as a connection error 1436 (Section 5.4.1) of type PROTOCOL_ERROR, unless the receiver recently 1437 sent a RST_STREAM frame to cancel the associated stream (see 1438 Section 5.1). 1440 6.7. PING 1442 The PING frame (type=0x6) is a mechanism for measuring a minimal 1443 round-trip time from the sender, as well as determining whether an 1444 idle connection is still functional. PING frames can be sent from 1445 any endpoint. 1447 0 1 2 3 1448 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 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | | 1451 | Opaque Data (64) | 1452 | | 1453 +---------------------------------------------------------------+ 1455 PING Payload Format 1457 In addition to the frame header, PING frames MUST contain 8 octets of 1458 data in the payload. A sender can include any value it chooses and 1459 use those bytes in any fashion. 1461 Receivers of a PING frame that does not include a ACK flag MUST send 1462 a PING frame with the ACK flag set in response, with an identical 1463 payload. PING responses SHOULD given higher priority than any other 1464 frame. 1466 The PING frame defines the following flags: 1468 ACK (0x1): Bit 1 being set indicates that this PING frame is a PING 1469 response. An endpoint MUST set this flag in PING responses. An 1470 endpoint MUST NOT respond to PING frames containing this flag. 1472 PING frames are not associated with any individual stream. If a PING 1473 frame is received with a stream identifier field value other than 1474 0x0, the recipient MUST respond with a connection error 1475 (Section 5.4.1) of type PROTOCOL_ERROR. 1477 Receipt of a PING frame with a length field value other than 8 MUST 1478 be treated as a connection error (Section 5.4.1) of type 1479 FRAME_SIZE_ERROR. 1481 6.8. GOAWAY 1483 The GOAWAY frame (type=0x7) informs the remote peer to stop creating 1484 streams on this connection. It can be sent from the client or the 1485 server. Once sent, the sender will ignore frames sent on new streams 1486 for the remainder of the connection. Receivers of a GOAWAY frame 1487 MUST NOT open additional streams on the connection, although a new 1488 connection can be established for new streams. The purpose of this 1489 frame is to allow an endpoint to gracefully stop accepting new 1490 streams (perhaps for a reboot or maintenance), while still finishing 1491 processing of previously established streams. 1493 There is an inherent race condition between an endpoint starting new 1494 streams and the remote sending a GOAWAY frame. To deal with this 1495 case, the GOAWAY contains the stream identifier of the last stream 1496 which was processed on the sending endpoint in this connection. If 1497 the receiver of the GOAWAY used streams that are newer than the 1498 indicated stream identifier, they were not processed by the sender 1499 and the receiver may treat the streams as though they had never been 1500 created at all (hence the receiver may want to re-create the streams 1501 later on a new connection). 1503 Endpoints SHOULD always send a GOAWAY frame before closing a 1504 connection so that the remote can know whether a stream has been 1505 partially processed or not. For example, if an HTTP client sends a 1506 POST at the same time that a server closes a connection, the client 1507 cannot know if the server started to process that POST request if the 1508 server does not send a GOAWAY frame to indicate where it stopped 1509 working. An endpoint might choose to close a connection without 1510 sending GOAWAY for misbehaving peers. 1512 After sending a GOAWAY frame, the sender can discard frames for new 1513 streams. However, any frames that alter connection state cannot be 1514 completely ignored. For instance, HEADERS, PUSH_PROMISE and 1515 CONTINUATION frames MUST be minimally processed to ensure a 1516 consistent compression state (see Section 4.3); similarly DATA frames 1517 MUST be counted toward the connection flow control window. 1519 0 1 2 3 1520 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 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 |X| Last-Stream-ID (31) | 1523 +-+-------------------------------------------------------------+ 1524 | Error Code (32) | 1525 +---------------------------------------------------------------+ 1526 | Additional Debug Data (*) | 1527 +---------------------------------------------------------------+ 1529 GOAWAY Payload Format 1531 The GOAWAY frame does not define any flags. 1533 The GOAWAY frame applies to the connection, not a specific stream. 1534 The stream identifier MUST be zero. 1536 The last stream identifier in the GOAWAY frame contains the highest 1537 numbered stream identifier for which the sender of the GOAWAY frame 1538 has received frames on and might have taken some action on. All 1539 streams up to and including the identified stream might have been 1540 processed in some way. The last stream identifier is set to 0 if no 1541 streams were processed. 1543 Note: In this case, "processed" means that some data from the 1544 stream was passed to some higher layer of software that might have 1545 taken some action as a result. 1547 If a connection terminates without a GOAWAY frame, this value is 1548 effectively the highest stream identifier. 1550 On streams with lower or equal numbered identifiers that were not 1551 closed completely prior to the connection being closed, re-attempting 1552 requests, transactions, or any protocol activity is not possible 1553 (with the exception of idempotent actions like HTTP GET, PUT, or 1554 DELETE). Any protocol activity that uses higher numbered streams can 1555 be safely retried using a new connection. 1557 Activity on streams numbered lower or equal to the last stream 1558 identifier might still complete successfully. The sender of a GOAWAY 1559 frame might gracefully shut down a connection by sending a GOAWAY 1560 frame, maintaining the connection in an open state until all in- 1561 progress streams complete. 1563 The last stream ID MUST be 0 if no streams were acted upon. 1565 The GOAWAY frame also contains a 32-bit error code (Section 7) that 1566 contains the reason for closing the connection. 1568 Endpoints MAY append opaque data to the payload of any GOAWAY frame. 1569 Additional debug data is intended for diagnostic purposes only and 1570 carries no semantic value. Debug data MUST NOT be persistently 1571 stored, since it could contain sensitive information. 1573 6.9. WINDOW_UPDATE 1575 The WINDOW_UPDATE frame (type=0x9) is used to implement flow control. 1577 Flow control operates at two levels: on each individual stream and on 1578 the entire connection. 1580 Both types of flow control are hop by hop; that is, only between the 1581 two endpoints. Intermediaries do not forward WINDOW_UPDATE frames 1582 between dependent connections. However, throttling of data transfer 1583 by any receiver can indirectly cause the propagation of flow control 1584 information toward the original sender. 1586 Flow control only applies to frames that are identified as being 1587 subject to flow control. Of the frame types defined in this 1588 document, this includes only DATA frame. Frames that are exempt from 1589 flow control MUST be accepted and processed, unless the receiver is 1590 unable to assign resources to handling the frame. A receiver MAY 1591 respond with a stream error (Section 5.4.2) or connection error 1592 (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable accept a 1593 frame. 1595 0 1 2 3 1596 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 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 |X| Window Size Increment (31) | 1599 +-+-------------------------------------------------------------+ 1601 WINDOW_UPDATE Payload Format 1603 The payload of a WINDOW_UPDATE frame is one reserved bit, plus an 1604 unsigned 31-bit integer indicating the number of bytes that the 1605 sender can transmit in addition to the existing flow control window. 1606 The legal range for the increment to the flow control window is 1 to 1607 2^31 - 1 (0x7fffffff) bytes. 1609 The WINDOW_UPDATE frame does not define any flags. 1611 The WINDOW_UPDATE frame can be specific to a stream or to the entire 1612 connection. In the former case, the frame's stream identifier 1613 indicates the affected stream; in the latter, the value "0" indicates 1614 that the entire connection is the subject of the frame. 1616 WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the 1617 END_STREAM flag. This means that a receiver could receive a 1618 WINDOW_UPDATE frame on a "half closed (remote)" or "closed" stream. 1619 A receiver MUST NOT treat this as an error, see Section 5.1. 1621 A receiver that receives a flow controlled frame MUST always account 1622 for its contribution against the connection flow control window, 1623 unless the receiver treats this as a connection error 1624 (Section 5.4.1). This is necessary even if the frame is in error. 1625 Since the sender counts the frame toward the flow control window, if 1626 the receiver does not, the flow control window at sender and receiver 1627 can become different. 1629 6.9.1. The Flow Control Window 1631 Flow control in HTTP/2.0 is implemented using a window kept by each 1632 sender on every stream. The flow control window is a simple integer 1633 value that indicates how many bytes of data the sender is permitted 1634 to transmit; as such, its size is a measure of the buffering 1635 capability of the receiver. 1637 Two flow control windows are applicable: the stream flow control 1638 window and the connection flow control window. The sender MUST NOT 1639 send a flow controlled frame with a length that exceeds the space 1640 available in either of the flow control windows advertised by the 1641 receiver. Frames with zero length with the END_STREAM flag set (for 1642 example, an empty data frame) MAY be sent if there is no available 1643 space in either flow control window. 1645 For flow control calculations, the 8 byte frame header is not 1646 counted. 1648 After sending a flow controlled frame, the sender reduces the space 1649 available in both windows by the length of the transmitted frame. 1651 The receiver of a frame sends a WINDOW_UPDATE frame as it consumes 1652 data and frees up space in flow control windows. Separate 1653 WINDOW_UPDATE frames are sent for the stream and connection level 1654 flow control windows. 1656 A sender that receives a WINDOW_UPDATE frame updates the 1657 corresponding window by the amount specified in the frame. 1659 A sender MUST NOT allow a flow control window to exceed 2^31 - 1 1660 bytes. If a sender receives a WINDOW_UPDATE that causes a flow 1661 control window to exceed this maximum it MUST terminate either the 1662 stream or the connection, as appropriate. For streams, the sender 1663 sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code; 1664 for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code. 1666 Flow controlled frames from the sender and WINDOW_UPDATE frames from 1667 the receiver are completely asynchronous with respect to each other. 1668 This property allows a receiver to aggressively update the window 1669 size kept by the sender to prevent streams from stalling. 1671 6.9.2. Initial Flow Control Window Size 1673 When a HTTP/2.0 connection is first established, new streams are 1674 created with an initial flow control window size of 65,535 bytes. 1675 The connection flow control window is 65,535 bytes. Both endpoints 1676 can adjust the initial window size for new streams by including a 1677 value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that 1678 forms part of the connection header. 1680 Prior to receiving a SETTINGS frame that sets a value for 1681 SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default 1682 initial window size when sending flow controlled frames. Similarly, 1683 the connection flow control window is set to the default initial 1684 window size until a WINDOW_UPDATE frame is received. 1686 A SETTINGS frame can alter the initial flow control window size for 1687 all current streams. When the value of SETTINGS_INITIAL_WINDOW_SIZE 1688 changes, a receiver MUST adjust the size of all stream flow control 1689 windows that it maintains by the difference between the new value and 1690 the old value. A SETTINGS frame cannot alter the connection flow 1691 control window. 1693 A change to SETTINGS_INITIAL_WINDOW_SIZE could cause the available 1694 space in a flow control window to become negative. A sender MUST 1695 track the negative flow control window, and MUST NOT send new flow 1696 controlled frames until it receives WINDOW_UPDATE frames that cause 1697 the flow control window to become positive. 1699 For example, if the client sends 60KB immediately on connection 1700 establishment, and the server sets the initial window size to be 1701 16KB, the client will recalculate the available flow control window 1702 to be -44KB on receipt of the SETTINGS frame. The client retains a 1703 negative flow control window until WINDOW_UPDATE frames restore the 1704 window to being positive, after which the client can resume sending. 1706 6.9.3. Reducing the Stream Window Size 1708 A receiver that wishes to use a smaller flow control window than the 1709 current size can send a new SETTINGS frame. However, the receiver 1710 MUST be prepared to receive data that exceeds this window size, since 1711 the sender might send data that exceeds the lower limit prior to 1712 processing the SETTINGS frame. 1714 A receiver has two options for handling streams that exceed flow 1715 control limits: 1717 1. The receiver can immediately send RST_STREAM with 1718 FLOW_CONTROL_ERROR error code for the affected streams. 1720 2. The receiver can accept the streams and tolerate the resulting 1721 head of line blocking, sending WINDOW_UPDATE frames as it 1722 consumes data. 1724 If a receiver decides to accept streams, both sides MUST recompute 1725 the available flow control window based on the initial window size 1726 sent in the SETTINGS. 1728 6.9.4. Ending Flow Control 1730 After a receiver reads in a frame that marks the end of a stream (for 1731 example, a data stream with a END_STREAM flag set), it MUST cease 1732 transmission of WINDOW_UPDATE frames for that stream. A sender is 1733 not obligated to maintain the available flow control window for 1734 streams that it is no longer sending on. 1736 Flow control can be disabled for the entire connection using the 1737 SETTINGS_FLOW_CONTROL_OPTIONS setting. This setting ends all forms 1738 of flow control. An implementation that does not wish to perform 1739 flow control can use this in the initial SETTINGS exchange. 1741 Flow control cannot be enabled again once disabled. Any attempt to 1742 re-enable flow control - by sending a WINDOW_UPDATE or by clearing 1743 the bits on the SETTINGS_FLOW_CONTROL_OPTIONS setting - MUST be 1744 rejected with a FLOW_CONTROL_ERROR error code. 1746 6.10. CONTINUATION 1748 The CONTINUATION frame (type=0xA) is used to continue a sequence of 1749 header block fragments (Section 4.3). Any number of CONTINUATION 1750 frames can be sent on an existing stream, as long as the preceding 1751 frame on the same stream is one of HEADERS, PUSH_PROMISE or 1752 CONTINUATION. 1754 0 1 2 3 1755 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 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 | Header Block Fragment (*) ... 1758 +---------------------------------------------------------------+ 1760 CONTINUATION Frame Payload 1762 The CONTINUATION frame defines the following flags: 1764 END_HEADERS (0x4): The END_HEADERS bit indicates that this frame 1765 ends the sequence of header block fragments necessary to provide a 1766 complete set of header fields. 1768 The payload for a complete header block is provided by a sequence 1769 that starts with a HEADERS or PUSH_PROMISE frame and zero or more 1770 CONTINUATION frames, terminated by a HEADERS or CONTINUATION frame 1771 with the END_HEADERS flag set, or PUSH_PROMISE frame with the 1772 END_PUSH_PROMISE flag set. Once the sequence terminates, the 1773 payload of all frames in the sequence are concatenated and 1774 interpreted as a single block. 1776 A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the 1777 END_HEADERS flag set MUST be followed by a CONTINUATION frame for 1778 the same stream. A receiver MUST treat the receipt of any other 1779 type of frame or a frame on a different stream as a connection 1780 error (Section 5.4.1) of type PROTOCOL_ERROR. 1782 The payload of a CONTINUATION frame contains a header block fragment 1783 (Section 4.3). 1785 The CONTINUATION frame changes the connection state as defined in 1786 Section 4.3. 1788 CONTINUATION frames MUST be associated with a stream. If a 1789 CONTINUATION frame is received whose stream identifier field is 0x0, 1790 the recipient MUST respond with a connection error (Section 5.4.1) of 1791 type PROTOCOL_ERROR. 1793 A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or 1794 CONTINUATION frame. A recipient that observes violation of this rule 1795 MUST respond with a connection error (Section 5.4.1) of type 1796 PROTOCOL_ERROR. 1798 7. Error Codes 1800 Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY 1801 frames to convey the reasons for the stream or connection error. 1803 Error codes share a common code space. Some error codes only apply 1804 to specific conditions and have no defined semantics in certain frame 1805 types. 1807 The following error codes are defined: 1809 NO_ERROR (0): The associated condition is not as a result of an 1810 error. For example, a GOAWAY might include this code to indicate 1811 graceful shutdown of a connection. 1813 PROTOCOL_ERROR (1): The endpoint detected an unspecific protocol 1814 error. This error is for use when a more specific error code is 1815 not available. 1817 INTERNAL_ERROR (2): The endpoint encountered an unexpected internal 1818 error. 1820 FLOW_CONTROL_ERROR (3): The endpoint detected that its peer violated 1821 the flow control protocol. 1823 SETTINGS_TIMEOUT (4): The endpoint sent a SETTINGS frame, but did 1824 not receive a response in a timely manner. See Settings 1825 Synchronization (Section 6.5.3). 1827 STREAM_CLOSED (5): The endpoint received a frame after a stream was 1828 half closed. 1830 FRAME_SIZE_ERROR (6): The endpoint received a frame that was larger 1831 than the maximum size that it supports. 1833 REFUSED_STREAM (7): The endpoint refuses the stream prior to 1834 performing any application processing, see Section 8.1.4 for 1835 details. 1837 CANCEL (8): Used by the endpoint to indicate that the stream is no 1838 longer needed. 1840 COMPRESSION_ERROR (9): The endpoint is unable to maintain the 1841 compression context for the connection. 1843 CONNECT_ERROR (10): The connection established in response to a 1844 CONNECT request (Section 8.3) was reset or abnormally closed. 1846 ENHANCE_YOUR_CALM (420): The endpoint detected that its peer is 1847 exhibiting a behavior over a given amount of time that has caused 1848 it to refuse to process further frames. 1850 8. HTTP Message Exchanges 1852 HTTP/2.0 is intended to be as compatible as possible with current 1853 web-based applications. This means that, from the perspective of the 1854 server business logic or application API, the features of HTTP are 1855 unchanged. To achieve this, all of the application request and 1856 response header semantics are preserved, although the syntax of 1857 conveying those semantics has changed. Thus, the rules from HTTP/1.1 1858 ([HTTP-p1], [HTTP-p2], [HTTP-p4], [HTTP-p5], [HTTP-p6], and 1859 [HTTP-p7]) apply with the changes in the sections below. 1861 8.1. HTTP Request/Response Exchange 1863 A client sends an HTTP request on a new stream, using a previously 1864 unused stream identifier (Section 5.1.1). A server sends an HTTP 1865 response on the same stream as the request. 1867 An HTTP request or response each consist of: 1869 1. a HEADERS frame; 1871 2. one contiguous sequence of zero or more CONTINUATION frames; 1873 3. zero or more DATA frames; and 1875 4. optionally, a contiguous sequence that starts with a HEADERS 1876 frame, followed by zero or more CONTINUATION frames. 1878 The last frame in the sequence bears an END_STREAM flag, though a 1879 HEADERS frame bearing the END_STREAM flag can be followed by 1880 CONTINUATION frames that carry any remaining portions of the header 1881 block. 1883 Other frames MAY be interspersed with these frames, but those frames 1884 do not carry HTTP semantics. In particular, HEADERS frames (and any 1885 CONTINUATION frames that follow) other than the first and optional 1886 last frames in this sequence do not carry HTTP semantics. 1888 Trailing header fields are carried in a header block that also 1889 terminates the stream. That is, a sequence starting with a HEADERS 1890 frame, followed by zero or more CONTINUATION frames, where the 1891 HEADERS frame bears an END_STREAM flag. Header blocks after the 1892 first that do not terminate the stream are not part of an HTTP 1893 request or response. 1895 An HTTP request/response exchange fully consumes a single stream. A 1896 request starts with the HEADERS frame that puts the stream into an 1897 "open" state and ends with a frame bearing END_STREAM, which causes 1898 the stream to become "half closed" for the client. A response starts 1899 with a HEADERS frame and ends with a frame bearing END_STREAM, which 1900 places the stream in the "closed" state. 1902 8.1.1. Informational Responses 1904 [[anchor12: This section is likely to change significantly. This 1905 only captures the high points.]] 1907 The 1xx series of HTTP response codes ([HTTP-p2], Section 6.2) are 1908 not supported by HTTP/2.0. 1910 An intermediary that translates HTTP/1.1 requests to HTTP/2.0 MUST 1911 generate any mandatory informational responses. For instance, a 1912 translating intermediary generates a 100 (Continue) response if a 1913 request includes an Expect header field with a "100-continue" token 1914 ([HTTP-p2], Section 5.1.1). 1916 An intermediary that translates HTTP/1.1 responses to HTTP/2.0 MUST 1917 ignore informational responses. 1919 8.1.2. Examples 1921 This section shows HTTP/1.1 requests and responses, with 1922 illustrations of equivalent HTTP/2.0 requests and responses. 1924 An HTTP GET request includes request header fields and no body and is 1925 therefore transmitted as a single contiguous sequence of HEADERS 1926 frames containing the serialized block of request header fields. The 1927 last HEADERS frame in the sequence has both the END_HEADERS and 1928 END_STREAM flag set: 1930 GET /resource HTTP/1.1 HEADERS 1931 Host: example.org ==> + END_STREAM 1932 Accept: image/jpeg + END_HEADERS 1933 :method = GET 1934 :scheme = https 1935 :authority = example.org 1936 :path = /resource 1937 accept = image/jpeg 1939 Similarly, a response that includes only response header fields is 1940 transmitted as a sequence of HEADERS frames containing the serialized 1941 block of response header fields. The last HEADERS frame in the 1942 sequence has both the END_HEADERS and END_STREAM flag set: 1944 HTTP/1.1 204 No Content HEADERS 1945 Content-Length: 0 ===> + END_STREAM 1946 + END_HEADERS 1947 :status = 204 1948 content-length: 0 1950 An HTTP POST request that includes request header fields and payload 1951 data is transmitted as one HEADERS frame, followed by zero or more 1952 CONTINUATION frames, containing the request header fields followed by 1953 one or more DATA frames, with the last CONTINUATION (or HEADERS) 1954 frame having the END_HEADERS flag set and the final DATA frame having 1955 the END_STREAM flag set: 1957 POST /resource HTTP/1.1 HEADERS 1958 Host: example.org ==> - END_STREAM 1959 Content-Type: image/jpeg + END_HEADERS 1960 Content-Length: 123 :method = POST 1961 :scheme = https 1962 {binary data} :authority = example.org 1963 :path = /resource 1964 content-type = image/jpeg 1965 content-length = 123 1967 DATA 1968 + END_STREAM 1969 {binary data} 1971 A response that includes header fields and payload data is 1972 transmitted as a HEADERS frame, followed by zero or more CONTINUATION 1973 frames, followed by one or more DATA frames, with the last DATA frame 1974 in the sequence having the END_STREAM flag set: 1976 HTTP/1.1 200 OK HEADERS 1977 Content-Type: image/jpeg ==> - END_STREAM 1978 Content-Length: 123 + END_HEADERS 1979 :status = 200 1980 {binary data} content-type = image/jpeg 1981 content-length = 123 1983 DATA 1984 + END_STREAM 1985 {binary data} 1987 Trailing header fields are sent as a header block after both the 1988 request or response header block and all the DATA frames have been 1989 sent. The sequence of HEADERS/CONTINUATION frames that bears the 1990 trailers includes a terminal frame that has both END_HEADERS and 1991 END_STREAM flags set. 1993 HTTP/1.1 200 OK HEADERS 1994 Content-Type: image/jpeg ===> - END_STREAM 1995 Content-Length: 123 + END_HEADERS 1996 Transfer-Encoding: chunked :status = 200 1997 TE: trailers content-length = 123 1998 123 content-type = image/jpeg 1999 {binary data} 2000 0 DATA 2001 Foo: bar - END_STREAM 2002 {binary data} 2004 HEADERS 2005 + END_STREAM 2006 + END_HEADERS 2007 foo: bar 2009 8.1.3. HTTP Header Fields 2011 HTTP/2.0 request and response header fields carry information as a 2012 series of key-value pairs. This includes the target URI for the 2013 request, the status code for the response, as well as HTTP header 2014 fields. 2016 HTTP header field names are strings of ASCII characters that are 2017 compared in a case-insensitive fashion. Header field names MUST be 2018 converted to lowercase prior to their encoding in HTTP/2.0. A 2019 request or response containing uppercase header field names MUST be 2020 treated as malformed (Section 8.1.3.3). 2022 The semantics of HTTP header fields are not altered by this 2023 specification, though header fields relating to connection management 2024 or request framing are no longer necessary. An HTTP/2.0 request or 2025 response MUST NOT include any of the following header fields: 2026 Connection, Keep-Alive, Proxy-Connection, TE, Transfer-Encoding, and 2027 Upgrade. A request or response containing these header fields MUST 2028 be treated as malformed (Section 8.1.3.3). 2030 Note: HTTP/2.0 purposefully does not support upgrade from HTTP/2.0 2031 to another protocol. The handshake methods described in Section 3 2032 are sufficient to negotiate the use of alternative protocols. 2034 8.1.3.1. Request Header Fields 2036 HTTP/2.0 defines a number of header fields starting with a colon ':' 2037 character that carry information about the request target: 2039 o The ":method" header field includes the HTTP method ([HTTP-p2], 2040 Section 4). 2042 o The ":scheme" header field includes the scheme portion of the 2043 target URI ([RFC3986], Section 3.1). 2045 o The ":authority" header field includes the authority portion of 2046 the target URI ([RFC3986], Section 3.2). 2048 To ensure that the HTTP/1.1 request line can be reproduced 2049 accurately, this header field MUST be omitted when translating 2050 from an HTTP/1.1 request that has a request target in origin or 2051 asterisk form (see [HTTP-p1], Section 5.3). Clients that generate 2052 HTTP/2.0 requests directly SHOULD instead omit the "Host" header 2053 field. An intermediary that converts a request to HTTP/1.1 MUST 2054 create a "Host" header field if one is not present in a request by 2055 copying the value of the ":authority" header field. 2057 o The ":path" header field includes the path and query parts of the 2058 target URI (the "path-absolute" production from [RFC3986] and 2059 optionally a '?' character followed by the "query" production, see 2060 [RFC3986], Section 3.3 and [RFC3986], Section 3.4). This field 2061 MUST NOT be empty; URIs that do not contain a path component MUST 2062 include a value of '/', unless the request is an OPTIONS in 2063 asterisk form, in which case the ":path" header field MUST include 2064 '*'. 2066 All HTTP/2.0 requests MUST include exactly one valid value for all of 2067 these header fields, unless this is a CONNECT request (Section 8.3). 2068 An HTTP request that omits mandatory header fields is malformed 2069 (Section 8.1.3.3). 2071 Header field names that contain a colon are only valid in the 2072 HTTP/2.0 context. These are not HTTP header fields. Implementations 2073 MUST NOT generate header fields that start with a colon, but they 2074 MUST ignore any header field that starts with a colon. In 2075 particular, header fields with names starting with a colon MUST NOT 2076 be exposed as HTTP header fields. 2078 HTTP/2.0 does not define a way to carry the version identifier that 2079 is included in the HTTP/1.1 request line. 2081 8.1.3.2. Response Header Fields 2083 A single ":status" header field is defined that carries the HTTP 2084 status code field (see [HTTP-p2], Section 6). This header field MUST 2085 be included in all responses, otherwise the response is malformed 2086 (Section 8.1.3.3). 2088 HTTP/2.0 does not define a way to carry the version or reason phrase 2089 that is included in an HTTP/1.1 status line. 2091 8.1.3.3. Malformed Requests and Responses 2093 A malformed request or response is one that uses a valid sequence of 2094 HTTP/2.0 frames, but is otherwise invalid due to the presence of 2095 prohibited header fields, the absence of mandatory header fields, or 2096 the inclusion of uppercase header field names. 2098 A request or response that includes an entity body can include a 2099 "content-length" header field. A request or response is also 2100 malformed if the value of a "content-length" header field does not 2101 equal the sum of the DATA frame payload lengths that form the body. 2103 Intermediaries MAY forward a malformed request or response, but only 2104 if the frames are forwarded without inspection of header fields. 2106 Implementations that detect malformed requests or responses need to 2107 ensure that the stream ends. For malformed requests, a server MAY 2108 send an HTTP response to prior to closing or resetting the stream. 2109 Clients MUST NOT accept a malformed response. 2111 8.1.4. Request Reliability Mechanisms in HTTP/2.0 2113 In HTTP/1.1, an HTTP client is unable to retry a non-idempotent 2114 request when an error occurs, because there is no means to determine 2115 the nature of the error. It is possible that some server processing 2116 occurred prior to the error, which could result in undesirable 2117 effects if the request were reattempted. 2119 HTTP/2.0 provides two mechanisms for providing a guarantee to a 2120 client that a request has not been processed: 2122 o The GOAWAY frame indicates the highest stream number that might 2123 have been processed. Requests on streams with higher numbers are 2124 therefore guaranteed to be safe to retry. 2126 o The REFUSED_STREAM error code can be included in a RST_STREAM 2127 frame to indicate that the stream is being closed prior to any 2128 processing having occurred. Any request that was sent on the 2129 reset stream can be safely retried. 2131 Clients MUST NOT treat requests that have not been processed as 2132 having failed. Clients MAY automatically retry these requests, 2133 including those with non-idempotent methods. 2135 A server MUST NOT indicate that a stream has not been processed 2136 unless it can guarantee that fact. If frames that are on a stream 2137 are passed to the application layer for any stream, then 2138 REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame 2139 MUST include a stream identifier that is greater than or equal to the 2140 given stream identifier. 2142 In addition to these mechanisms, the PING frame provides a way for a 2143 client to easily test a connection. Connections that remain idle can 2144 become broken as some middleboxes (for instance, network address 2145 translators, or load balancers) silently discard connection bindings. 2146 The PING frame allows a client to safely test whether a connection is 2147 still active without sending a request. 2149 8.2. Server Push 2151 HTTP/2.0 enables a server to pre-emptively send (or "push") multiple 2152 associated resources to a client in response to a single request. 2153 This feature becomes particularly helpful when the server knows the 2154 client will need to have those resources available in order to fully 2155 process the originally requested resource. 2157 Pushing additional resources is optional, and is negotiated only 2158 between individual endpoints. The SETTINGS_ENABLE_PUSH setting can 2159 be set to 0 to indicate that server push is disabled. Even if 2160 enabled, an intermediary could receive pushed resources from the 2161 server but could choose not to forward those on to the client. How 2162 to make use of the pushed resources is up to that intermediary. 2163 Equally, the intermediary might choose to push additional resources 2164 to the client, without any action taken by the server. 2166 A server can only push requests that are safe (see [HTTP-p2], Section 2167 4.2.1), cacheable (see [HTTP-p6], Section 3) and do not include a 2168 request body. 2170 8.2.1. Push Requests 2172 Server push is semantically equivalent to a server responding to a 2173 request. The PUSH_PROMISE frame, or frames, sent by the server 2174 includes a header block that contains a complete set of request 2175 header fields that the server attributes to the request. It is not 2176 possible to push a response to a request that includes a request 2177 body. 2179 Pushed resources are always associated with an explicit request from 2180 a client. The PUSH_PROMISE frames sent by the server are sent on the 2181 stream created for the original request. The PUSH_PROMISE frame 2182 includes a promised stream identifier, chosen from the stream 2183 identifiers available to the server (see Section 5.1.1). 2185 The header fields in PUSH_PROMISE and any subsequent CONTINUATION 2186 frames MUST be a valid and complete set of request header fields 2187 (Section 8.1.3.1). The server MUST include a method in the ":method" 2188 header field that is safe and cacheable. If a client receives a 2189 PUSH_PROMISE that does not include a complete and valid set of header 2190 fields, or the ":method" header field identifies a method that is not 2191 safe, it MUST respond with a stream error (Section 5.4.2) of type 2192 PROTOCOL_ERROR. 2194 The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to 2195 sending any frames that reference the promised resources. This 2196 avoids a race where clients issue requests for resources prior to 2197 receiving any PUSH_PROMISE frames. 2199 For example, if the server receives a request for a document 2200 containing embedded links to multiple image files, and the server 2201 chooses to push those additional images to the client, sending push 2202 promises before the DATA frames that contain the image links ensure 2203 that the client is able to see the promises before discovering the 2204 resources. Similarly, if the server pushes resources referenced by 2205 the header block (for instance, in Link header fields), sending the 2206 push promises before sending the header block ensures that clients do 2207 not request those resources. 2209 PUSH_PROMISE frames MUST NOT be sent by the client. PUSH_PROMISE 2210 frames can be sent by the server on any stream that was opened by the 2211 client. They MUST be sent on a stream that is in either the "open" 2212 or "half closed (remote)" state to the server. PUSH_PROMISE frames 2213 are interspersed with the frames that comprise a response, though 2214 they cannot be interspersed with HEADERS and CONTINUATION frames that 2215 comprise a single header block. 2217 8.2.2. Push Responses 2219 After sending the PUSH_PROMISE frame, the server can begin delivering 2220 the pushed resource as a response (Section 8.1.3.2) on a server- 2221 initiated stream that uses the promised stream identifier. The 2222 server uses this stream to transmit an HTTP response, using the same 2223 sequence of frames as defined in Section 8.1. This stream becomes 2224 "half closed" to the client (Section 5.1) after the initial HEADERS 2225 frame is sent. 2227 Once a client receives a PUSH_PROMISE frame and chooses to accept the 2228 pushed resource, the client SHOULD NOT issue any requests for the 2229 promised resource until after the promised stream has closed. 2231 If the client determines, for any reason, that it does not wish to 2232 receive the pushed resource from the server, or if the server takes 2233 too long to begin sending the promised resource, the client can send 2234 an RST_STREAM frame, using either the CANCEL or REFUSED_STREAM codes, 2235 and referencing the pushed stream's identifier. 2237 A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit 2238 the number of resources that can be concurrently pushed by a server. 2239 Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables 2240 server push by preventing the server from creating the necessary 2241 streams. This does not prohibit a server from sending PUSH_PROMISE 2242 frames; clients need to reset any promised streams that are not 2243 wanted. 2245 Clients receiving a pushed response MUST validate that the server is 2246 authorized to push the resource using the same-origin policy 2247 ([RFC6454], Section 3). For example, a HTTP/2.0 connection to 2248 "example.com" is generally [[anchor16: Ed: weaselly use of 2249 "generally", needs better definition]] not permitted to push a 2250 response for "www.example.org". 2252 8.3. The CONNECT Method 2254 The HTTP pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is used to 2255 convert an HTTP/1.1 connection into a tunnel to a remote host. 2256 CONNECT is primarily used with HTTP proxies to established a TLS 2257 session with a server for the purposes of interacting with "https" 2258 resources. 2260 In HTTP/2.0, the CONNECT method is used to establish a tunnel over a 2261 single HTTP/2.0 stream to a remote host. The HTTP header field 2262 mapping works as mostly as defined in Request Header Fields 2263 (Section 8.1.3.1), with a few differences. Specifically: 2265 o The ":method" header field is set to "CONNECT". 2267 o The ":scheme" and ":path" header fields MUST be omitted. 2269 o The ":authority" header field contains the host and port to 2270 connect to (equivalent to the authority-form of the request-target 2271 of CONNECT requests, see [HTTP-p1], Section 5.3). 2273 A proxy that supports CONNECT, establishes a TCP connection [TCP] to 2274 the server identified in the ":path" header field. Once this 2275 connection is successfully established, the proxy sends a HEADERS 2276 frame containing a 2xx series status code, as defined in [HTTP-p2], 2277 Section 4.3.6. 2279 After the initial HEADERS frame sent by each peer, all subsequent 2280 DATA frames correspond to data sent on the TCP connection. The 2281 payload of any DATA frames sent by the client are transmitted by the 2282 proxy to the TCP server; data received from the TCP server is 2283 assembled into DATA frames by the proxy. Frame types other than DATA 2284 or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY) 2285 MUST NOT be sent on a connected stream, and MUST be treated as a 2286 stream error (Section 5.4.2) if received. 2288 The TCP connection can be closed by either peer. The END_STREAM flag 2289 on a DATA frame is treated as being equivalent to the TCP FIN bit. A 2290 client is expected to send a DATA frame with the END_STREAM flag set 2291 after receiving a frame bearing the END_STREAM flag. A proxy that 2292 receives a DATA frame with the END_STREAM flag set sends the attached 2293 data with the FIN bit set on the last TCP segment. A proxy that 2294 receives a TCP segment with the FIN bit set sends a DATA frame with 2295 the END_STREAM flag set. Note that the final TCP segment or DATA 2296 frame could be empty. 2298 A TCP connection error is signaled with RST_STREAM. A proxy treats 2299 any error in the TCP connection, which includes receiving a TCP 2300 segment with the RST bit set, as a stream error (Section 5.4.2) of 2301 type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment 2302 with the RST bit set if it detects an error with the stream or the 2303 HTTP/2.0 connection. 2305 9. Additional HTTP Requirements/Considerations 2307 This section outlines attributes of the HTTP protocol that improve 2308 interoperability, reduce exposure to known security vulnerabilities, 2309 or reduce the potential for implementation variation. 2311 9.1. Connection Management 2313 HTTP/2.0 connections are persistent. For best performance, it is 2314 expected clients will not close connections until it is determined 2315 that no further communication with a server is necessary (for 2316 example, when a user navigates away from a particular web page), or 2317 until the server closes the connection. 2319 Clients SHOULD NOT open more than one HTTP/2.0 connection to a given 2320 origin ([RFC6454]) concurrently. A client can create additional 2321 connections as replacements, either to replace connections that are 2322 near to exhausting the available stream identifiers (Section 5.1.1), 2323 or to replace connections that have encountered errors 2324 (Section 5.4.1). 2326 Servers are encouraged to maintain open connections for as long as 2327 possible, but are permitted to terminate idle connections if 2328 necessary. When either endpoint chooses to close the transport-level 2329 TCP connection, the terminating endpoint SHOULD first send a GOAWAY 2330 (Section 6.8) frame so that both endpoints can reliably determine 2331 whether previously sent frames have been processed and gracefully 2332 complete or terminate any necessary remaining tasks. 2334 9.2. Use of TLS Features 2336 Implementations of HTTP/2.0 MUST support TLS 1.1 [TLS11]. [[anchor19: 2337 The working group intends to require at least the use of TLS 1.2 2338 [TLS12] prior to publication of this document; negotiating TLS 1.1 is 2339 permitted to enable the creation of interoperable implementations of 2340 early drafts.]] 2342 The TLS implementation MUST support the Server Name Indication (SNI) 2343 [TLS-EXT] extension to TLS. HTTP/2.0 clients MUST indicate the 2344 target domain name when negotiating TLS. 2346 A server that receives a TLS handshake that does not include either 2347 TLS 1.1 or SNI, MUST NOT negotiate HTTP/2.0. Removing HTTP/2.0 2348 protocols from consideration could result in the removal of all 2349 protocols from the set of protocols offered by the client. This 2350 causes protocol negotiation failure, as described in Section 3.2 of 2351 [TLSALPN]. 2353 Implementations are encouraged not to negotiate TLS cipher suites 2354 with known vulnerabilities, such as [RC4]. 2356 9.3. GZip Content-Encoding 2358 Clients MUST support gzip compression for HTTP response bodies. 2359 Regardless of the value of the accept-encoding header field, a server 2360 MAY send responses with gzip or deflate encoding. A compressed 2361 response MUST still bear an appropriate content-encoding header 2362 field. 2364 10. Security Considerations 2366 10.1. Server Authority and Same-Origin 2368 This specification uses the same-origin policy ([RFC6454], Section 3) 2369 to determine whether an origin server is permitted to provide 2370 content. 2372 A server that is contacted using TLS is authenticated based on the 2373 certificate that it offers in the TLS handshake (see [RFC2818], 2374 Section 3). A server is considered authoritative for an "https" 2375 resource if it has been successfully authenticated for the domain 2376 part of the origin of the resource that it is providing. 2378 A server is considered authoritative for an "http" resource if the 2379 connection is established to a resolved IP address for the domain in 2380 the origin of the resource. 2382 A client MUST NOT use, in any way, resources provided by a server 2383 that is not authoritative for those resources. 2385 10.2. Cross-Protocol Attacks 2387 When using TLS, we believe that HTTP/2.0 introduces no new cross- 2388 protocol attacks. TLS encrypts the contents of all transmission 2389 (except the handshake itself), making it difficult for attackers to 2390 control the data which could be used in a cross-protocol attack. 2391 [[anchor22: Issue: This is no longer true]] 2393 10.3. Intermediary Encapsulation Attacks 2395 HTTP/2.0 header field names and values are encoded as sequences of 2396 octets with a length prefix. This enables HTTP/2.0 to carry any 2397 string of octets as the name or value of a header field. An 2398 intermediary that translates HTTP/2.0 requests or responses into 2399 HTTP/1.1 directly could permit the creation of corrupted HTTP/1.1 2400 messages. An attacker might exploit this behavior to cause the 2401 intermediary to create HTTP/1.1 messages with illegal header fields, 2402 extra header fields, or even new messages that are entirely 2403 falsified. 2405 An intermediary that performs translation into HTTP/1.1 cannot alter 2406 the semantics of requests or responses. In particular, header field 2407 names or values that contain characters not permitted by HTTP/1.1, 2408 including carriage return (U+000D) or line feed (U+000A) MUST NOT be 2409 translated verbatim, as stipulated in [HTTP-p1], Section 3.2.4. 2411 Translation from HTTP/1.x to HTTP/2.0 does not produce the same 2412 opportunity to an attacker. Intermediaries that perform translation 2413 to HTTP/2.0 MUST remove any instances of the "obs-fold" production 2414 from header field values. 2416 10.4. Cacheability of Pushed Resources 2418 Pushed resources are responses without an explicit request; the 2419 request for a pushed resource is synthesized from the request that 2420 triggered the push, plus resource identification information provided 2421 by the server. Request header fields are necessary for HTTP cache 2422 control validations (such as the Vary header field) to work. For 2423 this reason, caches MUST inherit request header fields from the 2424 associated stream for the push. This includes the Cookie header 2425 field. 2427 Caching resources that are pushed is possible, based on the guidance 2428 provided by the origin server in the Cache-Control header field. 2429 However, this can cause issues if a single server hosts more than one 2430 tenant. For example, a server might offer multiple users each a 2431 small portion of its URI space. 2433 Where multiple tenants share space on the same server, that server 2434 MUST ensure that tenants are not able to push representations of 2435 resources that they do not have authority over. Failure to enforce 2436 this would allow a tenant to provide a representation that would be 2437 served out of cache, overriding the actual representation that the 2438 authoritative tenant provides. 2440 Pushed resources for which an origin server is not authoritative are 2441 never cached or used. 2443 10.5. Denial of Service Considerations 2445 An HTTP/2.0 connection can demand a greater commitment of resources 2446 to operate than a HTTP/1.1 connection. The use of header compression 2447 and flow control require that an implementation commit resources for 2448 storing a greater amount of state. Settings for these features 2449 ensure that memory commitments for these features are strictly 2450 bounded. Processing capacity cannot be guarded in the same fashion. 2452 The SETTINGS frame can be abused to cause a peer to expend additional 2453 processing time. This might be done by pointlessly changing 2454 settings, setting multiple undefined settings, or changing the same 2455 setting multiple times in the same frame. Similarly, WINDOW_UPDATE 2456 or PRIORITY frames can be abused to cause an unnecessary waste of 2457 resources. 2459 Large numbers of small or empty frames can be abused to cause a peer 2460 to expend time processing frame headers. Note however that some uses 2461 are entirely legitimate, such as the sending of an empty DATA frame 2462 to end a stream. 2464 Header compression also offers some opportunities to waste processing 2465 resources, see [COMPRESSION] for more details on potential abuses. 2467 In all these cases, there are legitimate reasons to use these 2468 protocol mechanisms. These features become a burden only when they 2469 are used unnecessarily or to excess. 2471 An endpoint that doesn't monitor this behavior exposes itself to a 2472 risk of denial of service attack. Implementations SHOULD track the 2473 use of these types of frames and set limits on their use. An 2474 endpoint MAY treat activity that is suspicious as a connection error 2475 (Section 5.4.1) of type ENHANCE_YOUR_CALM. 2477 11. Privacy Considerations 2479 HTTP/2.0 aims to keep connections open longer between clients and 2480 servers in order to reduce the latency when a user makes a request. 2481 The maintenance of these connections over time could be used to 2482 expose private information. For example, a user using a browser 2483 hours after the previous user stopped using that browser may be able 2484 to learn about what the previous user was doing. This is a problem 2485 with HTTP in its current form as well, however the short lived 2486 connections make it less of a risk. 2488 12. IANA Considerations 2490 A string for identifying HTTP/2.0 is entered into the "Application 2491 Layer Protocol Negotiation (ALPN) Protocol IDs" registry established 2492 in [TLSALPN]. 2494 This document establishes registries for frame types, error codes and 2495 settings. These new registries are entered in a new "Hypertext 2496 Transfer Protocol (HTTP) 2.0 Parameters" section. 2498 This document registers the "HTTP2-Settings" header field for use in 2499 HTTP. 2501 12.1. Registration of HTTP/2.0 Identification String 2503 This document creates a registration for the identification of 2504 HTTP/2.0 in the "Application Layer Protocol Negotiation (ALPN) 2505 Protocol IDs" registry established in [TLSALPN]. 2507 Protocol: HTTP/2.0 2509 Identification Sequence: 0x48 0x54 0x54 0x50 0x2f 0x32 0x2e 0x30 2510 ("HTTP/2.0") 2512 Specification: This document (RFCXXXX) 2514 12.2. Frame Type Registry 2516 This document establishes a registry for HTTP/2.0 frame types. The 2517 "HTTP/2.0 Frame Type" registry operates under the "IETF Review" 2518 policy [RFC5226]. 2520 Frame types are an 8-bit value. When reviewing new frame type 2521 registrations, special attention is advised for any frame type- 2522 specific flags that are defined. Frame flags can interact with 2523 existing flags and could prevent the creation of globally applicable 2524 flags. 2526 Initial values for the "HTTP/2.0 Frame Type" registry are shown in 2527 Table 1. 2529 +--------+---------------+---------------------------+--------------+ 2530 | Frame | Name | Flags | Section | 2531 | Type | | | | 2532 +--------+---------------+---------------------------+--------------+ 2533 | 0 | DATA | END_STREAM(1) | Section 6.1 | 2534 | 1 | HEADERS | END_STREAM(1), | Section 6.2 | 2535 | | | END_HEADERS(4), | | 2536 | | | PRIORITY(8) | | 2537 | 2 | PRIORITY | - | Section 6.3 | 2538 | 3 | RST_STREAM | - | Section 6.4 | 2539 | 4 | SETTINGS | ACK(1) | Section 6.5 | 2540 | 5 | PUSH_PROMISE | END_PUSH_PROMISE(4) | Section 6.6 | 2541 | 6 | PING | ACK(1) | Section 6.7 | 2542 | 7 | GOAWAY | - | Section 6.8 | 2543 | 9 | WINDOW_UPDATE | - | Section 6.9 | 2544 | 10 | CONTINUATION | END_HEADERS(4) | Section 6.10 | 2545 +--------+---------------+---------------------------+--------------+ 2547 Table 1 2549 12.3. Error Code Registry 2551 This document establishes a registry for HTTP/2.0 error codes. The 2552 "HTTP/2.0 Error Code" registry manages a 32-bit space. The "HTTP/2.0 2553 Error Code" registry operates under the "Expert Review" policy 2554 [RFC5226]. 2556 Registrations for error codes are required to include a description 2557 of the error code. An expert reviewer is advised to examine new 2558 registrations for possible duplication with existing error codes. 2559 Use of existing registrations is to be encouraged, but not mandated. 2561 New registrations are advised to provide the following information: 2563 Error Code: The 32-bit error code value. 2565 Name: A name for the error code. Specifying an error code name is 2566 optional. 2568 Description: A description of the conditions where the error code is 2569 applicable. 2571 Specification: An optional reference for a specification that 2572 defines the error code. 2574 An initial set of error code registrations can be found in Section 7. 2576 12.4. Settings Registry 2578 This document establishes a registry for HTTP/2.0 settings. The 2579 "HTTP/2.0 Settings" registry manages a 24-bit space. The "HTTP/2.0 2580 Settings" registry operates under the "Expert Review" policy 2581 [RFC5226]. 2583 Registrations for settings are required to include a description of 2584 the setting. An expert reviewer is advised to examine new 2585 registrations for possible duplication with existing settings. Use 2586 of existing registrations is to be encouraged, but not mandated. 2588 New registrations are advised to provide the following information: 2590 Setting: The 24-bit setting value. 2592 Name: A name for the setting. Specifying a name is optional. 2594 Flags: Any setting-specific flags that apply, including their value 2595 and semantics. 2597 Description: A description of the setting. This might include the 2598 range of values, any applicable units and how to act upon a value 2599 when it is provided. 2601 Specification: An optional reference for a specification that 2602 defines the setting. 2604 An initial set of settings registrations can be found in 2605 Section 6.5.2. 2607 12.5. HTTP2-Settings Header Field Registration 2609 This section registers the "HTTP2-Settings" header field in the 2610 Permanent Message Header Field Registry [BCP90]. 2612 Header field name: HTTP2-Settings 2614 Applicable protocol: http 2616 Status: standard 2618 Author/Change controller: IETF 2620 Specification document(s): Section 3.2.1 of this document 2622 Related information: This header field is only used by an HTTP/2.0 2623 client for Upgrade-based negotiation. 2625 13. Acknowledgements 2627 This document includes substantial input from the following 2628 individuals: 2630 o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa 2631 Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam 2632 Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, 2633 Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors). 2635 o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism) 2637 o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, 2638 Jitu Padhye, Roberto Peon, Rob Trace (Flow control) 2640 o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike 2641 Bishop (Substantial editorial contributions) 2643 14. References 2645 14.1. Normative References 2647 [COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression 2648 for HTTP/2.0", 2649 draft-ietf-httpbis-header-compression-04 (work in 2650 progress), October 2013. 2652 [HTTP-p1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 2653 Transfer Protocol (HTTP/1.1): Message Syntax and 2654 Routing", draft-ietf-httpbis-p1-messaging-24 (work in 2655 progress), September 2013. 2657 [HTTP-p2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 2658 Transfer Protocol (HTTP/1.1): Semantics and Content", 2659 draft-ietf-httpbis-p2-semantics-24 (work in progress), 2660 September 2013. 2662 [HTTP-p4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 2663 Transfer Protocol (HTTP/1.1): Conditional Requests", 2664 draft-ietf-httpbis-p4-conditional-24 (work in 2665 progress), September 2013. 2667 [HTTP-p5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, 2668 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range 2669 Requests", draft-ietf-httpbis-p5-range-24 (work in 2670 progress), September 2013. 2672 [HTTP-p6] Fielding, R., Ed., Nottingham, M., Ed., and J. 2673 Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): 2674 Caching", draft-ietf-httpbis-p6-cache-24 (work in 2675 progress), September 2013. 2677 [HTTP-p7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 2678 Transfer Protocol (HTTP/1.1): Authentication", 2679 draft-ietf-httpbis-p7-auth-24 (work in progress), 2680 September 2013. 2682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2683 Requirement Levels", BCP 14, RFC 2119, March 1997. 2685 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2687 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 2688 "Uniform Resource Identifier (URI): Generic Syntax", 2689 STD 66, RFC 3986, January 2005. 2691 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2692 Encodings", RFC 4648, October 2006. 2694 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2695 an IANA Considerations Section in RFCs", BCP 26, 2696 RFC 5226, May 2008. 2698 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2699 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2701 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2702 December 2011. 2704 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 2705 RFC 793, September 1981. 2707 [TLS-EXT] Eastlake, D., "Transport Layer Security (TLS) 2708 Extensions: Extension Definitions", RFC 6066, 2709 January 2011. 2711 [TLS11] Dierks, T. and E. Rescorla, "The Transport Layer 2712 Security (TLS) Protocol Version 1.1", RFC 4346, 2713 April 2006. 2715 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer 2716 Security (TLS) Protocol Version 1.2", RFC 5246, 2717 August 2008. 2719 [TLSALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2720 "Transport Layer Security (TLS) Application Layer 2721 Protocol Negotiation Extension", 2722 draft-ietf-tls-applayerprotoneg-02 (work in progress), 2723 September 2013. 2725 14.2. Informative References 2727 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2728 Procedures for Message Header Fields", BCP 90, 2729 RFC 3864, September 2004. 2731 [RC4] Rivest, R., "The RC4 encryption algorithm", RSA Data 2732 Security, Inc. , March 1992. 2734 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP 2735 Extensions for High Performance", RFC 1323, May 1992. 2737 [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. 2738 Jackson, "Talking to Yourself for Fun and Profit", 2739 2011, . 2741 Appendix A. Change Log (to be removed by RFC Editor before publication) 2743 A.1. Since draft-ietf-httpbis-http2-06 2745 Adding definition for CONNECT method. 2747 Constraining the use of push to safe, cacheable methods with no 2748 request body. 2750 Changing from :host to :authority to remove any potential confusion. 2752 Adding setting for header compression table size. 2754 Adding settings acknowledgement. 2756 Removing unnecessary and potentially problematic flags from 2757 CONTINUATION. 2759 Added denial of service considerations. 2761 A.2. Since draft-ietf-httpbis-http2-05 2763 Marking the draft ready for implementation. 2765 Renumbering END_PUSH_PROMISE flag. 2767 Editorial clarifications and changes. 2769 A.3. Since draft-ietf-httpbis-http2-04 2771 Added CONTINUATION frame for HEADERS and PUSH_PROMISE. 2773 PUSH_PROMISE is no longer implicitly prohibited if 2774 SETTINGS_MAX_CONCURRENT_STREAMS is zero. 2776 Push expanded to allow all safe methods without a request body. 2778 Clarified the use of HTTP header fields in requests and responses. 2779 Prohibited HTTP/1.1 hop-by-hop header fields. 2781 Requiring that intermediaries not forward requests with missing or 2782 illegal routing :-headers. 2784 Clarified requirements around handling different frames after stream 2785 close, stream reset and GOAWAY. 2787 Added more specific prohibitions for sending of different frame types 2788 in various stream states. 2790 Making the last received setting value the effective value. 2792 Clarified requirements on TLS version, extension and ciphers. 2794 A.4. Since draft-ietf-httpbis-http2-03 2796 Committed major restructuring atrocities. 2798 Added reference to first header compression draft. 2800 Added more formal description of frame lifecycle. 2802 Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA. 2804 Removed HEADERS+PRIORITY, added optional priority to HEADERS frame. 2806 Added PRIORITY frame. 2808 A.5. Since draft-ietf-httpbis-http2-02 2810 Added continuations to frames carrying header blocks. 2812 Replaced use of "session" with "connection" to avoid confusion with 2813 other HTTP stateful concepts, like cookies. 2815 Removed "message". 2817 Switched to TLS ALPN from NPN. 2819 Editorial changes. 2821 A.6. Since draft-ietf-httpbis-http2-01 2823 Added IANA considerations section for frame types, error codes and 2824 settings. 2826 Removed data frame compression. 2828 Added PUSH_PROMISE. 2830 Added globally applicable flags to framing. 2832 Removed zlib-based header compression mechanism. 2834 Updated references. 2836 Clarified stream identifier reuse. 2838 Removed CREDENTIALS frame and associated mechanisms. 2840 Added advice against naive implementation of flow control. 2842 Added session header section. 2844 Restructured frame header. Removed distinction between data and 2845 control frames. 2847 Altered flow control properties to include session-level limits. 2849 Added note on cacheability of pushed resources and multiple tenant 2850 servers. 2852 Changed protocol label form based on discussions. 2854 A.7. Since draft-ietf-httpbis-http2-00 2856 Changed title throughout. 2858 Removed section on Incompatibilities with SPDY draft#2. 2860 Changed INTERNAL_ERROR on GOAWAY to have a value of 2 . 2863 Replaced abstract and introduction. 2865 Added section on starting HTTP/2.0, including upgrade mechanism. 2867 Removed unused references. 2869 Added flow control principles (Section 5.2.1) based on . 2872 A.8. Since draft-mbelshe-httpbis-spdy-00 2874 Adopted as base for draft-ietf-httpbis-http2. 2876 Updated authors/editors list. 2878 Added status note. 2880 Authors' Addresses 2882 Mike Belshe 2883 Twist 2885 EMail: mbelshe@chromium.org 2887 Roberto Peon 2888 Google, Inc 2890 EMail: fenix@google.com 2892 Martin Thomson (editor) 2893 Microsoft 2894 3210 Porter Drive 2895 Palo Alto 94304 2896 US 2898 EMail: martin.thomson@skype.net 2900 Alexey Melnikov (editor) 2901 Isode Ltd 2902 5 Castle Business Village 2903 36 Station Road 2904 Hampton, Middlesex TW12 2BX 2905 UK 2907 EMail: Alexey.Melnikov@isode.com