draft-ietf-httpbis-http2-07.txt   draft-ietf-httpbis-http2-08.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: April 24, 2014 Google, Inc Expires: May 15, 2014 Google, Inc
M. Thomson, Ed. M. Thomson, Ed.
Microsoft Microsoft
A. Melnikov, Ed. A. Melnikov, Ed.
Isode Ltd Isode Ltd
October 21, 2013 November 11, 2013
Hypertext Transfer Protocol version 2.0 Hypertext Transfer Protocol version 2.0
draft-ietf-httpbis-http2-07 draft-ietf-httpbis-http2-08
Abstract Abstract
This specification describes an optimized expression of the syntax of This specification describes an optimized expression of the syntax of
the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more
efficient use of network resources and a reduced perception of efficient use of network resources and a reduced perception of
latency by introducing header field compression and allowing multiple latency by introducing header field compression and allowing multiple
concurrent messages on the same connection. It also introduces concurrent messages on the same connection. It also introduces
unsolicited push of representations from servers to clients. unsolicited push of representations from servers to clients.
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 syntax. HTTP's existing semantics remain unchanged. HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
This version of the draft has been marked for implementation.
Interoperability testing will occur in the HTTP/2.0 interim in
Zurich, CH, starting 2014-01-22.
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).
The changes in this draft are summarized in Appendix A.1. The changes in this draft are summarized in Appendix A.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014. This Internet-Draft will expire on May 15, 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 48 skipping to change at page 3, line 4
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. HTTP/2.0 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 . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 23 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23
5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23 5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23
skipping to change at page 4, line 14 skipping to change at page 4, line 19
12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54 12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54
12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55 12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55
12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55 12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55
12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56 12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
14.1. Normative References . . . . . . . . . . . . . . . . . . . 57 14.1. Normative References . . . . . . . . . . . . . . . . . . . 57
14.2. Informative References . . . . . . . . . . . . . . . . . . 58 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) . . . . . . . . . . . . . . . . . . . . 59 publication) . . . . . . . . . . . . . . . . . . . . 59
A.1. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59 A.1. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 59
A.2. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59 A.2. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59
A.3. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59 A.3. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59
A.4. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60 A.4. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59
A.5. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60 A.5. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60
A.6. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60 A.6. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60
A.7. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61 A.7. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60
A.8. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61 A.8. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61
A.9. 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 outstanding at In particular, HTTP/1.0 only allows one request to be outstanding at
skipping to change at page 9, line 20 skipping to change at page 9, line 20
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 an entity body MUST be sent in their entirety Requests that contain an entity body MUST be sent in their entirety
before the client can send HTTP/2.0 frames. This means that a large before the client can send HTTP/2.0 frames. This means that a large
request entity can block the use of the connection until it is request entity can block the use of the connection until it 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
... ...
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 16383 octets. between 0 and 16,383 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R | Length (14) | 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...) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
skipping to change at page 13, line 46 skipping to change at page 13, line 46
associated values. They are used within HTTP request and response associated values. They are used within HTTP request and response
messages as 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.
block by concatenating the individual fragments, then decompresses
the block to reconstruct the header set.
Header block fragments can only be sent as the payload of HEADERS, A receiving endpoint reassembles the header block by concatenating
PUSH_PROMISE or CONTINUATION frames. the individual fragments, then decompresses the block to reconstruct
the header set.
A compressed and encoded header block is transmitted in a HEADERS or A complete header block consists of either:
PUSH_PROMISE frame, followed by zero or more CONTINUATION frames. If
the number of octets in the block is greater than the space remaining o a single HEADERS or PUSH_PROMISE frame each respectively with the
in the frame, the block is divided into multiple fragments, which are END_HEADERS or END_PUSH_PROMISE flag set, or
then transmitted in multiple frames.
o a HEADERS or PUSH_PROMISE frame with the END_HEADERS or
END_PUSH_PROMISE flag cleared and one or more CONTINUATION frames,
where the last CONTINUATION frame has the END_HEADER flag set.
Header blocks MUST be transmitted as a contiguous sequence of frames, Header blocks MUST be transmitted as a contiguous sequence of frames,
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 or CONTINUATION
MUST have the END_HEADERS flag set. The last frame in a sequence of frames MUST have the END_HEADERS flag set. The last frame in a
PUSH_PROMISE/CONTINUATION frames MUST have the END_PUSH_PROMISE/ sequence of PUSH_PROMISEor CONTINUATION frames MUST have the
END_HEADERS flag set (respectively). END_PUSH_PROMISE or END_HEADERS flag set (respectively).
HEADERS, PUSH_PROMISE and CONTINUATION frames carry data that can Header block fragments can only be sent as the payload of HEADERS,
modify the compression context maintained by a receiver. An endpoint PUSH_PROMISE or CONTINUATION frames. HEADERS, PUSH_PROMISE and
receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST CONTINUATION frames carry data that can modify the compression
reassemble header blocks and perform decompression even if the frames context maintained by a receiver. An endpoint receiving HEADERS,
are to be discarded. A receiver MUST terminate the connection with a PUSH_PROMISE or CONTINUATION frames MUST reassemble header blocks and
connection error (Section 5.4.1) of type COMPRESSION_ERROR, if it perform decompression even if the frames are to be discarded. A
does not decompress a header block. receiver MUST terminate the connection with a connection error
(Section 5.4.1) of type COMPRESSION_ERROR, if it does not 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
open streams, with either endpoint interleaving frames from open streams, with either endpoint interleaving frames from
multiple streams. multiple streams.
skipping to change at page 23, line 38 skipping to change at page 23, line 38
A RST_STREAM is the last frame that an endpoint can send on a stream. A RST_STREAM is the last frame that an endpoint can send on a stream.
The peer that sends the RST_STREAM frame MUST be prepared to receive The peer that sends the RST_STREAM frame MUST be prepared to receive
any frames that were sent or enqueued for sending by the remote peer. any frames that were sent or enqueued for sending by the remote peer.
These frames can be ignored, except where they modify connection These frames can be ignored, except where they modify connection
state (such as the state maintained for header compression state (such as the state maintained for header compression
(Section 4.3)). (Section 4.3)).
Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
for any stream. However, an endpoint MAY send additional RST_STREAM for any stream. However, an endpoint MAY send additional RST_STREAM
frames if it receives frames on a closed stream after more than a frames if it receives frames on a closed stream after more than a
round trip time. This behavior is permitted to deal with misbehaving round-trip time. This behavior is permitted to deal with misbehaving
implementations. implementations.
An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM
frame, to avoid looping. frame, to avoid looping.
5.4.3. Connection Termination 5.4.3. Connection Termination
If the TCP connection is torn down while streams remain in open or If the TCP connection is torn down while streams remain in open or
half closed states, then the endpoint MUST assume that the stream was half closed states, then the endpoint MUST assume that the stream was
abnormally interrupted and could be incomplete. abnormally interrupted and could be incomplete.
skipping to change at page 24, line 31 skipping to change at page 24, line 31
6.1. DATA 6.1. DATA
DATA frames (type=0x0) convey arbitrary, variable-length sequences of DATA frames (type=0x0) convey arbitrary, variable-length sequences of
octets associated with a stream. One or more DATA frames are used, octets associated with a stream. One or more DATA frames are used,
for instance, to carry HTTP request or response payloads. for instance, to carry HTTP request or response payloads.
The DATA frame defines the following flags: The DATA 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 one of "half closed"
"closed" state (Section 5.1). states or "closed" state (Section 5.1).
RESERVED (0x2): Bit 2 is reserved for future use. RESERVED (0x2): Bit 2 is reserved for future use.
DATA frames MUST be associated with a stream. If a DATA frame is DATA frames MUST be associated with a stream. If a DATA frame is
received whose stream identifier field is 0x0, the recipient MUST received whose stream identifier field is 0x0, the recipient MUST
respond with a connection error (Section 5.4.1) of type respond with a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
DATA frames are subject to flow control and can only be sent when a DATA frames are subject to flow control and can only be sent when a
stream is in the "open" or "half closed (remote)" states. stream is in the "open" or "half closed (remote)" states. If a DATA
frame is received whose stream is not in "open" or "half closed
(local)" state, the recipient MUST respond with a connection error
(Section 5.4.1) of type PROTOCOL_ERROR.
6.2. HEADERS 6.2. HEADERS
The HEADERS frame (type=0x1) carries name-value pairs. It is used to The HEADERS frame (type=0x1) carries name-value pairs. It is used to
open a stream (Section 5.1). HEADERS frames can be sent on a stream open a stream (Section 5.1). HEADERS frames can be sent on a stream
in the "open" or "half closed (remote)" states. in the "open" or "half closed (remote)" states.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Priority (31) | |X| Priority (31) |
+-+-------------------------------------------------------------+ +-+-------------------------------------------------------------+
| Header Block Fragment (*) ... | Header Block Fragment (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
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 the header block
last that the endpoint will send for the identified stream. (Section 4.3) is the last that the endpoint will send for the
Setting this flag causes the stream to enter a "half closed" state identified stream. Setting this flag causes the stream to enter
(Section 5.1). one of "half closed" states (Section 5.1).
A HEADERS frame that is followed by CONTINUATION frames carries A HEADERS frame that is followed by CONTINUATION frames carries
the flag that signals the end of a stream. A CONTINUATION frame the END_STREAM flag that signals the end of a stream. A
cannot be used to terminate a stream. 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): Bit 3 being set indicates that this frame ends END_HEADERS (0x4): Bit 3 being set indicates that this frame
the sequence of header block fragments necessary to provide a contains an entire header block (Section 4.3) and is not followed
complete set of header fields. by any CONTINUATION frames.
The payload for a complete header block is provided by a sequence
of that starts with a HEADERS frame, followed by zero or more
CONTINUATION frames. The sequence is terminated by a frame with
the END_HEADERS flag set. Once the sequence terminates, the
payload of all HEADERS and CONTINUATION frames are concatenated
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
treat the receipt of any other type of frame or a frame on a 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.
PRIORITY (0x8): Bit 4 being set indicates that the first four octets PRIORITY (0x8): Bit 4 being set indicates that the first four octets
of this frame contain a single reserved bit and a 31-bit priority; of this frame contain a single reserved bit and a 31-bit priority;
see Section 5.3. If this bit is not set, the four bytes do not see Section 5.3. If this bit is not set, the four bytes do not
skipping to change at page 27, line 44 skipping to change at page 27, line 38
If a RST_STREAM frame identifying an idle stream is received, the If a RST_STREAM frame identifying an idle stream is received, the
recipient MUST treat this as a connection error (Section 5.4.1) of recipient MUST treat this as a connection error (Section 5.4.1) of
type PROTOCOL_ERROR. type PROTOCOL_ERROR.
6.5. SETTINGS 6.5. SETTINGS
The SETTINGS frame (type=0x4) conveys configuration parameters that The SETTINGS frame (type=0x4) conveys configuration parameters that
affect how endpoints communicate. The parameters are either affect how endpoints communicate. The parameters are either
constraints on peer behavior or preferences. constraints on peer behavior or preferences.
Settings are not negotiated. Settings describe characteristics of
the sending peer, which are used by the receiving peer. Different
values for the same setting can be advertised by each peer. For
example, a client might set a high initial flow control window,
whereas a server might set a lower value to conserve resources.
SETTINGS frames MUST be sent at the start of a connection, and MAY be SETTINGS frames MUST be sent at the start of a connection, and MAY be
sent at any other time by either endpoint over the lifetime of the sent at any other time by either endpoint over the lifetime of the
connection. connection.
Implementations MUST support all of the settings defined by this Implementations MUST support all of the settings defined by this
specification and MAY support additional settings defined by specification and MAY support additional settings defined by
extensions. Unsupported or unrecognized settings MUST be ignored. extensions. Unsupported or unrecognized settings MUST be ignored.
New settings MUST NOT be defined or implemented in a way that New settings MUST NOT be defined or implemented in a way that
requires endpoints to understand them in order to communicate requires endpoints to understand them in order to communicate
successfully. successfully.
skipping to change at page 29, line 11 skipping to change at page 29, line 11
+---------------------------------------------------------------+ +---------------------------------------------------------------+
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_HEADER_TABLE_SIZE (1): Allows the sender to inform the SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the
remote endpoint of the size of the header compression table used remote endpoint of the size of the header compression table used
to decode header blocks. The default value is 4096 bytes. to decode header blocks. The space available for encoding cannot
be changed; it is determined by the setting sent by the peer that
receives the header blocks. The initial value is 4096 bytes.
SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server
push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE 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 frame if it receives this setting set to a value of 0. The
default value is 1, which indicates that push is permitted. initial value is 1, which indicates that push is permitted.
SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of 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. Initially there is no limit to
is recommended that this value be no smaller than 100, so as to this value. It is recommended that this value be no smaller than
not unnecessarily limit parallelism. 100, so as to 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
skipping to change at page 29, line 46 skipping to change at page 29, line 48
All bits other than the least significant are reserved. All bits other than the least significant are reserved.
6.5.3. Settings Synchronization 6.5.3. Settings Synchronization
Most values in SETTINGS benefit from or require an understanding of Most values in SETTINGS benefit from or require an understanding of
when the peer has received and applied the changed setting values. when the peer has received and applied the changed setting values.
In order to provide such synchronization timepoints, the recipient of In order to provide such synchronization timepoints, the recipient of
a SETTINGS frame in which the ACK flag is not set MUST apply the a SETTINGS frame in which the ACK flag is not set MUST apply the
updated settings as soon as possible upon receipt. updated settings as soon as possible upon receipt.
The values in the SETTINGS frame MUST be applied in sequence, with no The values in the SETTINGS frame MUST be applied in the order they
other frame processing between values. Once all values have been appear, with no other frame processing between values. Once all
applied, the recipient MUST immediately emit a SETTINGS frame with values have been applied, the recipient MUST immediately emit a
the ACK flag set. SETTINGS frame with the ACK flag set. The sender of altered settings
applies changes upon receiving a SETTINGS frame with the ACK flag
set.
If the sender of a SETTINGS frame does not receive an acknowledgement If the sender of a SETTINGS frame does not receive an acknowledgement
within a reasonable amount of time, it MAY issue a connection error within a reasonable amount of time, it MAY issue a connection error
(Section 5.4.1) of type SETTINGS_TIMEOUT. (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 set of headers that
headers that provide additional context for the stream. Section 8.2 provide additional context for the stream. Section 8.2 contains a
contains a thorough description of the use of PUSH_PROMISE frames. thorough description of the use of PUSH_PROMISE frames.
PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of
the peer endpoint is set to 0. 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 (*) ...
skipping to change at page 30, line 44 skipping to change at page 30, line 48
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 (0x4): The END_PUSH_PROMISE bit indicates that this END_PUSH_PROMISE (0x4): Bit 3 being set indicates that this frame
frame ends the sequence of header block fragments necessary to contains an entire header block (Section 4.3) and is not followed
provide a complete set of headers. by any CONTINUATION frames.
The payload for a complete header block is provided by a sequence
of frames that starts with a PUSH_PROMISE frame, followed by zero
or more CONTINUATION frames. The sequence terminates by a
PUSH_PROMISE frame with the END_PUSH_PROMISE flag set or a
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 CONTINUATION 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.
skipping to change at page 38, line 21 skipping to change at page 38, line 21
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
The CONTINUATION frame (type=0xA) is used to continue a sequence of The CONTINUATION frame (type=0xA) is used to continue a sequence of
header block fragments (Section 4.3). Any number of CONTINUATION header block fragments (Section 4.3). Any number of CONTINUATION
frames can be sent on an existing stream, as long as the preceding frames can be sent on an existing stream, as long as the preceding
frame on the same stream is one of HEADERS, PUSH_PROMISE or frame on the same stream is one of HEADERS, PUSH_PROMISE or
CONTINUATION. CONTINUATION without the END_HEADERS or END_PUSH_PROMISE flag set.
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_HEADERS (0x4): The END_HEADERS bit indicates that this frame END_HEADERS (0x4): Bit 3 being set indicates that this frame ends a
ends the sequence of header block fragments necessary to provide a header block (Section 4.3).
complete set of header fields.
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
CONTINUATION frames, terminated by a HEADERS or CONTINUATION frame
with the END_HEADERS flag set, or PUSH_PROMISE frame with the
END_PUSH_PROMISE flag set. Once the sequence terminates, the
payload of all frames in the sequence are concatenated and
interpreted as a single block.
A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the If the END_HEADERS bit is not set, this frame MUST be followed by
END_HEADERS flag set MUST be followed by a CONTINUATION frame for another CONTINUATION frame. A receiver MUST treat the receipt of
the same stream. A receiver MUST treat the receipt of any other any other type of frame or a frame on a different stream as a
type of frame or a frame on a different stream as a connection 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).
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.
A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or
CONTINUATION frame. A recipient that observes violation of this rule CONTINUATION frame without the END_HEADERS flag set. A recipient
MUST respond with a connection error (Section 5.4.1) of type that observes violation of this rule MUST respond with a connection
PROTOCOL_ERROR. error (Section 5.4.1) of type 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 45, line 37 skipping to change at page 45, line 35
A malformed request or response is one that uses a valid sequence of A malformed request or response is one that uses a valid sequence of
HTTP/2.0 frames, but is otherwise invalid due to the presence of HTTP/2.0 frames, but is otherwise invalid due to the presence of
prohibited header fields, the absence of mandatory header fields, or prohibited header fields, the absence of mandatory header fields, or
the inclusion of uppercase header field names. the inclusion of uppercase header field names.
A request or response that includes an entity body can include a A request or response that includes an entity body can include a
"content-length" header field. A request or response is also "content-length" header field. A request or response is also
malformed if the value of a "content-length" header field does not malformed if the value of a "content-length" header field does not
equal the sum of the DATA frame payload lengths that form the body. equal the sum of the DATA frame payload lengths that form the body.
Intermediaries MAY forward a malformed request or response, but only Intermediaries that process HTTP requests or responses (i.e., all
if the frames are forwarded without inspection of header fields. intermediaries other than those acting as tunnels) MUST NOT forward a
malformed request or response.
Implementations that detect malformed requests or responses need to Implementations that detect malformed requests or responses need to
ensure that the stream ends. For malformed requests, a server MAY ensure that the stream ends. For malformed requests, a server MAY
send an HTTP response to prior to closing or resetting the stream. send an HTTP response to prior to closing or resetting the stream.
Clients MUST NOT accept a malformed response. Clients MUST NOT accept a malformed response.
8.1.4. Request Reliability Mechanisms in HTTP/2.0 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
skipping to change at page 52, line 23 skipping to change at page 52, line 23
to HTTP/2.0 MUST remove any instances of the "obs-fold" production to HTTP/2.0 MUST remove any instances of the "obs-fold" production
from header field values. from header field values.
10.4. Cacheability of Pushed Resources 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 associate the request header fields from the
associated stream for the push. This includes the Cookie header PUSH_PROMISE frame with the response headers and content delivered on
field. the pushed stream. This includes the Cookie header field.
Caching resources that are pushed is possible, based on the guidance Caching resources that are pushed is possible, based on the guidance
provided by the origin server in the Cache-Control header field. provided by the origin server in the Cache-Control header field.
However, this can cause issues if a single server hosts more than one However, this can cause issues if a single server hosts more than one
tenant. For example, a server might offer multiple users each a tenant. For example, a server might offer multiple users each a
small portion of its URI space. small portion of its URI space.
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
skipping to change at page 59, line 8 skipping to change at page 59, line 8
[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-06 A.1. Since draft-ietf-httpbis-http2-07
Marked draft for implementation.
A.2. Since draft-ietf-httpbis-http2-06
Adding definition for CONNECT method. Adding definition for CONNECT method.
Constraining the use of push to safe, cacheable methods with no Constraining the use of push to safe, cacheable methods with no
request body. request body.
Changing from :host to :authority to remove any potential confusion. Changing from :host to :authority to remove any potential confusion.
Adding setting for header compression table size. Adding setting for header compression table size.
Adding settings acknowledgement. Adding settings acknowledgement.
Removing unnecessary and potentially problematic flags from Removing unnecessary and potentially problematic flags from
CONTINUATION. CONTINUATION.
Added denial of service considerations. Added denial of service considerations.
A.2. Since draft-ietf-httpbis-http2-05 A.3. 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.3. Since draft-ietf-httpbis-http2-04 A.4. 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 60, line 12 skipping to change at page 60, line 15
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.4. Since draft-ietf-httpbis-http2-03 A.5. 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.5. Since draft-ietf-httpbis-http2-02 A.6. 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.6. Since draft-ietf-httpbis-http2-01 A.7. 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 61, line 23 skipping to change at page 61, line 27
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.7. Since draft-ietf-httpbis-http2-00 A.8. 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.8. Since draft-mbelshe-httpbis-spdy-00 A.9. 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
skipping to change at page 62, line 23 skipping to change at page 62, line 23
Google, Inc Google, Inc
EMail: fenix@google.com EMail: fenix@google.com
Martin Thomson (editor) Martin Thomson (editor)
Microsoft Microsoft
3210 Porter Drive 3210 Porter Drive
Palo Alto 94304 Palo Alto 94304
US US
EMail: martin.thomson@skype.net EMail: martin.thomson@gmail.com
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
EMail: Alexey.Melnikov@isode.com EMail: Alexey.Melnikov@isode.com
 End of changes. 43 change blocks. 
114 lines changed or deleted 116 lines changed or added

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