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