draft-ietf-httpbis-http2-11.txt   draft-ietf-httpbis-http2-12.txt 
HTTPbis Working Group M. Belshe HTTPbis Working Group M. Belshe
Internet-Draft Twist Internet-Draft Twist
Intended status: Standards Track R. Peon Intended status: Standards Track R. Peon
Expires: October 5, 2014 Google, Inc Expires: October 25, 2014 Google, Inc
M. Thomson, Ed. M. Thomson, Ed.
Mozilla Mozilla
April 3, 2014 April 23, 2014
Hypertext Transfer Protocol version 2 Hypertext Transfer Protocol version 2
draft-ietf-httpbis-http2-11 draft-ietf-httpbis-http2-12
Abstract Abstract
This specification describes an optimized expression of the syntax of This specification describes an optimized expression of the syntax of
the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more
efficient use of network resources and a reduced perception of efficient use of network resources and a reduced perception of
latency by introducing header field compression and allowing multiple latency by introducing header field compression and allowing multiple
concurrent messages on the same connection. It also introduces concurrent messages on the same connection. It also introduces
unsolicited push of representations from servers to clients. unsolicited push of representations from servers to clients.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at Working Group information can be found at
<http://tools.ietf.org/wg/httpbis/>; that specific to HTTP/2 are at <http://tools.ietf.org/wg/httpbis/>; that specific to HTTP/2 are at
<http://http2.github.io/>. <http://http2.github.io/>.
The changes in this draft are summarized in Appendix A. The changes in this draft are summarized in Appendix A.
This version of HTTP/2, identified as "h2-12" or "h2c-12", is
intended for implementation. An interoperability event will be
conducted 2014-06-05, see <https://github.com/http2/wg_materials/
blob/master/interim-14-06/agenda.md>.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 5, 2014. This Internet-Draft will expire on October 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 3, line 6
4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Header Compression and Decompression . . . . . . . . . . . 14 4.3. Header Compression and Decompression . . . . . . . . . . . 14
5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 15 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 15
5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 20 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 20
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 20 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 20
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 21 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 21
5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22
5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 23 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. Priority Groups and Weighting . . . . . . . . . . . . 23 5.3.1. Stream Dependencies . . . . . . . . . . . . . . . . . 23
5.3.2. Stream Dependencies . . . . . . . . . . . . . . . . . 24 5.3.2. Dependency Weighting . . . . . . . . . . . . . . . . . 24
5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . . 25 5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . . 24
5.3.4. Prioritization State Management . . . . . . . . . . . 25 5.3.4. Prioritization State Management . . . . . . . . . . . 25
5.3.5. Default Priorities . . . . . . . . . . . . . . . . . . 26 5.3.5. Default Priorities . . . . . . . . . . . . . . . . . . 26
5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 26 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 26
5.4.1. Connection Error Handling . . . . . . . . . . . . . . 27 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 27
5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 27 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 27
5.4.3. Connection Termination . . . . . . . . . . . . . . . . 28 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 28
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 28 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 28
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 34 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 36 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 35
6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 36 6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 35
6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 37 6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 37
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 37 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 37
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 43 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 42
6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 44 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 43
6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 45 6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 44
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 46 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 45
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 46 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 46
6.11. ALTSVC . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.11. ALTSVC . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.12. BLOCKED . . . . . . . . . . . . . . . . . . . . . . . . . 49
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49
8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 50 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 51
8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 51 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 51
8.1.1. Informational Responses . . . . . . . . . . . . . . . 52 8.1.1. Informational Responses . . . . . . . . . . . . . . . 52
8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 53 8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 53
8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 55 8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 55
8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . . 59 8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . . 59
8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 60 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 60
8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 60 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 61
8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 61 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 62
8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 62 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 63
9. Additional HTTP Requirements/Considerations . . . . . . . . . 63 9. Additional HTTP Requirements/Considerations . . . . . . . . . 64
9.1. Connection Management . . . . . . . . . . . . . . . . . . 63 9.1. Connection Management . . . . . . . . . . . . . . . . . . 64
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 64 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 65
9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 65 9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 65
10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 66
10.1. Server Authority . . . . . . . . . . . . . . . . . . . . . 65 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . . 66
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 66 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 66
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 66 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 67
10.4. Cacheability of Pushed Responses . . . . . . . . . . . . . 67 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . . 67
10.5. Denial of Service Considerations . . . . . . . . . . . . . 67 10.5. Denial of Service Considerations . . . . . . . . . . . . . 67
10.6. Use of Compression . . . . . . . . . . . . . . . . . . . . 68 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . . 68
10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . . 68 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . . 69
10.8. Privacy Considerations . . . . . . . . . . . . . . . . . . 69 10.8. Privacy Considerations . . . . . . . . . . . . . . . . . . 70
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 11.1. Registration of HTTP/2 Identification Strings . . . . . . 70
11.1. Registration of HTTP/2 Identification String . . . . . . . 70 11.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 71
11.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 70
11.3. HTTP2-Settings Header Field Registration . . . . . . . . . 71 11.3. HTTP2-Settings Header Field Registration . . . . . . . . . 71
11.4. PRI Method Registration . . . . . . . . . . . . . . . . . 71 11.4. PRI Method Registration . . . . . . . . . . . . . . . . . 72
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 71 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
13.1. Normative References . . . . . . . . . . . . . . . . . . . 72 13.1. Normative References . . . . . . . . . . . . . . . . . . . 73
13.2. Informative References . . . . . . . . . . . . . . . . . . 74 13.2. Informative References . . . . . . . . . . . . . . . . . . 74
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 74 publication) . . . . . . . . . . . . . . . . . . . . 75
A.1. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 74 A.1. Since draft-ietf-httpbis-http2-11 . . . . . . . . . . . . 75
A.2. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 75 A.2. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 75
A.3. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 75 A.3. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 76
A.4. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 75 A.4. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 76
A.5. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 75 A.5. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 76
A.6. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 76 A.6. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 76
A.7. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 76 A.7. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 77
A.8. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 76 A.8. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 77
A.9. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 77 A.9. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 77
A.10. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 77 A.10. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 78
A.11. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 78 A.11. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 78
A.12. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 78 A.12. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 79
A.13. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 79
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a wildly successful The Hypertext Transfer Protocol (HTTP) is a wildly successful
protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section
3) was designed to be implemented with the tools at hand in the 3) was designed to be implemented with the tools at hand in the
1990s, not modern Web application performance. As such it has 1990s, not modern Web application performance. As such it has
several characteristics that have a negative overall effect on several characteristics that have a negative overall effect on
application performance today. application performance today.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
to ensure that only data that can be used by a receiver is to ensure that only data that can be used by a receiver is
transmitted. Prioritization (Section 5.3) ensures that limited transmitted. Prioritization (Section 5.3) ensures that limited
resources can be directed to the most important requests first. resources can be directed to the most important requests first.
HTTP/2 adds a new interaction mode, whereby a server can push HTTP/2 adds a new interaction mode, whereby a server can push
responses to a client (Section 8.2). Server push allows a server to responses to a client (Section 8.2). Server push allows a server to
speculatively send a client data that the server anticipates the speculatively send a client data that the server anticipates the
client will need, trading off some network usage against a potential client will need, trading off some network usage against a potential
latency gain. The server does this by synthesizing a request, which latency gain. The server does this by synthesizing a request, which
it sends as a PUSH_PROMISE frame. The server is then able to send a it sends as a PUSH_PROMISE frame. The server is then able to send a
response to the synthetic request on an separate stream. response to the synthetic request on a separate stream.
Frames that contain HTTP header fields are compressed (Section 4.3). Frames that contain HTTP header fields are compressed (Section 4.3).
HTTP requests can be highly redundant, so compression can reduce the HTTP requests can be highly redundant, so compression can reduce the
size of requests and responses significantly. size of requests and responses significantly.
HTTP/2 also supports HTTP Alternative Services (see [ALT-SVC]) using HTTP/2 also supports HTTP Alternative Services (see [ALT-SVC]) using
the ALTSVC frame type (Section 6.11), to allow servers more control the ALTSVC frame type (Section 6.11), to allow servers more control
over traffic to them. over traffic to them.
2.1. Document Organization 2.1. Document Organization
skipping to change at page 10, line 19 skipping to change at page 10, line 19
... ...
A server that supports HTTP/2 can accept the upgrade with a 101 A server that supports HTTP/2 can accept the upgrade with a 101
(Switching Protocols) response. After the empty line that terminates (Switching Protocols) response. After the empty line that terminates
the 101 response, the server can begin sending HTTP/2 frames. These the 101 response, the server can begin sending HTTP/2 frames. These
frames MUST include a response to the request that initiated the frames MUST include a response to the request that initiated the
Upgrade. Upgrade.
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: Upgrade Connection: Upgrade
Upgrade: h2 Upgrade: h2c
[ HTTP/2 connection ... [ HTTP/2 connection ...
The first HTTP/2 frame sent by the server is a SETTINGS frame The first HTTP/2 frame sent by the server is a SETTINGS frame
(Section 6.5). Upon receiving the 101 response, the client sends a (Section 6.5). Upon receiving the 101 response, the client sends a
connection preface (Section 3.5), which includes a SETTINGS frame. connection preface (Section 3.5), which includes a SETTINGS frame.
The HTTP/1.1 request that is sent prior to upgrade is assigned stream The HTTP/1.1 request that is sent prior to upgrade is assigned stream
identifier 1 and is assigned default priority values (Section 5.3.5). identifier 1 and is assigned default priority values (Section 5.3.5).
Stream 1 is implicitly half closed from the client toward the server, Stream 1 is implicitly half closed from the client toward the server,
skipping to change at page 23, line 20 skipping to change at page 23, line 20
A client can assign a priority for a new stream by including A client can assign a priority for a new stream by including
prioritization information in the HEADERS frame (Section 6.2) that prioritization information in the HEADERS frame (Section 6.2) that
opens the stream. For an existing stream, the PRIORITY frame opens the stream. For an existing stream, the PRIORITY frame
(Section 6.3) can be used to change the priority. (Section 6.3) can be used to change the priority.
The purpose of prioritization is to allow an endpoint to express how The purpose of prioritization is to allow an endpoint to express how
it would prefer its peer allocate resources when managing concurrent it would prefer its peer allocate resources when managing concurrent
streams. Most importantly, priority can be used to select streams streams. Most importantly, priority can be used to select streams
for transmitting frames when there is limited capacity for sending. for transmitting frames when there is limited capacity for sending.
Each stream is prioritized into a group. Each group is identified Streams can be prioritized by marking them as dependent on the
using an identifier that is selected by the client. Each group is completion of other streams (Section 5.3.1). Each dependency is
assigned a relative weight, a number that is used to determine the assigned a relative weight, a number that is used to determine the
relative proportion of available resources that are assigned to that relative proportion of available resources that are assigned to
group. streams dependent on the same stream.
Within a priority group, streams can also be marked as being
dependent on the completion of other streams.
Explicitly setting the priority for a stream is input to a Explicitly setting the priority for a stream is input to a
prioritization process. It does not guarantee any particular prioritization process. It does not guarantee any particular
processing or transmission order for the stream relative to any other processing or transmission order for the stream relative to any other
stream. An endpoint cannot force a peer to process concurrent stream. An endpoint cannot force a peer to process concurrent
streams in a particular order using priority. Expressing priority is streams in a particular order using priority. Expressing priority is
therefore only ever a suggestion. therefore only ever a suggestion.
Prioritization information can be specified explicitly for streams as Prioritization information can be specified explicitly for streams as
they are created using the HEADERS frame, or changed using the they are created using the HEADERS frame, or changed using the
PRIORITY frame. Providing prioritization information is optional, so PRIORITY frame. Providing prioritization information is optional, so
default values are used if no explicit indicator is provided default values are used if no explicit indicator is provided
(Section 5.3.5). (Section 5.3.5).
Explicit prioritization information can be provided for a stream to 5.3.1. Stream Dependencies
either allocate the stream to a priority group (Section 5.3.1), or to
create a dependency on another stream (Section 5.3.2).
5.3.1. Priority Groups and Weighting
All streams are assigned a priority group. Each priority group is
allocated a 31-bit identifier and an integer weight between 1 to 256
(inclusive).
Specifying a priority group and weight for a stream causes the stream
to be assigned to the identified priority group and for the weight
for the group to be changed to the new value.
Resources are divided proportionally between priority groups based on
their weight. For example, a priority group with weight 4 ideally
receives one third of the resources allocated to a stream with weight
12.
5.3.2. Stream Dependencies
Each stream can be given an explicit dependency on another stream. Each stream can be given an explicit dependency on another stream.
Including a dependency expresses a preference to allocate resources Including a dependency expresses a preference to allocate resources
to the identified stream rather than to the dependent stream. to the identified stream rather than to the dependent stream.
A stream that is dependent on another stream becomes part of the A stream that is not dependent on any other stream can given a stream
priority group of the stream it depends on. It belongs to the same dependency of 0x0.
dependency tree as the stream it depends on.
A stream that is assigned directly to a priority group is not
dependent on any other stream. It is the root of a dependency tree
inside its priority group.
When assigning a dependency on another stream, by default, the stream When assigning a dependency on another stream, by default, the stream
is added as a new dependency of the stream it depends on. For is added as a new dependency of the stream it depends on. For
example, if streams B and C are dependent on stream A, and if stream example, if streams B and C are dependent on stream A, and if stream
D is created with a dependency on stream A, this results in a D is created with a dependency on stream A, this results in a
dependency order of A followed by B, C, and D. dependency order of A followed by B, C, and D.
A A A A
/ \ ==> /|\ / \ ==> /|\
B C B D C B C B D C
Example of Default Dependency Creation Example of Default Dependency Creation
An exclusive flag allows for the insertion of a new level of An exclusive flag allows for the insertion of a new level of
dependencies. The exclusive flag causes the stream to become the dependencies. The exclusive flag causes the stream to become the
sole dependency of the stream it depends on, causing other sole dependency of the stream it depends on, causing other
dependencies to become dependencies of the stream. In the previous dependencies to become dependencies of the stream. In the previous
example, if stream D is created with an exclusive dependency on example, if stream D is created with an exclusive dependency on
stream A, this results in a dependency order of A followed by D stream A, this results in a dependency order of A followed by D
followed by B and C. followed by B and C.
A A
A | A |
/ \ ==> D / \ ==> D
B C / \ B C / \
B C B C
Example of Exclusive Dependency Creation Example of Exclusive Dependency Creation
Streams are ordered into several dependency trees within their Inside the dependency tree, a dependent stream SHOULD only be
priority group. Each dependency tree within a priority group SHOULD allocated resources if the streams that it depends on are either
be allocated the same amount of resources. closed, or it is not possible to make progress on them.
Inside a dependency tree, a dependent stream SHOULD only be allocated 5.3.2. Dependency Weighting
resources if the streams that it depends on are either closed, or it
is not possible to make progress on them.
Streams with the same dependencies SHOULD be allocated the same Each dependency is allocated an integer weight between 1 to 256
amount of resources. Thus, if streams B and C depend on stream A, (inclusive).
and if no progress can be made on A, streams B and C are given an
equal share of resources. Streams with the same dependencies SHOULD be allocated resources
proportionally based on their weight. Thus, if stream B depends on
stream A with weight 4, and C depends on stream A with weight 12, and
if no progress can be made on A, stream B ideally receives one third
of the resources allocated to stream C.
A stream MUST NOT depend on itself. An endpoint MAY either treat A stream MUST NOT depend on itself. An endpoint MAY either treat
this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR, or this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR, or
assign default priority values (Section 5.3.5) to the stream. assign default priority values (Section 5.3.5) to the stream.
5.3.3. Reprioritization 5.3.3. Reprioritization
Stream priorities are changed using the PRIORITY frame. Setting a Stream priorities are changed using the PRIORITY frame. Setting a
priority group and weight causes a stream to become part of the
identified group, and not dependent on any other stream. Setting a
dependency causes a stream to become dependent on the identified dependency causes a stream to become dependent on the identified
stream, which can cause the reprioritized stream to move to a new stream.
priority group.
All streams that are dependent on a reprioritized stream move with All streams that are dependent on a reprioritized stream move with
it. Setting a dependency with the exclusive flag for a reprioritized it. Setting a dependency with the exclusive flag for a reprioritized
stream moves all the dependencies of the stream it depends on to stream moves all the dependencies of the stream it depends on to
become dependencies of the reprioritized stream. become dependencies of the reprioritized stream.
If a stream is made dependent on one of its own dependencies, the
formerly dependent stream is first moved to be depedent on the
reprioritized streams previous dependency, retaining its weight.
For example, for an original dependency tree where B and C depend on
A, D and E depend on C, and F depends on D; if A is made dependent on
D, then D takes the place of A with A dependent on D and all other
dependency relationships staying the same.
0
A / \ D D
/ \ D A / \ OR |
B C ==> / / \ ==> F A ==> A
/ \ F B C / \ /|\
D E | B C B C F
| E | |
F E F
(intermediate) (non-exclusive) (exclusive)
Example of Dependency Reordering
5.3.4. Prioritization State Management 5.3.4. Prioritization State Management
When a stream is closed, its dependencies can be moved to become When a stream is removed from the dependency tree, its dependencies
dependent on the stream the closed stream depends on, if any, or to can be moved to become dependent on the stream the closed stream
become new dependency tree roots otherwise. depends on. The weights of new dependencies SHOULD be assigned by
distributing the weight of the dependency of the closed stream
proportionally based on the weights of its dependencies.
Streams that are removed from the dependency tree cause some
prioritization information to be lost. Resources are shared between
streams that depend on the same stream, which means that if a stream
in that set closes or becomes blocked, any spare capacity allocated
to a stream is distributed to the immediate neighbors of the stream.
However, if the common dependency is removed from the tree, those
streams share resources with streams at the next highest level. For
example, assume streams A and B share a dependency, and C and D both
depend on A. Prior to the removal of A, if stream A and D are unable
to proceed, then C receives all the resources dedicated to A. If A is
removed from the tree, the weight of A is divided equally between D
and E, which results in stream C receiving a reduced proportion of
resources (one third, rather than one half).
It is possible for a stream to become closed while prioritization It is possible for a stream to become closed while prioritization
information that creates a dependency on that stream is in transit. information that creates a dependency on that stream is in transit.
If a stream identified in a dependency has been closed and any If a stream identified in a dependency has been closed and any
associated priority information destroyed then the dependent stream associated priority information destroyed then the dependent stream
is instead assigned a default priority. This potentially creates is instead assigned a default priority. This potentially creates
suboptimal prioritization, since the stream can be given an effective suboptimal prioritization, since the stream can be given an effective
priority that is higher than expressed by a peer. priority that is higher than expressed by a peer.
To avoid this problem, endpoints SHOULD maintain prioritization state To avoid these problems, endpoints SHOULD maintain prioritization
for closed streams for a period after streams close. This could state for closed streams for a period after streams close.
create an large state burden for an endpoint, so this state MAY be
limited. The amount of additional state an endpoint maintains could
be dependent on load; under high load, prioritization state can be
discarded to limit resource commitments. In extreme cases, an
endpoint could even discard prioritization state for active or
reserved streams.
An endpoint SHOULD retain stream prioritization state for at least
one round trip, though maintaining state over longer periods reduces
the chance that default values have to be assigned to streams. An
endpoint MAY apply a fixed upper limit on the number of closed
streams for which prioritization state is tracked to limit state
exposure. If a fixed limit is applied, endpoints SHOULD maintain
state for at least as many streams as allowed by their setting for
SETTINGS_MAX_CONCURRENT_STREAMS.
An endpoint receiving a PRIORITY frame that changes the priority of a An endpoint SHOULD retain stream prioritization state for a period
closed stream SHOULD alter the weight of the priority group, or the after streams become closed. The longer state is retained, the lower
dependencies of the streams that depend on it, if it has retained the chance that streams are assigned incorrect or default priority
enough state to do so. values.
Priority group information is part of the priority state of a stream. This could create a large state burden for an endpoint, so this state
Priority groups that contain only closed streams can be assigned a MAY be limited. An endpoint MAY apply a fixed upper limit on the
weight of zero. number of closed streams for which prioritization state is tracked to
limit state exposure. The amount of additional state an endpoint
maintains could be dependent on load; under high load, prioritization
state can be discarded to limit resource commitments. In extreme
cases, an endpoint could even discard prioritization state for active
or reserved streams. If a fixed limit is applied, endpoints SHOULD
maintain state for at least as many streams as allowed by their
setting for SETTINGS_MAX_CONCURRENT_STREAMS.
The number of priority groups cannot exceed the number of non-closed An endpoint receiving a PRIORITY frame that changes the priority of a
streams. This includes streams in the "reserved" state. Priority closed stream SHOULD alter the dependencies of the streams that
state size for peer-initiated streams is limited by the value of depend on it, if it has retained enough state to do so.
SETTINGS_MAX_CONCURRENT_STREAMS. Reserved streams do not count
toward the concurrent stream limit of either peer, but only the
endpoint that creates the reservation needs to maintain priority
information. Thus, the total amount of priority state for non-closed
streams can be limited by an endpoint.
5.3.5. Default Priorities 5.3.5. Default Priorities
Providing priority information is optional. Streams are assigned to Providing priority information is optional. Streams are assigned a
a priority group with an identifier equal to the stream identifier dependency on stream 0x0. Pushed streams (Section 8.2) initially
and a weight of 16. depend on their associated stream. In both cases, streams are
assigned a default weight of 16.
Pushed streams (Section 8.2) initially depend on their associated
stream.
5.4. Error Handling 5.4. Error Handling
HTTP/2 framing permits two classes of error: HTTP/2 framing permits two classes of error:
o An error condition that renders the entire connection unusable is o An error condition that renders the entire connection unusable is
a connection error. a connection error.
o An error in an individual stream is a stream error. o An error in an individual stream is a stream error.
skipping to change at page 29, line 37 skipping to change at page 29, line 30
END_STREAM (0x1): Bit 1 being set indicates that this frame is the END_STREAM (0x1): Bit 1 being set indicates that this frame is the
last that the endpoint will send for the identified stream. last that the endpoint will send for the identified stream.
Setting this flag causes the stream to enter one of the "half Setting this flag causes the stream to enter one of the "half
closed" states or the "closed" state (Section 5.1). closed" states or the "closed" state (Section 5.1).
END_SEGMENT (0x2): Bit 2 being set indicates that this frame is the END_SEGMENT (0x2): Bit 2 being set indicates that this frame is the
last for the current segment. Intermediaries MUST NOT coalesce last for the current segment. Intermediaries MUST NOT coalesce
frames across a segment boundary and MUST preserve segment frames across a segment boundary and MUST preserve segment
boundaries when forwarding frames. boundaries when forwarding frames.
PAD_LOW (0x08): Bit 4 being set indicates that the Pad Low field is PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is
present. present.
PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field
is present. This bit MUST NOT be set unless the PAD_LOW flag is is present. This bit MUST NOT be set unless the PAD_LOW flag is
also set. Endpoints that receive a frame with PAD_HIGH set and also set. Endpoints that receive a frame with PAD_HIGH set and
PAD_LOW cleared MUST treat this as a connection error PAD_LOW cleared MUST treat this as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
COMPRESSED (0x20): Bit 6 being set indicates that the data in the
frame has been compressed with GZIP compression ([GZIP]).
DATA frames MUST be associated with a stream. If a DATA frame is DATA frames MUST be associated with a stream. If a DATA frame is
received whose stream identifier field is 0x0, the recipient MUST received whose stream identifier field is 0x0, the recipient MUST
respond with a connection error (Section 5.4.1) of type respond with a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
Data frames are optionally compressed using GZip compression [GZIP].
Each frame is individually compressed; the state of the compressor is
reset for each frame.
An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set
unless the SETTINGS_COMPRESS_DATA setting is enabled, that is, set to
1. An endpoint that has not enabled DATA frame compression MUST
treat the receipt of a DATA frame with the COMPRESSED flag set as a
connection error (Section 5.4.1) of type PROTOCOL_ERROR.
DATA frames are subject to flow control and can only be sent when a DATA frames are subject to flow control and can only be sent when a
stream is in the "open" or "half closed (remote)" states. Padding is stream is in the "open" or "half closed (remote)" states. Padding is
included in flow control. If a DATA frame is received whose stream included in flow control. If a DATA frame is received whose stream
is not in "open" or "half closed (local)" state, the recipient MUST is not in "open" or "half closed (local)" state, the recipient MUST
respond with a stream error (Section 5.4.2) of type STREAM_CLOSED. respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.
The total number of padding octets is determined by multiplying the The total number of padding octets is determined by multiplying the
value of the Pad High field by 256 and adding the value of the Pad value of the Pad High field by 256 and adding the value of the Pad
Low field. Both Pad High and Pad Low fields assume a value of zero Low field. Both Pad High and Pad Low fields assume a value of zero
if absent. If the length of the padding is greater than the length if absent. If the length of the padding is greater than the length
skipping to change at page 30, line 32 skipping to change at page 30, line 38
The HEADERS frame (type=0x1) carries name-value pairs. It is used to The HEADERS frame (type=0x1) carries name-value pairs. It is used to
open a stream (Section 5.1). HEADERS frames can be sent on a stream open a stream (Section 5.1). HEADERS frames can be sent on a stream
in the "open" or "half closed (remote)" states. in the "open" or "half closed (remote)" states.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad High? (8) | Pad Low? (8) | | Pad High? (8) | Pad Low? (8) |
+-+-------------+---------------+-------------------------------+ +-+-------------+---------------+-------------------------------+
|R| Priority Group Identifier? (31) | |E| Stream Dependency? (31) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
| Weight? (8) | | Weight? (8) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
|E| Stream Dependency? (31) |
+-+-------------------------------------------------------------+
| Header Block Fragment (*) ... | Header Block Fragment (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Padding (*) ... | Padding (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
HEADERS Frame Payload HEADERS Frame Payload
The HEADERS frame payload has the following fields: The HEADERS frame payload has the following fields:
Pad High: Padding size high bits. This field is only present if the Pad High: Padding size high bits. This field is only present if the
PAD_HIGH flag is set. PAD_HIGH flag is set.
Pad Low: Padding size low bits. This field is only present if the Pad Low: Padding size low bits. This field is only present if the
PAD_LOW flag is set. PAD_LOW flag is set.
R: A single reserved bit. This field is optional and is only present
if the PRIORITY_GROUP flag is set.
Priority Group Identifier: A 31-bit identifier for a priority group,
see Section 5.3. This field is optional and is only present if
the PRIORITY_GROUP flag is set.
Weight: An 8-bit weight for the identified priority group, see
Section 5.3. This field is optional and is only present if the
PRIORITY_GROUP flag is set.
E: A single bit flag indicates that the stream dependency is E: A single bit flag indicates that the stream dependency is
exclusive, see Section 5.3. This field is optional and is only exclusive, see Section 5.3. This field is optional and is only
present if the PRIORITY_DEPENDENCY flag is set. present if the PRIORITY flag is set.
Stream Dependency: A 31-bit stream identifier for the stream that Stream Dependency: A 31-bit stream identifier for the stream that
this stream depends on, see Section 5.3. This field is optional this stream depends on, see Section 5.3. This field is optional
and is only present if the PRIORITY_DEPENDENCY flag is set. and is only present if the PRIORITY flag is set.
Weight: An 8-bit weight for the stream, see Section 5.3. Add one to
the value to obtain a weight between 1 and 256. This field is
optional and is only present if the PRIORITY flag is set.
Header Block Fragment: A header block fragment (Section 4.3). Header Block Fragment: A header block fragment (Section 4.3).
Padding: Padding octets. Padding: Padding octets.
The HEADERS frame defines the following flags: The HEADERS frame defines the following flags:
END_STREAM (0x1): Bit 1 being set indicates that the header block END_STREAM (0x1): Bit 1 being set indicates that the header block
(Section 4.3) is the last that the endpoint will send for the (Section 4.3) is the last that the endpoint will send for the
identified stream. Setting this flag causes the stream to enter identified stream. Setting this flag causes the stream to enter
skipping to change at page 32, line 17 skipping to change at page 32, line 14
PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is
present. present.
PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field
is present. This bit MUST NOT be set unless the PAD_LOW flag is is present. This bit MUST NOT be set unless the PAD_LOW flag is
also set. Endpoints that receive a frame with PAD_HIGH set and also set. Endpoints that receive a frame with PAD_HIGH set and
PAD_LOW cleared MUST treat this as a connection error PAD_LOW cleared MUST treat this as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
PRIORITY_GROUP (0x20): Bit 6 being set indicates that the Priority PRIORITY (0x20): Bit 6 being set indicates that the Exclusive Flag
Group Identifier and Weight fields are present; see Section 5.3. (E), Stream Dependency, and Weight fields are present; see
PRIORITY_DEPENDENCY (0x40): Bit 7 being set indicates that the
Exclusive Flag (E) and Stream Dependency fields are present; see
Section 5.3. Section 5.3.
The payload of a HEADERS frame contains a header block fragment The payload of a HEADERS frame contains a header block fragment
(Section 4.3). A header block that does not fit within a HEADERS (Section 4.3). A header block that does not fit within a HEADERS
frame is continued in a CONTINUATION frame (Section 6.10). frame is continued in a CONTINUATION frame (Section 6.10).
HEADERS frames MUST be associated with a stream. If a HEADERS frame HEADERS frames MUST be associated with a stream. If a HEADERS frame
is received whose stream identifier field is 0x0, the recipient MUST is received whose stream identifier field is 0x0, the recipient MUST
respond with a connection error (Section 5.4.1) of type respond with a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
A HEADERS frame MUST NOT have both the PRIORITY_GROUP and
PRIORITY_DEPENDENCY flags set. Receipt of a HEADERS frame with both
these flags set MUST be treated as a stream error (Section 5.4.2) of
type PROTOCOL_ERROR.
The HEADERS frame changes the connection state as described in The HEADERS frame changes the connection state as described in
Section 4.3. Section 4.3.
The HEADERS frame includes optional padding. Padding fields and The HEADERS frame includes optional padding. Padding fields and
flags are identical to those defined for DATA frames (Section 6.1). flags are identical to those defined for DATA frames (Section 6.1).
6.3. PRIORITY 6.3. PRIORITY
The PRIORITY frame (type=0x2) specifies the sender-advised priority The PRIORITY frame (type=0x2) specifies the sender-advised priority
of a stream (Section 5.3). It can be sent at any time for an of a stream (Section 5.3). It can be sent at any time for an
existing stream. This enables reprioritisation of existing streams. existing stream. This enables reprioritization of existing streams.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Priority Group Identifier? (31) | |E| Stream Dependency (31) |
+-+-------------+-----------------------------------------------+
| Weight? (8) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
|E| Stream Dependency? (31) | | Weight (8) |
+-+-------------------------------------------------------------+ +-+-------------+
PRIORITY Frame Payload PRIORITY Frame Payload
The payload of a PRIORITY frame contains the following fields: The payload of a PRIORITY frame contains the following fields:
R: A single reserved bit. This field is optional and is only present
if the PRIORITY_GROUP flag is set.
Priority Group Identifier: A 31-bit identifier for a priority group,
see Section 5.3. This field is optional and is only present if
the PRIORITY_GROUP flag is set.
Weight: An 8-bit weight for the identified priority group, see
Section 5.3. This field is optional and is only present if the
PRIORITY_GROUP flag is set.
E: A single bit flag indicates that the stream dependency is E: A single bit flag indicates that the stream dependency is
exclusive, see Section 5.3. This field is optional and is only exclusive, see Section 5.3.
present if the PRIORITY_DEPENDENCY flag is set.
Stream Dependency: A 31-bit stream identifier for the stream that Stream Dependency: A 31-bit stream identifier for the stream that
this stream depends on, see Section 5.3. This field is optional this stream depends on, see Section 5.3.
and is only present if the PRIORITY_DEPENDENCY flag is set.
The PRIORITY frame defines the following flags:
PRIORITY_GROUP (0x20): Bit 6 being set indicates that the Priority
Group Identifier and Weight fields are present; see Section 5.3.
PRIORITY_DEPENDENCY (0x40): Bit 7 being set indicates that the Weight: An 8-bit weight for the identified stream dependency, see
Exclusive Flag (E) and Stream Dependency fields are present; see Section 5.3. Add one to the value to obtain a weight between 1
Section 5.3. and 256.
A PRIORITY frame MUST have exactly one of the PRIORITY_GROUP and The PRIORITY frame does not define any flags.
PRIORITY_DEPENDENCY flags set. Receipt of a PRIORITY frame with
either none or both these flags set MUST be treated as a stream error
(Section 5.4.2) of type PROTOCOL_ERROR.
The PRIORITY frame is associated with an existing stream. If a The PRIORITY frame is associated with an existing stream. If a
PRIORITY frame is received with a stream identifier of 0x0, the PRIORITY frame is received with a stream identifier of 0x0, the
recipient MUST respond with a connection error (Section 5.4.1) of recipient MUST respond with a connection error (Section 5.4.1) of
type PROTOCOL_ERROR. type PROTOCOL_ERROR.
The PRIORITY frame can be sent on a stream in any of the "reserved The PRIORITY frame can be sent on a stream in any of the "reserved
(remote)", "open", "half-closed (local)", or "half closed (remote)" (remote)", "open", "half-closed (local)", or "half closed (remote)"
states, though it cannot be sent between consecutive frames that states, though it cannot be sent between consecutive frames that
comprise a single header block (Section 4.3). Note that this frame comprise a single header block (Section 4.3). Note that this frame
skipping to change at page 37, line 23 skipping to change at page 36, line 36
window size (in bytes) for stream level flow control. The initial window size (in bytes) for stream level flow control. The initial
value is 65,535. value is 65,535.
This setting affects the window size of all streams, including This setting affects the window size of all streams, including
existing streams, see Section 6.9.2. existing streams, see Section 6.9.2.
Values above the maximum flow control window size of 2^31 - 1 MUST Values above the maximum flow control window size of 2^31 - 1 MUST
be treated as a connection error (Section 5.4.1) of type be treated as a connection error (Section 5.4.1) of type
FLOW_CONTROL_ERROR. FLOW_CONTROL_ERROR.
SETTINGS_COMPRESS_DATA (5): This setting is used to enable GZip
compression of DATA frames.
A value of 1 indicates that DATA frames MAY be compressed. A
value of 0 indicates that compression is not permitted. The
initial value is 0.
Values other than 0 or 1 are invalid. An endpoint MUST treat the
receipt of any other value as a connection error (Section 5.4.1)
of type PROTOCOL_ERROR.
An endpoint that receives a SETTINGS frame with any other identifier An endpoint that receives a SETTINGS frame with any other identifier
MUST treat this as a connection error (Section 5.4.1) of type MUST treat this as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
6.5.3. Settings Synchronization 6.5.3. Settings Synchronization
Most values in SETTINGS benefit from or require an understanding of Most values in SETTINGS benefit from or require an understanding of
when the peer has received and applied the changed the communicated when the peer has received and applied the changed the communicated
parameter values. In order to provide such synchronization parameter values. In order to provide such synchronization
timepoints, the recipient of a SETTINGS frame in which the ACK flag timepoints, the recipient of a SETTINGS frame in which the ACK flag
skipping to change at page 40, line 30 skipping to change at page 40, line 7
| Opaque Data (64) | | Opaque Data (64) |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
PING Payload Format PING Payload Format
In addition to the frame header, PING frames MUST contain 8 octets of In addition to the frame header, PING frames MUST contain 8 octets of
data in the payload. A sender can include any value it chooses and data in the payload. A sender can include any value it chooses and
use those bytes in any fashion. use those bytes in any fashion.
Receivers of a PING frame that does not include a ACK flag MUST send Receivers of a PING frame that does not include an ACK flag MUST send
a PING frame with the ACK flag set in response, with an identical a PING frame with the ACK flag set in response, with an identical
payload. PING responses SHOULD be given higher priority than any payload. PING responses SHOULD be given higher priority than any
other frame. other frame.
The PING frame defines the following flags: The PING frame defines the following flags:
ACK (0x1): Bit 1 being set indicates that this PING frame is a PING ACK (0x1): Bit 1 being set indicates that this PING frame is a PING
response. An endpoint MUST set this flag in PING responses. An response. An endpoint MUST set this flag in PING responses. An
endpoint MUST NOT respond to PING frames containing this flag. endpoint MUST NOT respond to PING frames containing this flag.
skipping to change at page 41, line 36 skipping to change at page 41, line 10
Endpoints SHOULD always send a GOAWAY frame before closing a Endpoints SHOULD always send a GOAWAY frame before closing a
connection so that the remote can know whether a stream has been connection so that the remote can know whether a stream has been
partially processed or not. For example, if an HTTP client sends a partially processed or not. For example, if an HTTP client sends a
POST at the same time that a server closes a connection, the client POST at the same time that a server closes a connection, the client
cannot know if the server started to process that POST request if the cannot know if the server started to process that POST request if the
server does not send a GOAWAY frame to indicate where it stopped server does not send a GOAWAY frame to indicate where it stopped
working. An endpoint might choose to close a connection without working. An endpoint might choose to close a connection without
sending GOAWAY for misbehaving peers. sending GOAWAY for misbehaving peers.
After sending a GOAWAY frame, the sender can discard frames for new
streams. However, any frames that alter connection state cannot be
completely ignored. For instance, HEADERS, PUSH_PROMISE and
CONTINUATION frames MUST be minimally processed to ensure the state
maintained for header compression is consistent (see Section 4.3);
similarly DATA frames MUST be counted toward the connection flow
control window.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Last-Stream-ID (31) | |R| Last-Stream-ID (31) |
+-+-------------------------------------------------------------+ +-+-------------------------------------------------------------+
| Error Code (32) | | Error Code (32) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Additional Debug Data (*) | | Additional Debug Data (*) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
GOAWAY Payload Format GOAWAY Payload Format
The GOAWAY frame does not define any flags. The GOAWAY frame does not define any flags.
The GOAWAY frame applies to the connection, not a specific stream. The GOAWAY frame applies to the connection, not a specific stream.
An endpoint MUST treat a GOAWAY frame with a stream identifier other An endpoint MUST treat a GOAWAY frame with a stream identifier other
than 0x0 as a connection error (Section 5.4.1) of type than 0x0 as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
The last stream identifier in the GOAWAY frame contains the highest The last stream identifier in the GOAWAY frame contains the highest
numbered stream identifier for which the sender of the GOAWAY frame numbered stream identifier for which the sender of the GOAWAY frame
has received frames and might have taken some action on. All streams has received frames and might have taken some action on. All streams
up to and including the identified stream might have been processed up to and including the identified stream might have been processed
in some way. The last stream identifier is set to 0 if no streams in some way. The last stream identifier can be set to 0 if no
were processed. streams were processed.
Note: In this case, "processed" means that some data from the Note: In this context, "processed" means that some data from the
stream was passed to some higher layer of software that might have stream was passed to some higher layer of software that might have
taken some action as a result. taken some action as a result.
If a connection terminates without a GOAWAY frame, this value is If a connection terminates without a GOAWAY frame, this value is
effectively the highest stream identifier. effectively the highest possible stream identifier.
On streams with lower or equal numbered identifiers that were not On streams with lower or equal numbered identifiers that were not
closed completely prior to the connection being closed, re-attempting closed completely prior to the connection being closed, re-attempting
requests, transactions, or any protocol activity is not possible requests, transactions, or any protocol activity is not possible
(with the exception of idempotent actions like HTTP GET, PUT, or (with the exception of idempotent actions like HTTP GET, PUT, or
DELETE). Any protocol activity that uses higher numbered streams can DELETE). Any protocol activity that uses higher numbered streams can
be safely retried using a new connection. be safely retried using a new connection.
Activity on streams numbered lower or equal to the last stream Activity on streams numbered lower or equal to the last stream
identifier might still complete successfully. The sender of a GOAWAY identifier might still complete successfully. The sender of a GOAWAY
frame might gracefully shut down a connection by sending a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY
frame, maintaining the connection in an open state until all in- frame, maintaining the connection in an open state until all in-
progress streams complete. progress streams complete.
The last stream ID MUST be 0 if no streams were acted upon. An endpoint MAY send multiple GOAWAY frames if circumstances change.
For instance, an endpoint that sends GOAWAY with NO_ERROR during
graceful shutdown could subsequently encounter an condition that
requires immediate termination of the connection. The last stream
identifier from the last GOAWAY frame received applies.
If an endpoint maintains the connection and continues to exchange After sending a GOAWAY frame, the sender can discard frames for
frames, ignored frames MUST be counted toward flow control limits streams with identifiers higher than the identified last stream.
(Section 5.2) or update header compression state (Section 4.3). However, any frames that alter connection state cannot be completely
Otherwise, flow control or header compression state can become ignored. For instance, HEADERS, PUSH_PROMISE and CONTINUATION frames
unsynchronized. MUST be minimally processed to ensure the state maintained for header
compression is consistent (see Section 4.3); similarly DATA frames
MUST be counted toward the connection flow control window. Failure
to process these frames can cause flow control or header compression
state to become unsynchronized.
The GOAWAY frame also contains a 32-bit error code (Section 7) that The GOAWAY frame also contains a 32-bit error code (Section 7) that
contains the reason for closing the connection. contains the reason for closing the connection.
Endpoints MAY append opaque data to the payload of any GOAWAY frame. Endpoints MAY append opaque data to the payload of any GOAWAY frame.
Additional debug data is intended for diagnostic purposes only and Additional debug data is intended for diagnostic purposes only and
carries no semantic value. Debug information could contain security- carries no semantic value. Debug information could contain security-
or privacy-sensitive data. Logged or otherwise persistently stored or privacy-sensitive data. Logged or otherwise persistently stored
debug data MUST have adequate safeguards to prevent unauthorized debug data MUST have adequate safeguards to prevent unauthorized
access. access.
6.9. WINDOW_UPDATE 6.9. WINDOW_UPDATE
The WINDOW_UPDATE frame (type=0x8) is used to implement flow control; The WINDOW_UPDATE frame (type=0x8) is used to implement flow control;
see Section 5.2 for an overview. see Section 5.2 for an overview.
skipping to change at page 43, line 31 skipping to change at page 43, line 6
between dependent connections. However, throttling of data transfer between dependent connections. However, throttling of data transfer
by any receiver can indirectly cause the propagation of flow control by any receiver can indirectly cause the propagation of flow control
information toward the original sender. information toward the original sender.
Flow control only applies to frames that are identified as being Flow control only applies to frames that are identified as being
subject to flow control. Of the frame types defined in this subject to flow control. Of the frame types defined in this
document, this includes only DATA frame. Frames that are exempt from document, this includes only DATA frame. Frames that are exempt from
flow control MUST be accepted and processed, unless the receiver is flow control MUST be accepted and processed, unless the receiver is
unable to assign resources to handling the frame. A receiver MAY unable to assign resources to handling the frame. A receiver MAY
respond with a stream error (Section 5.4.2) or connection error respond with a stream error (Section 5.4.2) or connection error
(Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable accept a (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept
frame. a frame.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Window Size Increment (31) | |R| Window Size Increment (31) |
+-+-------------------------------------------------------------+ +-+-------------------------------------------------------------+
WINDOW_UPDATE Payload Format WINDOW_UPDATE Payload Format
The payload of a WINDOW_UPDATE frame is one reserved bit, plus an The payload of a WINDOW_UPDATE frame is one reserved bit, plus an
skipping to change at page 45, line 13 skipping to change at page 44, line 37
control window to exceed this maximum it MUST terminate either the control window to exceed this maximum it MUST terminate either the
stream or the connection, as appropriate. For streams, the sender stream or the connection, as appropriate. For streams, the sender
sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code; sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code;
for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code. for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code.
Flow controlled frames from the sender and WINDOW_UPDATE frames from Flow controlled frames from the sender and WINDOW_UPDATE frames from
the receiver are completely asynchronous with respect to each other. the receiver are completely asynchronous with respect to each other.
This property allows a receiver to aggressively update the window This property allows a receiver to aggressively update the window
size kept by the sender to prevent streams from stalling. size kept by the sender to prevent streams from stalling.
A sender that is unable to send data on a stream due to either flow
control window being zero or lower MAY send a BLOCKED frame
(Section 6.12) in order to inform the receiver of a potential flow
control problem.
6.9.2. Initial Flow Control Window Size 6.9.2. Initial Flow Control Window Size
When an HTTP/2 connection is first established, new streams are When an HTTP/2 connection is first established, new streams are
created with an initial flow control window size of 65,535 bytes. created with an initial flow control window size of 65,535 bytes.
The connection flow control window is 65,535 bytes. Both endpoints The connection flow control window is 65,535 bytes. Both endpoints
can adjust the initial window size for new streams by including a can adjust the initial window size for new streams by including a
value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that
forms part of the connection preface. The connection flow control forms part of the connection preface. The connection flow control
window initial size cannot be changed. window initial size cannot be changed.
skipping to change at page 48, line 4 skipping to change at page 47, line 36
The CONTINUATION frame includes optional padding. Padding fields and The CONTINUATION frame includes optional padding. Padding fields and
flags are identical to those defined for DATA frames (Section 6.1). flags are identical to those defined for DATA frames (Section 6.1).
6.11. ALTSVC 6.11. ALTSVC
The ALTSVC frame (type=0xA) advertises the availability of an The ALTSVC frame (type=0xA) advertises the availability of an
alternative service to the client. It can be sent at any time for an alternative service to the client. It can be sent at any time for an
existing client-initiated stream or stream 0, and is intended to existing client-initiated stream or stream 0, and is intended to
allow servers to load balance or otherwise segment traffic; see allow servers to load balance or otherwise segment traffic; see
[ALT-SVC] for details (in particular, Section 2.4, which outlines [ALT-SVC] for details (in particular, Section 2.4, which outlines
client handling of alternative services). client handling of alternative services).
An ALTSVC frame on a client-initiated stream indicates that the An ALTSVC frame on a client-initiated stream indicates that the
conveyed alternative service is associated with the origin of that conveyed alternative service is associated with the origin of that
stream. stream.
An ALTSVC frame on stream 0 indicates that the conveyed alternative An ALTSVC frame on stream 0 indicates that the conveyed alternative
service is associated with the origin contained in the Origin field service is associated with the origin contained in the Origin field
of the frame. An association with an origin that the client does not of the frame. An association with an origin that the client does not
consider authoritative for the current connection MUST be ignored. consider authoritative for the current connection MUST be ignored.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-Age (32) | | Max-Age (32) |
+-------------------------------+----------------+--------------+ +-------------------------------+---------------+---------------+
| Port (16) | Reserved (8) | PID_LEN (8) | | Port (16) | Reserved (8) | Proto-Len (8) |
+-------------------------------+----------------+--------------+ +-------------------------------+---------------+---------------+
| Protocol-ID (*) | | Protocol-ID (*) |
+---------------+-----------------------------------------------+ +---------------+-----------------------------------------------+
| HOST_LEN (8) | Host (*) ... | Host-Len (8) | Host (*) ...
+---------------+-----------------------------------------------+ +---------------+-----------------------------------------------+
| Origin? (*) ... | Origin? (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
ALTSVC Frame Payload
The ALTSVC frame contains the following fields: The ALTSVC frame contains the following fields:
Max-Age: An unsigned, 32-bit integer indicating the freshness Max-Age: An unsigned, 32-bit integer indicating the freshness
lifetime of the alternative service association, as per [ALT-SVC], lifetime of the alternative service association, as per [ALT-SVC],
Section 2.2. Section 2.2.
Port: An unsigned, 16-bit integer indicating the port that the Port: An unsigned, 16-bit integer indicating the port that the
alternative service is available upon. alternative service is available upon.
Reserved: For future use. Senders MUST set these bits to '0', and Reserved: For future use. Senders MUST set these bits to '0', and
recipients MUST ignore them. recipients MUST ignore them.
PID_LEN: An unsigned, 8-bit integer indicating the length, in Proto-Len: An unsigned, 8-bit integer indicating the length, in
octets, of the PROTOCOL-ID field. octets, of the Protocol-ID field.
Protocol-ID: A sequence of bytes (length determined by PID_LEN) Protocol-ID: A sequence of bytes (length determined by "Proto-Len")
containing the ALPN protocol identifier of the alternative containing the ALPN protocol identifier of the alternative
service. service.
HOST_LEN: An unsigned, 8-bit integer indicating the length, in Host-Len: An unsigned, 8-bit integer indicating the length, in
octets, of the Host field. octets, of the Host field.
Host: A sequence of characters (length determined by HOST_LEN) Host: A sequence of characters (length determined by "Host-Len")
containing an ASCII string indicating the host that the containing an ASCII string indicating the host that the
alternative service is available upon. An internationalized alternative service is available upon. An internationalized
domain name [IDNA] MUST be expressed using A-labels. domain name [IDNA] MUST be expressed using A-labels.
Origin: An optional sequence of characters (length determined by Origin: An optional sequence of characters (length determined by
subtracting the length of all preceding fields from the frame subtracting the length of all preceding fields from the frame
length) containing ASCII serialisation of an origin ([RFC6454], length) containing the ASCII serialisation of an origin
Section 6.2) that the alternate service is applicable to. ([RFC6454], Section 6.2) that the alternate service is applicable
to.
The ALTSVC frame does not define any flags. The ALTSVC frame does not define any flags.
The ALTSVC frame is intended for receipt by clients; a server that The ALTSVC frame is intended for receipt by clients; a server that
receives an ALTSVC frame MUST treat it as a connection error of type receives an ALTSVC frame MUST treat it as a connection error
PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT
forward ALTSVC frames, though it can use the information contained in forward ALTSVC frames, though it can use the information contained in
ALTSVC frames in forming new ALTSVC frames to send to its own ALTSVC frames in forming new ALTSVC frames to send to its own
clients. clients.
6.12. BLOCKED
The BLOCKED frame (type=0xB) indicates that the sender is unable to
send data due to a closed flow control window.
[[anchor12: The BLOCKED frame is included in this draft version to
facilitate experimentation. If the results of the experiment do not
provide positive feedback, it could be removed.]]
The BLOCKED frame is used to provide feedback about the performance
of flow control for the purposes of performance tuning and debugging.
The BLOCKED frame can be sent by a peer when flow controlled data
cannot be sent due to the connection- or stream-level flow control.
This frame MUST NOT be sent if there are other reasons preventing
data from being sent, either a lack of available data, or the
underlying transport being blocked.
The BLOCKED frame is sent on the stream that is blocked, that is, the
stream with a non-positive number of bytes available in the flow
control window. A BLOCKED frame can be sent on stream 0x0 to
indicate that connection-level flow control is blocked.
An endpoint MUST NOT send any subsequent BLOCKED frames until the
affected flow control window becomes positive. This means that
WINDOW_UPDATE frames are received or SETTINGS_INITIAL_WINDOW_SIZE is
increased before more BLOCKED frames can be sent.
The BLOCKED frame defines no flags and contains no payload. A
receiver MUST treat the receipt of a BLOCKED frame with a payload as
a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
7. Error Codes 7. Error Codes
Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY
frames to convey the reasons for the stream or connection error. frames to convey the reasons for the stream or connection error.
Error codes share a common code space. Some error codes only apply Error codes share a common code space. Some error codes only apply
to specific conditions and have no defined semantics in certain frame to specific conditions and have no defined semantics in certain frame
types. types.
The following error codes are defined: The following error codes are defined:
skipping to change at page 53, line 16 skipping to change at page 53, line 34
other 1xx informational responses. other 1xx informational responses.
8.1.2. Examples 8.1.2. Examples
This section shows HTTP/1.1 requests and responses, with This section shows HTTP/1.1 requests and responses, with
illustrations of equivalent HTTP/2 requests and responses. illustrations of equivalent HTTP/2 requests and responses.
An HTTP GET request includes request header fields and no body and is An HTTP GET request includes request header fields and no body and is
therefore transmitted as a single HEADERS frame, followed by zero or therefore transmitted as a single HEADERS frame, followed by zero or
more CONTINUATION frames containing the serialized block of request more CONTINUATION frames containing the serialized block of request
header fields. The last HEADERS frame in the sequence has both the header fields. The HEADERS frame in the following has both the
END_HEADERS and END_STREAM flags set: END_HEADERS and END_STREAM flags set; no CONTINUATION frames are
sent:
GET /resource HTTP/1.1 HEADERS GET /resource HTTP/1.1 HEADERS
Host: example.org ==> + END_STREAM Host: example.org ==> + END_STREAM
Accept: image/jpeg + END_HEADERS Accept: image/jpeg + END_HEADERS
:method = GET :method = GET
:scheme = https :scheme = https
:path = /resource :path = /resource
host = example.org host = example.org
accept = image/jpeg accept = image/jpeg
Similarly, a response that includes only response header fields is Similarly, a response that includes only response header fields is
transmitted as a HEADERS frame (again, followed by zero or more transmitted as a HEADERS frame (again, followed by zero or more
CONTINUATION frames) containing the serialized block of response CONTINUATION frames) containing the serialized block of response
header fields. The last HEADERS frame in the sequence has both the header fields.
END_HEADERS and END_STREAM flag set:
HTTP/1.1 304 Not Modified HEADERS HTTP/1.1 304 Not Modified HEADERS
ETag: "xyzzy" ==> + END_STREAM ETag: "xyzzy" ==> + END_STREAM
Expires: Thu, 23 Jan ... + END_HEADERS Expires: Thu, 23 Jan ... + END_HEADERS
:status = 304 :status = 304
etag: "xyzzy" etag: "xyzzy"
expires: Thu, 23 Jan ... expires: Thu, 23 Jan ...
An HTTP POST request that includes request header fields and payload An HTTP POST request that includes request header fields and payload
data is transmitted as one HEADERS frame, followed by zero or more data is transmitted as one HEADERS frame, followed by zero or more
CONTINUATION frames containing the request header fields, followed by CONTINUATION frames containing the request header fields, followed by
one or more DATA frames, with the last CONTINUATION (or HEADERS) one or more DATA frames, with the last CONTINUATION (or HEADERS)
frame having the END_HEADERS flag set and the final DATA frame having frame having the END_HEADERS flag set and the final DATA frame having
the END_STREAM flag set: the END_STREAM flag set:
POST /resource HTTP/1.1 HEADERS POST /resource HTTP/1.1 HEADERS
Host: example.org ==> - END_STREAM Host: example.org ==> - END_STREAM
Content-Type: image/jpeg + END_HEADERS Content-Type: image/jpeg - END_HEADERS
Content-Length: 123 :method = POST Content-Length: 123 :method = POST
:scheme = https :path = /resource
{binary data} :path = /resource {binary data} content-type = image/jpeg
CONTINUATION
+ END_HEADERS
:authority = example.org :authority = example.org
content-type = image/jpeg :scheme = https
content-length = 123 content-length = 123
DATA DATA
+ END_STREAM + END_STREAM
{binary data} {binary data}
Note that data contributing to any given header field could be spread
between header block fragments. The allocation of header fields to
frames in this example is illustrative only.
A response that includes header fields and payload data is A response that includes header fields and payload data is
transmitted as a HEADERS frame, followed by zero or more CONTINUATION transmitted as a HEADERS frame, followed by zero or more CONTINUATION
frames, followed by one or more DATA frames, with the last DATA frame frames, followed by one or more DATA frames, with the last DATA frame
in the sequence having the END_STREAM flag set: in the sequence having the END_STREAM flag set:
HTTP/1.1 200 OK HEADERS HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM Content-Type: image/jpeg ==> - END_STREAM
Content-Length: 123 + END_HEADERS Content-Length: 123 + END_HEADERS
:status = 200 :status = 200
{binary data} content-type = image/jpeg {binary data} content-type = image/jpeg
content-length = 123 content-length = 123
DATA DATA
+ END_STREAM + END_STREAM
{binary data} {binary data}
Trailing header fields are sent as a header block after both the Trailing header fields are sent as a header block after both the
request or response header block and all the DATA frames have been request or response header block and all the DATA frames have been
sent. The sequence of HEADERS/CONTINUATION frames that bears the sent. The HEADERS frame starting the trailers header block has the
trailers includes a terminal frame that has both END_HEADERS and END_STREAM flag set.
END_STREAM flags set.
HTTP/1.1 200 OK HEADERS HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM Content-Type: image/jpeg ==> - END_STREAM
Transfer-Encoding: chunked + END_HEADERS Transfer-Encoding: chunked + END_HEADERS
Trailer: Foo :status = 200 Trailer: Foo :status = 200
content-length = 123 content-length = 123
123 content-type = image/jpeg 123 content-type = image/jpeg
{binary data} trailer = Foo {binary data} trailer = Foo
0 0
Foo: bar DATA Foo: bar DATA
skipping to change at page 59, line 15 skipping to change at page 59, line 28
8.1.3.5. Malformed Messages 8.1.3.5. Malformed Messages
A malformed request or response is one that uses a valid sequence of A malformed request or response is one that uses a valid sequence of
HTTP/2 frames, but is otherwise invalid due to the presence of HTTP/2 frames, but is otherwise invalid due to the presence of
prohibited header fields, the absence of mandatory header fields, or prohibited header fields, the absence of mandatory header fields, or
the inclusion of uppercase header field names. the inclusion of uppercase header field names.
A request or response that includes an entity body can include a A request or response that includes an entity body can include a
"content-length" header field. A request or response is also "content-length" header field. A request or response is also
malformed if the value of a "content-length" header field does not malformed if the value of a "content-length" header field does not
equal the sum of the DATA frame payload lengths that form the body. equal the sum of the uncompressed DATA frame payload lengths that
form the body.
Note: The "Content-Length" header field is set to the length of an
entity body. Compression of DATA frames is a function of HTTP/2
that does not alter entities.
Intermediaries that process HTTP requests or responses (i.e., all Intermediaries that process HTTP requests or responses (i.e., all
intermediaries other than those acting as tunnels) MUST NOT forward a intermediaries other than those acting as tunnels) MUST NOT forward a
malformed request or response. malformed request or response.
Implementations that detect malformed requests or responses need to Implementations that detect malformed requests or responses need to
ensure that the stream ends. For malformed requests, a server MAY ensure that the stream ends. For malformed requests, a server MAY
send an HTTP response prior to closing or resetting the stream. send an HTTP response prior to closing or resetting the stream.
Clients MUST NOT accept a malformed response. Note that these Clients MUST NOT accept a malformed response. Note that these
requirements are intended to protect against several types of common requirements are intended to protect against several types of common
skipping to change at page 60, line 37 skipping to change at page 61, line 8
0 to indicate that server push is disabled. 0 to indicate that server push is disabled.
Because pushing responses is effectively hop-by-hop, an intermediary Because pushing responses is effectively hop-by-hop, an intermediary
could receive pushed responses from the server and choose not to could receive pushed responses from the server and choose not to
forward those on to the client. In other words, how to make use of forward those on to the client. In other words, how to make use of
the pushed responses is up to that intermediary. Equally, the the pushed responses is up to that intermediary. Equally, the
intermediary might choose to push additional responses to the client, intermediary might choose to push additional responses to the client,
without any action taken by the server. without any action taken by the server.
A client cannot push. Thus, servers MUST treat the receipt of a A client cannot push. Thus, servers MUST treat the receipt of a
PUSH_PROMISE frame as a connection error (Section 5.4.1). Clients PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to PROTOCOL_ERROR. Clients MUST reject any attempt to change the
a value other than "0" by treating the message as a connection error SETTINGS_ENABLE_PUSH setting to a value other than "0" by treating
(Section 5.4.1) of type PROTOCOL_ERROR. the message as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR.
A server can only push responses that are cacheable (see [HTTP-p6], A server can only push responses that are cacheable (see [HTTP-p6],
Section 3); promised requests MUST be safe (see [HTTP-p2], Section Section 3); promised requests MUST be safe (see [HTTP-p2], Section
4.2.1) and MUST NOT include a request body. 4.2.1) and MUST NOT include a request body.
8.2.1. Push Requests 8.2.1. Push Requests
Server push is semantically equivalent to a server responding to a Server push is semantically equivalent to a server responding to a
request; however, in this case that request is also sent by the request; however, in this case that request is also sent by the
server, as a PUSH_PROMISE frame. server, as a PUSH_PROMISE frame.
skipping to change at page 62, line 28 skipping to change at page 62, line 48
A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
the number of responses that can be concurrently pushed by a server. the number of responses that can be concurrently pushed by a server.
Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
server push by preventing the server from creating the necessary server push by preventing the server from creating the necessary
streams. This does not prohibit a server from sending PUSH_PROMISE streams. This does not prohibit a server from sending PUSH_PROMISE
frames; clients need to reset any promised streams that are not frames; clients need to reset any promised streams that are not
wanted. wanted.
Clients receiving a pushed response MUST validate that the server is Clients receiving a pushed response MUST validate that the server is
authorized to provide the response, see Section 10.1. For example, authorized to provide the response, see Section 10.1. For example, a
an server that offers a certificate for only the "example.com" DNS-ID server that offers a certificate for only the "example.com" DNS-ID or
or Common Name is not permitted to push a response for Common Name is not permitted to push a response for
"https://www.example.org/doc". "https://www.example.org/doc".
8.3. The CONNECT Method 8.3. The CONNECT Method
In HTTP/1.x, the pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is In HTTP/1.x, the pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is
used to convert an HTTP connection into a tunnel to a remote host. used to convert an HTTP connection into a tunnel to a remote host.
CONNECT is primarily used with HTTP proxies to establish a TLS CONNECT is primarily used with HTTP proxies to establish a TLS
session with an origin server for the purposes of interacting with session with an origin server for the purposes of interacting with
"https" resources. "https" resources.
skipping to change at page 64, line 17 skipping to change at page 64, line 35
destination, where a destination is the IP address and port that is destination, where a destination is the IP address and port that is
derived from a URI, a selected alternative service [ALT-SVC], or a derived from a URI, a selected alternative service [ALT-SVC], or a
configured proxy. A client can create additional connections as configured proxy. A client can create additional connections as
replacements, either to replace connections that are near to replacements, either to replace connections that are near to
exhausting the available stream identifier space (Section 5.1.1), or exhausting the available stream identifier space (Section 5.1.1), or
to replace connections that have encountered errors (Section 5.4.1). to replace connections that have encountered errors (Section 5.4.1).
A client MAY open multiple connections to the same IP address and TCP A client MAY open multiple connections to the same IP address and TCP
port using different Server Name Indication [TLS-EXT] values or to port using different Server Name Indication [TLS-EXT] values or to
provide different TLS client certificates, but SHOULD avoid creating provide different TLS client certificates, but SHOULD avoid creating
multiple connections with the same configuration. [[anchor15: Need multiple connections with the same configuration. [[anchor17: Need
more text on how client certificates relate here, see issue #363.]] more text on how client certificates relate here, see issue #363.]]
Clients MAY use a single server connection to send requests for URIs Clients MAY use a single server connection to send requests for URIs
with multiple different authority components as long as the server is with multiple different authority components as long as the server is
authoritative (Section 10.1). authoritative (Section 10.1).
Servers are encouraged to maintain open connections for as long as Servers are encouraged to maintain open connections for as long as
possible, but are permitted to terminate idle connections if possible, but are permitted to terminate idle connections if
necessary. When either endpoint chooses to close the transport-level necessary. When either endpoint chooses to close the transport-level
TCP connection, the terminating endpoint SHOULD first send a GOAWAY TCP connection, the terminating endpoint SHOULD first send a GOAWAY
skipping to change at page 65, line 48 skipping to change at page 66, line 20
10.1. Server Authority 10.1. Server Authority
A client is only able to accept HTTP/2 responses from servers that A client is only able to accept HTTP/2 responses from servers that
are authoritative for those resources. This is particularly are authoritative for those resources. This is particularly
important for server push (Section 8.2), where the client validates important for server push (Section 8.2), where the client validates
the PUSH_PROMISE before accepting the response. the PUSH_PROMISE before accepting the response.
HTTP/2 relies on the HTTP/1.1 definition of authority for determining HTTP/2 relies on the HTTP/1.1 definition of authority for determining
whether a server is authoritative in providing a given response, see whether a server is authoritative in providing a given response, see
[HTTP-p1], Section 9.1). This relies on local name resolution for [HTTP-p1], Section 9.1. This relies on local name resolution for the
the "http" URI scheme, and the offered server identity for the "http" URI scheme, and the offered server identity for the "https"
"https" scheme (see [RFC2818], Section 3). scheme (see [RFC2818], Section 3).
A client MUST NOT use, in any way, resources provided by a server A client MUST NOT use, in any way, resources provided by a server
that is not authoritative for those resources. that is not authoritative for those resources.
10.2. Cross-Protocol Attacks 10.2. Cross-Protocol Attacks
In a cross-protocol attack, an attacker causes a client to initiate a In a cross-protocol attack, an attacker causes a client to initiate a
transaction in one protocol toward a server that understands a transaction in one protocol toward a server that understands a
different protocol. An attacker might be able to cause the different protocol. An attacker might be able to cause the
transaction to appear as valid transaction in the second protocol. transaction to appear as valid transaction in the second protocol.
skipping to change at page 67, line 38 skipping to change at page 68, line 10
An HTTP/2 connection can demand a greater commitment of resources to An HTTP/2 connection can demand a greater commitment of resources to
operate than a HTTP/1.1 connection. The use of header compression operate than a HTTP/1.1 connection. The use of header compression
and flow control depend on a commitment of resources for storing a and flow control depend on a commitment of resources for storing a
greater amount of state. Settings for these features ensure that greater amount of state. Settings for these features ensure that
memory commitments for these features are strictly bounded. memory commitments for these features are strictly bounded.
Processing capacity cannot be guarded in the same fashion. Processing capacity cannot be guarded in the same fashion.
The SETTINGS frame can be abused to cause a peer to expend additional The SETTINGS frame can be abused to cause a peer to expend additional
processing time. This might be done by pointlessly changing SETTINGS processing time. This might be done by pointlessly changing SETTINGS
parameters, setting multiple undefined parameters, or changing the parameters, setting multiple undefined parameters, or changing the
same setting multiple times in the same frame. WINDOW_UPDATE or same setting multiple times in the same frame. WINDOW_UPDATE,
PRIORITY frames can be abused to cause an unnecessary waste of PRIORITY, or BLOCKED frames can be abused to cause an unnecessary
resources. A server might erroneously issue ALTSVC frames for waste of resources. A server might erroneously issue ALTSVC frames
origins on which it cannot be authoritative to generate excess work for origins on which it cannot be authoritative to generate excess
for clients. work for clients.
Large numbers of small or empty frames can be abused to cause a peer Large numbers of small or empty frames can be abused to cause a peer
to expend time processing frame headers. Note however that some uses to expend time processing frame headers. Note however that some uses
are entirely legitimate, such as the sending of an empty DATA frame are entirely legitimate, such as the sending of an empty DATA frame
to end a stream. to end a stream.
Header compression also offers some opportunities to waste processing Header compression also offers some opportunities to waste processing
resources; see [COMPRESSION] for more details on potential abuses. resources; see [COMPRESSION] for more details on potential abuses.
Limits in SETTINGS parameters cannot be reduced instantaneously, Limits in SETTINGS parameters cannot be reduced instantaneously,
skipping to change at page 68, line 38 skipping to change at page 69, line 11
multiple requests containing varying plaintext, observing the length multiple requests containing varying plaintext, observing the length
of the resulting ciphertext in each, which reveals a shorter length of the resulting ciphertext in each, which reveals a shorter length
when a guess about the secret is correct. when a guess about the secret is correct.
Implementations communicating on a secure channel MUST NOT compress Implementations communicating on a secure channel MUST NOT compress
content that includes both confidential and attacker-controlled data content that includes both confidential and attacker-controlled data
unless separate compression dictionaries are used for each source of unless separate compression dictionaries are used for each source of
data. Compression MUST NOT be used if the source of data cannot be data. Compression MUST NOT be used if the source of data cannot be
reliably determined. reliably determined.
Intermediaries MUST NOT alter the compression of DATA frames unless
additional information is available that allows the intermediary to
identify the source of data. In particular, frames that are not
compressed cannot be compressed, and frames that are separately
compressed cannot be merged into a single frame. Compressed frames
MAY be decompressed or split into multiple frames.
Further considerations regarding the compression of header fields are Further considerations regarding the compression of header fields are
described in [COMPRESSION]. described in [COMPRESSION].
10.7. Use of Padding 10.7. Use of Padding
Padding within HTTP/2 is not intended as a replacement for general Padding within HTTP/2 is not intended as a replacement for general
purpose padding, such as might be provided by TLS [TLS12]. Redundant purpose padding, such as might be provided by TLS [TLS12]. Redundant
padding could even be counterproductive. Correct application can padding could even be counterproductive. Correct application can
depend on having specific knowledge of the data that is being padded. depend on having specific knowledge of the data that is being padded.
skipping to change at page 70, line 5 skipping to change at page 70, line 34
This document establishes a registry for error codes. This new This document establishes a registry for error codes. This new
registry is entered into a new "Hypertext Transfer Protocol (HTTP) 2 registry is entered into a new "Hypertext Transfer Protocol (HTTP) 2
Parameters" section. Parameters" section.
This document registers the "HTTP2-Settings" header field for use in This document registers the "HTTP2-Settings" header field for use in
HTTP. HTTP.
This document registers the "PRI" method for use in HTTP, to avoid This document registers the "PRI" method for use in HTTP, to avoid
collisions with the connection preface (Section 3.5). collisions with the connection preface (Section 3.5).
11.1. Registration of HTTP/2 Identification String 11.1. Registration of HTTP/2 Identification Strings
This document creates two registrations for the identification of This document creates two registrations for the identification of
HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol
IDs" registry established in [TLSALPN]. IDs" registry established in [TLSALPN].
The "h2" string identifies HTTP/2 when used over TLS: The "h2" string identifies HTTP/2 when used over TLS:
Protocol: HTTP/2 over TLS Protocol: HTTP/2 over TLS
Identification Sequence: 0x68 0x32 ("h2") Identification Sequence: 0x68 0x32 ("h2")
skipping to change at page 72, line 17 skipping to change at page 73, line 4
o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike
Bishop, Herve Ruellan (Substantial editorial contributions). Bishop, Herve Ruellan (Substantial editorial contributions).
o Alexey Melnikov was an editor of this document during 2013. o Alexey Melnikov was an editor of this document during 2013.
o A substantial proportion of Martin's contribution was supported by o A substantial proportion of Martin's contribution was supported by
Microsoft during his employment there. Microsoft during his employment there.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", draft-ietf-httpbis-alt-svc-01 Alternative Services", draft-ietf-httpbis-alt-svc-01
(work in progress), April 2014. (work in progress), April 2014.
[COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression [COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression
for HTTP/2", draft-ietf-httpbis-header-compression-07 for HTTP/2", draft-ietf-httpbis-header-compression-07
(work in progress), April 2014. (work in progress), April 2014.
[COOKIE] Barth, A., "HTTP State Management Mechanism", [COOKIE] Barth, A., "HTTP State Management Mechanism",
RFC 6265, April 2011. RFC 6265, April 2011.
[GZIP] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification
version 4.3", RFC 1952, May 1996.
[HTTP-p1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Transfer Protocol (HTTP/1.1): Message Syntax and
Routing", draft-ietf-httpbis-p1-messaging-26 (work in Routing", draft-ietf-httpbis-p1-messaging-26 (work in
progress), February 2014. progress), February 2014.
[HTTP-p2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-26 (work in progress), draft-ietf-httpbis-p2-semantics-26 (work in progress),
February 2014. February 2014.
skipping to change at page 74, line 41 skipping to change at page 75, line 32
Jackson, "Talking to Yourself for Fun and Profit", Jackson, "Talking to Yourself for Fun and Profit",
2011, <http://w2spconf.com/2011/papers/websocket.pdf>. 2011, <http://w2spconf.com/2011/papers/websocket.pdf>.
[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", "Recommendations for Secure Use of TLS and DTLS",
draft-sheffer-tls-bcp-02 (work in progress), draft-sheffer-tls-bcp-02 (work in progress),
February 2014. February 2014.
Appendix A. Change Log (to be removed by RFC Editor before publication) Appendix A. Change Log (to be removed by RFC Editor before publication)
A.1. Since draft-ietf-httpbis-http2-10 A.1. Since draft-ietf-httpbis-http2-11
Added BLOCKED frame (at risk).
Simplified priority scheme.
Added DATA per-frame GZip compression.
A.2. Since draft-ietf-httpbis-http2-10
Changed "connection header" to "connection preface" to avoid Changed "connection header" to "connection preface" to avoid
confusion. confusion.
Added dependency-based stream prioritization. Added dependency-based stream prioritization.
Added "h2c" identifier to distinguish between cleartext and secured Added "h2c" identifier to distinguish between cleartext and secured
HTTP/2. HTTP/2.
Adding missing padding to PUSH_PROMISE. Adding missing padding to PUSH_PROMISE.
Integrate ALTSVC frame and supporting text. Integrate ALTSVC frame and supporting text.
Dropping requirement on "deflate" Content-Encoding. Dropping requirement on "deflate" Content-Encoding.
Improving security considerations around use of compression. Improving security considerations around use of compression.
A.2. Since draft-ietf-httpbis-http2-09 A.3. Since draft-ietf-httpbis-http2-09
Adding padding for data frames. Adding padding for data frames.
Renumbering frame types, error codes, and settings. Renumbering frame types, error codes, and settings.
Adding INADEQUATE_SECURITY error code. Adding INADEQUATE_SECURITY error code.
Updating TLS usage requirements to 1.2; forbidding TLS compression. Updating TLS usage requirements to 1.2; forbidding TLS compression.
Removing extensibility for frames and settings. Removing extensibility for frames and settings.
skipping to change at page 75, line 36 skipping to change at page 76, line 36
Changing the protocol identification token to "h2". Changing the protocol identification token to "h2".
Changing the use of :authority to make it optional and to allow Changing the use of :authority to make it optional and to allow
userinfo in non-HTTP cases. userinfo in non-HTTP cases.
Allowing split on 0x0 for Cookie. Allowing split on 0x0 for Cookie.
Reserved PRI method in HTTP/1.1 to avoid possible future collisions. Reserved PRI method in HTTP/1.1 to avoid possible future collisions.
A.3. Since draft-ietf-httpbis-http2-08 A.4. Since draft-ietf-httpbis-http2-08
Added cookie crumbling for more efficient header compression. Added cookie crumbling for more efficient header compression.
Added header field ordering with the value-concatenation mechanism. Added header field ordering with the value-concatenation mechanism.
A.4. Since draft-ietf-httpbis-http2-07 A.5. Since draft-ietf-httpbis-http2-07
Marked draft for implementation. Marked draft for implementation.
A.5. Since draft-ietf-httpbis-http2-06 A.6. Since draft-ietf-httpbis-http2-06
Adding definition for CONNECT method. Adding definition for CONNECT method.
Constraining the use of push to safe, cacheable methods with no Constraining the use of push to safe, cacheable methods with no
request body. request body.
Changing from :host to :authority to remove any potential confusion. Changing from :host to :authority to remove any potential confusion.
Adding setting for header compression table size. Adding setting for header compression table size.
Adding settings acknowledgement. Adding settings acknowledgement.
Removing unnecessary and potentially problematic flags from Removing unnecessary and potentially problematic flags from
CONTINUATION. CONTINUATION.
Added denial of service considerations. Added denial of service considerations.
A.6. Since draft-ietf-httpbis-http2-05 A.7. Since draft-ietf-httpbis-http2-05
Marking the draft ready for implementation. Marking the draft ready for implementation.
Renumbering END_PUSH_PROMISE flag. Renumbering END_PUSH_PROMISE flag.
Editorial clarifications and changes. Editorial clarifications and changes.
A.7. Since draft-ietf-httpbis-http2-04 A.8. Since draft-ietf-httpbis-http2-04
Added CONTINUATION frame for HEADERS and PUSH_PROMISE. Added CONTINUATION frame for HEADERS and PUSH_PROMISE.
PUSH_PROMISE is no longer implicitly prohibited if PUSH_PROMISE is no longer implicitly prohibited if
SETTINGS_MAX_CONCURRENT_STREAMS is zero. SETTINGS_MAX_CONCURRENT_STREAMS is zero.
Push expanded to allow all safe methods without a request body. Push expanded to allow all safe methods without a request body.
Clarified the use of HTTP header fields in requests and responses. Clarified the use of HTTP header fields in requests and responses.
Prohibited HTTP/1.1 hop-by-hop header fields. Prohibited HTTP/1.1 hop-by-hop header fields.
skipping to change at page 76, line 49 skipping to change at page 77, line 49
Clarified requirements around handling different frames after stream Clarified requirements around handling different frames after stream
close, stream reset and GOAWAY. close, stream reset and GOAWAY.
Added more specific prohibitions for sending of different frame types Added more specific prohibitions for sending of different frame types
in various stream states. in various stream states.
Making the last received setting value the effective value. Making the last received setting value the effective value.
Clarified requirements on TLS version, extension and ciphers. Clarified requirements on TLS version, extension and ciphers.
A.8. Since draft-ietf-httpbis-http2-03 A.9. Since draft-ietf-httpbis-http2-03
Committed major restructuring atrocities. Committed major restructuring atrocities.
Added reference to first header compression draft. Added reference to first header compression draft.
Added more formal description of frame lifecycle. Added more formal description of frame lifecycle.
Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA. Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA.
Removed HEADERS+PRIORITY, added optional priority to HEADERS frame. Removed HEADERS+PRIORITY, added optional priority to HEADERS frame.
Added PRIORITY frame. Added PRIORITY frame.
A.9. Since draft-ietf-httpbis-http2-02 A.10. Since draft-ietf-httpbis-http2-02
Added continuations to frames carrying header blocks. Added continuations to frames carrying header blocks.
Replaced use of "session" with "connection" to avoid confusion with Replaced use of "session" with "connection" to avoid confusion with
other HTTP stateful concepts, like cookies. other HTTP stateful concepts, like cookies.
Removed "message". Removed "message".
Switched to TLS ALPN from NPN. Switched to TLS ALPN from NPN.
Editorial changes. Editorial changes.
A.10. Since draft-ietf-httpbis-http2-01 A.11. Since draft-ietf-httpbis-http2-01
Added IANA considerations section for frame types, error codes and Added IANA considerations section for frame types, error codes and
settings. settings.
Removed data frame compression. Removed data frame compression.
Added PUSH_PROMISE. Added PUSH_PROMISE.
Added globally applicable flags to framing. Added globally applicable flags to framing.
skipping to change at page 78, line 12 skipping to change at page 79, line 12
Restructured frame header. Removed distinction between data and Restructured frame header. Removed distinction between data and
control frames. control frames.
Altered flow control properties to include session-level limits. Altered flow control properties to include session-level limits.
Added note on cacheability of pushed resources and multiple tenant Added note on cacheability of pushed resources and multiple tenant
servers. servers.
Changed protocol label form based on discussions. Changed protocol label form based on discussions.
A.11. Since draft-ietf-httpbis-http2-00 A.12. Since draft-ietf-httpbis-http2-00
Changed title throughout. Changed title throughout.
Removed section on Incompatibilities with SPDY draft#2. Removed section on Incompatibilities with SPDY draft#2.
Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <https:// Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <https://
groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU>. groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU>.
Replaced abstract and introduction. Replaced abstract and introduction.
Added section on starting HTTP/2.0, including upgrade mechanism. Added section on starting HTTP/2.0, including upgrade mechanism.
Removed unused references. Removed unused references.
Added flow control principles (Section 5.2.1) based on <http:// Added flow control principles (Section 5.2.1) based on <http://
tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01>. tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01>.
A.12. Since draft-mbelshe-httpbis-spdy-00 A.13. Since draft-mbelshe-httpbis-spdy-00
Adopted as base for draft-ietf-httpbis-http2. Adopted as base for draft-ietf-httpbis-http2.
Updated authors/editors list. Updated authors/editors list.
Added status note. Added status note.
Authors' Addresses Authors' Addresses
Mike Belshe Mike Belshe
 End of changes. 106 change blocks. 
287 lines changed or deleted 339 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/