draft-ietf-httpbis-http2-06.txt   draft-ietf-httpbis-http2-07.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: February 22, 2014 Google, Inc Expires: April 24, 2014 Google, Inc
M. Thomson, Ed. M. Thomson, Ed.
Microsoft Microsoft
A. Melnikov, Ed. A. Melnikov, Ed.
Isode Ltd Isode Ltd
August 21, 2013 October 21, 2013
Hypertext Transfer Protocol version 2.0 Hypertext Transfer Protocol version 2.0
draft-ietf-httpbis-http2-06 draft-ietf-httpbis-http2-07
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). The HTTP/2.0 encapsulation the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more
enables more efficient use of network resources and reduced efficient use of network resources and a reduced perception of
perception of latency by allowing header field compression and latency by introducing header field compression and allowing multiple
multiple concurrent messages on the same connection. It also concurrent messages on the same connection. It also introduces
introduces unsolicited push of representations from servers to unsolicited push of representations from servers to clients.
clients.
This document is an alternative to, but does not obsolete the
HTTP/1.1 message format or protocol. HTTP's existing semantics
remain unchanged.
This version of the draft has been marked for implementation. This document is an alternative to, but does not obsolete, the
Interoperability testing will occur in the HTTP/2.0 interim in HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Seatle, US, starting 2013-10-09.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
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 and related documents can be found at Working Group information and related documents can be found at
<http://tools.ietf.org/wg/httpbis/> (Wiki) and <http://tools.ietf.org/wg/httpbis/> (Wiki) and
<https://github.com/http2/http2-spec> (source code and issues <https://github.com/http2/http2-spec> (source code and issues
skipping to change at page 2, line 16 skipping to change at page 2, line 10
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 February 22, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 43 skipping to change at page 2, line 37
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Document Organization . . . . . . . . . . . . . . . . . . 5 1.1. Document Organization . . . . . . . . . . . . . . . . . . 5
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 6
2. HTTP/2.0 Protocol Overview . . . . . . . . . . . . . . . . . . 6 2. HTTP/2.0 Protocol Overview . . . . . . . . . . . . . . . . . . 6
2.1. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. HTTP Multiplexing . . . . . . . . . . . . . . . . . . . . 7 2.2. HTTP Multiplexing . . . . . . . . . . . . . . . . . . . . 7
2.3. HTTP Semantics . . . . . . . . . . . . . . . . . . . . . . 7 2.3. HTTP Semantics . . . . . . . . . . . . . . . . . . . . . . 7
3. Starting HTTP/2.0 . . . . . . . . . . . . . . . . . . . . . . 7 3. Starting HTTP/2.0 . . . . . . . . . . . . . . . . . . . . . . 7
3.1. HTTP/2.0 Version Identification . . . . . . . . . . . . . 8 3.1. HTTP/2.0 Version Identification . . . . . . . . . . . . . 7
3.2. Starting HTTP/2.0 for "http" URIs . . . . . . . . . . . . 8 3.2. Starting HTTP/2.0 for "http" URIs . . . . . . . . . . . . 8
3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10 3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10
3.3. Starting HTTP/2.0 for "https" URIs . . . . . . . . . . . . 10 3.3. Starting HTTP/2.0 for "https" URIs . . . . . . . . . . . . 10
3.4. Starting HTTP/2.0 with Prior Knowledge . . . . . . . . . . 10 3.4. Starting HTTP/2.0 with Prior Knowledge . . . . . . . . . . 10
3.5. Connection Header . . . . . . . . . . . . . . . . . . . . 11 3.5. HTTP/2.0 Connection Header . . . . . . . . . . . . . . . . 11
4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Header Compression and Decompression . . . . . . . . . . . 13 4.3. Header Compression and Decompression . . . . . . . . . . . 13
5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14
5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 18 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20
5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21
5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 21 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 22
5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22
5.4.1. Connection Error Handling . . . . . . . . . . . . . . 22 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 22
5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 22 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23
5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 23 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 24
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 26 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 27 6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 28
6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 28 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 29
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 28 6.5.3. Settings Synchronization . . . . . . . . . . . . . . . 29
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 30
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 33 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 34 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 34
6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 35 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 35
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 36 6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 36
6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 36 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 37
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 37 6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 37
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 38
8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 39 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 39 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 40
8.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 40 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 40
8.1.2. HTTP Header Fields . . . . . . . . . . . . . . . . . . 42 8.1.1. Informational Responses . . . . . . . . . . . . . . . 41
8.1.3. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 43 8.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 41
8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 44 8.1.3. HTTP Header Fields . . . . . . . . . . . . . . . . . . 43
8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 44 8.1.4. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 45
8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 45 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 46
9. Additional HTTP Requirements/Considerations . . . . . . . . . 46 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 47
9.1. Connection Management . . . . . . . . . . . . . . . . . . 46 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 48
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 47 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . . 48
9.3. Frame Size Limits for HTTP . . . . . . . . . . . . . . . . 47 9. Additional HTTP Requirements/Considerations . . . . . . . . . 49
9.4. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 47 9.1. Connection Management . . . . . . . . . . . . . . . . . . 50
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 50
10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 48 9.3. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 51
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 48 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51
10.3. Cacheability of Pushed Resources . . . . . . . . . . . . . 48 10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 51
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 51
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 49 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . . 51
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10.4. Cacheability of Pushed Resources . . . . . . . . . . . . . 52
12.1. Frame Type Registry . . . . . . . . . . . . . . . . . . . 49 10.5. Denial of Service Considerations . . . . . . . . . . . . . 52
12.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 50 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 53
12.3. Settings Registry . . . . . . . . . . . . . . . . . . . . 51 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
12.4. HTTP2-Settings Header Field Registration . . . . . . . . . 51 12.1. Registration of HTTP/2.0 Identification String . . . . . . 54
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52 12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . . 54 12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
14.1. Normative References . . . . . . . . . . . . . . . . . . . 57
14.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 54 publication) . . . . . . . . . . . . . . . . . . . . 59
A.1. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 54 A.1. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59
A.2. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 54 A.2. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59
A.3. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 55 A.3. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59
A.4. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 55 A.4. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60
A.5. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 55 A.5. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60
A.6. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 56 A.6. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60
A.7. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 56 A.7. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61
A.8. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61
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) is optimized for implementation simplicity and accessibility, not 3) is optimized for implementation simplicity and accessibility, not
application performance. As such it has several characteristics that application performance. As such it has several characteristics that
have a negative overall effect on application performance. have a negative overall effect on application performance.
In particular, HTTP/1.0 only allows one request to be delivered at a In particular, HTTP/1.0 only allows one request to be outstanding at
time on a given connection. HTTP/1.1 pipelining only partially a time on a given connection. HTTP/1.1 pipelining only partially
addressed request concurrency, and is not widely deployed. addressed request concurrency and suffers from head-of-line blocking.
Therefore, clients that need to make many requests (as is common on Therefore, clients that need to make many requests typically use
the Web) typically use multiple connections to a server in order to multiple connections to a server in order to reduce latency.
reduce perceived latency.
Furthermore, HTTP/1.1 header fields are often repetitive and verbose, Furthermore, HTTP/1.1 header fields are often repetitive and verbose,
which, in addition to generating more or larger network packets, can which, in addition to generating more or larger network packets, can
cause the small initial TCP congestion window to quickly fill. This cause the small initial TCP congestion window to quickly fill. This
can result in excessive latency when multiple requests are made on a can result in excessive latency when multiple requests are made on a
single new TCP connection. single new TCP connection.
This document addresses these issues by defining an optimized mapping This document addresses these issues by defining an optimized mapping
of HTTP's semantics to an underlying connection. Specifically, it of HTTP's semantics to an underlying connection. Specifically, it
allows interleaving of request and response messages on the same allows interleaving of request and response messages on the same
connection and uses an efficient coding for HTTP header fields. It connection and uses an efficient coding for HTTP header fields. It
also allows prioritization of requests, letting more important also allows prioritization of requests, letting more important
requests complete more quickly, further improving perceived requests complete more quickly, further improving performance.
performance.
The resulting protocol is designed to be more friendly to the The resulting protocol is designed to be more friendly to the
network, because fewer TCP connections can be used, in comparison to network, because fewer TCP connections can be used, in comparison to
HTTP/1.x. This means less competition with other flows, and longer- HTTP/1.x. This means less competition with other flows, and longer-
lived connections, which in turn leads to better utilization of lived connections, which in turn leads to better utilization of
available network capacity. available network capacity.
Finally, this encapsulation also enables more scalable processing of Finally, this encapsulation also enables more scalable processing of
messages through use of binary message framing. messages through use of binary message framing.
skipping to change at page 6, line 23 skipping to change at page 6, line 22
unless otherwise indicated. Literal values are provided in decimal unless otherwise indicated. Literal values are provided in decimal
or hexadecimal as appropriate. Hexadecimal literals are prefixed or hexadecimal as appropriate. Hexadecimal literals are prefixed
with "0x" to distinguish them from decimal literals. with "0x" to distinguish them from decimal literals.
The following terms are used: The following terms are used:
client: The endpoint initiating the HTTP connection. client: The endpoint initiating the HTTP connection.
connection: A transport-level connection between two endpoints. connection: A transport-level connection between two endpoints.
connection error: An error on the HTTP/2.0 connection.
endpoint: Either the client or server of the connection. endpoint: Either the client or server of the connection.
frame: The smallest unit of communication within an HTTP/2.0 frame: The smallest unit of communication within an HTTP/2.0
connection, consisting of a header and a variable-length sequence connection, consisting of a header and a variable-length sequence
of bytes structured according to the frame type. of bytes structured according to the frame type.
peer: An endpoint. When discussing a particular endpoint, "peer" peer: An endpoint. When discussing a particular endpoint, "peer"
refers to the endpoint that is remote to the primary subject of refers to the endpoint that is remote to the primary subject of
discussion. discussion.
receiver: An endpoint that is receiving frames. receiver: An endpoint that is receiving frames.
sender: An endpoint that is transmitting frames. sender: An endpoint that is transmitting frames.
server: The endpoint which did not initiate the HTTP connection. server: The endpoint which did not initiate the HTTP connection.
connection error: An error on the HTTP/2.0 connection.
stream: A bi-directional flow of frames across a virtual channel stream: A bi-directional flow of frames across a virtual channel
within the HTTP/2.0 connection. within the HTTP/2.0 connection.
stream error: An error on the individual HTTP/2.0 stream. stream error: An error on the individual HTTP/2.0 stream.
2. HTTP/2.0 Protocol Overview 2. HTTP/2.0 Protocol Overview
HTTP/2.0 provides an optimized transport for HTTP semantics. HTTP/2.0 provides an optimized transport for HTTP semantics.
An HTTP/2.0 connection is an application level protocol running on An HTTP/2.0 connection is an application level protocol running on
top of a TCP connection ([RFC0793]). The client is the TCP top of a TCP connection ([TCP]). The client is the TCP connection
connection initiator. initiator.
This document describes the HTTP/2.0 protocol using a logical This document describes the HTTP/2.0 protocol using a logical
structure that is formed of three parts: framing, streams, and structure that is formed of three parts: framing, streams, and
application mapping. This structure is provided primarily as an aid application mapping. This structure is provided primarily as an aid
to specification, implementations are free to diverge from this to specification, implementations are free to diverge from this
structure as necessary. structure as necessary.
2.1. HTTP Frames 2.1. HTTP Frames
HTTP/2.0 provides an efficient serialization of HTTP semantics. HTTP HTTP/2.0 provides an efficient serialization of HTTP semantics. HTTP
requests and responses are encoded into length-prefixed frames (see requests and responses are encoded into length-prefixed frames (see
Section 4.1). Section 4.1).
HTTP headers are compressed into a series of frames that contain HTTP header fields are compressed into a series of frames that
header block fragments (see Section 4.3). contain header block fragments (see Section 4.3).
2.2. HTTP Multiplexing 2.2. HTTP Multiplexing
HTTP/2.0 provides the ability to multiplex multiple HTTP requests and HTTP/2.0 provides the ability to multiplex HTTP requests and
responses onto a single connection. Multiple requests or responses responses over a single connection. Multiple requests or responses
can be sent concurrently on a connection using streams (Section 5). can be sent concurrently on a connection using streams (Section 5).
In order to maintain independent streams, flow control and In order to maintain independent streams, flow control and
prioritization are necessary. prioritization are necessary.
2.3. HTTP Semantics 2.3. HTTP Semantics
HTTP/2.0 defines how HTTP requests and responses are mapped to HTTP/2.0 defines how HTTP requests and responses are mapped to
streams (see Section 8.1) and introduces a new interaction model, streams (see Section 8.1) and introduces a new interaction model,
server push (Section 8.2). server push (Section 8.2).
skipping to change at page 9, line 13 skipping to change at page 9, line 13
(Section 3.2.1) header field. (Section 3.2.1) header field.
For example: For example:
GET /default.htm HTTP/1.1 GET /default.htm HTTP/1.1
Host: server.example.com Host: server.example.com
Connection: Upgrade, HTTP2-Settings Connection: Upgrade, HTTP2-Settings
Upgrade: HTTP/2.0 Upgrade: HTTP/2.0
HTTP2-Settings: <base64url encoding of HTTP/2.0 SETTINGS payload> HTTP2-Settings: <base64url encoding of HTTP/2.0 SETTINGS payload>
Requests that contain a request entity body MUST be sent in their Requests that contain an entity body MUST be sent in their entirety
entirety before the client can send HTTP/2.0 frames. This means that before the client can send HTTP/2.0 frames. This means that a large
a large request entity can block the use of the connection until it request entity can block the use of the connection until it is
is completely sent. completely sent.
If concurrency of an initial request with subsequent requests is If concurrency of an initial request with subsequent requests is
important, a small request can be used to perform the upgrade to important, a small request can be used to perform the upgrade to
HTTP/2.0, at the cost of an additional round trip. HTTP/2.0, at the cost of an additional round trip.
A server that does not support HTTP/2.0 can respond to the request as A server that does not support HTTP/2.0 can respond to the request as
though the Upgrade header field were absent: though the Upgrade header field were absent:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-length: 243 Content-Length: 243
Content-type: text/html Content-Type: text/html
... ...
A server that supports HTTP/2.0 accepts the upgrade with a 101 A server that supports HTTP/2.0 can accept the upgrade with a 101
(Switching Protocols) status code. After the empty line that (Switching Protocols) response. After the empty line that terminates
terminates the 101 response, the server can begin sending HTTP/2.0 the 101 response, the server can begin sending HTTP/2.0 frames.
frames. These frames MUST include a response to the request that These frames MUST include a response to the request that initiated
initiated the Upgrade. the Upgrade.
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: Upgrade Connection: Upgrade
Upgrade: HTTP/2.0 Upgrade: HTTP/2.0
[ HTTP/2.0 connection ... [ HTTP/2.0 connection ...
The first HTTP/2.0 frame sent by the server is a SETTINGS frame The first HTTP/2.0 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 header (Section 3.5), which includes a SETTINGS frame. connection header (Section 3.5), which includes a SETTINGS frame.
The HTTP/1.1 request that is sent prior to upgrade is associated with The HTTP/1.1 request that is sent prior to upgrade is assigned stream
stream 1 and is assigned the highest possible priority. Stream 1 is identifier 1 and is assigned the highest possible priority. Stream 1
implicitly half closed from the client toward the server, since the is implicitly half closed from the client toward the server, since
request is completed as an HTTP/1.1 request. After commencing the the request is completed as an HTTP/1.1 request. After commencing
HTTP/2.0 connection, stream 1 is used for the response. the HTTP/2.0 connection, stream 1 is used for the response.
3.2.1. HTTP2-Settings Header Field 3.2.1. HTTP2-Settings Header Field
A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly A request that upgrades from HTTP/1.1 to HTTP/2.0 MUST include
one "HTTP2-Settings" header field. The "HTTP2-Settings" header field exactly one "HTTP2-Settings" header field. The "HTTP2-Settings"
is a hop-by-hop header field that includes settings that govern the header field is a hop-by-hop header field that includes settings that
HTTP/2.0 connection, provided in anticipation of the server accepting govern the HTTP/2.0 connection, provided in anticipation of the
the request to upgrade. A server MUST reject an attempt to upgrade server accepting the request to upgrade. A server MUST reject an
if this header is not present. attempt to upgrade if this header field is not present.
HTTP2-Settings = token68 HTTP2-Settings = token68
The content of the "HTTP2-Settings" header field is the payload of a The content of the "HTTP2-Settings" header field is the payload of a
SETTINGS frame (Section 6.5), encoded as a base64url string (that is, SETTINGS frame (Section 6.5), encoded as a base64url string (that is,
the URL- and filename-safe Base64 encoding described in Section 5 of the URL- and filename-safe Base64 encoding described in Section 5 of
[RFC4648], with any trailing '=' characters omitted). The ABNF [RFC4648], with any trailing '=' characters omitted). The ABNF
[RFC5234] production for "token68" is defined in Section 2.1 of [RFC5234] production for "token68" is defined in Section 2.1 of
[HTTP-p7]. [HTTP-p7].
skipping to change at page 11, line 15 skipping to change at page 11, line 15
(Section 3.5). This only affects the resolution of "http" URIs; (Section 3.5). This only affects the resolution of "http" URIs;
servers supporting HTTP/2.0 are required to support protocol servers supporting HTTP/2.0 are required to support protocol
negotiation in TLS [TLSALPN] for "https" URIs. negotiation in TLS [TLSALPN] for "https" URIs.
Prior support for HTTP/2.0 is not a strong signal that a given server Prior support for HTTP/2.0 is not a strong signal that a given server
will support HTTP/2.0 for future connections. It is possible for will support HTTP/2.0 for future connections. It is possible for
server configurations to change or for configurations to differ server configurations to change or for configurations to differ
between instances in clustered server. Interception proxies (a.k.a. between instances in clustered server. Interception proxies (a.k.a.
"transparent" proxies) are another source of variability. "transparent" proxies) are another source of variability.
3.5. Connection Header 3.5. HTTP/2.0 Connection Header
Upon establishment of a TCP connection and determination that Upon establishment of a TCP connection and determination that
HTTP/2.0 will be used by both peers, each endpoint MUST send a HTTP/2.0 will be used by both peers, each endpoint MUST send a
connection header as a final confirmation and to establish the connection header as a final confirmation and to establish the
initial settings for the HTTP/2.0 connection. initial settings for the HTTP/2.0 connection.
The client connection header is a sequence of 24 octets, which in hex The client connection header starts with a sequence of 24 octets,
notation are: which in hex notation are:
505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
(the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n") followed by a (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence is
SETTINGS frame (Section 6.5). The client sends the client connection followed by a SETTINGS frame (Section 6.5). The client sends the
header immediately upon receipt of a 101 Switching Protocols response client connection header immediately upon receipt of a 101 Switching
(indicating a successful upgrade), or as the first application data Protocols response (indicating a successful upgrade), or as the first
octets of a TLS connection. If starting an HTTP/2.0 connection with application data octets of a TLS connection. If starting an HTTP/2.0
prior knowledge of server support for the protocol, the client connection with prior knowledge of server support for the protocol,
connection header is sent upon connection establishment. the client connection header is sent upon connection establishment.
The client connection header is selected so that a large The client connection header is selected so that a large
proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do
not attempt to process further frames. Note that this does not not attempt to process further frames. Note that this does not
address the concerns raised in [TALKING]. address the concerns raised in [TALKING].
The server connection header consists of just a SETTINGS frame The server connection header consists of just a SETTINGS frame
(Section 6.5) that MUST be the first frame the server sends in the (Section 6.5) that MUST be the first frame the server sends in the
HTTP/2.0 connection. HTTP/2.0 connection.
skipping to change at page 12, line 18 skipping to change at page 12, line 18
using HTTP/2.0. using HTTP/2.0.
4. HTTP Frames 4. HTTP Frames
Once the HTTP/2.0 connection is established, endpoints can begin Once the HTTP/2.0 connection is established, endpoints can begin
exchanging frames. exchanging frames.
4.1. Frame Format 4.1. Frame Format
All frames begin with an 8-octet header followed by a payload of All frames begin with an 8-octet header followed by a payload of
between 0 and 65,535 octets. between 0 and 16383 octets.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (16) | Type (8) | Flags (8) | | R | Length (14) | Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+ +-+-+-----------+---------------+-------------------------------+
|R| Stream Identifier (31) | |R| Stream Identifier (31) |
+-+-------------------------------------------------------------+ +-+-------------------------------------------------------------+
| Frame Payload (0...) ... | Frame Payload (0...) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Frame Header Frame Header
The fields of the frame header are defined as: The fields of the frame header are defined as:
Length: The length of the frame payload expressed as an unsigned 16- R: A reserved 2-bit field. The semantics of these bits are undefined
and the bit MUST remain unset (0) when sending and MUST be ignored
when receiving.
Length: The length of the frame payload expressed as an unsigned 14-
bit integer. The 8 octets of the frame header are not included in bit integer. The 8 octets of the frame header are not included in
this value. this value.
Type: The 8-bit type of the frame. The frame type determines how Type: The 8-bit type of the frame. The frame type determines how
the remainder of the frame header and payload are interpreted. the remainder of the frame header and payload are interpreted.
Implementations MUST ignore frames of unsupported or unrecognized Implementations MUST ignore frames of unsupported or unrecognized
types. types.
Flags: An 8-bit field reserved for frame-type specific boolean Flags: An 8-bit field reserved for frame-type specific boolean
flags. flags.
Flags are assigned semantics specific to the indicated frame type. Flags are assigned semantics specific to the indicated frame type.
Flags that have no defined semantics for a particular frame type Flags that have no defined semantics for a particular frame type
MUST be ignored, and MUST be left unset (0) when sending. MUST be ignored, and MUST be left unset (0) when sending.
R: A reserved 1-bit field. The semantics of this bit are undefined R: A reserved 1-bit field. The semantics of this bit are undefined
and the bit MUST remain unset (0) when sending and MUST be ignored and the bit MUST remain unset (0) when sending and MUST be ignored
when receiving. when receiving.
Stream Identifier: A 31-bit stream identifier (see Section 5.1.1). Stream Identifier: A 31-bit stream identifier (see Section 5.1.1).
A value 0 is reserved for frames that are associated with the The value 0 is reserved for frames that are associated with the
connection as a whole as opposed to an individual stream. connection as a whole as opposed to an individual stream.
The structure and content of the frame payload is dependent entirely The structure and content of the frame payload is dependent entirely
on the frame type. on the frame type.
4.2. Frame Size 4.2. Frame Size
The maximum size of a frame payload varies by frame type and use. The maximum size of a frame payload varies by frame type. The
For instance, the HTTP/2.0 usage limits frames to 2^16-1 (16,383) absolute maximum size of a frame is 2^14-1 (16,383) octets. All
octets (Section 9.3). All implementations SHOULD be capable of implementations SHOULD be capable of receiving and minimally
receiving and minimally processing frames up to the maximum size. processing frames up to this maximum size.
Certain frame types, such as PING (see Section 6.7), impose Certain frame types, such as PING (see Section 6.7), impose
additional limits on the amount of payload data allowed. Likewise, additional limits on the amount of payload data allowed. Likewise,
additional size limits can be set by specific application uses (see additional size limits can be set by specific application uses (see
Section 9). Section 9).
If a frame size exceeds any defined limit, or is too small to contain If a frame size exceeds any defined limit, or is too small to contain
mandatory frame data, the endpoint MUST send a FRAME_TOO_LARGE error. mandatory frame data, the endpoint MUST send a FRAME_SIZE_ERROR
Frame size errors in frames that affect connection-level state MUST error. Frame size errors in frames that affect connection-level
be treated as a connection error (Section 5.4.1). state MUST be treated as a connection error (Section 5.4.1).
4.3. Header Compression and Decompression 4.3. Header Compression and Decompression
A header in HTTP/2.0 is a name-value pair with one or more associated A header field in HTTP/2.0 is a name-value pair with one or more
values. They are used within HTTP request and response messages as associated values. They are used within HTTP request and response
well as server push operations (see Section 8.2). messages as well as server push operations (see Section 8.2).
Header sets are logical collections of zero or more header fields Header sets are logical collections of zero or more header fields
arranged at the application layer. When transmitted over a arranged at the application layer. When transmitted over a
connection, the header set is serialized into a header block using connection, the header set is serialized into a header block using
HTTP Header Compression [COMPRESSION]. The serialized header block HTTP Header Compression [COMPRESSION]. The serialized header block
is then divided into one or more octet sequences, called header block is then divided into one or more octet sequences, called header block
fragments, and transmitted within the payload of HEADERS fragments, and transmitted within the payload of HEADERS
(Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION (Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION
(Section 6.10) frames. The receiving endpoint reassembles the header (Section 6.10) frames. The receiving endpoint reassembles the header
block by concatenating the individual fragments, then decompresses block by concatenating the individual fragments, then decompresses
skipping to change at page 14, line 22 skipping to change at page 14, line 22
with no interleaved frames of any other type, or from any other with no interleaved frames of any other type, or from any other
stream. The last frame in a sequence of HEADERS/CONTINUATION frames stream. The last frame in a sequence of HEADERS/CONTINUATION frames
MUST have the END_HEADERS flag set. The last frame in a sequence of MUST have the END_HEADERS flag set. The last frame in a sequence of
PUSH_PROMISE/CONTINUATION frames MUST have the END_PUSH_PROMISE/ PUSH_PROMISE/CONTINUATION frames MUST have the END_PUSH_PROMISE/
END_HEADERS flag set (respectively). END_HEADERS flag set (respectively).
HEADERS, PUSH_PROMISE and CONTINUATION frames carry data that can HEADERS, PUSH_PROMISE and CONTINUATION frames carry data that can
modify the compression context maintained by a receiver. An endpoint modify the compression context maintained by a receiver. An endpoint
receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST
reassemble header blocks and perform decompression even if the frames reassemble header blocks and perform decompression even if the frames
are to be discarded, which is likely to occur after a stream is are to be discarded. A receiver MUST terminate the connection with a
reset. A receiver MUST terminate the connection with a connection connection error (Section 5.4.1) of type COMPRESSION_ERROR, if it
error (Section 5.4.1) of type COMPRESSION_ERROR, if it does not does not decompress a header block.
decompress a header block.
5. Streams and Multiplexing 5. Streams and Multiplexing
A "stream" is an independent, bi-directional sequence of HEADERS and A "stream" is an independent, bi-directional sequence of HEADERS and
DATA frames exchanged between the client and server within an DATA frames exchanged between the client and server within an
HTTP/2.0 connection. Streams have several important characteristics: HTTP/2.0 connection. Streams have several important characteristics:
o A single HTTP/2.0 connection can contain multiple concurrently o A single HTTP/2.0 connection can contain multiple concurrently
active streams, with either endpoint interleaving frames from open streams, with either endpoint interleaving frames from
multiple streams. multiple streams.
o Streams can be established and used unilaterally or shared by o Streams can be established and used unilaterally or shared by
either the client or server. either the client or server.
o Streams can be closed by either endpoint. o Streams can be closed by either endpoint.
o The order in which frames are sent within a stream is significant. o The order in which frames are sent within a stream is significant.
Recipients process frames in the order they are received. Recipients process frames in the order they are received.
o Streams are identified by an integer. Stream identifiers are o Streams are identified by an integer. Stream identifiers are
assigned to streams by the endpoint that initiates a stream. assigned to streams by the initiating endpoint.
5.1. Stream States 5.1. Stream States
The lifecycle of a stream is shown in Figure 1. The lifecycle of a stream is shown in Figure 1.
+--------+ +--------+
PP | | PP PP | | PP
,--------| idle |--------. ,--------| idle |--------.
/ | | \ / | | \
v +--------+ v v +--------+ v
skipping to change at page 15, line 50 skipping to change at page 15, line 50
Streams have the following states: Streams have the following states:
idle: idle:
All streams start in the "idle" state. In this state, no frames All streams start in the "idle" state. In this state, no frames
have been exchanged. have been exchanged.
The following transitions are valid from this state: The following transitions are valid from this state:
* Sending or receiving a HEADERS frame causes the stream to * Sending or receiving a HEADERS frame causes the stream to
become "open". The stream identifier is selected as described become "open". The stream identifier is selected as described
in Section 5.1.1. in Section 5.1.1. The same HEADERS frame can also cause a
stream to immediately become "half closed".
* Sending a PUSH_PROMISE frame marks the associated stream for * Sending a PUSH_PROMISE frame marks the associated stream for
later use. The stream state for the reserved stream later use. The stream state for the reserved stream
transitions to "reserved (local)". transitions to "reserved (local)".
* Receiving a PUSH_PROMISE frame marks the associated stream as * Receiving a PUSH_PROMISE frame marks the associated stream as
reserved by the remote peer. The state of the stream becomes reserved by the remote peer. The state of the stream becomes
"reserved (remote)". "reserved (remote)".
reserved (local): reserved (local):
skipping to change at page 16, line 25 skipping to change at page 16, line 25
promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame
reserves an idle stream by associating the stream with an open reserves an idle stream by associating the stream with an open
stream that was initiated by the remote peer (see Section 8.2). stream that was initiated by the remote peer (see Section 8.2).
In this state, only the following transitions are possible: In this state, only the following transitions are possible:
* The endpoint can send a HEADERS frame. This causes the stream * The endpoint can send a HEADERS frame. This causes the stream
to open in a "half closed (remote)" state. to open in a "half closed (remote)" state.
* Either endpoint can send a RST_STREAM frame to cause the stream * Either endpoint can send a RST_STREAM frame to cause the stream
to become "closed". This also releases the stream reservation. to become "closed". This releases the stream reservation.
An endpoint MUST NOT send any other type of frame in this state. An endpoint MUST NOT send frames other than than HEADERS or
Receiving any frame other than RST_STREAM or PRIORITY MUST be RST_STREAM in this state.
treated as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. A PRIORITY frame MAY be received in this state. Receiving any
frame other than HEADERS, RST_STREAM, or PRIORITY MUST be treated
as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
reserved (remote): reserved (remote):
A stream in the "reserved (remote)" state has been reserved by a A stream in the "reserved (remote)" state has been reserved by a
remote peer. remote peer.
In this state, only the following transitions are possible: In this state, only the following transitions are possible:
* Receiving a HEADERS frame causes the stream to transition to * Receiving a HEADERS frame causes the stream to transition to
"half closed (local)". "half closed (local)".
* Either endpoint can send a RST_STREAM frame to cause the stream * Either endpoint can send a RST_STREAM frame to cause the stream
to become "closed". This also releases the stream reservation. to become "closed". This releases the stream reservation.
Receiving any other type of frame MUST be treated as a stream An endpoint MAY send a PRIORITY frame in this state to
error (Section 5.4.2) of type PROTOCOL_ERROR. An endpoint MAY reprioritize the reserved stream. An endpoint MUST NOT send any
send RST_STREAM or PRIORITY frames in this state to cancel or other type of frame other than RST_STREAM or PRIORITY.
reprioritize the reserved stream.
Receiving any other type of frame other than HEADERS or RST_STREAM
MUST be treated as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR.
open: open:
The "open" state is where both peers can send frames of any type. A stream in the "open" state may be used by both peers to send
In this state, sending peers observe advertised stream level flow frames of any type. In this state, sending peers observe
control limits (Section 5.2). advertised stream level flow control limits (Section 5.2).
From this state either endpoint can send a frame with a END_STREAM From this state either endpoint can send a frame with an
flag set, which causes the stream to transition into one of the END_STREAM flag set, which causes the stream to transition into
"half closed" states: an endpoint sending a END_STREAM flag causes one of the "half closed" states: an endpoint sending an END_STREAM
the stream state to become "half closed (local)"; an endpoint flag causes the stream state to become "half closed (local)"; an
receiving a END_STREAM flag causes the stream state to become endpoint receiving an END_STREAM flag causes the stream state to
"half closed (remote)". become "half closed (remote)". A HEADERS frame bearing an
END_STREAM flag can be followed by CONTINUATION frames.
Either endpoint can send a RST_STREAM frame from this state, Either endpoint can send a RST_STREAM frame from this state,
causing it to transition immediately to "closed". causing it to transition immediately to "closed".
half closed (local): half closed (local):
A stream that is "half closed (local)" cannot be used for sending A stream that is in the "half closed (local)" state cannot be used
frames. for sending frames.
A stream transitions from this state to "closed" when a frame that A stream transitions from this state to "closed" when a frame that
contains a END_STREAM flag is received, or when either peer sends contains an END_STREAM flag is received, or when either peer sends
a RST_STREAM frame. a RST_STREAM frame. A HEADERS frame bearing an END_STREAM flag
can be followed by CONTINUATION frames.
A receiver can ignore WINDOW_UPDATE or PRIORITY frames in this A receiver can ignore WINDOW_UPDATE or PRIORITY frames in this
state. These frame types might arrive for a short period after a state. These frame types might arrive for a short period after a
frame bearing the END_STREAM flag is sent. frame bearing the END_STREAM flag is sent.
half closed (remote): half closed (remote):
A stream that is "half closed (remote)" is no longer being used by A stream that is "half closed (remote)" is no longer being used by
the peer to send frames. In this state, an endpoint is no longer the peer to send frames. In this state, an endpoint is no longer
obligated to maintain a receiver flow control window if it obligated to maintain a receiver flow control window if it
performs flow control. performs flow control.
If an endpoint receives additional frames for a stream that is in If an endpoint receives additional frames for a stream that is in
this state it MUST respond with a stream error (Section 5.4.2) of this state, other than CONTINUATION frames, it MUST respond with a
type STREAM_CLOSED. stream error (Section 5.4.2) of type STREAM_CLOSED.
A stream can transition from this state to "closed" by sending a A stream can transition from this state to "closed" by sending a
frame that contains a END_STREAM flag, or when either peer sends a frame that contains a END_STREAM flag, or when either peer sends a
RST_STREAM frame. RST_STREAM frame.
closed: closed:
The "closed" state is the terminal state. The "closed" state is the terminal state.
An endpoint MUST NOT send frames on a closed stream. An endpoint An endpoint MUST NOT send frames on a closed stream. An endpoint
that receives a frame after receiving a RST_STREAM or a frame that receives any frame after receiving a RST_STREAM MUST treat
containing a END_STREAM flag on that stream MUST treat that as a that as a stream error (Section 5.4.2) of type STREAM_CLOSED.
stream error (Section 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint that receives any frame after receiving a
DATA frame with the END_STREAM flag set, or any frame except a
CONTINUATION frame after receiving a HEADERS frame with a
END_STREAM flag set MUST treat that as a stream error
(Section 5.4.2) of type STREAM_CLOSED.
WINDOW_UPDATE, PRIORITY, or RST_STREAM frames can be received in WINDOW_UPDATE, PRIORITY, or RST_STREAM frames can be received in
this state for a short period after a a frame containing an this state for a short period after a DATA or HEADERS frame
END_STREAM flag is sent. Until the remote peer receives and containing an END_STREAM flag is sent. Until the remote peer
processes the frame bearing the END_STREAM flag, it might send receives and processes the frame bearing the END_STREAM flag, it
frame of any of these types. Endpoints MUST ignore WINDOW_UPDATE, might send frame of any of these types. Endpoints MUST ignore
PRIORITY, or RST_STREAM frames received in this state, though WINDOW_UPDATE, PRIORITY, or RST_STREAM frames received in this
endpoints MAY choose to treat frames that arrive a significant state, though endpoints MAY choose to treat frames that arrive a
time after sending END_STREAM as a connection error significant time after sending END_STREAM as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
If this state is reached as a result of sending a RST_STREAM If this state is reached as a result of sending a RST_STREAM
frame, the peer that receives the RST_STREAM might have already frame, the peer that receives the RST_STREAM might have already
sent - or enqueued for sending - frames on the stream that cannot sent - or enqueued for sending - frames on the stream that cannot
be withdrawn. An endpoint MUST ignore frames that it receives on be withdrawn. An endpoint MUST ignore frames that it receives on
closed streams after it has sent a RST_STREAM frame. An endpoint closed streams after it has sent a RST_STREAM frame. An endpoint
MAY choose to limit the period over which it ignores frames and MAY choose to limit the period over which it ignores frames and
treat frames that arrive after this time as being in error. treat frames that arrive after this time as being in error.
skipping to change at page 20, line 25 skipping to change at page 20, line 42
and for the entire connection. This is a credit-based scheme. and for the entire connection. This is a credit-based scheme.
3. Flow control is directional with overall control provided by the 3. Flow control is directional with overall control provided by the
receiver. A receiver MAY choose to set any window size that it receiver. A receiver MAY choose to set any window size that it
desires for each stream and for the entire connection. A sender desires for each stream and for the entire connection. A sender
MUST respect flow control limits imposed by a receiver. Clients, MUST respect flow control limits imposed by a receiver. Clients,
servers and intermediaries all independently advertise their flow servers and intermediaries all independently advertise their flow
control preferences as a receiver and abide by the flow control control preferences as a receiver and abide by the flow control
limits set by their peer when sending. limits set by their peer when sending.
4. The initial value for the flow control window is 65535 bytes for 4. The initial value for the flow control window is 65,535 bytes for
both new streams and the overall connection. both new streams and the overall connection.
5. The frame type determines whether flow control applies to a 5. The frame type determines whether flow control applies to a
frame. Of the frames specified in this document, only DATA frame. Of the frames specified in this document, only DATA
frames are subject to flow control; all other frame types do not frames are subject to flow control; all other frame types do not
consume space in the advertised flow control window. This consume space in the advertised flow control window. This
ensures that important control frames are not blocked by flow ensures that important control frames are not blocked by flow
control. control.
6. Flow control can be disabled by a receiver. A receiver can 6. Flow control can be disabled by a receiver. A receiver can
skipping to change at page 21, line 51 skipping to change at page 22, line 22
The purpose of this value is to allow an endpoint to express the The purpose of this value is to allow an endpoint to express the
relative priority of a stream. An endpoint can use this information relative priority of a stream. An endpoint can use this information
to preferentially allocate resources to a stream. Within HTTP/2.0, to preferentially allocate resources to a stream. Within HTTP/2.0,
priority can be used to select streams for transmitting frames when priority can be used to select streams for transmitting frames when
there is limited capacity for sending. For instance, an endpoint there is limited capacity for sending. For instance, an endpoint
might enqueue frames for all concurrently active streams. As might enqueue frames for all concurrently active streams. As
transmission capacity becomes available, frames from higher priority transmission capacity becomes available, frames from higher priority
streams might be sent before lower priority streams. streams might be sent before lower priority streams.
Explicitly setting the priority for a stream does not guarantee any Explicitly setting the priority for a stream does not guarantee any
particular processing or transmision order for the stream relative to particular processing or transmission order for the stream relative
any other stream. Nor is there any mechanism provided by which the to any other stream. Nor is there any mechanism provided by which
initiator of a stream can force or require a receiving endpoint to the initiator of a stream can force or require a receiving endpoint
process concurrent streams in a particular order. to process concurrent streams in a particular order.
Unless explicitly specified in the HEADERS frame (Section 6.2) during Unless explicitly specified in the HEADERS frame (Section 6.2) during
stream creation, the default stream priority is 2^30. stream creation, the default stream priority is 2^30.
Pushed streams (Section 8.2) have a lower priority than their Pushed streams (Section 8.2) have a lower priority than their
associated stream. The promised stream inherits the priority value associated stream. The promised stream inherits the priority value
of the associated stream plus one, up to a maximum of 2^31-1. of the associated stream plus one, up to a maximum of 2^31-1.
5.4. Error Handling 5.4. Error Handling
skipping to change at page 24, line 45 skipping to change at page 25, line 22
HEADERS Frame Payload HEADERS Frame Payload
The HEADERS frame defines the following flags: The HEADERS frame defines the following flags:
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 a "half closed" state Setting this flag causes the stream to enter a "half closed" state
(Section 5.1). (Section 5.1).
A HEADERS frame that is followed by CONTINUATION frames carries
the flag that signals the end of a stream. A CONTINUATION frame
cannot be used to terminate a stream.
RESERVED (0x2): Bit 2 is reserved for future use. RESERVED (0x2): Bit 2 is reserved for future use.
END_HEADERS (0x4): The END_HEADERS bit indicates that this frame END_HEADERS (0x4): Bit 3 being set indicates that this frame ends
ends the sequence of header block fragments necessary to provide a the sequence of header block fragments necessary to provide a
complete set of headers. complete set of header fields.
The payload for a complete header block is provided by a sequence The payload for a complete header block is provided by a sequence
of that starts with a HEADERS frame, followed by zero or more of that starts with a HEADERS frame, followed by zero or more
CONTINUATION frames. The sequence is terminated by a frame with CONTINUATION frames. The sequence is terminated by a frame with
the END_HEADERS flag set. Once the sequence terminates, the the END_HEADERS flag set. Once the sequence terminates, the
payload of all HEADERS and CONTINUATION frames are concatenated payload of all HEADERS and CONTINUATION frames are concatenated
and interpreted as a single block. and interpreted as a single block.
A HEADERS frame without the END_HEADERS flag set MUST be followed A HEADERS frame without the END_HEADERS flag set MUST be followed
by a CONTINUATION frame for the same stream. A receiver MUST by a CONTINUATION frame for the same stream. A receiver MUST
skipping to change at page 27, line 36 skipping to change at page 28, line 16
Each setting in a SETTINGS frame replaces the existing value for that Each setting in a SETTINGS frame replaces the existing value for that
setting. Settings are processed in the order in which they appear, setting. Settings are processed in the order in which they appear,
and a receiver of a SETTINGS frame does not need to maintain any and a receiver of a SETTINGS frame does not need to maintain any
state other than the current value of settings. Therefore, the value state other than the current value of settings. Therefore, the value
of a setting is the last value that is seen by a receiver. This of a setting is the last value that is seen by a receiver. This
permits the inclusion of the same settings multiple times in the same permits the inclusion of the same settings multiple times in the same
SETTINGS frame, though doing so does nothing other than waste SETTINGS frame, though doing so does nothing other than waste
connection capacity. connection capacity.
The SETTINGS frame does not define any flags. The SETTINGS frame defines the following flag:
ACK (0x1): Bit 1 being set indicates that this frame acknowledges
receipt and application of the peer's SETTINGS frame. When this
bit is set, the payload of the SETTINGS frame MUST be empty.
Receipt of a SETTINGS frame with the ACK flag set and a length
field value other than 0 MUST be treated as a connection error
(Section 5.4.1) of type FRAME_SIZE_ERROR. For more info, see
Settings Synchronization (Section 6.5.3).
SETTINGS frames always apply to a connection, never a single stream. SETTINGS frames always apply to a connection, never a single stream.
The stream identifier for a settings frame MUST be zero. If an The stream identifier for a settings frame MUST be zero. If an
endpoint receives a SETTINGS frame whose stream identifier field is endpoint receives a SETTINGS frame whose stream identifier field is
anything other than 0x0, the endpoint MUST respond with a connection anything other than 0x0, the endpoint MUST respond with a connection
error (Section 5.4.1) of type PROTOCOL_ERROR. error (Section 5.4.1) of type PROTOCOL_ERROR.
The SETTINGS frame affects connection state. A badly formed or The SETTINGS frame affects connection state. A badly formed or
incomplete SETTINGS frame MUST be treated as a connection error incomplete SETTINGS frame MUST be treated as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
skipping to change at page 28, line 19 skipping to change at page 29, line 9
+---------------+-----------------------------------------------+ +---------------+-----------------------------------------------+
| Value (32) | | Value (32) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Setting Format Setting Format
6.5.2. Defined Settings 6.5.2. Defined Settings
The following settings are defined: The following settings are defined:
SETTINGS_MAX_CONCURRENT_STREAMS (4): indicates the maximum number of SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the
remote endpoint of the size of the header compression table used
to decode header blocks. The default value is 4096 bytes.
SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server
push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE
frame if it receives this setting set to a value of 0. The
default value is 1, which indicates that push is permitted.
SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of
concurrent streams that the sender will allow. This limit is concurrent streams that the sender will allow. This limit is
directional: it applies to the number of streams that the sender directional: it applies to the number of streams that the sender
permits the receiver to create. By default there is no limit. It permits the receiver to create. By default there is no limit. It
is recommended that this value be no smaller than 100, so as to is recommended that this value be no smaller than 100, so as to
not unnecessarily limit parallelism. not unnecessarily limit parallelism.
SETTINGS_INITIAL_WINDOW_SIZE (7): indicates the sender's initial SETTINGS_INITIAL_WINDOW_SIZE (7): Indicates the sender's initial
window size (in bytes) for stream level flow control. window size (in bytes) for stream level flow control.
This settings affects the window size of all streams, including This settings affects the window size of all streams, including
existing streams, see Section 6.9.2. existing streams, see Section 6.9.2.
SETTINGS_FLOW_CONTROL_OPTIONS (10): indicates flow control options. SETTINGS_FLOW_CONTROL_OPTIONS (10): Indicates flow control options.
The least significant bit (0x1) of the value is set to indicate The least significant bit (0x1) of the value is set to indicate
that the sender has disabled all flow control. This bit cannot be that the sender has disabled all flow control. This bit cannot be
cleared once set, see Section 6.9.4. cleared once set, see Section 6.9.4.
All bits other than the least significant are reserved. All bits other than the least significant are reserved.
6.5.3. Settings Synchronization
Most values in SETTINGS benefit from or require an understanding of
when the peer has received and applied the changed setting values.
In order to provide such synchronization timepoints, the recipient of
a SETTINGS frame in which the ACK flag is not set MUST apply the
updated settings as soon as possible upon receipt.
The values in the SETTINGS frame MUST be applied in sequence, with no
other frame processing between values. Once all values have been
applied, the recipient MUST immediately emit a SETTINGS frame with
the ACK flag set.
If the sender of a SETTINGS frame does not receive an acknowledgement
within a reasonable amount of time, it MAY issue a connection error
(Section 5.4.1) of type SETTINGS_TIMEOUT.
6.6. PUSH_PROMISE 6.6. PUSH_PROMISE
The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint
in advance of streams the sender intends to initiate. The in advance of streams the sender intends to initiate. The
PUSH_PROMISE frame includes the unsigned 31-bit identifier of the PUSH_PROMISE frame includes the unsigned 31-bit identifier of the
stream the endpoint plans to create along with a minimal set of stream the endpoint plans to create along with a minimal set of
headers that provide additional context for the stream. Section 8.2 headers that provide additional context for the stream. Section 8.2
contains a thorough description of the use of PUSH_PROMISE frames. contains a thorough description of the use of PUSH_PROMISE frames.
PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of
the peer endpoint is set to 0.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Promised-Stream-ID (31) | |X| Promised-Stream-ID (31) |
+-+-------------------------------------------------------------+ +-+-------------------------------------------------------------+
| Header Block Fragment (*) ... | Header Block Fragment (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
PUSH_PROMISE Payload Format PUSH_PROMISE Payload Format
skipping to change at page 31, line 5 skipping to change at page 32, line 19
| 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 PONG flag MUST send Receivers of a PING frame that does not include a ACK flag MUST send
a PING frame with the PONG flag set in response, with an identical a PING frame with the ACK flag set in response, with an identical
payload. PING responses SHOULD given higher priority than any other payload. PING responses SHOULD given higher priority than any other
frame. frame.
The PING frame defines the following flags: The PING frame defines the following flags:
PONG (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.
PING frames are not associated with any individual stream. If a PING PING frames are not associated with any individual stream. If a PING
frame is received with a stream identifier field value other than frame is received with a stream identifier field value other than
0x0, the recipient MUST respond with a connection error 0x0, the recipient MUST respond with a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
Receipt of a PING frame with a length field value other than 8 MUST Receipt of a PING frame with a length field value other than 8 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
PROTOCOL_ERROR. FRAME_SIZE_ERROR.
6.8. GOAWAY 6.8. GOAWAY
The GOAWAY frame (type=0x7) informs the remote peer to stop creating The GOAWAY frame (type=0x7) informs the remote peer to stop creating
streams on this connection. It can be sent from the client or the streams on this connection. It can be sent from the client or the
server. Once sent, the sender will ignore frames sent on new streams server. Once sent, the sender will ignore frames sent on new streams
for the remainder of the connection. Receivers of a GOAWAY frame for the remainder of the connection. Receivers of a GOAWAY frame
MUST NOT open additional streams on the connection, although a new MUST NOT open additional streams on the connection, although a new
connection can be established for new streams. The purpose of this connection can be established for new streams. The purpose of this
frame is to allow an endpoint to gracefully stop accepting new frame is to allow an endpoint to gracefully stop accepting new
skipping to change at page 35, line 25 skipping to change at page 36, line 39
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.
6.9.2. Initial Flow Control Window Size 6.9.2. Initial Flow Control Window Size
When a HTTP/2.0 connection is first established, new streams are When a HTTP/2.0 connection is first established, new streams are
created with an initial flow control window size of 65535 bytes. The created with an initial flow control window size of 65,535 bytes.
connection flow control window is 65535 bytes. Both endpoints can The connection flow control window is 65,535 bytes. Both endpoints
adjust the initial window size for new streams by including a value can adjust the initial window size for new streams by including a
for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that
part of the connection header. forms part of the connection header.
Prior to receiving a SETTINGS frame that sets a value for Prior to receiving a SETTINGS frame that sets a value for
SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default
initial window size when sending flow controlled frames. Similarly, initial window size when sending flow controlled frames. Similarly,
the connection flow control window is set to the default initial the connection flow control window is set to the default initial
window size until a WINDOW_UPDATE frame is received. window size until a WINDOW_UPDATE frame is received.
A SETTINGS frame can alter the initial flow control window size for A SETTINGS frame can alter the initial flow control window size for
all current streams. When the value of SETTINGS_INITIAL_WINDOW_SIZE all current streams. When the value of SETTINGS_INITIAL_WINDOW_SIZE
changes, a receiver MUST adjust the size of all stream flow control changes, a receiver MUST adjust the size of all stream flow control
skipping to change at page 36, line 39 skipping to change at page 38, line 5
sent in the SETTINGS. sent in the SETTINGS.
6.9.4. Ending Flow Control 6.9.4. Ending Flow Control
After a receiver reads in a frame that marks the end of a stream (for After a receiver reads in a frame that marks the end of a stream (for
example, a data stream with a END_STREAM flag set), it MUST cease example, a data stream with a END_STREAM flag set), it MUST cease
transmission of WINDOW_UPDATE frames for that stream. A sender is transmission of WINDOW_UPDATE frames for that stream. A sender is
not obligated to maintain the available flow control window for not obligated to maintain the available flow control window for
streams that it is no longer sending on. streams that it is no longer sending on.
Flow control can be disabled the entire connection using the Flow control can be disabled for the entire connection using the
SETTINGS_FLOW_CONTROL_OPTIONS setting. This setting ends all forms SETTINGS_FLOW_CONTROL_OPTIONS setting. This setting ends all forms
of flow control. An implementation that does not wish to perform of flow control. An implementation that does not wish to perform
flow control can use this in the initial SETTINGS exchange. flow control can use this in the initial SETTINGS exchange.
Flow control cannot be enabled again once disabled. Any attempt to Flow control cannot be enabled again once disabled. Any attempt to
re-enable flow control - by sending a WINDOW_UPDATE or by clearing re-enable flow control - by sending a WINDOW_UPDATE or by clearing
the bits on the SETTINGS_FLOW_CONTROL_OPTIONS setting - MUST be the bits on the SETTINGS_FLOW_CONTROL_OPTIONS setting - MUST be
rejected with a FLOW_CONTROL_ERROR error code. rejected with a FLOW_CONTROL_ERROR error code.
6.10. CONTINUATION 6.10. CONTINUATION
skipping to change at page 37, line 23 skipping to change at page 38, line 33
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block Fragment (*) ... | Header Block Fragment (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
CONTINUATION Frame Payload CONTINUATION Frame Payload
The CONTINUATION frame defines the following flags: The CONTINUATION frame defines the following flags:
END_STREAM (0x1): Bit 1 being set indicates that this frame is the
last that the endpoint will send for the identified stream.
Setting this flag causes the stream to enter a "half closed" or
"closed" state (Section 5.1). [[anchor12: We have not decided yet
if it is a good idea to keep this flag here since it could be used
to end a stream by being attached to a PUSH_PROMISE continuation.
See https://github.com/http2/http2-spec/issues/228 for details.]]
Unused (0x2): This flag is not currently used.
END_HEADERS (0x4): The END_HEADERS bit indicates that this frame END_HEADERS (0x4): The END_HEADERS bit indicates that this frame
ends the sequence of header block fragments necessary to provide a ends the sequence of header block fragments necessary to provide a
complete set of headers. complete set of header fields.
The payload for a complete header block is provided by a sequence The payload for a complete header block is provided by a sequence
that starts with a HEADERS or PUSH_PROMISE frame and zero or more that starts with a HEADERS or PUSH_PROMISE frame and zero or more
CONTINUATION frames, terminated by a HEADERS or CONTINUATION frame CONTINUATION frames, terminated by a HEADERS or CONTINUATION frame
with the END_HEADERS flag set, or PUSH_PROMISE frame with the with the END_HEADERS flag set, or PUSH_PROMISE frame with the
END_PUSH_PROMISE flag set. Once the sequence terminates, the END_PUSH_PROMISE flag set. Once the sequence terminates, the
payload of all frames in the sequence are concatenated and payload of all frames in the sequence are concatenated and
interpreted as a single block. interpreted as a single block.
A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the
skipping to change at page 38, line 13 skipping to change at page 39, line 13
(Section 4.3). (Section 4.3).
The CONTINUATION frame changes the connection state as defined in The CONTINUATION frame changes the connection state as defined in
Section 4.3. Section 4.3.
CONTINUATION frames MUST be associated with a stream. If a CONTINUATION frames MUST be associated with a stream. If a
CONTINUATION frame is received whose stream identifier field is 0x0, CONTINUATION frame is received whose stream identifier field is 0x0,
the recipient MUST respond with a connection error (Section 5.4.1) of the recipient MUST respond with a connection error (Section 5.4.1) of
type PROTOCOL_ERROR. type PROTOCOL_ERROR.
header block fragments (Section 4.3). A CONTINUATION frame MUST be A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or
preceded by one of HEADERS, PUSH_PROMISE or CONTINUATION frame. A CONTINUATION frame. A recipient that observes violation of this rule
recipient that observes violation of this rule MUST respond with a MUST respond with a connection error (Section 5.4.1) of type
connection error (Section 5.4.1) of type PROTOCOL_ERROR. PROTOCOL_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.
skipping to change at page 38, line 43 skipping to change at page 39, line 43
PROTOCOL_ERROR (1): The endpoint detected an unspecific protocol PROTOCOL_ERROR (1): The endpoint detected an unspecific protocol
error. This error is for use when a more specific error code is error. This error is for use when a more specific error code is
not available. not available.
INTERNAL_ERROR (2): The endpoint encountered an unexpected internal INTERNAL_ERROR (2): The endpoint encountered an unexpected internal
error. error.
FLOW_CONTROL_ERROR (3): The endpoint detected that its peer violated FLOW_CONTROL_ERROR (3): The endpoint detected that its peer violated
the flow control protocol. the flow control protocol.
SETTINGS_TIMEOUT (4): The endpoint sent a SETTINGS frame, but did
not receive a response in a timely manner. See Settings
Synchronization (Section 6.5.3).
STREAM_CLOSED (5): The endpoint received a frame after a stream was STREAM_CLOSED (5): The endpoint received a frame after a stream was
half closed. half closed.
FRAME_TOO_LARGE (6): The endpoint received a frame that was larger FRAME_SIZE_ERROR (6): The endpoint received a frame that was larger
than the maximum size that it supports. than the maximum size that it supports.
REFUSED_STREAM (7): The endpoint refuses the stream prior to REFUSED_STREAM (7): The endpoint refuses the stream prior to
performing any application processing, see Section 8.1.3 for performing any application processing, see Section 8.1.4 for
details. details.
CANCEL (8): Used by the endpoint to indicate that the stream is no CANCEL (8): Used by the endpoint to indicate that the stream is no
longer needed. longer needed.
COMPRESSION_ERROR (9): The endpoint is unable to maintain the COMPRESSION_ERROR (9): The endpoint is unable to maintain the
compression context for the connection. compression context for the connection.
CONNECT_ERROR (10): The connection established in response to a
CONNECT request (Section 8.3) was reset or abnormally closed.
ENHANCE_YOUR_CALM (420): The endpoint detected that its peer is
exhibiting a behavior over a given amount of time that has caused
it to refuse to process further frames.
8. HTTP Message Exchanges 8. HTTP Message Exchanges
HTTP/2.0 is intended to be as compatible as possible with current HTTP/2.0 is intended to be as compatible as possible with current
web-based applications. This means that, from the perspective of the web-based applications. This means that, from the perspective of the
server business logic or application API, the features of HTTP are server business logic or application API, the features of HTTP are
unchanged. To achieve this, all of the application request and unchanged. To achieve this, all of the application request and
response header semantics are preserved, although the syntax of response header semantics are preserved, although the syntax of
conveying those semantics has changed. Thus, the rules from HTTP/1.1 conveying those semantics has changed. Thus, the rules from HTTP/1.1
([HTTP-p1], [HTTP-p2], [HTTP-p4], [HTTP-p5], [HTTP-p6], and ([HTTP-p1], [HTTP-p2], [HTTP-p4], [HTTP-p5], [HTTP-p6], and
[HTTP-p7]) apply with the changes in the sections below. [HTTP-p7]) apply with the changes in the sections below.
skipping to change at page 39, line 39 skipping to change at page 41, line 5
1. a HEADERS frame; 1. a HEADERS frame;
2. one contiguous sequence of zero or more CONTINUATION frames; 2. one contiguous sequence of zero or more CONTINUATION frames;
3. zero or more DATA frames; and 3. zero or more DATA frames; and
4. optionally, a contiguous sequence that starts with a HEADERS 4. optionally, a contiguous sequence that starts with a HEADERS
frame, followed by zero or more CONTINUATION frames. frame, followed by zero or more CONTINUATION frames.
The last frame in the sequence bears an END_STREAM flag. The last frame in the sequence bears an END_STREAM flag, though a
HEADERS frame bearing the END_STREAM flag can be followed by
CONTINUATION frames that carry any remaining portions of the header
block.
Other frames MAY be interspersed with these frames, but those frames Other frames MAY be interspersed with these frames, but those frames
do not carry HTTP semantics. In particular, HEADERS frames (and any do not carry HTTP semantics. In particular, HEADERS frames (and any
CONTINUATION frames that follow) other than the first and optional CONTINUATION frames that follow) other than the first and optional
last frames in this sequence do not carry HTTP semantics. last frames in this sequence do not carry HTTP semantics.
Trailing header fields are carried in a header block that also Trailing header fields are carried in a header block that also
terminates the stream. That is, a sequence starting with a HEADERS terminates the stream. That is, a sequence starting with a HEADERS
frame, followed by zero or more CONTINUATION frames, that carries an frame, followed by zero or more CONTINUATION frames, where the
END_STREAM flag on the last frame. Header blocks after the first HEADERS frame bears an END_STREAM flag. Header blocks after the
that do not terminate the stream are not part of an HTTP request or first that do not terminate the stream are not part of an HTTP
response. request or response.
An HTTP request/response exchange fully consumes a single stream. A An HTTP request/response exchange fully consumes a single stream. A
request starts with the HEADERS frame that puts the stream into an request starts with the HEADERS frame that puts the stream into an
"open" state and ends with a frame bearing END_STREAM, which causes "open" state and ends with a frame bearing END_STREAM, which causes
the stream to become "half closed" for the client. A response starts the stream to become "half closed" for the client. A response starts
with a HEADERS frame and ends with a frame bearing END_STREAM, which with a HEADERS frame and ends with a frame bearing END_STREAM, which
places the stream in the "closed" state. places the stream in the "closed" state.
8.1.1. Examples 8.1.1. Informational Responses
For example, an HTTP GET request that includes request header fields [[anchor12: This section is likely to change significantly. This
and no body, is transmitted as a single contiguous sequence of only captures the high points.]]
HEADERS frames containing the serialized block of request header
fields. The last HEADERS frame in the sequence has both the The 1xx series of HTTP response codes ([HTTP-p2], Section 6.2) are
END_HEADERS and END_STREAM flag set: not supported by HTTP/2.0.
An intermediary that translates HTTP/1.1 requests to HTTP/2.0 MUST
generate any mandatory informational responses. For instance, a
translating intermediary generates a 100 (Continue) response if a
request includes an Expect header field with a "100-continue" token
([HTTP-p2], Section 5.1.1).
An intermediary that translates HTTP/1.1 responses to HTTP/2.0 MUST
ignore informational responses.
8.1.2. Examples
This section shows HTTP/1.1 requests and responses, with
illustrations of equivalent HTTP/2.0 requests and responses.
An HTTP GET request includes request header fields and no body and is
therefore transmitted as a single contiguous sequence of HEADERS
frames containing the serialized block of request header fields. The
last HEADERS frame in the sequence has both the END_HEADERS and
END_STREAM flag set:
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
:host = example.org :authority = example.org
:path = /resource :path = /resource
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 sequence of HEADERS frames containing the serialized transmitted as a sequence of HEADERS frames containing the serialized
block of response header fields. The last HEADERS frame in the block of response header fields. The last HEADERS frame in the
sequence has both the END_HEADERS and END_STREAM flag set: sequence has both the END_HEADERS and END_STREAM flag set:
HTTP/1.1 204 No Content HEADERS HTTP/1.1 204 No Content HEADERS
Content-Length: 0 ===> + END_STREAM Content-Length: 0 ===> + END_STREAM
+ END_HEADERS + END_HEADERS
:status = 204 :status = 204
content-length: 0 content-length: 0
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 headers followed by one CONTINUATION frames, containing the request header fields followed by
or more DATA frames, with the last CONTINUATION (or HEADERS) frame one or more DATA frames, with the last CONTINUATION (or HEADERS)
having the END_HEADERS flag set and the final DATA frame having the frame having the END_HEADERS flag set and the final DATA frame having
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 :scheme = https
{binary data} :host = example.org {binary data} :authority = example.org
:path = /resource :path = /resource
content-type = image/jpeg content-type = image/jpeg
content-length = 123 content-length = 123
DATA DATA
+ END_STREAM + END_STREAM
{binary data} {binary data}
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
skipping to change at page 42, line 8 skipping to change at page 43, line 26
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 sequence of HEADERS/CONTINUATION frames that bears the
trailers includes a terminal frame that has both END_HEADERS and trailers includes a terminal frame that has both END_HEADERS and
END_STREAM flags 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
Content-Length: 123 + END_HEADERS Content-Length: 123 + END_HEADERS
TE: trailers :status = 200 Transfer-Encoding: chunked :status = 200
TE: trailers content-length = 123
123 content-type = image/jpeg 123 content-type = image/jpeg
{binary data} content-length = 123 {binary data}
0 0 DATA
Foo: bar DATA Foo: bar - END_STREAM
- END_STREAM
{binary data} {binary data}
HEADERS HEADERS
+ END_STREAM + END_STREAM
+ END_HEADERS + END_HEADERS
foo: bar foo: bar
8.1.2. HTTP Header Fields 8.1.3. HTTP Header Fields
HTTP/2.0 request and response header fields carry information as a HTTP/2.0 request and response header fields carry information as a
series of key-value pairs. This includes the target URI for the series of key-value pairs. This includes the target URI for the
request, the status code for the response, as well as HTTP header request, the status code for the response, as well as HTTP header
fields. fields.
HTTP header field names are strings of ASCII characters that are HTTP header field names are strings of ASCII characters that are
compared in a case-insensitive fashion. Note that header compression compared in a case-insensitive fashion. Header field names MUST be
could cause case information to be lost. converted to lowercase prior to their encoding in HTTP/2.0. A
request or response containing uppercase header field names MUST be
treated as malformed (Section 8.1.3.3).
The semantics of HTTP header fields are not altered by this The semantics of HTTP header fields are not altered by this
specification, though header fields relating to connection management specification, though header fields relating to connection management
or request framing are no longer necessary. An HTTP/2.0 request or or request framing are no longer necessary. An HTTP/2.0 request or
response MUST NOT include any of the following header fields: response MUST NOT include any of the following header fields:
Connection, Host, Keep-Alive, Proxy-Connection, TE, Transfer- Connection, Keep-Alive, Proxy-Connection, TE, Transfer-Encoding, and
Encoding, and Upgrade. A server MUST treat the presence of any of Upgrade. A request or response containing these header fields MUST
these header fields as a stream error (Section 5.4.2) of type be treated as malformed (Section 8.1.3.3).
PROTOCOL_ERROR.
8.1.2.1. Request Header Fields Note: HTTP/2.0 purposefully does not support upgrade from HTTP/2.0
to another protocol. The handshake methods described in Section 3
are sufficient to negotiate the use of alternative protocols.
HTTP/2.0 defines a number of headers starting with a ':' character 8.1.3.1. Request Header Fields
that carry information about the request target:
HTTP/2.0 defines a number of header fields starting with a colon ':'
character that carry information about the request target:
o The ":method" header field includes the HTTP method ([HTTP-p2], o The ":method" header field includes the HTTP method ([HTTP-p2],
Section 4). Section 4).
o The ":scheme" header field includes the scheme portion of the o The ":scheme" header field includes the scheme portion of the
target URI ([RFC3986], Section 3.1). target URI ([RFC3986], Section 3.1).
o The ":host" header field includes the authority portion of the o The ":authority" header field includes the authority portion of
target URI ([RFC3986], Section 3.2). the target URI ([RFC3986], Section 3.2).
To ensure that the HTTP/1.1 request line can be reproduced
accurately, this header field MUST be omitted when translating
from an HTTP/1.1 request that has a request target in origin or
asterisk form (see [HTTP-p1], Section 5.3). Clients that generate
HTTP/2.0 requests directly SHOULD instead omit the "Host" header
field. An intermediary that converts a request to HTTP/1.1 MUST
create a "Host" header field if one is not present in a request by
copying the value of the ":authority" header field.
o The ":path" header field includes the path and query parts of the o The ":path" header field includes the path and query parts of the
target URI (the "path-absolute" production from [RFC3986] and target URI (the "path-absolute" production from [RFC3986] and
optionally a '?' character followed by the "query" production, see optionally a '?' character followed by the "query" production, see
[RFC3986], Section 3.3 and [RFC3986], Section 3.4). This field [RFC3986], Section 3.3 and [RFC3986], Section 3.4). This field
MUST NOT be empty; URIs that do not contain a path component MUST MUST NOT be empty; URIs that do not contain a path component MUST
include a value of '/', unless the request is an OPTIONS request include a value of '/', unless the request is an OPTIONS in
for '*', in which case the ":path" header field MUST include '*'. asterisk form, in which case the ":path" header field MUST include
'*'.
All HTTP/2.0 requests MUST include exactly one valid value for all of All HTTP/2.0 requests MUST include exactly one valid value for all of
these header fields. An intermediary MUST ensure that requests that these header fields, unless this is a CONNECT request (Section 8.3).
it forwards are correct. A server MUST treat the absence of any of An HTTP request that omits mandatory header fields is malformed
these header fields, presence of multiple values, or an invalid value (Section 8.1.3.3).
as a stream error (Section 5.4.2) of type PROTOCOL_ERROR.
Header field names that contain a colon are only valid in the
HTTP/2.0 context. These are not HTTP header fields. Implementations
MUST NOT generate header fields that start with a colon, but they
MUST ignore any header field that starts with a colon. In
particular, header fields with names starting with a colon MUST NOT
be exposed as HTTP header fields.
HTTP/2.0 does not define a way to carry the version identifier that HTTP/2.0 does not define a way to carry the version identifier that
is included in the HTTP/1.1 request line. is included in the HTTP/1.1 request line.
All HTTP Requests that include a body can include a "content-length" 8.1.3.2. Response Header Fields
header field. If a server receives a request where the sum of the
DATA frame payload lengths does not equal the value of the
"content-length" header field, the server MUST return a 400 (Bad
Request) error.
8.1.2.2. Response Header Fields
A single ":status" header field is defined that carries the HTTP A single ":status" header field is defined that carries the HTTP
status code field (see [HTTP-p2], Section 6). This header field MUST status code field (see [HTTP-p2], Section 6). This header field MUST
be included in all responses. An intermediary MUST ensure that it be included in all responses, otherwise the response is malformed
does not forward responses with absent or invalid values. A client (Section 8.1.3.3).
MUST treat the absence of the ":status"" header field, the presence
of multiple values, or an invalid value as a stream error
(Section 5.4.2) of type PROTOCOL_ERROR.
HTTP/2.0 does not define a way to carry the version or reason phrase HTTP/2.0 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line. that is included in an HTTP/1.1 status line.
8.1.3. Request Reliability Mechanisms in HTTP/2.0 8.1.3.3. Malformed Requests and Responses
A malformed request or response is one that uses a valid sequence of
HTTP/2.0 frames, but is otherwise invalid due to the presence of
prohibited header fields, the absence of mandatory header fields, or
the inclusion of uppercase header field names.
A request or response that includes an entity body can include a
"content-length" header field. A request or response is also
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.
Intermediaries MAY forward a malformed request or response, but only
if the frames are forwarded without inspection of header fields.
Implementations that detect malformed requests or responses need to
ensure that the stream ends. For malformed requests, a server MAY
send an HTTP response to prior to closing or resetting the stream.
Clients MUST NOT accept a malformed response.
8.1.4. Request Reliability Mechanisms in HTTP/2.0
In HTTP/1.1, an HTTP client is unable to retry a non-idempotent In HTTP/1.1, an HTTP client is unable to retry a non-idempotent
request when an error occurs, because there is no means to determine request when an error occurs, because there is no means to determine
the nature of the error. It is possible that some server processing the nature of the error. It is possible that some server processing
occurred prior to the error, which could result in undesirable occurred prior to the error, which could result in undesirable
effects if the request were reattempted. effects if the request were reattempted.
HTTP/2.0 provides two mechanisms for providing a guarantee to a HTTP/2.0 provides two mechanisms for providing a guarantee to a
client that a request has not been processed: client that a request has not been processed:
o The GOAWAY frame indicates the highest stream number that might o The GOAWAY frame indicates the highest stream number that might
have been processed. Requests on streams with higher numbers are have been processed. Requests on streams with higher numbers are
therefore guaranteed to be safe to retry. therefore guaranteed to be safe to retry.
o The REFUSED_STREAM error code can be included in a RST_STREAM o The REFUSED_STREAM error code can be included in a RST_STREAM
frame to indicate that the stream is being closed prior to any frame to indicate that the stream is being closed prior to any
processing having occurred. Any request that was sent on the processing having occurred. Any request that was sent on the
reset stream can be safely retried. reset stream can be safely retried.
In both cases, clients MAY automatically retry all requests, Clients MUST NOT treat requests that have not been processed as
having failed. Clients MAY automatically retry these requests,
including those with non-idempotent methods. including those with non-idempotent methods.
A server MUST NOT indicate that a stream has not been processed A server MUST NOT indicate that a stream has not been processed
unless it can guarantee that fact. If frames that are on a stream unless it can guarantee that fact. If frames that are on a stream
are passed to the application layer for any stream, then are passed to the application layer for any stream, then
REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame
MUST include a stream identifier that is greater than or equal to the MUST include a stream identifier that is greater than or equal to the
given stream identifier. given stream identifier.
In addition to these mechanisms, the PING frame provides a way for a In addition to these mechanisms, the PING frame provides a way for a
skipping to change at page 44, line 41 skipping to change at page 46, line 44
8.2. Server Push 8.2. Server Push
HTTP/2.0 enables a server to pre-emptively send (or "push") multiple HTTP/2.0 enables a server to pre-emptively send (or "push") multiple
associated resources to a client in response to a single request. associated resources to a client in response to a single request.
This feature becomes particularly helpful when the server knows the This feature becomes particularly helpful when the server knows the
client will need to have those resources available in order to fully client will need to have those resources available in order to fully
process the originally requested resource. process the originally requested resource.
Pushing additional resources is optional, and is negotiated only Pushing additional resources is optional, and is negotiated only
between individual endpoints. For instance, an intermediary could between individual endpoints. The SETTINGS_ENABLE_PUSH setting can
receive pushed resources from the server but is not required to be set to 0 to indicate that server push is disabled. Even if
forward those on to the client. How to make use of the pushed enabled, an intermediary could receive pushed resources from the
resources is up to that intermediary. Equally, the intermediary server but could choose not to forward those on to the client. How
might choose to push additional resources to the client, without any to make use of the pushed resources is up to that intermediary.
action taken by the server. Equally, the intermediary might choose to push additional resources
to the client, without any action taken by the server.
A server can only push requests that are safe (see [HTTP-p2], Section
4.2.1), cacheable (see [HTTP-p6], Section 3) and do 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. The PUSH_PROMISE frame, or frames, sent by the server request. The PUSH_PROMISE frame, or frames, sent by the server
includes a header block that contains a complete set of request includes a header block that contains a complete set of request
headers that the server attributes to the request. It is not header fields that the server attributes to the request. It is not
possible to push a response to a request that includes a request possible to push a response to a request that includes a request
body. body.
Pushed resources are always associated with an explicit request from Pushed resources are always associated with an explicit request from
a client. The PUSH_PROMISE frames sent by the server are sent on the a client. The PUSH_PROMISE frames sent by the server are sent on the
stream created for the original request. The PUSH_PROMISE frame stream created for the original request. The PUSH_PROMISE frame
includes a promised stream identifier, chosen from the stream includes a promised stream identifier, chosen from the stream
identifiers available to the server (see Section 5.1.1). identifiers available to the server (see Section 5.1.1).
The header fields in PUSH_PROMISE and any subsequent CONTINUATION The header fields in PUSH_PROMISE and any subsequent CONTINUATION
frames MUST be a valid and complete set of request headers frames MUST be a valid and complete set of request header fields
(Section 8.1.2.1). The server MUST include a method in the ":method" (Section 8.1.3.1). The server MUST include a method in the ":method"
header field that is safe (see [HTTP-p2], Section 4.2.1). If a header field that is safe and cacheable. If a client receives a
client receives a PUSH_PROMISE that does not include a complete and PUSH_PROMISE that does not include a complete and valid set of header
valid set of header fields, or the ":method" header field identifies fields, or the ":method" header field identifies a method that is not
a method that is not safe, it MUST respond with a stream error safe, it MUST respond with a stream error (Section 5.4.2) of type
(Section 5.4.2) of type PROTOCOL_ERROR. PROTOCOL_ERROR.
The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to
sending any frames that reference the promised resources. This sending any frames that reference the promised resources. This
avoids a race where clients issue requests for resources prior to avoids a race where clients issue requests for resources prior to
receiving any PUSH_PROMISE frames. receiving any PUSH_PROMISE frames.
For example, if the server receives a request for a document For example, if the server receives a request for a document
containing embedded links to multiple image files, and the server containing embedded links to multiple image files, and the server
chooses to push those additional images to the client, sending push chooses to push those additional images to the client, sending push
promises before the DATA frames that contain the image links ensure promises before the DATA frames that contain the image links ensure
that the client is able to see the promises before discovering the that the client is able to see the promises before discovering the
resources. Similarly, if the server pushes resources referenced by resources. Similarly, if the server pushes resources referenced by
the header block (for instance, in Link header fields), sending the the header block (for instance, in Link header fields), sending the
push promises before sending the header block ensures that clients do push promises before sending the header block ensures that clients do
not request those resources. not request those resources.
PUSH_PROMISE frames MUST NOT be sent by the client. PUSH_PROMISE PUSH_PROMISE frames MUST NOT be sent by the client. PUSH_PROMISE
frames can be sent by the server on any stream that was opened by the frames can be sent by the server on any stream that was opened by the
client. They MUST be sent on a stream that is in either the "open" client. They MUST be sent on a stream that is in either the "open"
or "half closed (remote)" to the server. PUSH_PROMISE frames are or "half closed (remote)" state to the server. PUSH_PROMISE frames
interspersed with the frames that comprise a response, though they are interspersed with the frames that comprise a response, though
cannot be interspersed with HEADERS and CONTINUATION frames that they cannot be interspersed with HEADERS and CONTINUATION frames that
comprise a single header block. comprise a single header block.
8.2.2. Push Responses 8.2.2. Push Responses
After sending the PUSH_PROMISE frame, the server can begin delivering After sending the PUSH_PROMISE frame, the server can begin delivering
the pushed resource as a response (Section 8.1.2.2) on a server- the pushed resource as a response (Section 8.1.3.2) on a server-
initiated stream that uses the promised stream identifier. The initiated stream that uses the promised stream identifier. The
server uses this stream to transmit an HTTP response, using the same server uses this stream to transmit an HTTP response, using the same
sequence of frames as defined in Section 8.1. This stream becomes sequence of frames as defined in Section 8.1. This stream becomes
"half closed" to the client (Section 5.1) after the initial HEADERS "half closed" to the client (Section 5.1) after the initial HEADERS
frame is sent. frame is sent.
Once a client receives a PUSH_PROMISE frame and chooses to accept the Once a client receives a PUSH_PROMISE frame and chooses to accept the
pushed resource, the client SHOULD NOT issue any requests for the pushed resource, the client SHOULD NOT issue any requests for the
promised resource until after the promised stream has closed. promised resource until after the promised stream has closed.
skipping to change at page 46, line 34 skipping to change at page 48, line 41
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 push the resource using the same-origin policy authorized to push the resource using the same-origin policy
([RFC6454], Section 3). For example, a HTTP/2.0 connection to ([RFC6454], Section 3). For example, a HTTP/2.0 connection to
"example.com" is generally [[anchor16: Ed: weaselly use of "example.com" is generally [[anchor16: Ed: weaselly use of
"generally", needs better definition]] not permitted to push a "generally", needs better definition]] not permitted to push a
response for "www.example.org". response for "www.example.org".
8.3. The CONNECT Method
The HTTP pseudo-method CONNECT ([HTTP-p2], Section 4.3.6) is used to
convert an HTTP/1.1 connection into a tunnel to a remote host.
CONNECT is primarily used with HTTP proxies to established a TLS
session with a server for the purposes of interacting with "https"
resources.
In HTTP/2.0, the CONNECT method is used to establish a tunnel over a
single HTTP/2.0 stream to a remote host. The HTTP header field
mapping works as mostly as defined in Request Header Fields
(Section 8.1.3.1), with a few differences. Specifically:
o The ":method" header field is set to "CONNECT".
o The ":scheme" and ":path" header fields MUST be omitted.
o The ":authority" header field contains the host and port to
connect to (equivalent to the authority-form of the request-target
of CONNECT requests, see [HTTP-p1], Section 5.3).
A proxy that supports CONNECT, establishes a TCP connection [TCP] to
the server identified in the ":path" header field. Once this
connection is successfully established, the proxy sends a HEADERS
frame containing a 2xx series status code, as defined in [HTTP-p2],
Section 4.3.6.
After the initial HEADERS frame sent by each peer, all subsequent
DATA frames correspond to data sent on the TCP connection. The
payload of any DATA frames sent by the client are transmitted by the
proxy to the TCP server; data received from the TCP server is
assembled into DATA frames by the proxy. Frame types other than DATA
or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY)
MUST NOT be sent on a connected stream, and MUST be treated as a
stream error (Section 5.4.2) if received.
The TCP connection can be closed by either peer. The END_STREAM flag
on a DATA frame is treated as being equivalent to the TCP FIN bit. A
client is expected to send a DATA frame with the END_STREAM flag set
after receiving a frame bearing the END_STREAM flag. A proxy that
receives a DATA frame with the END_STREAM flag set sends the attached
data with the FIN bit set on the last TCP segment. A proxy that
receives a TCP segment with the FIN bit set sends a DATA frame with
the END_STREAM flag set. Note that the final TCP segment or DATA
frame could be empty.
A TCP connection error is signaled with RST_STREAM. A proxy treats
any error in the TCP connection, which includes receiving a TCP
segment with the RST bit set, as a stream error (Section 5.4.2) of
type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment
with the RST bit set if it detects an error with the stream or the
HTTP/2.0 connection.
9. Additional HTTP Requirements/Considerations 9. Additional HTTP Requirements/Considerations
This section outlines attributes of the HTTP protocol that improve This section outlines attributes of the HTTP protocol that improve
interoperability, reduce exposure to known security vulnerabilities, interoperability, reduce exposure to known security vulnerabilities,
or reduce the potential for implementation variation. or reduce the potential for implementation variation.
9.1. Connection Management 9.1. Connection Management
HTTP/2.0 connections are persistent. For best performance, it is HTTP/2.0 connections are persistent. For best performance, it is
expected clients will not close connections until it is determined expected clients will not close connections until it is determined
skipping to change at page 47, line 37 skipping to change at page 51, line 5
A server that receives a TLS handshake that does not include either A server that receives a TLS handshake that does not include either
TLS 1.1 or SNI, MUST NOT negotiate HTTP/2.0. Removing HTTP/2.0 TLS 1.1 or SNI, MUST NOT negotiate HTTP/2.0. Removing HTTP/2.0
protocols from consideration could result in the removal of all protocols from consideration could result in the removal of all
protocols from the set of protocols offered by the client. This protocols from the set of protocols offered by the client. This
causes protocol negotiation failure, as described in Section 3.2 of causes protocol negotiation failure, as described in Section 3.2 of
[TLSALPN]. [TLSALPN].
Implementations are encouraged not to negotiate TLS cipher suites Implementations are encouraged not to negotiate TLS cipher suites
with known vulnerabilities, such as [RC4]. with known vulnerabilities, such as [RC4].
9.3. Frame Size Limits for HTTP 9.3. GZip Content-Encoding
Frames used for HTTP messages MUST NOT exceed 2^14-1 (16,383) octets
in length, not counting the 8 octet frame header. An endpoint MUST
treat the receipt of a larger frame as a FRAME_TOO_LARGE error (see
Section 4.2).
9.4. GZip Content-Encoding
Clients MUST support gzip compression for HTTP response bodies. Clients MUST support gzip compression for HTTP response bodies.
Regardless of the value of the accept-encoding header field, a server Regardless of the value of the accept-encoding header field, a server
MAY send responses with gzip or deflate encoding. A compressed MAY send responses with gzip or deflate encoding. A compressed
response MUST still bear an appropriate content-encoding header response MUST still bear an appropriate content-encoding header
field. field.
10. Security Considerations 10. Security Considerations
10.1. Server Authority and Same-Origin 10.1. Server Authority and Same-Origin
skipping to change at page 48, line 32 skipping to change at page 51, line 40
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
When using TLS, we believe that HTTP/2.0 introduces no new cross- When using TLS, we believe that HTTP/2.0 introduces no new cross-
protocol attacks. TLS encrypts the contents of all transmission protocol attacks. TLS encrypts the contents of all transmission
(except the handshake itself), making it difficult for attackers to (except the handshake itself), making it difficult for attackers to
control the data which could be used in a cross-protocol attack. control the data which could be used in a cross-protocol attack.
[[anchor23: Issue: This is no longer true]] [[anchor22: Issue: This is no longer true]]
10.3. Cacheability of Pushed Resources 10.3. Intermediary Encapsulation Attacks
HTTP/2.0 header field names and values are encoded as sequences of
octets with a length prefix. This enables HTTP/2.0 to carry any
string of octets as the name or value of a header field. An
intermediary that translates HTTP/2.0 requests or responses into
HTTP/1.1 directly could permit the creation of corrupted HTTP/1.1
messages. An attacker might exploit this behavior to cause the
intermediary to create HTTP/1.1 messages with illegal header fields,
extra header fields, or even new messages that are entirely
falsified.
An intermediary that performs translation into HTTP/1.1 cannot alter
the semantics of requests or responses. In particular, header field
names or values that contain characters not permitted by HTTP/1.1,
including carriage return (U+000D) or line feed (U+000A) MUST NOT be
translated verbatim, as stipulated in [HTTP-p1], Section 3.2.4.
Translation from HTTP/1.x to HTTP/2.0 does not produce the same
opportunity to an attacker. Intermediaries that perform translation
to HTTP/2.0 MUST remove any instances of the "obs-fold" production
from header field values.
10.4. Cacheability of Pushed Resources
Pushed resources are responses without an explicit request; the Pushed resources are responses without an explicit request; the
request for a pushed resource is synthesized from the request that request for a pushed resource is synthesized from the request that
triggered the push, plus resource identification information provided triggered the push, plus resource identification information provided
by the server. Request header fields are necessary for HTTP cache by the server. Request header fields are necessary for HTTP cache
control validations (such as the Vary header field) to work. For control validations (such as the Vary header field) to work. For
this reason, caches MUST inherit request header fields from the this reason, caches MUST inherit request header fields from the
associated stream for the push. This includes the Cookie header associated stream for the push. This includes the Cookie header
field. field.
skipping to change at page 49, line 12 skipping to change at page 52, line 43
Where multiple tenants share space on the same server, that server Where multiple tenants share space on the same server, that server
MUST ensure that tenants are not able to push representations of MUST ensure that tenants are not able to push representations of
resources that they do not have authority over. Failure to enforce resources that they do not have authority over. Failure to enforce
this would allow a tenant to provide a representation that would be this would allow a tenant to provide a representation that would be
served out of cache, overriding the actual representation that the served out of cache, overriding the actual representation that the
authoritative tenant provides. authoritative tenant provides.
Pushed resources for which an origin server is not authoritative are Pushed resources for which an origin server is not authoritative are
never cached or used. never cached or used.
10.5. Denial of Service Considerations
An HTTP/2.0 connection can demand a greater commitment of resources
to operate than a HTTP/1.1 connection. The use of header compression
and flow control require that an implementation commit resources for
storing a greater amount of state. Settings for these features
ensure that memory commitments for these features are strictly
bounded. Processing capacity cannot be guarded in the same fashion.
The SETTINGS frame can be abused to cause a peer to expend additional
processing time. This might be done by pointlessly changing
settings, setting multiple undefined settings, or changing the same
setting multiple times in the same frame. Similarly, WINDOW_UPDATE
or PRIORITY frames can be abused to cause an unnecessary waste of
resources.
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
are entirely legitimate, such as the sending of an empty DATA frame
to end a stream.
Header compression also offers some opportunities to waste processing
resources, see [COMPRESSION] for more details on potential abuses.
In all these cases, there are legitimate reasons to use these
protocol mechanisms. These features become a burden only when they
are used unnecessarily or to excess.
An endpoint that doesn't monitor this behavior exposes itself to a
risk of denial of service attack. Implementations SHOULD track the
use of these types of frames and set limits on their use. An
endpoint MAY treat activity that is suspicious as a connection error
(Section 5.4.1) of type ENHANCE_YOUR_CALM.
11. Privacy Considerations 11. Privacy Considerations
HTTP/2.0 aims to keep connections open longer between clients and HTTP/2.0 aims to keep connections open longer between clients and
servers in order to reduce the latency when a user makes a request. servers in order to reduce the latency when a user makes a request.
The maintenance of these connections over time could be used to The maintenance of these connections over time could be used to
expose private information. For example, a user using a browser expose private information. For example, a user using a browser
hours after the previous user stopped using that browser may be able hours after the previous user stopped using that browser may be able
to learn about what the previous user was doing. This is a problem to learn about what the previous user was doing. This is a problem
with HTTP in its current form as well, however the short lived with HTTP in its current form as well, however the short lived
connections make it less of a risk. connections make it less of a risk.
12. IANA Considerations 12. IANA Considerations
A string for identifying HTTP/2.0 is entered into the "Application
Layer Protocol Negotiation (ALPN) Protocol IDs" registry established
in [TLSALPN].
This document establishes registries for frame types, error codes and This document establishes registries for frame types, error codes and
settings. These new registries are entered in a new "Hypertext settings. These new registries are entered in a new "Hypertext
Transfer Protocol (HTTP) 2.0 Parameters" section. Transfer Protocol (HTTP) 2.0 Parameters" section.
This document also registers the "HTTP2-Settings" header field for This document registers the "HTTP2-Settings" header field for use in
use in HTTP. HTTP.
12.1. Frame Type Registry 12.1. Registration of HTTP/2.0 Identification String
This document creates a registration for the identification of
HTTP/2.0 in the "Application Layer Protocol Negotiation (ALPN)
Protocol IDs" registry established in [TLSALPN].
Protocol: HTTP/2.0
Identification Sequence: 0x48 0x54 0x54 0x50 0x2f 0x32 0x2e 0x30
("HTTP/2.0")
Specification: This document (RFCXXXX)
12.2. Frame Type Registry
This document establishes a registry for HTTP/2.0 frame types. The This document establishes a registry for HTTP/2.0 frame types. The
"HTTP/2.0 Frame Type" registry operates under the "IETF Review" "HTTP/2.0 Frame Type" registry operates under the "IETF Review"
policy [RFC5226]. policy [RFC5226].
Frame types are an 8-bit value. When reviewing new frame type Frame types are an 8-bit value. When reviewing new frame type
registrations, special attention is advised for any frame type- registrations, special attention is advised for any frame type-
specific flags that are defined. Frame flags can interact with specific flags that are defined. Frame flags can interact with
existing flags and could prevent the creation of globally applicable existing flags and could prevent the creation of globally applicable
flags. flags.
skipping to change at page 50, line 15 skipping to change at page 54, line 43
+--------+---------------+---------------------------+--------------+ +--------+---------------+---------------------------+--------------+
| Frame | Name | Flags | Section | | Frame | Name | Flags | Section |
| Type | | | | | Type | | | |
+--------+---------------+---------------------------+--------------+ +--------+---------------+---------------------------+--------------+
| 0 | DATA | END_STREAM(1) | Section 6.1 | | 0 | DATA | END_STREAM(1) | Section 6.1 |
| 1 | HEADERS | END_STREAM(1), | Section 6.2 | | 1 | HEADERS | END_STREAM(1), | Section 6.2 |
| | | END_HEADERS(4), | | | | | END_HEADERS(4), | |
| | | PRIORITY(8) | | | | | PRIORITY(8) | |
| 2 | PRIORITY | - | Section 6.3 | | 2 | PRIORITY | - | Section 6.3 |
| 3 | RST_STREAM | - | Section 6.4 | | 3 | RST_STREAM | - | Section 6.4 |
| 4 | SETTINGS | - | Section 6.5 | | 4 | SETTINGS | ACK(1) | Section 6.5 |
| 5 | PUSH_PROMISE | END_PUSH_PROMISE(1) | Section 6.6 | | 5 | PUSH_PROMISE | END_PUSH_PROMISE(4) | Section 6.6 |
| 6 | PING | PONG(1) | Section 6.7 | | 6 | PING | ACK(1) | Section 6.7 |
| 7 | GOAWAY | - | Section 6.8 | | 7 | GOAWAY | - | Section 6.8 |
| 9 | WINDOW_UPDATE | - | Section 6.9 | | 9 | WINDOW_UPDATE | - | Section 6.9 |
| 10 | CONTINUATION | END_STREAM(1), | Section 6.10 | | 10 | CONTINUATION | END_HEADERS(4) | Section 6.10 |
| | | END_HEADERS(4) | |
+--------+---------------+---------------------------+--------------+ +--------+---------------+---------------------------+--------------+
Table 1 Table 1
12.2. Error Code Registry 12.3. Error Code Registry
This document establishes a registry for HTTP/2.0 error codes. The This document establishes a registry for HTTP/2.0 error codes. The
"HTTP/2.0 Error Code" registry manages a 32-bit space. The "HTTP/2.0 "HTTP/2.0 Error Code" registry manages a 32-bit space. The "HTTP/2.0
Error Code" registry operates under the "Expert Review" policy Error Code" registry operates under the "Expert Review" policy
[RFC5226]. [RFC5226].
Registrations for error codes are required to include a description Registrations for error codes are required to include a description
of the error code. An expert reviewer is advised to examine new of the error code. An expert reviewer is advised to examine new
registrations for possible duplication with existing error codes. registrations for possible duplication with existing error codes.
Use of existing registrations is to be encouraged, but not mandated. Use of existing registrations is to be encouraged, but not mandated.
skipping to change at page 51, line 5 skipping to change at page 55, line 32
optional. optional.
Description: A description of the conditions where the error code is Description: A description of the conditions where the error code is
applicable. applicable.
Specification: An optional reference for a specification that Specification: An optional reference for a specification that
defines the error code. defines the error code.
An initial set of error code registrations can be found in Section 7. An initial set of error code registrations can be found in Section 7.
12.3. Settings Registry 12.4. Settings Registry
This document establishes a registry for HTTP/2.0 settings. The This document establishes a registry for HTTP/2.0 settings. The
"HTTP/2.0 Settings" registry manages a 24-bit space. The "HTTP/2.0 "HTTP/2.0 Settings" registry manages a 24-bit space. The "HTTP/2.0
Settings" registry operates under the "Expert Review" policy Settings" registry operates under the "Expert Review" policy
[RFC5226]. [RFC5226].
Registrations for settings are required to include a description of Registrations for settings are required to include a description of
the setting. An expert reviewer is advised to examine new the setting. An expert reviewer is advised to examine new
registrations for possible duplication with existing settings. Use registrations for possible duplication with existing settings. Use
of existing registrations is to be encouraged, but not mandated. of existing registrations is to be encouraged, but not mandated.
skipping to change at page 51, line 36 skipping to change at page 56, line 18
Description: A description of the setting. This might include the Description: A description of the setting. This might include the
range of values, any applicable units and how to act upon a value range of values, any applicable units and how to act upon a value
when it is provided. when it is provided.
Specification: An optional reference for a specification that Specification: An optional reference for a specification that
defines the setting. defines the setting.
An initial set of settings registrations can be found in An initial set of settings registrations can be found in
Section 6.5.2. Section 6.5.2.
12.4. HTTP2-Settings Header Field Registration 12.5. HTTP2-Settings Header Field Registration
This section registers the "HTTP2-Settings" header field in the This section registers the "HTTP2-Settings" header field in the
Permanent Message Header Field Registry [BCP90]. Permanent Message Header Field Registry [BCP90].
Header field name: HTTP2-Settings Header field name: HTTP2-Settings
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
skipping to change at page 52, line 4 skipping to change at page 56, line 32
Header field name: HTTP2-Settings Header field name: HTTP2-Settings
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): Section 3.2.1 of this document Specification document(s): Section 3.2.1 of this document
Related information: This header field is only used by an HTTP/2.0 Related information: This header field is only used by an HTTP/2.0
client for Upgrade-based negotiation. client for Upgrade-based negotiation.
13. Acknowledgements 13. Acknowledgements
This document includes substantial input from the following This document includes substantial input from the following
individuals: individuals:
o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa
Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam
Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay,
Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors). Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors).
o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism) o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism)
o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro,
Jitu Padhye, Roberto Peon, Rob Trace (Flow control) Jitu Padhye, Roberto Peon, Rob Trace (Flow control)
o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike
(Substantial editorial contributions) Bishop (Substantial editorial contributions)
14. References 14. References
14.1. Normative References 14.1. Normative References
[COMPRESSION] Ruellan, H. and R. Peon, "HTTP Header Compression", [COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression
draft-ietf-httpbis-header-compression-02 (work in for HTTP/2.0",
progress), August 2013. draft-ietf-httpbis-header-compression-04 (work in
progress), October 2013.
[HTTP-p1] Fielding, R. and J. Reschke, "Hypertext Transfer [HTTP-p1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Message Syntax and Routing", Transfer Protocol (HTTP/1.1): Message Syntax and
draft-ietf-httpbis-p1-messaging-23 (work in progress), Routing", draft-ietf-httpbis-p1-messaging-24 (work in
July 2013. progress), September 2013.
[HTTP-p2] Fielding, R. and J. Reschke, "Hypertext Transfer [HTTP-p2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-23 (work in progress), draft-ietf-httpbis-p2-semantics-24 (work in progress),
July 2013. September 2013.
[HTTP-p4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-23 (work in draft-ietf-httpbis-p4-conditional-24 (work in
progress), July 2013. progress), September 2013.
[HTTP-p5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, [HTTP-p5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-23 (work in Requests", draft-ietf-httpbis-p5-range-24 (work in
progress), July 2013. progress), September 2013.
[HTTP-p6] Fielding, R., Ed., Nottingham, M., Ed., and J. [HTTP-p6] Fielding, R., Ed., Nottingham, M., Ed., and J.
Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1):
Caching", draft-ietf-httpbis-p6-cache-23 (work in Caching", draft-ietf-httpbis-p6-cache-24 (work in
progress), July 2013. progress), September 2013.
[HTTP-p7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [HTTP-p7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-23 (work in progress), draft-ietf-httpbis-p7-auth-24 (work in progress),
July 2013. September 2013.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
skipping to change at page 53, line 40 skipping to change at page 58, line 18
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008. RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011. December 2011.
[TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[TLS-EXT] Eastlake, D., "Transport Layer Security (TLS) [TLS-EXT] Eastlake, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
January 2011. January 2011.
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer [TLS11] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, Security (TLS) Protocol Version 1.1", RFC 4346,
April 2006. April 2006.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008. August 2008.
[TLSALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, [TLSALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application Layer "Transport Layer Security (TLS) Application Layer
Protocol Negotiation Extension", Protocol Negotiation Extension",
draft-ietf-tls-applayerprotoneg-01 (work in progress), draft-ietf-tls-applayerprotoneg-02 (work in progress),
April 2013. September 2013.
14.2. Informative References 14.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
[RC4] Rivest, R., "The RC4 encryption algorithm", RSA Data [RC4] Rivest, R., "The RC4 encryption algorithm", RSA Data
Security, Inc. , March 1992. Security, Inc. , March 1992.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP
Extensions for High Performance", RFC 1323, May 1992. Extensions for High Performance", RFC 1323, May 1992.
[TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.
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>.
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-05 A.1. Since draft-ietf-httpbis-http2-06
Adding definition for CONNECT method.
Constraining the use of push to safe, cacheable methods with no
request body.
Changing from :host to :authority to remove any potential confusion.
Adding setting for header compression table size.
Adding settings acknowledgement.
Removing unnecessary and potentially problematic flags from
CONTINUATION.
Added denial of service considerations.
A.2. 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.2. Since draft-ietf-httpbis-http2-04 A.3. 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 55, line 12 skipping to change at page 60, line 12
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.3. Since draft-ietf-httpbis-http2-03 A.4. 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.4. Since draft-ietf-httpbis-http2-02 A.5. 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.5. Since draft-ietf-httpbis-http2-01 A.6. 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 56, line 23 skipping to change at page 61, line 23
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.6. Since draft-ietf-httpbis-http2-00 A.7. 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.7. Since draft-mbelshe-httpbis-spdy-00 A.8. 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. 133 change blocks. 
347 lines changed or deleted 601 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/