idnits 2.17.1 draft-ietf-httpbis-http2-04.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 (July 8, 2013) is 3943 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-00 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-22 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-ietf-tls-applayerprotoneg-01 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 4 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: January 9, 2014 Google, Inc 6 M. Thomson, Ed. 7 Microsoft 8 A. Melnikov, Ed. 9 Isode Ltd 10 July 8, 2013 12 Hypertext Transfer Protocol version 2.0 13 draft-ietf-httpbis-http2-04 15 Abstract 17 This specification describes an optimized expression of the syntax of 18 the Hypertext Transfer Protocol (HTTP). The HTTP/2.0 encapsulation 19 enables more efficient use of network resources and reduced 20 perception of latency by allowing header field compression and 21 multiple concurrent messages on the same connection. It also 22 introduces unsolicited push of representations from servers to 23 clients. 25 This document is an alternative to, but does not obsolete the 26 HTTP/1.1 message format or protocol. HTTP's existing semantics 27 remain unchanged. 29 This version of the draft has been marked for implementation. 30 Interoperability testing will occur in the HTTP/2.0 interim in 31 Hamburg, DE, starting 2013-08-05. 33 Editorial Note (To be removed by RFC Editor) 35 Discussion of this draft takes place on the HTTPBIS working group 36 mailing list (ietf-http-wg@w3.org), which is archived at 37 . 39 Working Group information and related documents can be found at 40 (Wiki) and 41 (source code and issues 42 tracker). 44 The changes in this draft are summarized in Appendix A.1. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on January 9, 2014. 63 Copyright Notice 65 Copyright (c) 2013 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 1.1. Document Organization . . . . . . . . . . . . . . . . . . 5 82 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 83 2. HTTP/2.0 Protocol Overview . . . . . . . . . . . . . . . . . . 6 84 2.1. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . 7 85 2.2. HTTP Multiplexing . . . . . . . . . . . . . . . . . . . . 7 86 2.3. HTTP Semantics . . . . . . . . . . . . . . . . . . . . . . 7 87 3. Starting HTTP/2.0 . . . . . . . . . . . . . . . . . . . . . . 7 88 3.1. HTTP/2.0 Version Identification . . . . . . . . . . . . . 8 89 3.2. Starting HTTP/2.0 for "http" URIs . . . . . . . . . . . . 8 90 3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10 91 3.3. Starting HTTP/2.0 for "https" URIs . . . . . . . . . . . . 10 92 3.4. Starting HTTP/2.0 with Prior Knowledge . . . . . . . . . . 10 93 3.5. Connection Header . . . . . . . . . . . . . . . . . . . . 11 94 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 4.1. Frame Header . . . . . . . . . . . . . . . . . . . . . . . 12 96 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 13 97 4.3. Header Compression and Decompression . . . . . . . . . . . 13 98 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14 99 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14 100 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 18 101 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 18 102 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 18 103 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 19 104 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 20 105 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 20 106 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 21 107 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 21 108 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 22 109 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 22 110 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 22 111 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 112 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 23 113 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 24 114 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 25 115 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 26 116 6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 26 117 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 27 118 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 27 119 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 120 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 29 121 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 31 122 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 32 123 6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 33 124 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 34 125 6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 34 126 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 35 127 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 36 128 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 36 129 8.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 37 130 8.1.2. Request Header Fields . . . . . . . . . . . . . . . . 38 131 8.1.3. Response Header Fields . . . . . . . . . . . . . . . . 39 132 8.1.4. GZip Content-Encoding . . . . . . . . . . . . . . . . 40 133 8.1.5. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 40 134 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 41 135 9. Additional HTTP Requirements/Considerations . . . . . . . . . 43 136 9.1. Frame Size Limits for HTTP . . . . . . . . . . . . . . . . 43 137 9.2. Connection Management . . . . . . . . . . . . . . . . . . 43 138 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 139 10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 43 140 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 44 141 10.3. Cacheability of Pushed Resources . . . . . . . . . . . . . 44 142 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 45 143 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 144 12.1. Frame Type Registry . . . . . . . . . . . . . . . . . . . 45 145 12.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 46 146 12.3. Settings Registry . . . . . . . . . . . . . . . . . . . . 47 147 12.4. HTTP2-Settings Header Field Registration . . . . . . . . . 47 148 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 149 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 150 14.1. Normative References . . . . . . . . . . . . . . . . . . . 48 151 14.2. Informative References . . . . . . . . . . . . . . . . . . 50 152 Appendix A. Change Log (to be removed by RFC Editor before 153 publication) . . . . . . . . . . . . . . . . . . . . 50 154 A.1. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 50 155 A.2. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 50 156 A.3. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 50 157 A.4. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 51 158 A.5. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 51 160 1. Introduction 162 The Hypertext Transfer Protocol (HTTP) is a wildly successful 163 protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section 164 3) is optimized for implementation simplicity and accessibility, not 165 application performance. As such it has several characteristics that 166 have a negative overall effect on application performance. 168 In particular, HTTP/1.0 only allows one request to be delivered at a 169 time on a given connection. HTTP/1.1 pipelining only partially 170 addressed request concurrency, and is not widely deployed. 171 Therefore, clients that need to make many requests (as is common on 172 the Web) typically use multiple connections to a server in order to 173 reduce perceived latency. 175 Furthermore, HTTP/1.1 header fields are often repetitive and verbose, 176 which, in addition to generating more or larger network packets, can 177 cause the small initial TCP congestion window to quickly fill. This 178 can result in excessive latency when multiple requests are made on a 179 single new TCP connection. 181 This document addresses these issues by defining an optimized mapping 182 of HTTP's semantics to an underlying connection. Specifically, it 183 allows interleaving of request and response messages on the same 184 connection and uses an efficient coding for HTTP header fields. It 185 also allows prioritization of requests, letting more important 186 requests complete more quickly, further improving perceived 187 performance. 189 The resulting protocol is designed to have be more friendly to the 190 network, because fewer TCP connections can be used, in comparison to 191 HTTP/1.x. This means less competition with other flows, and longer- 192 lived connections, which in turn leads to better utilization of 193 available network capacity. 195 Finally, this encapsulation also enables more scalable processing of 196 messages through use of binary message framing. 198 1.1. Document Organization 200 The HTTP/2.0 Specification is split into three parts: starting 201 HTTP/2.0 (Section 3), which covers how a HTTP/2.0 connection is 202 initiated; a framing layer (Section 4), which multiplexes a single 203 TCP connection into independent frames of various types; and an HTTP 204 layer (Section 8), which specifies the mechanism for expressing HTTP 205 interactions using the framing layer. While some of the framing 206 layer concepts are isolated from HTTP, building a generic framing 207 layer has not been a goal. The framing layer is tailored to the 208 needs of the HTTP protocol and server push. 210 1.2. Conventions and Terminology 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC 2119 [RFC2119]. 216 All numeric values are in network byte order. Values are unsigned 217 unless otherwise indicated. Literal values are provided in decimal 218 or hexadecimal as appropriate. Hexadecimal literals are prefixed 219 with "0x" to distinguish them from decimal literals. 221 The following terms are used: 223 client: The endpoint initiating the HTTP connection. 225 connection: A transport-level connection between two endpoints. 227 endpoint: Either the client or server of the connection. 229 frame: The smallest unit of communication within an HTTP/2.0 230 connection, consisting of a header and a variable-length sequence 231 of bytes structured according to the frame type. 233 peer: An endpoint. When discussing a particular endpoint, "peer" 234 refers to the endpoint that is remote to the primary subject of 235 discussion. 237 receiver: An endpoint that is receiving frames. 239 sender: An endpoint that is transmitting frames. 241 server: The endpoint which did not initiate the HTTP connection. 243 connection error: An error on the HTTP/2.0 connection. 245 stream: A bi-directional flow of frames across a virtual channel 246 within the HTTP/2.0 connection. 248 stream error: An error on the individual HTTP/2.0 stream. 250 2. HTTP/2.0 Protocol Overview 252 HTTP/2.0 provides an optimized transport for HTTP semantics. 254 An HTTP/2.0 connection is an application level protocol running on 255 top of a TCP connection ([RFC0793]). The client is the TCP 256 connection initiator. 258 This document describes the HTTP/2.0 protocol using a logical 259 structure that is formed of three parts: framing, streams, and 260 application mapping. This structure is provided primarily as an aid 261 to specification, implementations are free to diverge from this 262 structure as necessary. 264 2.1. HTTP Frames 266 HTTP/2.0 provides an efficient serialization of HTTP semantics. HTTP 267 requests and responses are encoded into length-prefixed frames (see 268 Section 4.1). 270 HTTP headers are compressed into a series of frames that contain 271 header block fragments (see Section 4.3). 273 2.2. HTTP Multiplexing 275 HTTP/2.0 provides the ability to multiplex multiple HTTP requests and 276 responses onto a single connection. Multiple requests or responses 277 can be sent concurrently on a connection using streams (Section 5). 278 In order to maintain independent streams, flow control and 279 prioritization are necessary. 281 2.3. HTTP Semantics 283 HTTP/2.0 defines how HTTP requests and responses are mapped to 284 streams (see Section 8) and introduces a new interaction model, 285 server push (Section 8.2). 287 3. Starting HTTP/2.0 289 HTTP/2.0 uses the same "http" and "https" URI schemes used by 290 HTTP/1.1. HTTP/2.0 shares the same default port numbers: 80 for 291 "http" URIs and 443 for "https" URIs. As a result, implementations 292 processing requests for target resource URIs like 293 "http://example.org/foo" or "https://example.com/bar" are required to 294 first discover whether the upstream server (the immediate peer to 295 which the client wishes to establish a connection) supports HTTP/2.0. 297 The means by which support for HTTP/2.0 is determined is different 298 for "http" and "https" URIs. Discovery for "http" URIs is described 299 in Section 3.2. Discovery for "https" URIs is described in 300 Section 3.3. 302 3.1. HTTP/2.0 Version Identification 304 The protocol defined in this document is identified using the string 305 "HTTP/2.0". This identification is used in the HTTP/1.1 Upgrade 306 header field, in the TLS application layer protocol negotiation 307 extension [TLSALPN] field, and other places where protocol 308 identification is required. 310 Negotiating "HTTP/2.0" implies the use of the transport, security, 311 framing and message semantics described in this document. 313 [[anchor6: Editor's Note: please remove the following text prior to 314 the publication of a final version of this document.]] 316 Only implementations of the final, published RFC can identify 317 themselves as "HTTP/2.0". Until such an RFC exists, implementations 318 MUST NOT identify themselves using "HTTP/2.0". 320 Examples and text throughout the rest of this document use "HTTP/2.0" 321 as a matter of editorial convenience only. Implementations of draft 322 versions MUST NOT identify using this string. 324 Implementations of draft versions of the protocol MUST add the string 325 "-draft-" and the corresponding draft number to the identifier before 326 the separator ('/'). For example, draft-ietf-httpbis-http2-03 is 327 identified using the string "HTTP-draft-03/2.0". 329 Non-compatible experiments that are based on these draft versions 330 MUST instead replace the string "draft" with a different identifier. 331 For example, an experimental implementation of packet mood-based 332 encoding based on draft-ietf-httpbis-http2-07 might identify itself 333 as "HTTP-emo-07/2.0". Note that any label MUST conform to the 334 "token" syntax defined in Section 3.2.6 of [HTTP-p1]. Experimenters 335 are encouraged to coordinate their experiments on the 336 ietf-http-wg@w3.org mailing list. 338 3.2. Starting HTTP/2.0 for "http" URIs 340 A client that makes a request to an "http" URI without prior 341 knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism 342 (Section 6.7 of [HTTP-p1]). The client makes an HTTP/1.1 request 343 that includes an Upgrade header field identifying HTTP/2.0. The 344 HTTP/1.1 request MUST include an HTTP2-Settings (Section 3.2.1) 345 header field. 347 For example: 349 GET /default.htm HTTP/1.1 350 Host: server.example.com 351 Connection: Upgrade, HTTP2-Settings 352 Upgrade: HTTP/2.0 353 HTTP2-Settings: 355 Requests that contain a request entity body MUST be sent in their 356 entirety before the client can send HTTP/2.0 frames. This means that 357 a large request entity can block the use of the connection until it 358 is completely sent. 360 If concurrency of an initial request with subsequent requests is 361 important, a small request can be used to perform the upgrade to 362 HTTP/2.0, at the cost of an additional round trip. 364 A server that does not support HTTP/2.0 can respond to the request as 365 though the Upgrade header field were absent: 367 HTTP/1.1 200 OK 368 Content-length: 243 369 Content-type: text/html 371 ... 373 A server that supports HTTP/2.0 accepts the upgrade with a 101 374 (Switching Protocols) status code. After the empty line that 375 terminates the 101 response, the server can begin sending HTTP/2.0 376 frames. These frames MUST include a response to the request that 377 initiated the Upgrade. 379 HTTP/1.1 101 Switching Protocols 380 Connection: Upgrade 381 Upgrade: HTTP/2.0 383 [ HTTP/2.0 connection ... 385 The first HTTP/2.0 frame sent by the server is a SETTINGS frame 386 (Section 6.5). Upon receiving the 101 response, the client sends a 387 connection header (Section 3.5), which includes a SETTINGS frame. 389 The HTTP/1.1 request that is sent prior to upgrade is associated with 390 stream 1 and is assigned the highest possible priority. Stream 1 is 391 implicitly half closed from the client toward the server, since the 392 request is completed as an HTTP/1.1 request. After commencing the 393 HTTP/2.0 connection, stream 1 is used for the response. 395 3.2.1. HTTP2-Settings Header Field 397 A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include an 398 "HTTP2-Settings" header field. The "HTTP2-Settings" header field is 399 a hop-by-hop header field that includes settings that govern the 400 HTTP/2.0 connection, provided in anticipation of the server accepting 401 the request to upgrade. A server MUST reject an attempt to upgrade 402 if this header is not present. 404 HTTP2-Settings = token68 406 The content of the "HTTP2-Settings" header field is the payload of a 407 SETTINGS frame (Section 6.5), encoded as a base64url string (that is, 408 the URL- and filename-safe Base64 encoding described in Section 5 of 409 [RFC4648], with any trailing '=' characters omitted). The ABNF 410 [RFC5234] production for "token68" is defined in Section 2.1 of 411 [HTTP-p7]. 413 The client MUST include values for the following settings 414 (Section 6.5.1): 416 o SETTINGS_MAX_CONCURRENT_STREAMS 418 o SETTINGS_INITIAL_WINDOW_SIZE 420 As a hop-by-hop header field, the "Connection" header field MUST 421 include a value of "HTTP2-Settings" in addition to "Upgrade" when 422 upgrading to HTTP/2.0. 424 A server decodes and interprets these values as it would any other 425 SETTINGS frame. Providing these values in the Upgrade request 426 ensures that the protocol does not require default values for the 427 above settings, and gives a client an opportunity to provide other 428 settings prior to receiving any frames from the server. 430 3.3. Starting HTTP/2.0 for "https" URIs 432 A client that makes a request to an "https" URI without prior 433 knowledge about support for HTTP/2.0 uses TLS [RFC5246] with the 434 application layer protocol negotiation extension [TLSALPN]. 436 Once TLS negotiation is complete, both the client and the server send 437 a connection header (Section 3.5). 439 3.4. Starting HTTP/2.0 with Prior Knowledge 441 A client can learn that a particular server supports HTTP/2.0 by 442 other means. A client MAY immediately send HTTP/2.0 frames to a 443 server that is known to support HTTP/2.0, after the connection header 444 (Section 3.5). This only affects the resolution of "http" URIs; 445 servers supporting HTTP/2.0 are required to support protocol 446 negotiation in TLS [TLSALPN] for "https" URIs. 448 Prior support for HTTP/2.0 is not a strong signal that a given server 449 will support HTTP/2.0 for future connections. It is possible for 450 server configurations to change or for configurations to differ 451 between instances in clustered server. Interception proxies (a.k.a. 452 "transparent" proxies) are another source of variability. 454 3.5. Connection Header 456 Upon establishment of a TCP connection and determination that 457 HTTP/2.0 will be used by both peers, each endpoint MUST send a 458 connection header as a final confirmation and to establish the 459 initial settings for the HTTP/2.0 connection. 461 The client connection header is a sequence of 24 octets, which in hex 462 notation are: 464 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 466 (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n") followed by a 467 SETTINGS frame (Section 6.5). The client sends the client connection 468 header immediately upon receipt of a 101 Switching Protocols response 469 (indicating a successful upgrade), or after receiving a TLS Finished 470 message from the server. If starting an HTTP/2.0 connection with 471 prior knowledge of server support for the protocol, the client 472 connection header is sent upon connection establishment. 474 The client connection header is selected so that a large 475 proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do 476 not attempt to process further frames. Note that this does not 477 address the concerns raised in [TALKING]. 479 The server connection header consists of just a SETTINGS frame 480 (Section 6.5) that MUST be the first frame the server sends in the 481 HTTP/2.0 connection. 483 To avoid unnecessary latency, clients are permitted to send 484 additional frames to the server immediately after sending the client 485 connection header, without waiting to receive the server connection 486 header. It is important to note, however, that the server connection 487 header SETTINGS frame might include parameters that necessarily alter 488 how a client is expected to communicate with the server. Upon 489 receiving the SETTINGS frame, the client is expected to honor any 490 parameters established. 492 Clients and servers MUST terminate the TCP connection if either peer 493 does not begin with a valid connection header. A GOAWAY frame 494 (Section 6.8) MAY be omitted if it is clear that the peer is not 495 using HTTP/2.0. 497 4. HTTP Frames 499 Once the HTTP/2.0 connection is established, endpoints can begin 500 exchanging frames. 502 4.1. Frame Header 504 All frames begin with an 8-octet header followed by a payload of 505 between 0 and 65,535 octets. 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Length (16) | Type (8) | Flags (8) | 511 +-+-------------+---------------+-------------------------------+ 512 |R| Stream Identifier (31) | 513 +-+-------------------------------------------------------------+ 514 | Frame Payload (0...) ... 515 +---------------------------------------------------------------+ 517 Frame Header 519 The fields of the frame header are defined as: 521 Length: The length of the frame payload expressed as an unsigned 16- 522 bit integer. The 8 octets of the frame header are not included in 523 this value. 525 Type: The 8-bit type of the frame. The frame type determines how 526 the remainder of the frame header and payload are interpreted. 527 Implementations MUST ignore unsupported and unrecognized frame 528 types. 530 Flags: An 8-bit field reserved for frame-type specific boolean 531 flags. 533 Flags are assigned semantics specific to the indicated frame type. 534 Flags that have no defined semantics for a particular frame type 535 MUST be ignored, and MUST be left unset (0) when sending. 537 R: A reserved 1-bit field. The semantics of this bit are undefined 538 and the bit MUST remain unset (0) when sending and MUST be ignored 539 when receiving. 541 Stream Identifier: A 31-bit stream identifier (see Section 5.1.1). 542 A value 0 is reserved for frames that are associated with the 543 connection as a whole as opposed to an individual stream. 545 The structure and content of the frame payload is dependent entirely 546 on the frame type. 548 4.2. Frame Size 550 The maximum size of a frame payload varies by frame type and use. 551 The absolute maximum size is 65,535 octets. All implementations 552 SHOULD be capable of receiving and minimally processing frames up to 553 this size. 555 Certain frame types, such as PING (see Section 6.7), impose 556 additional limits on the amount of payload data allowed. Likewise, 557 additional size limits can be set by specific application uses (see 558 Section 9). 560 If a frame size exceeds any defined limit, or is too small to contain 561 mandatory frame data, the endpoint MUST send a FRAME_TOO_LARGE error. 562 Frame size errors in frames that affect connection-level state MUST 563 be treated as a connection error (Section 5.4.1). 565 4.3. Header Compression and Decompression 567 A header in HTTP/2.0 is a name-value pair with one or more associated 568 values. They are used within HTTP request and response messages as 569 well as server push operations (see Section 8.2). 571 Header sets are logical collections of zero or more header fields 572 arranged at the application layer. When transmitted over a 573 connection, the header set is serialized into a header block using 574 HTTP Header Compression [COMPRESSION]. The serialized header block 575 is then divided into one or more octet sequences, called header block 576 fragments, and transmitted within the payload of HEADERS 577 (Section 6.2) or PUSH_PROMISE (Section 6.6) frames. The receiving 578 endpoint reassembles the header block by concatenating the individual 579 fragments, then decompresses the block to reconstruct the header set. 581 Header block fragments can only be sent as the payload of HEADERS or 582 PUSH_PROMISE frames. 584 A compressed and encoded header block is transmitted in one or more 585 HEADERS or PUSH_PROMISE frames. If the number of octets in the block 586 is greater than the space remaining in the frame, the block is 587 divided into multiple fragments, which are then transmitted in 588 multiple frames. 590 Header blocks MUST be transmitted as a contiguous sequence of frames, 591 with no interleaved frames of any other type, or from any other 592 stream. The last frame in a sequence of HEADERS frames MUST have the 593 END_HEADERS flag set. The last frame in a sequence of PUSH_PROMISE 594 frames MUST have the END_PUSH_PROMISE flag set. 596 HEADERS and PUSH_PROMISE frames carry data that can modify the 597 compression context maintained by a receiver. An endpoint receiving 598 HEADERS or PUSH_PROMISE frames MUST reassemble header blocks and 599 perform decompression even if the frames are to be discarded, which 600 is likely to occur after a stream is reset. A receiver MUST 601 terminate the connection with a connection error (Section 5.4.1) of 602 type COMPRESSION_ERROR, if it does not decompress a header block. 604 5. Streams and Multiplexing 606 A "stream" is an independent, bi-directional sequence of HEADER and 607 DATA frames exchanged between the client and server within an 608 HTTP/2.0 connection. Streams have several important characteristics: 610 o A single HTTP/2.0 connection can contain multiple concurrently 611 active streams, with either endpoint interleaving frames from 612 multiple streams. 614 o Streams can be established and used unilaterally or shared by 615 either the client or server. 617 o Streams can be closed by either endpoint. 619 o The order in which frames are sent within a stream is significant. 620 Recipients process frames in the order they are received. 622 o Streams are identified by an integer. Stream identifiers are 623 assigned to streams by the endpoint that initiates a stream. 625 5.1. Stream States 627 The lifecycle of a stream is shown in Figure 1. 629 +--------+ 630 PP | | PP 631 ,--------| idle |--------. 632 / | | \ 633 v +--------+ v 634 +----------+ | +----------+ 635 | | | H | | 636 ,---| reserved | | | reserved |---. 637 | | (local) | v | (remote) | | 638 | +----------+ +--------+ +----------+ | 639 | | ES | | ES | | 640 | | H ,-------| open |-------. | H | 641 | | / | | \ | | 642 | v v +--------+ v v | 643 | +----------+ | +----------+ | 644 | | half | | | half | | 645 | | closed | | R | closed | | 646 | | (remote) | | | (local) | | 647 | +----------+ | +----------+ | 648 | | v | | 649 | | ES / R +--------+ ES / R | | 650 | `----------->| |<-----------' | 651 | R | closed | R | 652 `-------------------->| |<--------------------' 653 +--------+ 655 Figure 1: Stream States 657 Both endpoints have a subjective view of the state of a stream that 658 could be different when frames are in transit. Endpoints do not 659 coordinate the creation of streams, they are created unilaterally by 660 either endpoint. The negative consequences of a mismatch in states 661 are limited to the "closed" state after sending RST_STREAM, where 662 frames might be received for some time after closing. 664 Streams have the following states: 666 idle: 667 All streams start in the "idle" state. In this state, no frames 668 have been exchanged. 670 The following transitions are valid from this state: 672 * Sending or receiving a HEADERS frame causes the stream to 673 become "open". The stream identifier is selected as described 674 in Section 5.1.1. 676 * Sending a PUSH_PROMISE frame marks the associated stream for 677 later use. The stream state for the reserved stream 678 transitions to "reserved (local)". 680 * Receiving a PUSH_PROMISE frame marks the associated stream as 681 reserved by the remote peer. The state of the stream becomes 682 "reserved (remote)". 684 reserved (local): 685 A stream in the "reserved (local)" state is one that has been 686 promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame 687 reserves an idle stream by associating the stream with an open 688 stream that was initiated by the remote peer (see Section 8.2). 690 In this state, only the following transitions are possible: 692 * The endpoint can send a HEADERS frame. This causes the stream 693 to open in a "half closed (remote)" state. 695 * Either endpoint can send a RST_STREAM frame to cause the stream 696 to become "closed". This releases the stream reservation. 698 An endpoint MUST NOT send any other type of frame in this state. 700 reserved (remote): 701 A stream in the "reserved (remote)" state has been reserved by a 702 remote peer. 704 In this state, only the following transitions are possible: 706 * Receiving a HEADERS frame causes the stream to transition to 707 "half closed (local)". 709 * Either endpoint can send a RST_STREAM frame to cause the stream 710 to become "closed". This releases the stream reservation. 712 Receiving any other type of frame MUST be treated as a stream 713 error (Section 5.4.2) of type PROTOCOL_ERROR. 715 open: 716 The "open" state is where both peers can send frames. In this 717 state, sending peers observe advertised stream level flow control 718 limits (Section 5.2). 720 From this state either endpoint can send a frame with a END_STREAM 721 flag set, which causes the stream to transition into one of the 722 "half closed" states: an endpoint sending a END_STREAM flag causes 723 the stream state to become "half closed (local)"; an endpoint 724 receiving a END_STREAM flag causes the stream state to become 725 "half closed (remote)". 727 Either endpoint can send a RST_STREAM frame from this state, 728 causing it to transition immediately to "closed". 730 half closed (local): 731 A stream that is "half closed (local)" cannot be used for sending 732 frames. 734 A stream transitions from this state to "closed" when a frame that 735 contains a END_STREAM flag is received, or when either peer sends 736 a RST_STREAM frame. 738 half closed (remote): 739 A stream that is "half closed (remote)" is no longer being used by 740 the peer to send frames. In this state, an endpoint is no longer 741 obligated to maintain a receiver flow control window if it 742 performs flow control. 744 If an endpoint receives additional frames for a stream that is in 745 this state it MUST respond with a stream error (Section 5.4.2) of 746 type STREAM_CLOSED. 748 A stream can transition from this state to "closed" by sending a 749 frame that contains a END_STREAM flag, or when either peer sends a 750 RST_STREAM frame. 752 closed: 753 The "closed" state is the terminal state. 755 An endpoint MUST NOT send frames on a closed stream. An endpoint 756 that receives a frame after receiving a RST_STREAM or a frame 757 containing a END_STREAM flag on that stream MUST treat that as a 758 stream error (Section 5.4.2) of type STREAM_CLOSED. 760 If this state is reached as a result of sending a RST_STREAM 761 frame, the peer that receives the RST_STREAM might have already 762 sent - or enqueued for sending - frames on the stream that cannot 763 be withdrawn. An endpoint that sends a RST_STREAM frame MUST 764 ignore frames that it receives on closed streams after it has sent 765 a RST_STREAM frame. An endpoint MAY choose to limit the period 766 over which it ignores frames and treat frames that arrive after 767 this time as being in error. 769 An endpoint might receive a PUSH_PROMISE frame after it sends 770 RST_STREAM. PUSH_PROMISE causes a stream to become "reserved". 771 If promised streams are not desired, a RST_STREAM can be used to 772 close any of those streams. 774 5.1.1. Stream Identifiers 776 Streams are identified with an unsigned 31-bit integer. Streams 777 initiated by a client MUST use odd-numbered stream identifiers; those 778 initiated by the server MUST use even-numbered stream identifiers. A 779 stream identifier of zero (0x0) is used for connection control 780 message; the stream identifier zero MUST NOT be used to establish a 781 new stream. 783 The identifier of a newly established stream MUST be numerically 784 greater than all streams that the initiating endpoint has opened or 785 reserved. This governs streams that are opened using a HEADERS frame 786 and streams that are reserved using PUSH_PROMISE. An endpoint that 787 receives an unexpected stream identifier MUST respond with a 788 connection error (Section 5.4.1) of type PROTOCOL_ERROR. 790 Stream identifiers cannot be reused. Long-lived connections can 791 result in endpoint exhausting the available range of stream 792 identifiers. A client that is unable to establish a new stream 793 identifier can establish a new connection for new streams. 795 5.1.2. Stream Concurrency 797 A peer can limit the number of concurrently active streams using the 798 SETTINGS_MAX_CONCURRENT_STREAMS parameters within a SETTINGS frame. 799 The maximum concurrent streams setting is specific to each endpoint 800 and applies only to the peer that receives the setting. That is, 801 clients specify the maximum number of concurrent streams the server 802 can initiate, and servers specify the maximum number of concurrent 803 streams the client can initiate. Endpoints MUST NOT exceed the limit 804 set by their peer. 806 Streams that are in the "open" state, or either of the "half closed" 807 states count toward the maximum number of streams that an endpoint is 808 permitted to open. Streams in any of these three states count toward 809 the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting 810 (see Section 6.5.2). 812 Streams in either of the "reserved" states do not count as open, even 813 if a small amount of application state is retained to ensure that the 814 promised stream can be successfully used. 816 5.2. Flow Control 818 Using streams for multiplexing introduces contention over use of the 819 TCP connection, resulting in blocked streams. A flow control scheme 820 ensures that streams on the same connection do not destructively 821 interfere with each other. Flow control is used for both individual 822 streams and for the connection as a whole. 824 HTTP/2.0 provides for flow control through use of the WINDOW_UPDATE 825 (Section 6.9) frame type. 827 5.2.1. Flow Control Principles 829 Experience with TCP congestion control has shown that algorithms can 830 evolve over time to become more sophisticated without requiring 831 protocol changes. TCP congestion control and its evolution is 832 clearly different from HTTP/2.0 flow control, though the evolution of 833 TCP congestion control algorithms shows that a similar approach could 834 be feasible for HTTP/2.0 flow control. 836 HTTP/2.0 stream flow control aims to allow for future improvements to 837 flow control algorithms without requiring protocol changes. Flow 838 control in HTTP/2.0 has the following characteristics: 840 1. Flow control is hop-by-hop, not end-to-end. 842 2. Flow control is based on window update frames. Receivers 843 advertise how many bytes they are prepared to receive on a stream 844 and for the entire connection. This is a credit-based scheme. 846 3. Flow control is directional with overall control provided by the 847 receiver. A receiver MAY choose to set any window size that it 848 desires for each stream and for the entire connection. A sender 849 MUST respect flow control limits imposed by a receiver. Clients, 850 servers and intermediaries all independently advertise their flow 851 control preferences as a receiver and abide by the flow control 852 limits set by their peer when sending. 854 4. The initial value for the flow control window is 65536 bytes for 855 both new streams and the overall connection. 857 5. The frame type determines whether flow control applies to a 858 frame. Of the frames specified in this document, only DATA 859 frames are subject to flow control; all other frame types do not 860 consume space in the advertised flow control window. This 861 ensures that important control frames are not blocked by flow 862 control. 864 6. Flow control can be disabled by a receiver. A receiver can 865 choose to either disable flow control for a stream or connection 866 by sending a window update frame with a specific flag. See 867 Ending Flow Control (Section 6.9.4) for more details. 869 7. HTTP/2.0 standardizes only the format of the WINDOW_UPDATE frame 870 (Section 6.9). This does not stipulate how a receiver decides 871 when to send this frame or the value that it sends. Nor does it 872 specify how a sender chooses to send packets. Implementations 873 are able to select any algorithm that suits their needs. 875 Implementations are also responsible for managing how requests and 876 responses are sent based on priority; choosing how to avoid head of 877 line blocking for requests; and managing the creation of new streams. 878 Algorithm choices for these could interact with any flow control 879 algorithm. 881 5.2.2. Appropriate Use of Flow Control 883 Flow control is defined to protect endpoints that are operating under 884 resource constraints. For example, a proxy needs to share memory 885 between many connections, and also might have a slow upstream 886 connection and a fast downstream one. Flow control addresses cases 887 where the receiver is unable process data on one stream, yet wants to 888 continue to process other streams in the same connection. 890 Deployments that do not require this capability SHOULD disable flow 891 control for data that is being received. Note that flow control 892 cannot be disabled for sending. Sending data is always subject to 893 the flow control window advertised by the receiver. 895 Deployments with constrained resources (for example, memory) MAY 896 employ flow control to limit the amount of memory a peer can consume. 897 Note, however, that this can lead to suboptimal use of available 898 network resources if flow control is enabled without knowledge of the 899 bandwidth-delay product (see [RFC1323]). 901 Even with full awareness of the current bandwidth-delay product, 902 implementation of flow control is difficult. However, it can ensure 903 that constrained resources are protected without any reduction in 904 connection utilization. 906 5.3. Stream priority 908 The endpoint establishing a new stream can assign a priority for the 909 stream. Priority is represented as an unsigned 31-bit integer. 0 910 represents the highest priority and 2^31-1 represents the lowest 911 priority. 913 The purpose of this value is to allow the initiating endpoint to 914 request that frames for the stream be processed with a specified 915 priority relative to other concurrently active streams. That is, if 916 an endpoint receives interleaved frames for multiple streams, the 917 endpoint ought to make a best-effort attempt at processing frames for 918 higher priority streams before processing those for lower priority 919 streams. 921 Explicitly setting the priority for a stream does not guarantee any 922 particular processing order for the stream relative to any other 923 stream. Nor is there any mechanism provided by which the initiator 924 of a stream can force or require a receiving endpoint to process 925 frames from one stream before processing frames from another. 927 Unless explicitly specified in the HEADERS frame (Section 6.2) during 928 stream creation, the default stream priority is 2^30. Pushed streams 929 (Section 8.2) are assumed to inherit the priority of the associated 930 stream plus one (or 2^31-1 if the the associated stream priority is 931 2^31-1), i.e. they have priority one lower than the associated 932 stream. 934 5.4. Error Handling 936 HTTP/2.0 framing permits two classes of error: 938 o An error condition that renders the entire connection unusable is 939 a connection error. 941 o An error in an individual stream is a stream error. 943 A list of error codes is included in Section 7. 945 5.4.1. Connection Error Handling 947 A connection error is any error which prevents further processing of 948 the framing layer or which corrupts any connection state. 950 An endpoint that encounters a connection error SHOULD first send a 951 GOAWAY (Section 6.8) frame with the stream identifier of the last 952 stream that it successfully received from its peer. The GOAWAY frame 953 includes an error code that indicates why the connection is 954 terminating. After sending the GOAWAY frame, the endpoint MUST close 955 the TCP connection. 957 It is possible that the GOAWAY will not be reliably received by the 958 receiving endpoint. In the event of a connection error, GOAWAY only 959 provides a best-effort attempt to communicate with the peer about why 960 the connection is being terminated. 962 An endpoint can end a connection at any time. In particular, an 963 endpoint MAY choose to treat a stream error as a connection error if 964 the error is recurrent. Endpoints SHOULD send a GOAWAY frame when 965 ending a connection, as long as circumstances permit it. 967 5.4.2. Stream Error Handling 969 A stream error is an error related to a specific stream identifier 970 that does not affect processing of other streams. 972 An endpoint that detects a stream error sends a RST_STREAM 973 (Section 6.4) frame that contains the stream identifier of the stream 974 where the error occurred. The RST_STREAM frame includes an error 975 code that indicates the type of error. 977 A RST_STREAM is the last frame that an endpoint can send on a stream. 978 The peer that sends the RST_STREAM frame MUST be prepared to receive 979 any frames that were sent or enqueued for sending by the remote peer. 980 These frames can be ignored, except where they modify connection 981 state (such as the state maintained for header compression 982 (Section 4.3)). 984 Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame 985 for any stream. However, an endpoint MAY send additional RST_STREAM 986 frames if it receives frames on a closed stream after more than a 987 round trip time. This behavior is permitted to deal with misbehaving 988 implementations. 990 An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM 991 frame, to avoid looping. 993 5.4.3. Connection Termination 995 If the TCP connection is torn down while streams remain in open or 996 half closed states, then the endpoint MUST assume that the stream was 997 abnormally interrupted and could be incomplete. 999 6. Frame Definitions 1001 This specification defines a number of frame types, each identified 1002 by a unique 8-bit type code. Each frame type serves a distinct 1003 purpose either in the establishment and management of the connection 1004 as a whole, or of individual streams. 1006 The transmission of specific frame types can alter the state of a 1007 connection. If endpoints fail to maintain a synchronized view of the 1008 connection state, successful communication within the connection will 1009 no longer be possible. Therefore, it is important that endpoints 1010 have a shared comprehension of how the state is affected by the use 1011 any given frame. Accordingly, while it is expected that new frame 1012 types will be introduced by extensions to this protocol, only frames 1013 defined by this document are permitted to alter the connection state. 1015 6.1. DATA 1017 DATA frames (type=0x0) convey arbitrary, variable-length sequences of 1018 octets associated with a stream. One or more DATA frames are used, 1019 for instance, to carry HTTP request or response payloads. 1021 The DATA frame defines the following flags: 1023 END_STREAM (0x1): Bit 1 being set indicates that this frame is the 1024 last that the endpoint will send for the identified stream. 1025 Setting this flag causes the stream to enter a "half closed" state 1026 (Section 5.1). 1028 RESERVED (0x2): Bit 2 is reserved for future use. 1030 DATA frames MUST be associated with a stream. If a DATA frame is 1031 received whose stream identifier field is 0x0, the recipient MUST 1032 respond with a connection error (Section 5.4.1) of type 1033 PROTOCOL_ERROR. 1035 6.2. HEADERS 1037 The HEADERS frame (type=0x1) carries name-value pairs. The HEADERS 1038 is used to open a stream (Section 5.1). Any number of HEADERS frames 1039 can be sent on an existing stream at any time. 1041 0 1 2 3 1042 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 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 |X| Priority (31) | 1045 +-+-------------------------------------------------------------+ 1046 | Header Block Fragment (*) ... 1047 +---------------------------------------------------------------+ 1049 HEADERS Frame Payload 1051 The HEADERS frame defines the following flags: 1053 END_STREAM (0x1): Bit 1 being set indicates that this frame is the 1054 last that the endpoint will send for the identified stream. 1055 Setting this flag causes the stream to enter a "half closed" state 1056 (Section 5.1). 1058 RESERVED (0x2): Bit 2 is reserved for future use. 1060 END_HEADERS (0x4): The END_HEADERS bit indicates that this frame 1061 ends the sequence of header block fragments necessary to provide a 1062 complete set of headers. 1064 The payload for a complete header block is provided by a sequence 1065 of HEADERS frames, terminated by a HEADERS frame with the 1066 END_HEADERS flag set. Once the sequence terminates, the payload 1067 of all HEADERS frames are concatenated and interpreted as a single 1068 block. 1070 A HEADERS frame without the END_HEADERS flag set MUST be followed 1071 by a HEADERS frame for the same stream. A receiver MUST treat the 1072 receipt of any other type of frame or a frame on a different 1073 stream as a connection error (Section 5.4.1) of type 1074 PROTOCOL_ERROR. 1076 PRIORITY (0x8): Bit 4 being set indicates that the first four octets 1077 of this frame contain a single reserved bit and a 31-bit priority; 1078 see Section 5.3. If this bit is not set, the four bytes do not 1079 appear and the frame only contains a header block fragment. 1081 The payload of a HEADERS frame contains a header block fragment 1082 (Section 4.3). 1084 HEADERS frames MUST be associated with a stream. If a HEADERS frame 1085 is received whose stream identifier field is 0x0, the recipient MUST 1086 respond with a connection error (Section 5.4.1) of type 1087 PROTOCOL_ERROR. 1089 The HEADERS frame changes the connection state as defined in 1090 Section 4.3. 1092 6.3. PRIORITY 1094 The PRIORITY frame (type=0x2) specifies the sender-advised priority 1095 of a stream. It can be sent at any time for an existing stream. 1096 This enables reprioritisation of existing streams. 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 |X| Priority (31) | 1102 +-+-------------------------------------------------------------+ 1104 PRIORITY Frame Payload 1106 The payload of a PRIORITY frame contains a single reserved bit and a 1107 31-bit priority. 1109 The PRIORITY frame does not define any flags. 1111 The PRIORITY frame is associated with an existing stream. If a 1112 PRIORITY frame is received with a stream identifier of 0x0, the 1113 recipient MUST respond with a connection error (Section 5.4.1) of 1114 type PROTOCOL_ERROR. 1116 6.4. RST_STREAM 1118 The RST_STREAM frame (type=0x3) allows for abnormal termination of a 1119 stream. When sent by the initiator of a stream, it indicates that 1120 they wish to cancel the stream or that an error condition has 1121 occurred. When sent by the receiver of a stream, it indicates that 1122 either the receiver is rejecting the stream, requesting that the 1123 stream be cancelled or that an error condition has occurred. 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Error Code (32) | 1129 +---------------------------------------------------------------+ 1131 RST_STREAM Frame Payload 1133 The RST_STREAM frame contains a single unsigned, 32-bit integer 1134 identifying the error code (Section 7). The error code indicates why 1135 the stream is being terminated. 1137 The RST_STREAM frame does not define any flags. 1139 The RST_STREAM frame fully terminates the referenced stream and 1140 causes it to enter the closed state. After receiving a RST_STREAM on 1141 a stream, the receiver MUST NOT send additional frames for that 1142 stream. However, after sending the RST_STREAM, the sending endpoint 1143 MUST be prepared to receive and process additional frames sent on the 1144 stream that might have been sent by the peer prior to the arrival of 1145 the RST_STREAM. 1147 RST_STREAM frames MUST be associated with a stream. If a RST_STREAM 1148 frame is received whose stream identifier field is 0x0 the recipient 1149 MUST respond with a connection error (Section 5.4.1) of type 1150 PROTOCOL_ERROR. 1152 6.5. SETTINGS 1154 The SETTINGS frame (type=0x4) conveys configuration parameters that 1155 affect how endpoints communicate. The parameters are either 1156 constraints on peer behavior or preferences. 1158 SETTINGS frames MUST be sent at the start of a connection, and MAY be 1159 sent at any other time by either endpoint over the lifetime of the 1160 connection. 1162 Implementations MUST support all of the settings defined by this 1163 specification and MAY support additional settings defined by 1164 extensions. Unsupported or unrecognized settings MUST be ignored. 1165 New settings MUST NOT be defined or implemented in a way that 1166 requires endpoints to understand them in order to communicate 1167 successfully. 1169 A SETTINGS frame is not required to include every defined setting; 1170 senders can include only those parameters for which it has accurate 1171 values and a need to convey. When multiple parameters are sent, they 1172 SHOULD be sent in order of numerically lowest ID to highest ID. A 1173 single SETTINGS frame MUST NOT contain multiple values for the same 1174 ID. If the receiver of a SETTINGS frame discovers multiple values 1175 for the same ID, it MUST ignore all values for that ID except the 1176 first one. 1178 Over the lifetime of a connection, an endpoint MAY send multiple 1179 SETTINGS frames containing previously unspecified parameters or new 1180 values for parameters whose values have already been established. 1181 Only the most recent provided setting value applies. 1183 The SETTINGS frame does not define any flags. 1185 SETTINGS frames always apply to a connection, never a single stream. 1186 The stream identifier for a settings frame MUST be zero. If an 1187 endpoint receives a SETTINGS frame whose stream identifier field is 1188 anything other than 0x0, the endpoint MUST respond with a connection 1189 error (Section 5.4.1) of type PROTOCOL_ERROR. 1191 The SETTINGS frame affects connection state. A badly formed or 1192 incomplete SETTINGS frame MUST be treated as a connection error 1193 (Section 5.4.1). 1195 6.5.1. Setting Format 1197 The payload of a SETTINGS frame consists of zero or more settings. 1198 Each setting consists of an 8-bit reserved field, an unsigned 24-bit 1199 setting identifier, and an unsigned 32-bit value. 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Reserved (8) | Setting Identifier (24) | 1205 +---------------+-----------------------------------------------+ 1206 | Value (32) | 1207 +---------------------------------------------------------------+ 1209 Setting Format 1211 6.5.2. Defined Settings 1213 The following settings are defined: 1215 SETTINGS_MAX_CONCURRENT_STREAMS (4): indicates the maximum number of 1216 concurrent streams that the sender will allow. This limit is 1217 directional: it applies to the number of streams that the sender 1218 permits the receiver to create. By default there is no limit. It 1219 is recommended that this value be no smaller than 100, so as to 1220 not unnecessarily limit parallelism. 1222 SETTINGS_INITIAL_WINDOW_SIZE (7): indicates the sender's initial 1223 window size (in bytes) for stream level flow control. 1225 This settings affects the window size of all streams, including 1226 existing streams, see Section 6.9.2. 1228 SETTINGS_FLOW_CONTROL_OPTIONS (10): indicates that streams directed 1229 to the sender will not be subject to flow control. The least 1230 significant bit (0x1) of the value is set to indicate that new 1231 streams are not flow controlled. All other bits are reserved. 1233 This setting applies to all streams, including existing streams. 1235 These bits cannot be cleared once set, see Section 6.9.4. 1237 6.6. PUSH_PROMISE 1239 The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint 1240 in advance of streams the sender intends to initiate. The 1241 PUSH_PROMISE frame includes the unsigned 31-bit identifier of the 1242 stream the endpoint plans to create along with a minimal set of 1243 headers that provide additional context for the stream. Section 8.2 1244 contains a thorough description of the use of PUSH_PROMISE frames. 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 |X| Promised-Stream-ID (31) | 1250 +-+-------------------------------------------------------------+ 1251 | Header Block Fragment (*) ... 1252 +---------------------------------------------------------------+ 1254 PUSH_PROMISE Payload Format 1256 The payload of a PUSH_PROMISE includes a "Promised-Stream-ID". This 1257 unsigned 31-bit integer identifies the stream the endpoint intends to 1258 start sending frames for. The promised stream identifier MUST be a 1259 valid choice for the next stream sent by the sender (see new stream 1260 identifier (Section 5.1.1)). 1262 Following the "Promised-Stream-ID" is a header block fragment 1263 (Section 4.3). 1265 PUSH_PROMISE frames MUST be associated with an existing, peer- 1266 initiated stream. If the stream identifier field specifies the value 1267 0x0, a recipient MUST respond with a connection error (Section 5.4.1) 1268 of type PROTOCOL_ERROR. 1270 The PUSH_PROMISE frame defines the following flags: 1272 END_PUSH_PROMISE (0x1): The END_PUSH_PROMISE bit indicates that this 1273 frame ends the sequence of header block fragments necessary to 1274 provide a complete set of headers. 1276 The payload for a complete header block is provided by a sequence 1277 of PUSH_PROMISE frames, terminated by a PUSH_PROMISE frame with 1278 the END_PUSH_PROMISE flag set. Once the sequence terminates, the 1279 payload of all PUSH_PROMISE frames are concatenated and 1280 interpreted as a single block. 1282 A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be 1283 followed by a PUSH_PROMISE frame for the same stream. A receiver 1284 MUST treat the receipt of any other type of frame or a frame on a 1285 different stream as a connection error (Section 5.4.1) of type 1286 PROTOCOL_ERROR. 1288 Promised streams are not required to be used in order promised. The 1289 PUSH_PROMISE only reserves stream identifiers for later use. 1291 Recipients of PUSH_PROMISE frames can choose to reject promised 1292 streams by returning a RST_STREAM referencing the promised stream 1293 identifier back to the sender of the PUSH_PROMISE. 1295 The PUSH_PROMISE frame modifies the connection state as defined in 1296 Section 4.3. 1298 6.7. PING 1300 The PING frame (type=0x6) is a mechanism for measuring a minimal 1301 round-trip time from the sender, as well as determining whether an 1302 idle connection is still functional. PING frames can be sent from 1303 any endpoint. 1305 0 1 2 3 1306 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 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | | 1309 | Opaque Data (64) | 1310 | | 1311 +---------------------------------------------------------------+ 1313 PING Payload Format 1315 In addition to the frame header, PING frames MUST contain 8 octets of 1316 data in the payload. A sender can include any value it chooses and 1317 use those bytes in any fashion. 1319 Receivers of a PING frame that does not include a PONG flag MUST send 1320 a PING frame with the PONG flag set in response, with an identical 1321 payload. PING responses SHOULD given higher priority than any other 1322 frame. 1324 The PING frame defines the following flags: 1326 PONG (0x1): Bit 1 being set indicates that this PING frame is a PING 1327 response. An endpoint MUST set this flag in PING responses. An 1328 endpoint MUST NOT respond to PING frames containing this flag. 1330 PING frames are not associated with any individual stream. If a PING 1331 frame is received with a stream identifier field value other than 1332 0x0, the recipient MUST respond with a connection error 1333 (Section 5.4.1) of type PROTOCOL_ERROR. 1335 Receipt of a PING frame with a length field value other than 8 MUST 1336 be treated as a connection error (Section 5.4.1) of type 1337 PROTOCOL_ERROR. 1339 6.8. GOAWAY 1341 The GOAWAY frame (type=0x7) informs the remote peer to stop creating 1342 streams on this connection. It can be sent from the client or the 1343 server. Once sent, the sender will ignore frames sent on new streams 1344 for the remainder of the connection. Receivers of a GOAWAY frame 1345 MUST NOT open additional streams on the connection, although a new 1346 connection can be established for new streams. The purpose of this 1347 frame is to allow an endpoint to gracefully stop accepting new 1348 streams (perhaps for a reboot or maintenance), while still finishing 1349 processing of previously established streams. 1351 There is an inherent race condition between an endpoint starting new 1352 streams and the remote sending a GOAWAY frame. To deal with this 1353 case, the GOAWAY contains the stream identifier of the last stream 1354 which was processed on the sending endpoint in this connection. If 1355 the receiver of the GOAWAY used streams that are newer than the 1356 indicated stream identifier, they were not processed by the sender 1357 and the receiver may treat the streams as though they had never been 1358 created at all (hence the receiver may want to re-create the streams 1359 later on a new connection). 1361 Endpoints SHOULD always send a GOAWAY frame before closing a 1362 connection so that the remote can know whether a stream has been 1363 partially processed or not. For example, if an HTTP client sends a 1364 POST at the same time that a server closes a connection, the client 1365 cannot know if the server started to process that POST request if the 1366 server does not send a GOAWAY frame to indicate where it stopped 1367 working. An endpoint might choose to close a connection without 1368 sending GOAWAY for misbehaving peers. 1370 After sending a GOAWAY frame, the sender can discard frames for new 1371 streams. However, any frames that alter connection state cannot be 1372 completely ignored. For instance, HEADERS and PUSH_PROMISE frames 1373 MUST be minimally processed to ensure a consistent compression state 1374 (see Section 4.3). 1376 0 1 2 3 1377 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 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 |X| Last-Stream-ID (31) | 1380 +-+-------------------------------------------------------------+ 1381 | Error Code (32) | 1382 +---------------------------------------------------------------+ 1383 | Additional Debug Data (*) | 1384 +---------------------------------------------------------------+ 1386 GOAWAY Payload Format 1388 The GOAWAY frame does not define any flags. 1390 The GOAWAY frame applies to the connection, not a specific stream. 1392 The stream identifier MUST be zero. 1394 The last stream identifier in the GOAWAY frame contains the highest 1395 numbered stream identifier for which the sender of the GOAWAY frame 1396 has received frames on and might have taken some action on. All 1397 streams up to and including the identified stream might have been 1398 processed in some way. The last stream identifier is set to 0 if no 1399 streams were processed. 1401 Note: In this case, "processed" means that some data from the 1402 stream was passed to some higher layer of software that might have 1403 taken some action as a result. 1405 On streams with lower or equal numbered identifiers that were not 1406 closed completely prior to the connection being closed, re-attempting 1407 requests, transactions, or any protocol activity is not possible 1408 (with the exception of idempotent actions like HTTP GET, PUT, or 1409 DELETE). Any protocol activity that uses higher numbered streams can 1410 be safely retried using a new connection. 1412 Activity on streams numbered lower or equal to the last stream 1413 identifier might still complete successfully. The sender of a GOAWAY 1414 frame might gracefully shut down a connection by sending a GOAWAY 1415 frame, maintaining the connection in an open state until all in- 1416 progress streams complete. 1418 The last stream ID MUST be 0 if no streams were acted upon. 1420 The GOAWAY frame also contains a 32-bit error code (Section 7) that 1421 contains the reason for closing the connection. 1423 Endpoints MAY append opaque data to the payload of any GOAWAY frame. 1424 Additional debug data is intended for diagnostic purposes only and 1425 carries no semantic value. Debug data MUST NOT be persistently 1426 stored, since it could contain sensitive information. 1428 6.9. WINDOW_UPDATE 1430 The WINDOW_UPDATE frame (type=0x9) is used to implement flow control. 1432 Flow control operates at two levels: on each individual stream and on 1433 the entire connection. 1435 Both types of flow control are hop by hop; that is, only between the 1436 two endpoints. Intermediaries do not forward WINDOW_UPDATE frames 1437 between dependent connections. However, throttling of data transfer 1438 by any receiver can indirectly cause the propagation of flow control 1439 information toward the original sender. 1441 Flow control only applies to frames that are identified as being 1442 subject to flow control. Of the frame types defined in this 1443 document, this includes only DATA frame. Frames that are exempt from 1444 flow control MUST be accepted and processed, unless the receiver is 1445 unable to assign resources to handling the frame. A receiver MAY 1446 respond with a stream error (Section 5.4.2) or connection error 1447 (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable accept a 1448 frame. 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 |X| Window Size Increment (31) | 1454 +-+-------------------------------------------------------------+ 1456 WINDOW_UPDATE Payload Format 1458 The payload of a WINDOW_UPDATE frame is one reserved bit, plus an 1459 unsigned 31-bit integer indicating the number of bytes that the 1460 sender can transmit in addition to the existing flow control window. 1461 The legal range for the increment to the flow control window is 1 to 1462 2^31 - 1 (0x7fffffff) bytes. 1464 The WINDOW_UPDATE frame defines the following flags: 1466 END_FLOW_CONTROL (0x1): Bit 1 being set indicates that flow control 1467 for the identified stream or connection has been ended; subsequent 1468 frames do not need to be flow controlled. 1470 The WINDOW_UPDATE frame can be specific to a stream or to the entire 1471 connection. In the former case, the frame's stream identifier 1472 indicates the affected stream; in the latter, the value "0" indicates 1473 that the entire connection is the subject of the frame. 1475 6.9.1. The Flow Control Window 1477 Flow control in HTTP/2.0 is implemented using a window kept by each 1478 sender on every stream. The flow control window is a simple integer 1479 value that indicates how many bytes of data the sender is permitted 1480 to transmit; as such, its size is a measure of the buffering 1481 capability of the receiver. 1483 Two flow control windows are applicable; the stream flow control 1484 window and the connection flow control window. The sender MUST NOT 1485 send a flow controlled frame with a length that exceeds the space 1486 available in either of the flow control windows advertised by the 1487 receiver. Frames with zero length with the END_STREAM flag set (for 1488 example, an empty data frame) MAY be sent if there is no available 1489 space in either flow control window. 1491 For flow control calculations, the 8 byte frame header is not 1492 counted. 1494 After sending a flow controlled frame, the sender reduces the space 1495 available in both windows by the length of the transmitted frame. 1497 The receiver of a frame sends a WINDOW_UPDATE frame as it consumes 1498 data and frees up space in flow control windows. Separate 1499 WINDOW_UPDATE frames are sent for the stream and connection level 1500 flow control windows. 1502 A sender that receives a WINDOW_UPDATE frame updates the 1503 corresponding window by the amount specified in the frame. 1505 A sender MUST NOT allow a flow control window to exceed 2^31 - 1 1506 bytes. If a sender receives a WINDOW_UPDATE that causes a flow 1507 control window to exceed this maximum it MUST terminate either the 1508 stream or the connection, as appropriate. For streams, the sender 1509 sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code; 1510 for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code. 1512 Flow controlled frames from the sender and WINDOW_UPDATE frames from 1513 the receiver are completely asynchronous with respect to each other. 1514 This property allows a receiver to aggressively update the window 1515 size kept by the sender to prevent streams from stalling. 1517 6.9.2. Initial Flow Control Window Size 1519 When a HTTP/2.0 connection is first established, new streams are 1520 created with an initial flow control window size of 65535 bytes. The 1521 connection flow control window is 65535 bytes. Both endpoints can 1522 adjust the initial window size for new streams by including a value 1523 for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms 1524 part of the connection header. 1526 Prior to receiving a SETTINGS frame that sets a value for 1527 SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default 1528 initial window size when sending flow controlled frames. Similarly, 1529 the connection flow control window is set to the default initial 1530 window size until a WINDOW_UPDATE frame is received. 1532 A SETTINGS frame can alter the initial flow control window size for 1533 all current streams. When the value of SETTINGS_INITIAL_WINDOW_SIZE 1534 changes, a receiver MUST adjust the size of all stream flow control 1535 windows that it maintains by the difference between the new value and 1536 the old value. A SETTINGS frame cannot alter the connection flow 1537 control window. 1539 A change to SETTINGS_INITIAL_WINDOW_SIZE could cause the available 1540 space in a flow control window to become negative. A sender MUST 1541 track the negative flow control window, and MUST NOT send new flow 1542 controlled frames until it receives WINDOW_UPDATE frames that cause 1543 the flow control window to become positive. 1545 For example, if the client sends 64KB immediately on connection 1546 establishment, and the server sets the initial window size to be 1547 16KB, the client will recalculate the available flow control window 1548 to be -48KB on receipt of the SETTINGS frame. The client retains a 1549 negative flow control window until WINDOW_UPDATE frames restore the 1550 window to being positive, after which the client can resume sending. 1552 6.9.3. Reducing the Stream Window Size 1554 A receiver that wishes to use a smaller flow control window than the 1555 current size can send a new SETTINGS frame. However, the receiver 1556 MUST be prepared to receive data that exceeds this window size, since 1557 the sender might send data that exceeds the lower limit prior to 1558 processing the SETTINGS frame. 1560 A receiver has two options for handling streams that exceed flow 1561 control limits: 1563 1. The receiver can immediately send RST_STREAM with 1564 FLOW_CONTROL_ERROR error code for the affected streams. 1566 2. The receiver can accept the streams and tolerate the resulting 1567 head of line blocking, sending WINDOW_UPDATE frames as it 1568 consumes data. 1570 If a receiver decides to accept streams, both sides MUST recompute 1571 the available flow control window based on the initial window size 1572 sent in the SETTINGS. 1574 6.9.4. Ending Flow Control 1576 After a receiver reads in a frame that marks the end of a stream (for 1577 example, a data stream with a END_STREAM flag set), it MUST cease 1578 transmission of WINDOW_UPDATE frames for that stream. A sender is 1579 not obligated to maintain the available flow control window for 1580 streams that it is no longer sending on. 1582 Flow control can be disabled for all streams on the connection using 1583 the SETTINGS_FLOW_CONTROL_OPTIONS setting. An implementation that 1584 does not wish to perform stream flow control can use this in the 1585 initial SETTINGS exchange. 1587 Flow control can be disabled for an individual stream or the overall 1588 connection by sending a WINDOW_UPDATE with the END_FLOW_CONTROL flag 1589 set. The payload of a WINDOW_UPDATE frame that has the 1590 END_FLOW_CONTROL flag set is ignored. 1592 Flow control cannot be enabled again once disabled. Any attempt to 1593 re-enable flow control - by sending a WINDOW_UPDATE or by clearing 1594 the bits on the SETTINGS_FLOW_CONTROL_OPTIONS setting - MUST be 1595 rejected with a FLOW_CONTROL_ERROR error code. 1597 7. Error Codes 1599 Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY 1600 frames to convey the reasons for the stream or connection error. 1602 Error codes share a common code space. Some error codes only apply 1603 to specific conditions and have no defined semantics in certain frame 1604 types. 1606 The following error codes are defined: 1608 NO_ERROR (0): The associated condition is not as a result of an 1609 error. For example, a GOAWAY might include this code to indicate 1610 graceful shutdown of a connection. 1612 PROTOCOL_ERROR (1): The endpoint detected an unspecific protocol 1613 error. This error is for use when a more specific error code is 1614 not available. 1616 INTERNAL_ERROR (2): The endpoint encountered an unexpected internal 1617 error. 1619 FLOW_CONTROL_ERROR (3): The endpoint detected that its peer violated 1620 the flow control protocol. 1622 STREAM_CLOSED (5): The endpoint received a frame after a stream was 1623 half closed. 1625 FRAME_TOO_LARGE (6): The endpoint received a frame that was larger 1626 than the maximum size that it supports. 1628 REFUSED_STREAM (7): The endpoint refuses the stream prior to 1629 performing any application processing, see Section 8.1.5 for 1630 details. 1632 CANCEL (8): Used by the endpoint to indicate that the stream is no 1633 longer needed. 1635 COMPRESSION_ERROR (9): The endpoint is unable to maintain the 1636 compression context for the connection. 1638 8. HTTP Message Exchanges 1640 HTTP/2.0 is intended to be as compatible as possible with current 1641 web-based applications. This means that, from the perspective of the 1642 server business logic or application API, the features of HTTP are 1643 unchanged. To achieve this, all of the application request and 1644 response header semantics are preserved, although the syntax of 1645 conveying those semantics has changed. Thus, the rules from HTTP/1.1 1646 ([HTTP-p1], [HTTP-p2], [HTTP-p4], [HTTP-p5], [HTTP-p6], and 1647 [HTTP-p7]) apply with the changes in the sections below. 1649 8.1. HTTP Request/Response Exchange 1651 A client sends an HTTP request on a new stream, using a previously 1652 unused stream identifier (Section 5.1.1). A server sends an HTTP 1653 response on the same stream as the request. 1655 An HTTP request or response each consist of: 1657 o one contiguous sequence of HEADERS frames; 1659 o zero or more DATA frames; and 1661 o optionally, a contiguous sequence of HEADERS frames 1663 The last frame in the sequence bears an END_STREAM flag. 1665 Other frames, including HEADERS, MAY be interspersed with these 1666 frames, but those frames do not carry HTTP semantics. 1668 Trailing header fields are carried in a header block that also 1669 terminates the stream. That is, a sequence of HEADERS frames that 1670 carries an END_STREAM flag on the last frame. Header blocks after 1671 the first that do not terminate the stream are not part of an HTTP 1672 request or response. 1674 An HTTP request/response exchange fully consumes a single stream. A 1675 request starts with the HEADERS frame that puts the stream into an 1676 "open" state and ends with a frame bearing END_STREAM, which causes 1677 the stream to become "half closed" for the client. A response starts 1678 with a HEADERS frame and ends with a frame bearing END_STREAM, which 1679 places the stream in the "closed" state. 1681 8.1.1. Examples 1683 For example, an HTTP GET request that includes request header fields 1684 and no body, is transmitted as a single contiguous sequence of 1685 HEADERS frames containing the serialized block of request header 1686 fields. The last HEADERS frame in the sequence has both the 1687 END_HEADERS and END_STREAM flag set: 1689 GET /resource HTTP/1.1 HEADERS 1690 Host: example.org ==> + END_STREAM 1691 Accept: image/jpeg + END_HEADERS 1692 :method = get 1693 :scheme = https 1694 :host = example.org 1695 :path = /resource 1696 accept = image/jpeg 1698 Similarly, a response that includes only response header fields is 1699 transmitted as a sequence of HEADERS frames containing the serialized 1700 block of response header fields. The last HEADERS frame in the 1701 sequence has both the END_HEADERS and END_STREAM flag set: 1703 HTTP/1.1 204 No Content HEADERS 1704 Content-Length: 0 ===> + END_STREAM 1705 + END_HEADERS 1706 :status = 204 1707 content-length: 0 1709 An HTTP POST request that includes request header fields and payload 1710 data is transmitted as one or more HEADERS frames containing the 1711 request headers followed by one or more DATA frames, with the last 1712 HEADERS frame having the END_HEADERS flag set and the final DATA 1713 frame having the END_STREAM flag set: 1715 POST /resource HTTP/1.1 HEADERS 1716 Host: example.org ==> - END_STREAM 1717 Content-Type: image/jpeg + END_HEADERS 1718 Content-Length: 123 :method = post 1719 :scheme = https 1720 {binary data} :host = example.org 1721 :path = /resource 1722 content-type = image/jpeg 1723 content-length = 123 1725 DATA 1726 + END_STREAM 1727 {binary data} 1729 A response that includes header fields and payload data is 1730 transmitted as one or more HEADERS frames followed by one or more 1731 DATA frames, with the last DATA frame in the sequence having the 1732 END_STREAM flag set: 1734 HTTP/1.1 200 OK HEADERS 1735 Content-Type: image/jpeg ==> - END_STREAM 1736 Content-Length: 123 + END_HEADERS 1737 :status = 200 1738 {binary data} content-type = image/jpeg 1739 content-length = 123 1741 DATA 1742 + END_STREAM 1743 {binary data} 1745 Trailing header fields are sent as a header block after both the 1746 request or response header block and all the DATA frames have been 1747 sent. The sequence of HEADERS frames that bears the trailers 1748 includes a terminal frame that has both END_HEADERS and END_STREAM 1749 flags set. 1751 HTTP/1.1 200 OK HEADERS 1752 Content-Type: image/jpeg ===> - END_STREAM 1753 Content-Length: 123 + END_HEADERS 1754 TE: trailers :status = 200 1755 123 content-type = image/jpeg 1756 {binary data} content-length = 123 1757 0 1758 Foo: bar DATA 1759 - END_STREAM 1760 {binary data} 1762 HEADERS 1763 + END_STREAM 1764 + END_HEADERS 1765 foo: bar 1767 8.1.2. Request Header Fields 1769 The definitions of the request header fields are largely unchanged 1770 relative to HTTP/1.1, with a few notable exceptions: 1772 o The HTTP/1.1 request-line has been split into two separate header 1773 fields named :method and :path, whose values specify the HTTP 1774 method for the request and the request-target, respectively. The 1775 HTTP-version component of the request-line is removed entirely 1776 from the headers. 1778 o The host and optional port portions of the request URI (see 1779 [RFC3986], Section 3.2), are specified using the new :host header 1780 field. [[anchor13: Ed. Note: it needs to be clarified whether or 1781 not this replaces the existing HTTP/1.1 Host header.]] 1783 o A new :scheme header field has been added to specify the scheme 1784 portion of the request-target (e.g. "https") 1786 o All header field names MUST be lowercased, and the definitions of 1787 all header field names defined by HTTP/1.1 are updated to be all 1788 lowercase. 1790 o The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer- 1791 Encoding header fields are no longer valid and MUST NOT be sent. 1792 [[anchor14: Ed. Note: And "TE" I presume?]] 1794 All HTTP Requests MUST include the ":method", ":path", ":host", and 1795 ":scheme" header fields. 1797 Header fields whose names begin with ":" (whether defined in this 1798 document or future extensions to this document) MUST appear before 1799 any other header fields. [[anchor15: Ed. Note: This requirement is 1800 currently pending review. Consider it "on hold" for the moment.]] 1802 All HTTP Requests that include a body SHOULD include the "content- 1803 length" header field. If a server receives a request where the sum 1804 of the DATA frame payload lengths does not equal the value of the 1805 "content-length" header field, the server MUST return a 400 (Bad 1806 Request) error. 1808 If a client omits a mandatory header field from the request, the 1809 server MUST reply with a HTTP 400 Bad Request reply. 1811 8.1.3. Response Header Fields 1813 The definitions of the response header fields are largely unchanged 1814 relative to HTTP/1.1, with a few notable exceptions: 1816 o The response status line has been reduced to a single ":status" 1817 header field whose value specifies only the numeric response 1818 status code. The status text component of the HTTP/1.1 response 1819 has been dropped entirely. 1821 o The response MUST contain exactly one :status header field with 1822 exactly one response status value. If the client receives an HTTP 1823 response that does not include the :status field, or provides 1824 multiple response status code values, it MUST respond with a 1825 stream error (Section 5.4.2) of type PROTOCOL_ERROR. 1827 o All header field names MUST be lowercased, and the definitions of 1828 all header field names defined by HTTP/1.1 are updated to be all 1829 lowercase. 1831 o The Connection, Keep-Alive, Proxy-Connection, and Transfer- 1832 Encoding header fields are not valid and MUST NOT be sent. 1834 Header fields whose names begin with ":" (whether defined in this 1835 document or future extensions to this document) MUST appear before 1836 any other header fields. [[anchor16: Ed. Note: This requirement is 1837 currently pending review. Consider it "on hold" for the moment.]] 1839 8.1.4. GZip Content-Encoding 1841 Clients MUST support gzip compression for HTTP response bodies. 1842 Regardless of the value of the accept-encoding header field, a server 1843 MAY send responses with gzip or deflate encoding. A compressed 1844 response MUST still bear an appropriate content-encoding header 1845 field. 1847 8.1.5. Request Reliability Mechanisms in HTTP/2.0 1849 In HTTP/1.1, an HTTP client is unable to retry a non-idempotent 1850 request when an error occurs, because there is no means to determine 1851 the nature of the error. It is possible that some server processing 1852 occurred prior to the error, which could result in undesirable 1853 effects if the request were reattempted. 1855 HTTP/2.0 provides two mechanisms for providing a guarantee to a 1856 client that a request has not been processed: 1858 o The GOAWAY frame indicates the highest stream number that might 1859 have been processed. Requests on streams with higher numbers are 1860 therefore guaranteed to be safe to retry. 1862 o The REFUSED_STREAM error code can be included in a RST_STREAM 1863 frame to indicate that the stream is being closed prior to any 1864 processing having occurred. Any request that was sent on the 1865 reset stream can be safely retried. 1867 In both cases, clients MAY automatically retry all requests, 1868 including those with non-idempotent methods. 1870 A server MUST NOT indicate that a stream has not been processed 1871 unless it can guarantee that fact. If frames that are on a stream 1872 are passed to the application layer for any stream, then 1873 REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame 1874 MUST include a stream identifier that is greater than or equal to the 1875 given stream identifier. 1877 In addition to these mechanisms, the PING frame provides a way for a 1878 client to easily test a connection. Connections that remain idle can 1879 become broken as some middleboxes (for instance, network address 1880 translators, or load balancers) silently discard connection bindings. 1881 The PING frame allows a client to safely test whether a connection is 1882 still active without sending a request. 1884 8.2. Server Push 1886 HTTP/2.0 enables a server to pre-emptively send (or "push") multiple 1887 associated resources to a client in response to a single request. 1888 This feature becomes particularly helpful when the server knows the 1889 client will need to have those resources available in order to fully 1890 process the originally requested resource. 1892 Pushing additional resources is optional, and is negotiated only 1893 between individual endpoints. For instance, an intermediary could 1894 receive pushed resources from the server but is not required to 1895 forward those on to the client. How to make use of the pushed 1896 resources is up to that intermediary. Equally, the intermediary 1897 might choose to push additional resources to the client, without any 1898 action taken by the server. 1900 Server push is semantically equivalent to a server responding to a 1901 GET request for that resource. The PUSH_PROMISE frame, or frames, 1902 sent by the server includes a header block that contains the request 1903 headers that the server has assumed. 1905 Pushed resources are always associated with an explicit request from 1906 a client. The PUSH_PROMISE frames sent by the server are sent on the 1907 stream created for the original request. The PUSH_PROMSE frame 1908 includes a promised stream identifier, chosen from the stream 1909 identifiers available to the server (see Section 5.1.1). Any header 1910 fields that are not specified in the PUSH_PROMISE frames sent by the 1911 server are inherited from the original request sent by the client. 1913 The header fields in PUSH_PROMISE MUST include the ":scheme", ":host" 1914 and ":path" header fields that identify the resource that is being 1915 pushed. A PUSH_PROMISE always implies an HTTP method of GET. If a 1916 client receives a PUSH_PROMISE that does not include these header 1917 fields, or a value for the ":method" header field, it MUST respond 1918 with a stream error (Section 5.4.2) of type PROTOCOL_ERROR. 1920 After sending the PUSH_PROMISE frame, the server can begin delivering 1921 the pushed resource on a new, server-initiated stream that uses the 1922 promised stream identifier. This stream is already implicitly "half 1923 closed" to the client (Section 5.1). The server uses this stream to 1924 transmit an HTTP response, using the same sequence of frames as 1925 defined in Section 8.1. 1927 Once a client receives a PUSH_PROMISE frame and chooses to accept the 1928 pushed resource, the client SHOULD NOT issue any subsequent GET 1929 requests for the promised resource until after the promised stream 1930 has closed. 1932 The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to 1933 sending any HEADERS or DATA frames that reference the promised 1934 resources. This avoids a race where clients issue requests for 1935 resources prior to receiving any PUSH_PROMISE frames. 1937 For example, if the server receives a request for a document 1938 containing embedded links to multiple image files, and the server 1939 chooses to push those additional images to the client, sending push 1940 promises before the DATA frames that contain the image links ensure 1941 that the client is able to see the promises before discovering the 1942 resources. Likewise, if the server pushes resources referenced by 1943 the header block (for instance, in Link header fields), sending the 1944 push promises before sending the header block ensures that clients do 1945 not request those resources. 1947 PUSH_PROMISE frames MUST NOT be sent by the client. PUSH_PROMISE 1948 frames can be sent by the server on any stream that was opened by the 1949 client. They MUST be sent on a stream that is in either the "open" 1950 or "half closed (remote)" to the server. PUSH_PROMISE frames can be 1951 interspersed within the frames that comprise response, with the 1952 exception that they cannot be interspersed with HEADERS frames that 1953 comprise a single header block. 1955 A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit 1956 the number of resources that can be concurrently pushed by a server. 1957 Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables 1958 server push by preventing the server from creating the necessary 1959 streams. 1961 The request header fields provided in the PUSH_PROMISE frame SHOULD 1962 include enough information for a client to determine whether a cached 1963 representation of the resource is already available. If the client 1964 determines, for any reason, that it does not wish to receive the 1965 pushed resource from the server, or if the server takes too long to 1966 begin sending the promised resource, the client can send an 1967 RST_STREAM frame, using either the CANCEL or REFUSED_STREAM codes, 1968 and referencing the pushed stream's identifier. 1970 Clients receiving a pushed response MUST validate that the server is 1971 authorized to push the resource using the same-origin policy 1972 ([RFC6454], Section 3). For example, a HTTP/2.0 connection to 1973 "example.com" is generally [[anchor17: Ed: weaselly use of 1974 "generally", needs better definition]] not permitted to push a 1975 response for "www.example.org". 1977 9. Additional HTTP Requirements/Considerations 1979 TODO: SNI, gzip and deflate Content-Encoding, etc.. 1981 9.1. Frame Size Limits for HTTP 1983 Frames used for HTTP messages MUST NOT exceed 2^14-1 (16383) octets 1984 in length, not counting the 8 octet frame header. An endpoint MUST 1985 treat the receipt of a larger frame as a FRAME_TOO_LARGE error (see 1986 Section 4.2). 1988 9.2. Connection Management 1990 HTTP/2.0 connections are persistent. For best performance, it is 1991 expected clients will not close connections until it is determined 1992 that no further communication with a server is necessary (for 1993 example, when a user navigates away from a particular web page), or 1994 until the server closes the connection. 1996 Clients SHOULD NOT open more than one HTTP/2.0 connection to a given 1997 origin ([RFC6454]) concurrently. A client can create additional 1998 connections as replacements, either to replace connections that are 1999 near to exhausting the available stream identifiers (Section 5.1.1), 2000 or to replace connections that have encountered errors 2001 (Section 5.4.1). 2003 Servers are encouraged to maintain open connections for as long as 2004 possible, but are permitted to terminate idle connections if 2005 necessary. When either endpoint chooses to close the transport-level 2006 TCP connection, the terminating endpoint MUST first send a GOAWAY 2007 (Section 6.8) frame so that both endpoints can reliably determine 2008 whether previously sent frames have been processed and gracefully 2009 complete or terminate any necessary remaining tasks. 2011 10. Security Considerations 2013 10.1. Server Authority and Same-Origin 2015 This specification uses the same-origin policy ([RFC6454], Section 3) 2016 to determine whether an origin server is permitted to provide 2017 content. 2019 A server that is contacted using TLS is authenticated based on the 2020 certificate that it offers in the TLS handshake (see [RFC2818], 2021 Section 3). A server is considered authoritative for an "https" 2022 resource if it has been successfully authenticated for the domain 2023 part of the origin of the resource that it is providing. 2025 A server is considered authoritative for an "http" resource if the 2026 connection is established to a resolved IP address for the domain in 2027 the origin of the resource. 2029 A client MUST NOT use, in any way, resources provided by a server 2030 that is not authoritative for those resources. 2032 10.2. Cross-Protocol Attacks 2034 When using TLS, we believe that HTTP/2.0 introduces no new cross- 2035 protocol attacks. TLS encrypts the contents of all transmission 2036 (except the handshake itself), making it difficult for attackers to 2037 control the data which could be used in a cross-protocol attack. 2038 [[anchor23: Issue: This is no longer true]] 2040 10.3. Cacheability of Pushed Resources 2042 Pushed resources are responses without an explicit request; the 2043 request for a pushed resource is synthesized from the request that 2044 triggered the push, plus resource identification information provided 2045 by the server. Request header fields are necessary for HTTP cache 2046 control validations (such as the Vary header field) to work. For 2047 this reason, caches MUST inherit request header fields from the 2048 associated stream for the push. This includes the Cookie header 2049 field. 2051 Caching resources that are pushed is possible, based on the guidance 2052 provided by the origin server in the Cache-Control header field. 2053 However, this can cause issues if a single server hosts more than one 2054 tenant. For example, a server might offer multiple users each a 2055 small portion of its URI space. 2057 Where multiple tenants share space on the same server, that server 2058 MUST ensure that tenants are not able to push representations of 2059 resources that they do not have authority over. Failure to enforce 2060 this would allow a tenant to provide a representation that would be 2061 served out of cache, overriding the actual representation that the 2062 authoritative tenant provides. 2064 Pushed resources for which an origin server is not authoritative are 2065 never cached or used. 2067 11. Privacy Considerations 2069 HTTP/2.0 aims to keep connections open longer between clients and 2070 servers in order to reduce the latency when a user makes a request. 2071 The maintenance of these connections over time could be used to 2072 expose private information. For example, a user using a browser 2073 hours after the previous user stopped using that browser may be able 2074 to learn about what the previous user was doing. This is a problem 2075 with HTTP in its current form as well, however the short lived 2076 connections make it less of a risk. 2078 12. IANA Considerations 2080 This document establishes registries for frame types, error codes and 2081 settings. These new registries are entered in a new "Hypertext 2082 Transfer Protocol (HTTP) 2.0 Parameters" section. 2084 This document also registers the "HTTP2-Settings" header field for 2085 use in HTTP. 2087 12.1. Frame Type Registry 2089 This document establishes a registry for HTTP/2.0 frame types. The 2090 "HTTP/2.0 Frame Type" registry operates under the "IETF Review" 2091 policy [RFC5226]. 2093 Frame types are an 8-bit value. When reviewing new frame type 2094 registrations, special attention is advised for any frame type- 2095 specific flags that are defined. Frame flags can interact with 2096 existing flags and could prevent the creation of globally applicable 2097 flags. 2099 Initial values for the "HTTP/2.0 Frame Type" registry are shown in 2100 Table 1. 2102 +-----------+---------------+---------------------------------------+ 2103 | Frame | Name | Flags | 2104 | Type | | | 2105 +-----------+---------------+---------------------------------------+ 2106 | 0 | DATA | END_STREAM(1) | 2107 | 1 | HEADERS | END_STREAM(1), END_HEADERS(4), | 2108 | | | PRIORITY(8) | 2109 | 2 | PRIORITY | - | 2110 | 3 | RST_STREAM | - | 2111 | 4 | SETTINGS | - | 2112 | 5 | PUSH_PROMISE | END_PUSH_PROMISE(1) | 2113 | 6 | PING | PONG(1) | 2114 | 7 | GOAWAY | - | 2115 | 9 | WINDOW_UPDATE | END_FLOW_CONTROL(1) | 2116 +-----------+---------------+---------------------------------------+ 2118 Table 1 2120 12.2. Error Code Registry 2122 This document establishes a registry for HTTP/2.0 error codes. The 2123 "HTTP/2.0 Error Code" registry manages a 32-bit space. The "HTTP/2.0 2124 Error Code" registry operates under the "Expert Review" policy 2125 [RFC5226]. 2127 Registrations for error codes are required to include a description 2128 of the error code. An expert reviewer is advised to examine new 2129 registrations for possible duplication with existing error codes. 2130 Use of existing registrations is to be encouraged, but not mandated. 2132 New registrations are advised to provide the following information: 2134 Error Code: The 32-bit error code value. 2136 Name: A name for the error code. Specifying an error code name is 2137 optional. 2139 Description: A description of the conditions where the error code is 2140 applicable. 2142 Specification: An optional reference for a specification that 2143 defines the error code. 2145 An initial set of error code registrations can be found in Section 7. 2147 12.3. Settings Registry 2149 This document establishes a registry for HTTP/2.0 settings. The 2150 "HTTP/2.0 Settings" registry manages a 24-bit space. The "HTTP/2.0 2151 Settings" registry operates under the "Expert Review" policy 2152 [RFC5226]. 2154 Registrations for settings are required to include a description of 2155 the setting. An expert reviewer is advised to examine new 2156 registrations for possible duplication with existing settings. Use 2157 of existing registrations is to be encouraged, but not mandated. 2159 New registrations are advised to provide the following information: 2161 Setting: The 24-bit setting value. 2163 Name: A name for the setting. Specifying a name is optional. 2165 Flags: Any setting-specific flags that apply, including their value 2166 and semantics. 2168 Description: A description of the setting. This might include the 2169 range of values, any applicable units and how to act upon a value 2170 when it is provided. 2172 Specification: An optional reference for a specification that 2173 defines the setting. 2175 An initial set of settings registrations can be found in 2176 Section 6.5.2. 2178 12.4. HTTP2-Settings Header Field Registration 2180 This section registers the "HTTP2-Settings" header field in the 2181 Permanent Message Header Field Registry [BCP90]. 2183 Header field name: HTTP2-Settings 2185 Applicable protocol: http 2187 Status: standard 2189 Author/Change controller: IETF 2191 Specification document(s): RFC XXXX (this document) 2192 Related information: This header field is only used by an HTTP/2.0 2193 client for Upgrade-based negotiation. 2195 13. Acknowledgements 2197 This document includes substantial input from the following 2198 individuals: 2200 o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa 2201 Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam 2202 Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, 2203 Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors). 2205 o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism) 2207 o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, 2208 Jitu Padhye, Roberto Peon, Rob Trace (Flow control) 2210 o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner 2211 (Substantial editorial contributions) 2213 14. References 2215 14.1. Normative References 2217 [COMPRESSION] Ruellan, H. and R. Peon, "HTTP Header Compression", 2218 draft-ietf-httpbis-header-compression-00 (work in 2219 progress), June 2013. 2221 [HTTP-p1] Fielding, R. and J. Reschke, "Hypertext Transfer 2222 Protocol (HTTP/1.1): Message Syntax and Routing", 2223 draft-ietf-httpbis-p1-messaging-22 (work in progress), 2224 February 2013. 2226 [HTTP-p2] Fielding, R. and J. Reschke, "Hypertext Transfer 2227 Protocol (HTTP/1.1): Semantics and Content", 2228 draft-ietf-httpbis-p2-semantics-22 (work in progress), 2229 February 2013. 2231 [HTTP-p4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 2232 Transfer Protocol (HTTP/1.1): Conditional Requests", 2233 draft-ietf-httpbis-p4-conditional-22 (work in 2234 progress), February 2013. 2236 [HTTP-p5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, 2237 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range 2238 Requests", draft-ietf-httpbis-p5-range-22 (work in 2239 progress), February 2013. 2241 [HTTP-p6] Fielding, R., Ed., Nottingham, M., Ed., and J. 2242 Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): 2243 Caching", draft-ietf-httpbis-p6-cache-22 (work in 2244 progress), February 2013. 2246 [HTTP-p7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 2247 Transfer Protocol (HTTP/1.1): Authentication", 2248 draft-ietf-httpbis-p7-auth-22 (work in progress), 2249 February 2013. 2251 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2252 RFC 793, September 1981. 2254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2255 Requirement Levels", BCP 14, RFC 2119, March 1997. 2257 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2259 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 2260 "Uniform Resource Identifier (URI): Generic Syntax", 2261 STD 66, RFC 3986, January 2005. 2263 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2264 Encodings", RFC 4648, October 2006. 2266 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2267 an IANA Considerations Section in RFCs", BCP 26, 2268 RFC 5226, May 2008. 2270 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2271 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2273 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2274 Security (TLS) Protocol Version 1.2", RFC 5246, 2275 August 2008. 2277 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2278 December 2011. 2280 [TLSALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2281 "Transport Layer Security (TLS) Application Layer 2282 Protocol Negotiation Extension", 2283 draft-ietf-tls-applayerprotoneg-01 (work in progress), 2284 April 2013. 2286 14.2. Informative References 2288 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2289 Procedures for Message Header Fields", BCP 90, 2290 RFC 3864, September 2004. 2292 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP 2293 Extensions for High Performance", RFC 1323, May 1992. 2295 [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. 2296 Jackson, "Talking to Yourself for Fun and Profit", 2297 2011, . 2299 Appendix A. Change Log (to be removed by RFC Editor before publication) 2301 A.1. Since draft-ietf-httpbis-http2-03 2303 Committed major restructuring atrocities. 2305 Added reference to first header compression draft. 2307 Added more formal description of frame lifecycle. 2309 Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA. 2311 Removed HEADERS+PRIORITY, added optional priority to HEADERS frame. 2313 Added PRIORITY frame. 2315 A.2. Since draft-ietf-httpbis-http2-02 2317 Added continuations to frames carrying header blocks. 2319 Replaced use of "session" with "connection" to avoid confusion with 2320 other HTTP stateful concepts, like cookies. 2322 Removed "message". 2324 Switched to TLS ALPN from NPN. 2326 Editorial changes. 2328 A.3. Since draft-ietf-httpbis-http2-01 2330 Added IANA considerations section for frame types, error codes and 2331 settings. 2333 Removed data frame compression. 2335 Added PUSH_PROMISE. 2337 Added globally applicable flags to framing. 2339 Removed zlib-based header compression mechanism. 2341 Updated references. 2343 Clarified stream identifier reuse. 2345 Removed CREDENTIALS frame and associated mechanisms. 2347 Added advice against naive implementation of flow control. 2349 Added session header section. 2351 Restructured frame header. Removed distinction between data and 2352 control frames. 2354 Altered flow control properties to include session-level limits. 2356 Added note on cacheability of pushed resources and multiple tenant 2357 servers. 2359 Changed protocol label form based on discussions. 2361 A.4. Since draft-ietf-httpbis-http2-00 2363 Changed title throughout. 2365 Removed section on Incompatibilities with SPDY draft#2. 2367 Changed INTERNAL_ERROR on GOAWAY to have a value of 2 . 2370 Replaced abstract and introduction. 2372 Added section on starting HTTP/2.0, including upgrade mechanism. 2374 Removed unused references. 2376 Added flow control principles (Section 5.2.1) based on . 2379 A.5. Since draft-mbelshe-httpbis-spdy-00 2381 Adopted as base for draft-ietf-httpbis-http2. 2383 Updated authors/editors list. 2385 Added status note. 2387 Authors' Addresses 2389 Mike Belshe 2390 Twist 2392 EMail: mbelshe@chromium.org 2394 Roberto Peon 2395 Google, Inc 2397 EMail: fenix@google.com 2399 Martin Thomson (editor) 2400 Microsoft 2401 3210 Porter Drive 2402 Palo Alto 94304 2403 US 2405 EMail: martin.thomson@skype.net 2407 Alexey Melnikov (editor) 2408 Isode Ltd 2409 5 Castle Business Village 2410 36 Station Road 2411 Hampton, Middlesex TW12 2BX 2412 UK 2414 EMail: Alexey.Melnikov@isode.com