draft-ietf-httpbis-http2-05.txt   draft-ietf-httpbis-http2-06.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 14, 2014 Google, Inc Expires: February 22, 2014 Google, Inc
M. Thomson, Ed. M. Thomson, Ed.
Microsoft Microsoft
A. Melnikov, Ed. A. Melnikov, Ed.
Isode Ltd Isode Ltd
August 13, 2013 August 21, 2013
Hypertext Transfer Protocol version 2.0 Hypertext Transfer Protocol version 2.0
draft-ietf-httpbis-http2-05 draft-ietf-httpbis-http2-06
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). The HTTP/2.0 encapsulation
enables more efficient use of network resources and reduced enables more efficient use of network resources and reduced
perception of latency by allowing header field compression and perception of latency by allowing header field compression and
multiple concurrent messages on the same connection. It also multiple concurrent messages on the same connection. It also
introduces unsolicited push of representations from servers to introduces unsolicited push of representations from servers to
clients. clients.
This document is an alternative to, but does not obsolete the This document is an alternative to, but does not obsolete the
HTTP/1.1 message format or protocol. HTTP's existing semantics HTTP/1.1 message format or protocol. HTTP's existing semantics
remain unchanged. remain unchanged.
This version of the draft has been marked for implementation.
Interoperability testing will occur in the HTTP/2.0 interim in
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
tracker). tracker).
skipping to change at page 2, line 12 skipping to change at page 2, line 16
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 14, 2014. This Internet-Draft will expire on February 22, 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 3, line 6 skipping to change at page 3, line 10
3.5. Connection Header . . . . . . . . . . . . . . . . . . . . 11 3.5. 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 . . . . . . . . . . . . . . . . . . 18
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . 22
5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 23 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 23
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 29 skipping to change at page 3, line 33
6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 27 6.5.1. Setting Format . . . . . . . . . . . . . . . . . . . . 27
6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 28 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . . 28
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 28 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 28
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 33 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 33
6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 34 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 34
6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 35 6.9.2. Initial Flow Control Window Size . . . . . . . . . . . 35
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 36 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 36
6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 36 6.9.4. Ending Flow Control . . . . . . . . . . . . . . . . . 36
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 36 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 37
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 38
8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 38 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . . 39
8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 39 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . . 39
8.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 39 8.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 40
8.1.2. HTTP Header Fields . . . . . . . . . . . . . . . . . . 41 8.1.2. HTTP Header Fields . . . . . . . . . . . . . . . . . . 42
8.1.3. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 43 8.1.3. Request Reliability Mechanisms in HTTP/2.0 . . . . . . 43
8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 43 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 44 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 44
8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 45 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . . 45
9. Additional HTTP Requirements/Considerations . . . . . . . . . 46 9. Additional HTTP Requirements/Considerations . . . . . . . . . 46
9.1. Connection Management . . . . . . . . . . . . . . . . . . 46 9.1. Connection Management . . . . . . . . . . . . . . . . . . 46
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 46 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 47
9.3. Frame Size Limits for HTTP . . . . . . . . . . . . . . . . 47 9.3. Frame Size Limits for HTTP . . . . . . . . . . . . . . . . 47
9.4. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 47 9.4. GZip Content-Encoding . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 47 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 47 10.1. Server Authority and Same-Origin . . . . . . . . . . . . . 48
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 47 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . . 48
10.3. Cacheability of Pushed Resources . . . . . . . . . . . . . 48 10.3. Cacheability of Pushed Resources . . . . . . . . . . . . . 48
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 48
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 49
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12.1. Frame Type Registry . . . . . . . . . . . . . . . . . . . 49 12.1. Frame Type Registry . . . . . . . . . . . . . . . . . . . 49
12.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 49 12.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 50
12.3. Settings Registry . . . . . . . . . . . . . . . . . . . . 50 12.3. Settings Registry . . . . . . . . . . . . . . . . . . . . 51
12.4. HTTP2-Settings Header Field Registration . . . . . . . . . 51 12.4. HTTP2-Settings Header Field Registration . . . . . . . . . 51
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 51 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 53 publication) . . . . . . . . . . . . . . . . . . . . 54
A.1. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 53 A.1. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 54
A.2. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 54 A.2. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 54
A.3. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 54 A.3. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 55
A.4. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 54 A.4. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 55
A.5. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 55 A.5. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 55
A.6. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 55 A.6. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 56
A.7. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 56
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 delivered at a
skipping to change at page 13, line 19 skipping to change at page 13, line 19
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 A 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 and use.
The absolute maximum size is 65,535 octets. All implementations For instance, the HTTP/2.0 usage limits frames to 2^16-1 (16,383)
SHOULD be capable of receiving and minimally processing frames up to octets (Section 9.3). All implementations SHOULD be capable of
this size. receiving and minimally processing frames up to the 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_TOO_LARGE error.
Frame size errors in frames that affect connection-level state MUST Frame size errors in frames that affect connection-level state MUST
be treated as a connection error (Section 5.4.1). be treated as a connection error (Section 5.4.1).
skipping to change at page 17, line 49 skipping to change at page 17, line 49
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 a frame after receiving a RST_STREAM or a frame
containing a END_STREAM flag on that stream MUST treat that as a containing a END_STREAM flag on that stream MUST treat that as a
stream error (Section 5.4.2) of type STREAM_CLOSED. stream error (Section 5.4.2) of type STREAM_CLOSED.
WINDOW_UPDATE or PRIORITY frames can be received in this state for WINDOW_UPDATE, PRIORITY, or RST_STREAM frames can be received in
a short period after a a frame containing an END_STREAM flag is this state for a short period after a a frame containing an
sent. Until the remote peer receives and processes the frame END_STREAM flag is sent. Until the remote peer receives and
bearing the END_STREAM flag, it might send either frame type. processes the frame bearing the END_STREAM flag, it might send
frame of any of these types. Endpoints MUST ignore WINDOW_UPDATE,
Endpoints MUST ignore WINDOW_UPDATE frames received in this state, PRIORITY, or RST_STREAM frames received in this state, though
though endpoints MAY choose to treat WINDOW_UPDATE frames that endpoints MAY choose to treat frames that arrive a significant
arrive a significant time after sending END_STREAM as a connection time after sending END_STREAM as a connection error
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.
Flow controlled frames (i.e., DATA) received after sending Flow controlled frames (i.e., DATA) received after sending
RST_STREAM are counted toward the connection flow control window. RST_STREAM are counted toward the connection flow control window.
Even though these frames might be ignored, because they are sent Even though these frames might be ignored, because they are sent
before the sender receives the RST_STREAM, the sender will before the sender receives the RST_STREAM, the sender will
consider the frames to count against the flow control window. consider the frames to count against the flow control window.
An endpoint might receive a PUSH_PROMISE or a CONTINUATION frame An endpoint might receive a PUSH_PROMISE frame after it sends
after it sends RST_STREAM. PUSH_PROMISE causes a stream to become RST_STREAM. PUSH_PROMISE causes a stream to become "reserved".
"reserved". If promised streams are not desired, a RST_STREAM can The RST_STREAM does not cancel any promised stream. Therefore, if
be used to close any of those streams. promised streams are not desired, a RST_STREAM can be used to
close any of those streams.
In the absence of more specific guidance elsewhere in this document, In the absence of more specific guidance elsewhere in this document,
implementations SHOULD treat the receipt of a message that is not implementations SHOULD treat the receipt of a message that is not
expressly permitted in the description of a state as a connection expressly permitted in the description of a state as a connection
error (Section 5.4.1) of type PROTOCOL_ERROR. error (Section 5.4.1) of type PROTOCOL_ERROR.
5.1.1. Stream Identifiers 5.1.1. Stream Identifiers
Streams are identified with an unsigned 31-bit integer. Streams Streams are identified with an unsigned 31-bit integer. Streams
initiated by a client MUST use odd-numbered stream identifiers; those initiated by a client MUST use odd-numbered stream identifiers; those
initiated by the server MUST use even-numbered stream identifiers. A initiated by the server MUST use even-numbered stream identifiers. A
stream identifier of zero (0x0) is used for connection control stream identifier of zero (0x0) is used for connection control
message; the stream identifier zero MUST NOT be used to establish a message; the stream identifier zero MUST NOT be used to establish a
new stream. A stream identifier of one (0x1) is used to respond to new stream.
the HTTP/1.1 request which was specified during Upgrade (see
Section 3.2); the stream identifier one MUST NOT be used to establish A stream identifier of one (0x1) is used to respond to the HTTP/1.1
a new stream. request which was specified during Upgrade (see Section 3.2). After
the upgrade completes, stream 0x1 is "half closed (local)" to the
client. Therefore, stream 0x1 cannot be selected as a new stream
identifier by a client that upgrades from HTTP/1.1.
The identifier of a newly established stream MUST be numerically The identifier of a newly established stream MUST be numerically
greater than all streams that the initiating endpoint has opened or greater than all streams that the initiating endpoint has opened or
reserved. This governs streams that are opened using a HEADERS frame reserved. This governs streams that are opened using a HEADERS frame
and streams that are reserved using PUSH_PROMISE. An endpoint that and streams that are reserved using PUSH_PROMISE. An endpoint that
receives an unexpected stream identifier MUST respond with a receives an unexpected stream identifier MUST respond with a
connection error (Section 5.4.1) of type PROTOCOL_ERROR. connection error (Section 5.4.1) of type PROTOCOL_ERROR.
The first use of a new stream identifier implicitly closes all idle The first use of a new stream identifier implicitly closes all
streams that might have been initiated by that peer with a lower- streams in the "idle" state that might have been initiated by that
valued stream identifier. peer with a lower-valued stream identifier. For example, if a client
sends a HEADERS frame on stream 7 without ever sending a frame on
stream 5, then stream 5 transitions to the "closed" state when the
first frame for stream 7 is sent or received.
Stream identifiers cannot be reused. Long-lived connections can Stream identifiers cannot be reused. Long-lived connections can
result in endpoint exhausting the available range of stream result in endpoint exhausting the available range of stream
identifiers. A client that is unable to establish a new stream identifiers. A client that is unable to establish a new stream
identifier can establish a new connection for new streams. identifier can establish a new connection for new streams.
5.1.2. Stream Concurrency 5.1.2. Stream Concurrency
A peer can limit the number of concurrently active streams using the A peer can limit the number of concurrently active streams using the
SETTINGS_MAX_CONCURRENT_STREAMS parameters within a SETTINGS frame. SETTINGS_MAX_CONCURRENT_STREAMS parameters within a SETTINGS frame.
skipping to change at page 19, line 48 skipping to change at page 20, line 7
TCP connection, resulting in blocked streams. A flow control scheme TCP connection, resulting in blocked streams. A flow control scheme
ensures that streams on the same connection do not destructively ensures that streams on the same connection do not destructively
interfere with each other. Flow control is used for both individual interfere with each other. Flow control is used for both individual
streams and for the connection as a whole. streams and for the connection as a whole.
HTTP/2.0 provides for flow control through use of the WINDOW_UPDATE HTTP/2.0 provides for flow control through use of the WINDOW_UPDATE
frame type. frame type.
5.2.1. Flow Control Principles 5.2.1. Flow Control Principles
Experience with TCP congestion control has shown that algorithms can
evolve over time to become more sophisticated without requiring
protocol changes. TCP congestion control and its evolution is
clearly different from HTTP/2.0 flow control, though the evolution of
TCP congestion control algorithms shows that a similar approach could
be feasible for HTTP/2.0 flow control.
HTTP/2.0 stream flow control aims to allow for future improvements to HTTP/2.0 stream flow control aims to allow for future improvements to
flow control algorithms without requiring protocol changes. Flow flow control algorithms without requiring protocol changes. Flow
control in HTTP/2.0 has the following characteristics: control in HTTP/2.0 has the following characteristics:
1. Flow control is hop-by-hop, not end-to-end. 1. Flow control is hop-by-hop, not end-to-end.
2. Flow control is based on window update frames. Receivers 2. Flow control is based on window update frames. Receivers
advertise how many bytes they are prepared to receive on a stream advertise how many bytes they are prepared to receive on a stream
and for the entire connection. This is a credit-based scheme. and for the entire connection. This is a credit-based scheme.
skipping to change at page 29, line 31 skipping to change at page 29, line 31
Following the "Promised-Stream-ID" is a header block fragment Following the "Promised-Stream-ID" is a header block fragment
(Section 4.3). (Section 4.3).
PUSH_PROMISE frames MUST be associated with an existing, peer- PUSH_PROMISE frames MUST be associated with an existing, peer-
initiated stream. If the stream identifier field specifies the value initiated stream. If the stream identifier field specifies the value
0x0, a recipient MUST respond with a connection error (Section 5.4.1) 0x0, a recipient MUST respond with a connection error (Section 5.4.1)
of type PROTOCOL_ERROR. of type PROTOCOL_ERROR.
The PUSH_PROMISE frame defines the following flags: The PUSH_PROMISE frame defines the following flags:
END_PUSH_PROMISE (0x1): The END_PUSH_PROMISE bit indicates that this END_PUSH_PROMISE (0x4): The END_PUSH_PROMISE bit indicates that this
frame ends the sequence of header block fragments necessary to frame ends the sequence of header block fragments necessary to
provide a complete set of headers. provide a complete set of headers.
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 PUSH_PROMISE frames, terminated by a PUSH_PROMISE frame with of frames that starts with a PUSH_PROMISE frame, followed by zero
the END_PUSH_PROMISE flag set. Once the sequence terminates, the or more CONTINUATION frames. The sequence terminates by a
payload of all PUSH_PROMISE frames are concatenated and PUSH_PROMISE frame with the END_PUSH_PROMISE flag set or a
interpreted as a single block. CONTINUATION frame with the END_HEADERS flag set. Once the
sequence terminates, the payload of all frames in the sequence are
concatenated and interpreted as a single block.
A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be
followed by a PUSH_PROMISE frame for the same stream. A receiver followed by a CONTINUATION frame for the same stream. A receiver
MUST treat the receipt of any other type of frame or a frame on a MUST treat the receipt of any other type of frame or a frame on a
different stream as a connection error (Section 5.4.1) of type different stream as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
Promised streams are not required to be used in order promised. The Promised streams are not required to be used in order promised. The
PUSH_PROMISE only reserves stream identifiers for later use. PUSH_PROMISE only reserves stream identifiers for later use.
Recipients of PUSH_PROMISE frames can choose to reject promised Recipients of PUSH_PROMISE frames can choose to reject promised
streams by returning a RST_STREAM referencing the promised stream streams by returning a RST_STREAM referencing the promised stream
identifier back to the sender of the PUSH_PROMISE. identifier back to the sender of the PUSH_PROMISE.
skipping to change at page 30, line 26 skipping to change at page 30, line 28
state). state).
Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame
causes the stream state to become indeterminate. A receiver MUST causes the stream state to become indeterminate. A receiver MUST
treat the receipt of a PUSH_PROMISE on a stream that is neither treat the receipt of a PUSH_PROMISE on a stream that is neither
"open" nor "half-closed (local)" as a connection error "open" nor "half-closed (local)" as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. Similarly, a receiver MUST (Section 5.4.1) of type PROTOCOL_ERROR. Similarly, a receiver MUST
treat the receipt of a PUSH_PROMISE that promises an illegal stream treat the receipt of a PUSH_PROMISE that promises an illegal stream
identifier (Section 5.1.1) (that is, an identifier for a stream that identifier (Section 5.1.1) (that is, an identifier for a stream that
is not currently in the "idle" state) as a connection error is not currently in the "idle" state) as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR, unless the receiver recently
sent a RST_STREAM frame to cancel the associated stream (see
Section 5.1).
6.7. PING 6.7. PING
The PING frame (type=0x6) is a mechanism for measuring a minimal The PING frame (type=0x6) is a mechanism for measuring a minimal
round-trip time from the sender, as well as determining whether an round-trip time from the sender, as well as determining whether an
idle connection is still functional. PING frames can be sent from idle connection is still functional. PING frames can be sent from
any endpoint. any endpoint.
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
skipping to change at page 37, line 18 skipping to change at page 37, line 26
| 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 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" or Setting this flag causes the stream to enter a "half closed" or
"closed" state (Section 5.1). "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.]]
END_HEADERS (0x2): The END_HEADERS bit indicates that this frame Unused (0x2): This flag is not currently used.
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 headers.
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, PUSH_PROMISE, or CONTINUATION frames, terminated by a HEADERS or CONTINUATION frame
CONTINUATION frame with the END_HEADERS flag set. Once the with the END_HEADERS flag set, or PUSH_PROMISE frame with the
sequence terminates, the payload of all frames in the sequence are END_PUSH_PROMISE flag set. Once the sequence terminates, the
concatenated and interpreted as a single block. payload of all frames in the sequence are concatenated and
interpreted as a single block.
A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the
END_HEADERS flag set MUST be followed by a CONTINUATION frame for END_HEADERS flag set MUST be followed by a CONTINUATION frame for
the same stream. A receiver MUST treat the receipt of any other the same stream. A receiver MUST treat the receipt of any other
type of frame or a frame on a different stream as a connection type of frame or a frame on a different stream as a connection
error (Section 5.4.1) of type PROTOCOL_ERROR. error (Section 5.4.1) of type PROTOCOL_ERROR.
The payload of a CONTINUATION frame contains a header block fragment The payload of a CONTINUATION frame contains a header block fragment
(Section 4.3). (Section 4.3).
skipping to change at page 41, line 51 skipping to change at page 42, line 34
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. Note that header compression
could cause case information to be lost. could cause case information to be lost.
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 MUST or request framing are no longer necessary. An HTTP/2.0 request or
NOT include any of the following header fields: Connection, Host, response MUST NOT include any of the following header fields:
Keep-Alive, Proxy-Connection, TE, Transfer-Encoding, and Upgrade. A Connection, Host, Keep-Alive, Proxy-Connection, TE, Transfer-
server MUST treat the presence of any of these header fields as a Encoding, and Upgrade. A server MUST treat the presence of any of
stream error (Section 5.4.2) of type PROTOCOL_ERROR. these header fields as a stream error (Section 5.4.2) of type
PROTOCOL_ERROR.
8.1.2.1. Request Header Fields 8.1.2.1. Request Header Fields
HTTP/2.0 defines a number of headers starting with a ':' character HTTP/2.0 defines a number of headers starting with a ':' character
that carry information about the request target: 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
skipping to change at page 45, line 45 skipping to change at page 46, line 30
the number of resources that can be concurrently pushed by a server. the number of resources that can be concurrently pushed by a server.
Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
server push by preventing the server from creating the necessary server push by preventing the server from creating the necessary
streams. This does not prohibit a server from sending PUSH_PROMISE streams. This does not prohibit a server from sending PUSH_PROMISE
frames; clients need to reset any promised streams that are not frames; clients need to reset any promised streams that are not
wanted. wanted.
Clients receiving a pushed response MUST validate that the server is Clients receiving a pushed response MUST validate that the server is
authorized to 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 [[anchor15: 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".
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
skipping to change at page 46, line 29 skipping to change at page 47, line 10
Clients SHOULD NOT open more than one HTTP/2.0 connection to a given Clients SHOULD NOT open more than one HTTP/2.0 connection to a given
origin ([RFC6454]) concurrently. A client can create additional origin ([RFC6454]) concurrently. A client can create additional
connections as replacements, either to replace connections that are connections as replacements, either to replace connections that are
near to exhausting the available stream identifiers (Section 5.1.1), near to exhausting the available stream identifiers (Section 5.1.1),
or to replace connections that have encountered errors or to replace connections that have encountered errors
(Section 5.4.1). (Section 5.4.1).
Servers are encouraged to maintain open connections for as long as Servers are encouraged to maintain open connections for as long as
possible, but are permitted to terminate idle connections if possible, but are permitted to terminate idle connections if
necessary. When either endpoint chooses to close the transport-level necessary. When either endpoint chooses to close the transport-level
TCP connection, the terminating endpoint MUST first send a GOAWAY TCP connection, the terminating endpoint SHOULD first send a GOAWAY
(Section 6.8) frame so that both endpoints can reliably determine (Section 6.8) frame so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks. complete or terminate any necessary remaining tasks.
9.2. Use of TLS Features 9.2. Use of TLS Features
Implementations of HTTP/2.0 MUST support TLS 1.1 [TLS11]. [[anchor18: Implementations of HTTP/2.0 MUST support TLS 1.1 [TLS11]. [[anchor19:
The working group intends to require at least the use of TLS 1.2 The working group intends to require at least the use of TLS 1.2
[TLS12] prior to publication of this document; negotiating TLS 1.1 is [TLS12] prior to publication of this document; negotiating TLS 1.1 is
permitted to enable the creation of interoperable implementations of permitted to enable the creation of interoperable implementations of
early drafts.]] early drafts.]]
The TLS implementation MUST support the Server Name Indication (SNI) The TLS implementation MUST support the Server Name Indication (SNI)
[TLS-EXT] extension to TLS. HTTP/2.0 clients MUST indicate the [TLS-EXT] extension to TLS. HTTP/2.0 clients MUST indicate the
target domain name when negotiating TLS. target domain name when negotiating TLS.
A server that receives a TLS handshake that does not include either A server that receives a TLS handshake that does not include either
skipping to change at page 47, line 10 skipping to change at page 47, line 39
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. Frame Size Limits for HTTP
Frames used for HTTP messages MUST NOT exceed 2^14-1 (16383) octets 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 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 treat the receipt of a larger frame as a FRAME_TOO_LARGE error (see
Section 4.2). Section 4.2).
9.4. GZip Content-Encoding 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
skipping to change at page 51, line 46 skipping to change at page 52, line 30
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
(Substantial editorial contributions) (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, "HTTP Header Compression",
draft-ietf-httpbis-header-compression-00 (work in draft-ietf-httpbis-header-compression-02 (work in
progress), June 2013. progress), August 2013.
[HTTP-p1] Fielding, R. and J. Reschke, "Hypertext Transfer [HTTP-p1] Fielding, R. and J. Reschke, "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-23 (work in progress), draft-ietf-httpbis-p1-messaging-23 (work in progress),
July 2013. July 2013.
[HTTP-p2] Fielding, R. and J. Reschke, "Hypertext Transfer [HTTP-p2] Fielding, R. and J. Reschke, "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-23 (work in progress), draft-ietf-httpbis-p2-semantics-23 (work in progress),
July 2013. July 2013.
skipping to change at page 53, line 42 skipping to change at page 54, line 27
[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-04 A.1. Since draft-ietf-httpbis-http2-05
Marking the draft ready for implementation.
Renumbering END_PUSH_PROMISE flag.
Editorial clarifications and changes.
A.2. 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.
Requiring that intermediaries not forward requests with missing or Requiring that intermediaries not forward requests with missing or
illegal routing :-headers. illegal routing :-headers.
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.2. Since draft-ietf-httpbis-http2-03 A.3. 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.3. Since draft-ietf-httpbis-http2-02 A.4. 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.4. Since draft-ietf-httpbis-http2-01 A.5. 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 55, line 31 skipping to change at page 56, 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.5. Since draft-ietf-httpbis-http2-00 A.6. 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.6. Since draft-mbelshe-httpbis-spdy-00 A.7. 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. 42 change blocks. 
90 lines changed or deleted 114 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/