Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

2377 lines (2228 sloc) 116.82 kb
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
<rfc ipr="trust200902"
docName="draft-ietf-httpbis-http2-latest"
xmlns:x='http://purl.org/net/xml2rfc/ext'>
<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
<front>
<title abbrev="HTTP/2.0">Hypertext Transfer Protocol version 2.0</title>
<author initials="M." surname="Belshe" fullname="Mike Belshe">
<organization>Twist</organization>
<address>
<email>mbelshe@chromium.org</email>
</address>
</author>
<author initials="R." surname="Peon" fullname="Roberto Peon">
<organization>Google, Inc</organization>
<address>
<email>fenix@google.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
<organization>Microsoft</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<city>Palo Alto</city>
<code>94043</code>
<country>US</country>
</postal>
<email>martin.thomson@skype.net</email>
</address>
</author>
<author initials="A." surname="Melnikov" fullname="Alexey Melnikov" role="editor">
<organization>Isode Ltd</organization>
<address>
<postal>
<street>5 Castle Business Village</street>
<street>36 Station Road</street>
<city>Hampton</city>
<region>Middlesex</region>
<code>TW12 2BX</code>
<country>UK</country>
</postal>
<email>Alexey.Melnikov@isode.com</email>
</address>
</author>
<date year="2013" />
<area>Applications</area>
<workgroup>HTTPbis Working Group</workgroup>
<keyword>HTTP</keyword>
<abstract>
<t>
This document describes an optimised expression of the semantics of the HTTP protocol. The
HTTP/2.0 encapsulation enables more efficient transfer of representations over HTTP by
providing compressed headers, simultaneous requests, and unsolicited push of representations
from server to client.
</t>
<t>
This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol
semantics described in RFC{http-p2..p7} are unmodified.
</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>
This draft is a work-in-progress, and does not yet reflect Working Group
consensus.
</t>
<t>
This draft contains features from the SPDY Protocol as a starting point, as per the Working
Group's charter. Future drafts will add, remove and change text, based upon the Working
Group's decisions.
</t>
<t>
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
</t>
<t>
The current issues list is at <eref
target="http://tools.ietf.org/wg/httpbis/trac/report/21"/> and related documents (including
fancy diffs) can be found at <eref target="http://tools.ietf.org/wg/httpbis/"/>.
</t>
<t>
The changes in this draft are summarized in <xref
target="changes.since.draft-ietf-httpbis-http2-01"/>.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
HTTP is a wildly successful protocol. <xref target="HTTP-p1">HTTP/1.1 message
encapsulation</xref> is optimized for implementation simplicity and accessibility, not
application performance. As such it has several characteristics that have a negative
overall effect on application performance.
</t>
<t>
The HTTP/1.1 encapsulation ensures that only one request can be delivered at a time on a
given connection. HTTP/1.1 pipelining, which is not widely deployed, only partially
addresses these concerns. Clients that need to make multiple requests therefore use
commonly multiple connections to a server or servers in order to reduce the overall latency
of those requests.
</t>
<t>
Furthermore, HTTP/1.1 headers are represented in an inefficient fashion, which, in addition
to generating more or larger network packets, can cause the small initial TCP window to fill
more quickly than is ideal. This results in excessive latency where multiple requests are
made on a new TCP connection.
</t>
<t>
This document defines an optimized mapping of the HTTP semantics to a TCP connection. This
optimization reduces the latency costs of HTTP by allowing parallel requests on the same
connection and by using an efficient coding for HTTP headers. Prioritization of requests
lets more important requests complete faster, further improving application performance.
</t>
<t>
HTTP/2.0 applications have an improved impact on network congestion due to the use of fewer
TCP connections to achieve the same effect. Fewer TCP connections compete more fairly with
other flows. Long-lived connections are also more able to take better advantage of the
available network capacity, rather than operating in the slow start phase of TCP.
</t>
<t>
The HTTP/2.0 encapsulation also enables more efficient processing of messages by providing
efficient message framing. Processing of headers in HTTP/2.0 messages is more efficient
(for entities that process many messages).
</t>
<section title="Document Organization">
<t>
The HTTP/2.0 Specification is split into three parts: <xref target="starting">starting
HTTP/2.0</xref>, which covers how a HTTP/2.0 is started; <xref target="FramingLayer">a
framing layer</xref>, which multiplexes a TCP connection into independent, length-prefixed
frames; and <xref target="HTTPLayer">an HTTP layer</xref>, which specifies the mechanism
for overlaying HTTP request/response pairs on top of the framing layer. While some of the
framing layer concepts are isolated from the HTTP layer, building a generic framing layer
has not been a goal. The framing layer is tailored to the needs of the HTTP protocol and
server push.
</t>
</section>
<section title="Conventions and Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
All numeric values are in network byte order. Values are unsigned unless otherwise
indicated. Literal values are provided in decimal or hexadecimal as appropriate.
Hexadecimal literals are prefixed with <spanx style="verb">0x</spanx> to distinguish them
from decimal literals.
</t>
<t>
The following terms are used:
<list style="hanging">
<t hangText="client:">
The endpoint initiating the HTTP/2.0 session.
</t>
<t hangText="connection:">
A transport-level connection between two endpoints.
</t>
<t hangText="endpoint:">
Either the client or server of a connection.
</t>
<t hangText="frame:">
The smallest unit of communication, each containing a frame header.
</t>
<t hangText="message:">
A complete sequence of frames.
</t>
<t hangText="receiver:">
An endpoint that is receiving frames.
</t>
<t hangText="sender:">
An endpoint that is transmitting frames.
</t>
<t hangText="server:">
The endpoint which did not initiate the HTTP/2.0 session.
</t>
<t hangText="session:">
A synonym for a connection.
</t>
<t hangText="session error:">
An error on the HTTP/2.0 session.
</t>
<t hangText="stream:">
A bi-directional flow of bytes across a virtual channel within a HTTP/2.0 session.
</t>
<t hangText="stream error:">
An error on an individual HTTP/2.0 stream.
</t>
</list>
</t>
</section>
</section>
<section anchor="starting" title="Starting HTTP/2.0">
<t>
Just as HTTP/1.1 does, HTTP/2.0 uses the "http:" and "https:" URI schemes. An
HTTP/2.0-capable client is therefore required to discover whether a server (or intermediary)
supports HTTP/2.0.
</t>
<t>
Different discovery mechanisms are defined for "http:" and "https:" URIs. Discovery for
"http:" URIs is described in <xref target="discover-http"/>; discovery for "https:" URIs is
described in <xref target="discover-https"/>.
</t>
<section anchor="versioning" title="HTTP/2.0 Version Identification">
<t>
HTTP/2.0 is identified using the string "HTTP/2.0". This identification is used in the
HTTP/1.1 Upgrade header, in the <xref target="TLSNPN">TLS-NPN</xref> [[TBD]] field and
other places where protocol identification is required.
</t>
<t>
Negotiating "HTTP/2.0" implies the use of the transport, security, framing and message
semantics described in this document.
</t>
<t>
[[Editor's Note: please remove the following text prior to the publication of a final
version of this document.]]
</t>
<t>
Only implementations of the final, published RFC can identify themselves as "HTTP/2.0".
Until such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0".
</t>
<t>
Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of
editorial convenience only. Implementations of draft versions MUST NOT identify using
this string.
</t>
<t>
Implementations of draft versions of the protocol MUST add the string "-draft-" and the
corresponding draft number to the identifier before the separator ('/'). For example,
draft-ietf-httpbis-http2-03 is identified using the string "HTTP-draft-03/2.0".
</t>
<t>
Non-compatible experiments that are based on these draft versions MUST instead replace the
string "draft" with a different identifier. For example, an experimental implementation
of packet mood-based encoding based on draft-ietf-httpbis-http2-07 might identify itself
as "HTTP-emo-07/2.0". Note that any label MUST conform with the "token" syntax defined in
Section 3.2.4 of <xref target="HTTP-p1"/>. Experimenters are encouraged to coordinate
their experiments on the ietf-http-wg@w3.org mailing list.
</t>
</section>
<section anchor="discover-http" title="Starting HTTP/2.0 for &quot;http:&quot; URIs">
<t>
A client that makes a request to an "http:" URI without prior knowledge about support for
HTTP/2.0 uses the HTTP Upgrade mechanism <xref target="HTTP-p2"/>. The client makes an
HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0.
</t>
<t>
For example:
</t>
<figure>
<artwork><![CDATA[
GET /default.htm HTTP/1.1
Host: server.example.com
Connection: Upgrade
Upgrade: HTTP/2.0
]]></artwork>
</figure>
<t>
A server that does not support HTTP/2.0 can respond to the request as though the Upgrade
header field were absent:
</t>
<figure>
<artwork><![CDATA[
HTTP/1.1 200 OK
Content-length: 243
Content-type: text/html
...
]]></artwork>
</figure>
<t>
A server that supports HTTP/2.0 can accept the upgrade with a 101 (Switching Protocols)
status code. After the empty line that terminates the 101 response, the server can begin
sending HTTP/2.0 frames. These frames MUST include a response to the request that
initiated the Upgrade.
</t>
<figure>
<artwork><![CDATA[
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: HTTP/2.0
[ HTTP/2.0 session ...
]]></artwork>
</figure>
<t>
Once the server returns the 101 response, both the client and the server send a <xref
target="SessionHeader">session header</xref>.
</t>
</section>
<section anchor="discover-https" title="Starting HTTP/2.0 for &quot;https:&quot; URIs">
<t>
A client that makes a request to an "https:" URI without prior knowledge about support for
HTTP/2.0 uses TLS with <xref target="TLSNPN">TLS-NPN</xref> extension. [[TBD, maybe ALPN]]
</t>
<t>
Once TLS negotiation is complete, both the client and the server send a <xref
target="SessionHeader">session header</xref>.
</t>
</section>
<section anchor="known-http" title="Starting HTTP/2.0 with Prior Knowledge">
<t>
A client can learn that a particular server supports HTTP/2.0 by other means. A client
MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0. This
only affects the resolution of "http:" URIs, servers supporting HTTP/2.0 are required to
support <xref target="TLSNPN">protocol negotiation in TLS</xref>.
</t>
<t>
Prior support for HTTP/2.0 is not a strong signal that a given server will support
HTTP/2.0 for future sessions. It is possible for server configurations to change or for
configurations to differ between instances in clustered server. Different "transparent"
intermediaries - intermediaries that are not explicitly selected by either client or
server - are another source of variability.
</t>
</section>
</section>
<section anchor="FramingLayer" title="HTTP/2.0 Framing Layer">
<section title="Session">
<t>
The HTTP/2.0 session runs atop <xref target="TCP">TCP</xref>. The client is the TCP
connection initiator.
</t>
<t>
HTTP/2.0 connections are persistent connections. For best performance, it is expected
that clients will not close open connections until the user navigates away from all web
pages referencing a connection, or until the server closes the connection. Servers are
encouraged to leave connections open for as long as possible, but can terminate idle
connections if necessary. When either endpoint closes the transport-level connection, it
MUST first send a <xref target="GOAWAY">GOAWAY</xref> frame so that the endpoints can
reliably determine if requests finished before the close.
</t>
</section>
<section anchor="SessionHeader" title="Session Header">
<t>
After opening a TCP connection and performing either an HTTP/1.1 Upgrade or TLS handshake,
the client sends the client session header. The server replies with a server session
header.
</t>
<t>
The session header provides a final confirmation that both peers agree to use the HTTP/2.0
protocol. The SETTINGS frame ensures that client or server configuration is known as
quickly as possible.
</t>
<t>
The client session header is the 8 byte sequence 0x535044590d0a0d0a followed by a <xref
target="SETTINGS">SETTINGS frame</xref>. The client sends the client session header
immediately after receiving an HTTP/1.1 Upgrade, or after receiving a TLS Finished message
from the server.
</t>
<t>
The server session header is the 8 byte sequence 0x736c6f770d0a0d0a followed by a <xref
target="SETTINGS">SETTINGS frame</xref>. The server sends the server session header
immediately after receiving and validating the client session header.
</t>
<t>
The client sends requests immediately after sending the session header, without waiting to
receive a server session header. This ensures that confirming session headers does not
add latency.
</t>
<t>
A client or server MUST close the connection if it does not begin with a valid session
header. A <xref target="GOAWAY">GOAWAY frame</xref> MAY be omitted if it is clear that
the peer is not using HTTP/2.0.
</t>
</section>
<section title="Framing">
<t>
Once the connection is established, clients and servers exchange HTTP/2.0 frames. Frames
are the basic unit of communication.
</t>
<section anchor="frame-header" title="Frame Header">
<t>
HTTP/2.0 frames share a common header format. Frames have an 8 byte header with between
0 and 65535 bytes of data.
</t>
<figure title="Frame Header">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (16) | Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Identifier (31) |
+-+-------------------------------------------------------------+
| Frame Data (0...) ...
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
The fields of the frame header are defined as:
<list style="hanging">
<t hangText="Length:">
The 16-bit length of the frame payload in bytes. The length of the frame header is
not included in this sum.
</t>
<t hangText="Type:">
The 8-bit type of the frame. The frame type determines how the remainder of the
frame header and payload are interpreted.
</t>
<t hangText="Flags:">
An 8-bit field reserved for flags. The semantics of each bit in flags depends on
the frame type. Bits that have undefined semantics are reserved.
</t>
<t hangText="R:">
A reserved 1-bit field. The semantics of this bit are not defined.
</t>
<t hangText="Identifier:">
A 31-bit identifier for the frame. The frame type determines how this identifier is
intepreted. For many frame types, this field includes a stream number.
</t>
<t hangText="Frame Data:">
Frames contain between 0 and 65535 bytes of data.
</t>
</list>
</t>
<t>
Reserved bits in the frame header MUST be set to zero when sending and MUST be ignored
when receiving frames, unless the semantics of the bit are known.
</t>
</section>
<section anchor="FrameSize" title="Frame Processing">
<t>
A frame of the maximum size might be too large for implementations with limited
resources to process. Implementations MAY choose to support frames smaller than the
maximum possible size. However, implementations MUST be able to receive frames
containing at least 8192 octets of payload.
</t>
<t>
An implementation MUST immediately close a stream if it is unable to process a frame
related to that stream due to it exceeding a size limit. The implementation MUST send a
<xref target="RST_STREAM">RST_STREAM frame</xref> containing FRAME_TOO_LARGE error code
if the frame size limit is exceeded.
</t>
<t>
[[ISSUE https://github.com/http2/http2-spec/issues/28: Need a way to signal the
maximum frame size; no way to RST_STREAM on non-stream-related frames.]]
</t>
</section>
</section>
<section title="Streams">
<t>
Streams are independent sequences of bi-directional data divided into frames with several
properties:
<list style="symbols">
<t>
Streams can be created by either the client or server.
</t>
<t>
Streams optionally carry a set of name-value header pairs.
</t>
<t>
Streams can concurrently send data interleaved with other streams.
</t>
<t>
Streams can be established and used unilaterally.
</t>
<t>
Streams can be cancelled.
</t>
</list>
</t>
<section anchor="StreamFrames" title="Stream Frames">
<t>
HTTP/2.0 defines 3 control frames to manage the lifecycle of a stream:
<list style="hanging">
<t hangText="SYN_STREAM:">
Open a new stream <xref target="SYN_STREAM"/>
</t>
<t hangText="SYN_REPLY:">
Remote acknowledgement of a new, open stream <xref target="SYN_REPLY"/>
</t>
<t hangText="RST_STREAM:">
Close a stream <xref target="RST_STREAM"/>
</t>
</list>
</t>
</section>
<section anchor="StreamCreation" title="Stream Creation">
<t>
A stream is created by sending a control frame with the type set to <xref
target="SYN_STREAM">SYN_STREAM</xref>.
</t>
<t>
Streams initiated by a client use odd numbered stream identifiers. Streams initiated by
the server use odd numbered stream identifiers. A stream identifier of zero MUST NOT be
used to create a new stream.
</t>
<t>
The stream identifier of a new stream MUST be greater than all other streams from that
endpoint. If an endpoint receives a SYN_STREAM with a stream identifier which is less
than or equal to a previously received SYN_STREAM, it MUST issue a <xref
target="SessionErrorHandler">session error</xref> with the status PROTOCOL_ERROR.
</t>
<t>
A long-lived session can result in available stream identifiers being exhausted. An
endpoint that is unable to create a new stream identifier can establish a new session
for any new streams.
</t>
<t>
An endpoint cannot prevent the creation of a new stream, but it can request the early
termination of an unwanted stream. Upon receipt of a SYN_STREAM frame, the recipient
can terminate the stream by sending a <xref target="StreamErrorHandler">stream
error</xref> with the error code REFUSED_STREAM. This cannot prevent the initiating
endpoint from sending frames for that stream prior to receiving this request.
</t>
<t>
New streams do not require confirmation from a peer. A stream creator is able to send
frames on a newly created stream immediately after the SYN_STREAM frame.
</t>
<section title="Unidirectional streams">
<t>
When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag set, it creates a
unidirectional stream which the creating endpoint can use to send frames, but the
receiving endpoint cannot. The receiving endpoint is implicitly already in the <xref
target="StreamHalfClose">half-closed</xref> state.
</t>
</section>
<section title="Bidirectional streams">
<t>
SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are bidirectional
streams. Both endpoints can send data on a bi-directional stream.
</t>
</section>
</section>
<section anchor="StreamPriority" title="Stream priority">
<t>
The creator of a stream assigns a priority for that stream. Priority is represented as
a 31 bit integer. 0 represents the highest priority and 2^31-1 represents the lowest
priority.
</t>
<t>
The sender and recipient SHOULD use best-effort to process streams in the order of
highest priority to lowest priority. [[ED: toothless, useless "SHOULD": reword]]
</t>
</section>
<section title="Stream headers">
<t>
Streams carry optional sets of pair headers which carry metadata about the stream.
After the stream has been created, and as long as the sender is not <xref
target="StreamClose">closed</xref> or <xref target="StreamHalfClose">half-closed</xref>,
each side may send HEADERS frame(s) containing the header data. Header data can be sent
in multiple HEADERS frames, and HEADERS frames may be interleaved with data frames.
</t>
</section>
<section title="Stream data exchange">
<t>
Once a stream is created, it can be used to send arbitrary amounts of data. Generally
this means that a series of data frames will be sent on the stream until a frame
containing the FLAG_FIN flag is set. The FLAG_FIN can be set on a <xref
target="SYN_STREAM">SYN_STREAM</xref>, <xref target="SYN_REPLY">SYN_REPLY</xref>, <xref
target="HEADERS">HEADERS</xref> or a <xref target="DataFrames">DATA</xref> frame. Once
the FLAG_FIN has been sent, the stream is considered to be half-closed.
</t>
</section>
<section anchor="StreamHalfClose" title="Stream half-close">
<t>
When one side of the stream sends a frame with the FLAG_FIN flag set, the stream is
half-closed from that endpoint. The sender of the FLAG_FIN MUST NOT send further frames
on that stream. When both sides have half-closed, the stream is closed.
</t>
<t>
If an endpoint receives a data frame after the stream is half-closed from the sender
(e.g. the endpoint has already received a prior frame for the stream with the FIN flag
set), it MUST send a RST_STREAM to the sender with the status STREAM_ALREADY_CLOSED.
</t>
</section>
<section anchor="StreamClose" title="Stream close">
<t>
There are 3 ways that streams can be terminated:
<list>
<t>
Normal termination: Normal stream termination occurs when both sender and recipient
have half-closed the stream by sending a FLAG_FIN.
</t>
<t>
Abrupt termination: Either the client or server can send a RST_STREAM control frame
at any time. A RST_STREAM contains an error code to indicate the reason for failure.
When a RST_STREAM is sent from the stream originator, it indicates a failure to
complete the stream and that no further data will be sent on the stream. When a
RST_STREAM is sent from the stream recipient, the sender, upon receipt, should stop
sending any data on the stream. The stream recipient should be aware that there is
a race between data already in transit from the sender and the time the RST_STREAM
is received. See <xref target="StreamErrorHandler">Stream Error Handling</xref>
</t>
<t>
TCP connection teardown: If the TCP connection is torn down while un-closed streams
exist, then the endpoint must assume that the stream was abnormally interrupted and
may be incomplete.
</t>
</list>
</t>
<t>
If an endpoint receives a data frame after the stream is closed, it must send a
RST_STREAM to the sender with the status PROTOCOL_ERROR.
</t>
</section>
</section>
<section title="Error Handling">
<t>
The HTTP/2.0 framing layer has only two types of errors, and they are always handled
consistently. Any reference in this specification to "issue a session error" refers to
<xref target="SessionErrorHandler"></xref>. Any reference to "issue a stream error"
refers to <xref target="StreamErrorHandler"></xref>.
</t>
<section anchor="SessionErrorHandler" title="Session Error Handling">
<t>
A session error is any error which prevents further processing of the framing layer or
which corrupts the session compression state. When a session error occurs, the endpoint
encountering the error MUST first send a <xref target="GOAWAY">GOAWAY</xref> frame with
the stream id of most recently received stream from the remote endpoint, and the error
code for why the session is terminating. After sending the GOAWAY frame, the endpoint
MUST close the TCP connection.
</t>
<t>
Note that the session compression state is dependent upon both endpoints always
processing all compressed data. If an endpoint partially processes a frame containing
compressed data without updating compression state properly, future control frames which
use compression will be always be errored. Implementations SHOULD always try to process
compressed data so that errors which could be handled as stream errors do not become
session errors.
</t>
<t>
Note that because this GOAWAY is sent during a session error case, it is possible that
the GOAWAY will not be reliably received by the receiving endpoint. It is a best-effort
attempt to communicate with the remote about why the session is going down.
</t>
</section>
<section anchor="StreamErrorHandler" title="Stream Error Handling">
<t>
A stream error is an error related to a specific stream-id which does not affect
processing of other streams at the framing layer. Upon a stream error, the endpoint
MUST send a <xref target="RST_STREAM">RST_STREAM</xref> frame which contains the stream
id of the stream where the error occurred and the error status which caused the error.
After sending the RST_STREAM, the stream is closed to the sending endpoint. After
sending the RST_STREAM, if the sender receives any frames other than a RST_STREAM for
that stream id, it will result in sending additional RST_STREAM frames. An endpoint
MUST NOT send a RST_STREAM in response to an RST_STREAM, as doing so would lead to
RST_STREAM loops. Sending a RST_STREAM does not cause the HTTP/2.0 session to be
closed.
</t>
<t>
If an endpoint has multiple RST_STREAM frames to send in succession for the same
stream-id and the same error code, it MAY coalesce them into a single RST_STREAM frame.
(This can happen if a stream is closed, but the remote sends multiple data frames.
There is no reason to send a RST_STREAM for each frame in succession).
</t>
</section>
</section>
<section anchor="flowcontrol" title="Stream Flow Control">
<t>
Multiplexing streams introduces contention for access to the shared TCP connection.
Stream contention can result in streams being blocked by other streams. A flow control
scheme ensures that streams do not destructively interfere with other streams on the same
TCP connection.
</t>
<section anchor="fc-principles" title="Flow Control Principles">
<t>
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.
</t>
<t>
HTTP/2.0 stream flow control aims to allow for future improvements to flow control
algorithms without requiring protocol changes. Flow control in HTTP/2.0 has the
following characteristics:
<list style="numbers">
<t>
Flow control is hop-by-hop, not end-to-end.
</t>
<t>
Flow control is based on window update messages. Receivers advertise how many
octets they are prepared to receive on a stream. This is a credit-based scheme.
</t>
<t>
Flow control is directional with overall control provided by the receiver. A
receiver MAY choose to set any window size that it desires for each stream and for
the entire connection. A sender MUST respect flow control limits imposed by a
receiver. Clients, servers and intermediaries all independently advertise their
flow control preferences as a receiver and abide by the flow control limits set by
their peer when sending.
</t>
<t>
The initial value for the flow control window is 65536 bytes for both new streams
and the overall connection.
</t>
<t>
The frame type determines whether flow control applies to a frame. Of the frames
specified in this document, only data frames are subject to flow control; all other
frame types do not consume space in the advertised flow control window. This
ensures that important control frames are not blocked by flow control.
</t>
<t>
Flow control can be disabled by a receiver. A receiver can choose to either disable
flow control for a stream or connection by declaring an infinite flow control limit.
</t>
<t>
HTTP/2.0 standardizes only the format of the <xref target="WINDOW_UPDATE">window
update message</xref>. This does not stipulate how a receiver decides when to send
this message or the value that it sends. Nor does it specify how a sender chooses
to send packets. Implementations are able to select any algorithm that suits their
needs.
</t>
</list>
</t>
<t>
Implementations are also responsible for managing how requests and responses are sent
based on priority; choosing how to avoid head of line blocking for requests; and
managing the creation of new streams. Algorithm choices for these could interact with
any flow control algorithm.
</t>
</section>
<section title="Appropriate Use of Flow Control">
<t>
Flow control is defined to protect deployments (client, server or intermediary) that are
operating under constraints. For example, a proxy must share memory between many
connections. Flow control addresses cases where the receiver is unable process data on
one stream, yet wants to be continue to process other streams.
</t>
<t>
Deployments that do not rely on this capability SHOULD disable flow control for data
that is being received. Note that flow control cannot be disabled for sending.
Sending data is always subject to the flow control window advertised by the receiver.
</t>
<t>
Deployments with constrained resources (for example, memory), MAY employ flow control to
limit the amount of memory a peer can consume. This can lead to suboptimal use of
available network resources if flow control is enabled without knowledge of the <xref
target="RFC1323">bandwidth-delay product</xref>.
</t>
<t>
Implementation of flow control in full awareness of the current bandwidth-delay product
is difficult, but it can ensure that constrained resources are protected without any
reduction in connection utilization.
</t>
</section>
</section>
<section title="Frame Types">
<section anchor="DataFrames" title="Data Frames">
<t>
Data frames (type=0) are used to convey HTTP message bodies. The payload of a data
frame contains either a request or response body.
</t>
<t>
Valid flags for data frames are:
<list style="hanging">
<t hangText="FINAL (0x1):">
Bit 1 (the least significant flag bit) being set signifies that this frame is the
last frame to be transmitted on this stream (see <xref target="StreamClose">Stream
Close</xref>).
</t>
<t hangText="COMPRESSED (0x2):">
Bit 2 being set indicates that the data in the frame has been compressed with <xref
target="ZLIB">ZLIB compression</xref>.
</t>
</list>
</t>
<t>
The identifier field in the data frame header MUST contain a stream identifier for an
open stream.
</t>
<t>
Data frame processing requirements:
<list>
<t>
If an endpoint receives a data frame for a stream-id which is not open and the
endpoint has not sent a <xref target="GOAWAY">GOAWAY</xref> frame, it MUST send
issue a <xref target="StreamErrorHandler">stream error</xref> with the error code
INVALID_STREAM for the stream-id.
</t>
<t>
If the endpoint which created the stream receives a data frame before receiving a
SYN_REPLY on that stream, it is a protocol error, and the recipient MUST issue a
<xref target="StreamErrorHandler">stream error</xref> with the error code
PROTOCOL_ERROR for the stream-id.
</t>
<t>
Implementors note: If an endpoint receives multiple data frames for invalid
stream-ids, it MAY close the session.
</t>
<t>
All HTTP/2.0 endpoints MUST accept compressed data frames. Compression of data
frames is always done using zlib compression. Each stream initializes and uses its
own compression context dedicated to use within that stream. Endpoints are
encouraged to use application level compression rather than HTTP/2.0 stream level
compression.
</t>
<t>
Each HTTP/2.0 stream sending compressed frames creates a separate zlib context for
the data streams on that stream. Thus, if both endpoints of a stream are
compressing data on the stream, there will be two zlib contexts, one for sending and
one for receiving.
</t>
</list>
</t>
</section>
<section anchor="SYN_STREAM" title="SYN_STREAM">
<t>
The SYN_STREAM frame (type=1) allows the sender to asynchronously create a stream
between the endpoints. See <xref target="StreamCreation">Stream Creation</xref>
</t>
<figure title="SYN_STREAM Frame Payload">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Associated-Stream-ID (31) |
+-+-------------------------------------------------------------+
|X| Priority (31) |
+-+-------------------------------------------------------------+
| Header Block (*) ...
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Valid flags for the SYN_STREAM frame are:
<list style="hanging">
<t hangText="FINAL (0x1):">
Bit 1 (the least significant bit) being set marks this frame as the last frame to be
transmitted on this stream and puts the sender in the <xref
target="StreamHalfClose">half-closed</xref> state.
</t>
<t hangText="UNIDIRECTIONAL (0x2):">
Bit 2 being set marks this stream as unidirectional. The stream creator is the only
peer that can send on the stream. This flag being set puts the recipient in the
<xref target="StreamHalfClose">half-closed</xref> state.
</t>
</list>
</t>
<t>
The identifier field in the frame header MUST contain an unused stream identifier, see
<xref target="StreamCreation"/>.
</t>
<t>
The SYN_STREAM payload contains the following fields:
<list style="hanging">
<t>
Associated-To-Stream-ID: The 31-bit identifier for a stream which this stream is
associated to. If this stream is independent of all other streams, it should be 0.
[[ED: This will be moved to the push promise.]]
</t>
<t>
X: A 1-bit field reserved for future use.
</t>
<t>
Priority: A 31-bit <xref target="StreamPriority">priority</xref> field.
</t>
<t>
Headers Block: A set of name-value pairs carried as part of the SYN_STREAM. <xref
target="HeaderBlock">See Header Block</xref>.
</t>
</list>
</t>
</section>
<section anchor="SYN_REPLY" title="SYN_REPLY">
<t>
The SYN_REPLY frame (type=2) indicates the acceptance of a stream creation by the
recipient of a SYN_STREAM frame.
</t>
<t>
Valid flags for the SYN_REPLY frame are:
<list style="hanging">
<t hangText="FINAL (0x1):">
Bit 1 (the least significant bit) being set marks this frame as the last frame to be
transmitted on this stream and puts the sender in the <xref
target="StreamHalfClose">half-closed</xref> state.
</t>
</list>
</t>
<t>
The identifier field in the frame header MUST contain the stream identifier that was
included in the corresponding SYN_STREAM, see <xref target="StreamCreation"/>.
</t>
<t>
If an endpoint receives multiple SYN_REPLY frames for the same active stream ID, it MUST
issue a <xref target="StreamErrorHandler">stream error</xref> with the error code
STREAM_IN_USE.
</t>
<t>
The body of a SYN_REPLY contains a Header Block. <xref target="HeaderBlock">see Header
Block</xref>.
</t>
</section>
<section anchor="RST_STREAM" title="RST_STREAM">
<t>
The RST_STREAM frame (type=3) allows for abnormal termination of a stream. When sent by
the creator of a stream, it indicates the creator wishes to cancel the stream. When
sent by the recipient of a stream, it indicates an error or that the recipient did not
want to accept the stream, so the stream should be closed.
</t>
<figure title="RST_STREAM Frame Payload">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (32) |
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
The RST_STREAM frame does not define any valid flags.
</t>
<t>
The identifier field in the frame header MUST contain the stream identifier for an open
stream.
</t>
<t>
The RST_STREAM frame contains a single 32-bit error code. The error code indicates why
the stream is being terminated. The following error codes are defined:
<list>
<t hangText="PROTOCOL_ERROR (1):">
This is a generic error, and should only be used if a more specific error is not
available. [[ED: Doesn't sound so generic. Someone committed a protocol violation.
Might need to change the name.]]
</t>
<t hangText="INVALID_STREAM (2):">
This is returned when a frame is received for a stream which is not active.
</t>
<t hangText="REFUSED_STREAM (3):">
Indicates that the stream was refused before any processing has been done on the
stream.
</t>
<t hangText="CANCEL (5):">
Used by the creator of a stream to indicate that the stream is no longer needed.
</t>
<t hangText="INTERNAL_ERROR (6):">
This is a generic error which can be used when the implementation has internally
failed, not due to anything in the protocol.
</t>
<t hangText="FLOW_CONTROL_ERROR (7):">
The endpoint detected that its peer violated the flow control protocol.
</t>
<t hangText="STREAM_IN_USE (8):">
The endpoint received a SYN_REPLY for a stream already open.
</t>
<t hangText="STREAM_ALREADY_CLOSED (9):">
The endpoint received a data or SYN_REPLY frame for a stream which is half closed.
</t>
<t hangText="FRAME_TOO_LARGE (11):">
The endpoint received a frame that was larger than the maximum size that it
supports.
</t>
</list>
</t>
<t>
After receiving a RST_STREAM on a stream, the recipient must not send additional frames
for that stream, and the stream moves into the closed state.
</t>
</section>
<section anchor="SETTINGS" title="SETTINGS">
<t>
A SETTINGS frame (type=4) contains a set of id/value pairs for communicating
configuration data about how the two endpoints may communicate. SETTINGS frames MUST be
sent at the start of a session, but they can be sent at any other time by either
endpoint. Settings are declarative, not negotiated, each peer indicates their own
configuration.
</t>
<t>
[[Note that persistence of settings is under discussion in the WG and might be removed
in a future version of this document.]]
</t>
<t>
When the server is the sender, the sender can request that configuration data be
persisted by the client across HTTP/2.0 sessions and returned to the server in future
communications.
</t>
<t>
Clients persist settings on a per origin basis (see <xref target="ORIGIN"/> for a
definition of web origins). That is, when a client connects to a server, and the server
persists settings within the client, the client SHOULD return the persisted settings on
future connections to the same origin AND IP address and TCP port. Clients MUST NOT
request servers to use the persistence features of the SETTINGS frames, and servers MUST
ignore persistence related flags sent by a client.
</t>
<t>
Valid flags for the SYN_REPLY frame are:
<list style="hanging">
<t hangText="CLEAR_PERSISTED:">
Bit 1 (the least significant bit) being set indicates a request to clear any
previously persisted settings before processing the settings. Clients MUST NOT set
this flag.
</t>
</list>
</t>
<t>
SETTINGS frames always apply to a session, never a single stream. The identifier field
in the frame header carries a count of the number of settings contained in the payload.
[[ED: this seems totally unnecessary.]]
</t>
<figure title="SETTINGS ID/Value Pair">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SettingFlags(8)| Setting Identifier (24) |
+---------------+-----------------------------------------------+
| Value (32) |
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
The payload of a SETTINGS frame contains zero or more settings. Each setting is
comprised of the following
<list style="hanging">
<t hangText="Settings Flags:">
An 8-bit flags field containing per-setting instructions. The following flags are
valid:
<list style="hanging">
<t hangText="PERSIST_VALUE (0x1):">
Bit 1 (the least significant bit) being set indicates a request from the server
to the client to persist this setting. A client MUST NOT set this flag.
</t>
<t hangText="PERSISTED (0x2):">
Bit 2 being set indicates that this setting is a persisted setting being
returned by the client to the server. This also indicates that this setting is
not a client setting, but a value previously set by the server. A server MUST
NOT set this flag.
</t>
</list>
All other settings flags are reserved.
</t>
<t hangText="Setting Identifier:">
A 24-bit field that identifies the setting.
</t>
<t hangText="Value:">
A 32-bit value for the setting.
</t>
</list>
</t>
<t>
The following settings are defined:
<list style="hanging">
<t hangText="SETTINGS_UPLOAD_BANDWIDTH (1):">
allows the sender to send its expected upload bandwidth on this channel. This number
is an estimate. The value should be the integral number of kilobytes per second that
the sender predicts as an expected maximum upload channel capacity.
</t>
<t hangText="SETTINGS_DOWNLOAD_BANDWIDTH (2):">
allows the sender to send its expected download bandwidth on this channel. This
number is an estimate. The value should be the integral number of kilobytes per
second that the sender predicts as an expected maximum download channel capacity.
</t>
<t hangText="SETTINGS_ROUND_TRIP_TIME (3):">
allows the sender to send its expected round-trip-time on this channel. The round
trip time is defined as the minimum amount of time to send a control frame from this
client to the remote and receive a response. The value is represented in
milliseconds.
</t>
<t hangText="SETTINGS_MAX_CONCURRENT_STREAMS (4):">
allows the sender to inform the remote endpoint the maximum number of concurrent
streams which it will allow. This limit is directional: it applies to the number of
streams that the sender permits the receiver to create. By default there is no
limit. For implementors it is recommended that this value be no smaller than 100,
so as to not unnecessarily limit parallelism.
</t>
<t hangText="SETTINGS_CURRENT_CWND (5):">
allows the sender to inform the remote endpoint of the current TCP CWND value.
</t>
<t hangText="SETTINGS_DOWNLOAD_RETRANS_RATE (6):">
allows the sender to inform the remote endpoint the retransmission rate (bytes
retransmitted / total bytes transmitted).
</t>
<t hangText="SETTINGS_INITIAL_WINDOW_SIZE (7):">
allows the sender to inform the remote endpoint the initial window size (in bytes)
for new streams.
</t>
<t hangText="SETTINGS_END_FLOW_CONTROL (10):">
This setting allows an endpoint to indicate that streams directed to them will not
be subject to flow control. The least significant bit (0x1) is set to indicate that
new streams are not flow controlled. Bit 2 (0x2) is set to indicate that the
session is not flow controlled. All other bits are reserved.
<vspace blankLines="1"/>
This setting applies to all streams, including existing streams.
<vspace blankLines="1"/>
These bits cannot be cleared once set, see <xref target="EndFlowControl"/>.
</t>
</list>
</t>
<t>
The message is intentionally extensible for future information which may improve
client-server communications. The sender does not need to send every type of
ID/value. It must only send those for which it has accurate values to convey. When
multiple ID/value pairs are sent, they should be sent in order of lowest id to highest
id. A single SETTINGS frame MUST not contain multiple values for the same ID. If the
recipient of a SETTINGS frame discovers multiple values for the same ID, it MUST ignore
all values except the first one.
</t>
<t>
A server may send multiple SETTINGS frames containing different ID/Value pairs. When
the same ID/Value is sent twice, the most recent value overrides any previously sent
values. If the server sends IDs 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE in a
first SETTINGS frame, and then sends IDs 4 and 5 with the FLAG_SETTINGS_PERSIST_VALUE,
when the client returns the persisted state on its next SETTINGS frame, it SHOULD send
all 5 settings (1, 2, 3, 4, and 5 in this example) to the server.
</t>
</section>
<section anchor="PING" title="PING">
<t>
The PING frame (type=6) is a mechanism for measuring a minimal round-trip time from the
sender. PING frames can be sent from the client or the server.
</t>
<t>
Recipients of a PING frame send an identical frame to the sender as soon as possible.
PING should take highest priority if there is other data waiting to be sent.
</t>
<t>
The PING frame does not define any valid flags.
</t>
<t>
A client MUST populate the identifier field in the frame header of a PING frame with an
odd numbered value. A server MUST populate the identifier field in the frame header of
a PING frame with an even numbered value. A client MUST reply to PING frames with
even numbered identifiers; a server MUST only reply to PING frames with odd numbered
identifiers. These measures ensure that accidental looping of PINGs cannot occur.
</t>
<t>
The payload of a PING frame contains any value. A PING response MUST contain the
contents of the PING request.
</t>
</section>
<section anchor="GOAWAY" title="GOAWAY">
<t>
The GOAWAY frame (type=7) informs the remote side of the connection to stop creating
streams on this session. It can be sent from the client or the server. Once sent, the
sender will not respond to any new SYN_STREAMs on this session. Recipients of a GOAWAY
frame must not owen additional streams on this session, although a new session can be
established for new streams. The purpose of this message is to allow an endpoint to
gracefully stop accepting new streams (perhaps for a reboot or maintenance), while still
finishing processing of previously established streams.
</t>
<t>
There is an inherent race condition between an endpoint sending SYN_STREAMs and the
remote sending a GOAWAY message. To deal with this case, the GOAWAY contains a
last-stream-id indicating the stream-id of the last stream which was created on the
sending endpoint in this session. If the receiver of the GOAWAY sent new SYN_STREAMs
for sessions after this last-stream-id, they were not processed by the server and the
receiver may treat the stream as though it had never been created at all (hence the
receiver may want to re-create the stream later on a new session).
</t>
<t>
Endpoints should always send a GOAWAY message before closing a connection so that the
remote can know whether a stream has been partially processed or not. (For example, if
an HTTP client sends a POST at the same time that a server closes a connection, the
client cannot know if the server started to process that POST request if the server does
not send a GOAWAY frame to indicate where it stopped working).
</t>
<t>
After sending a GOAWAY message, the sender must ignore all SYN_STREAM frames for new
streams.
</t>
<t>
The GOAWAY frame does not define any valid flags.
</t>
<t>
The GOAWAY message applies to the session, not a specific stream. The identifier field
of the frame header contains the identifier for the last stream that the sender of the
GOAWAY frame is prepared to provide replies to. If no streams were replied to, this
value MUST be 0.
</t>
<t>
The payload of a GOAWAY frame contains a 32-bit error code that contains the reason for
closing the session:
<list style="hanging">
<t hangText="OK (0):">
The session is closing normally.
</t>
<t hangText="PROTOCOL_ERROR (1):">
This is a generic error, and should only be used if a more specific error is not
available. [[ED: bad name]]
</t>
<t hangText="INTERNAL_ERROR (2):">
The implementation has internally failed, not due to anything in the protocol.
</t>
<t hangText="FLOW_CONTROL_ERROR (7):">
The endpoint detected that its peer violated the flow control protocol.
</t>
</list>
</t>
</section>
<section anchor="HEADERS" title="HEADERS">
<t>
The HEADERS frame (type=8) augments a stream with additional headers. It may be
optionally sent on an existing stream at any time. Specific application of the headers
in this frame is application-dependent.
</t>
<t>
Valid flags for the HEADERS frame are:
<list style="hanging">
<t hangText="FINAL (0x1):">
Bit 1 (the least significant bit) being set indicates that this is the last frame to
be transmitted on this stream. Setting this bit puts the sender in the <xref
target="StreamHalfClose">half-closed</xref> state.
</t>
</list>
</t>
<t>
The identifier field in the HEADERS frame header MUST contain a stream identifier for an
open stream.
</t>
<t>
The body of a HEADERS frame contains a <xref target="HeaderBlock">Headers Block</xref>.
</t>
</section>
<section anchor="WINDOW_UPDATE" title="WINDOW_UPDATE">
<t>
The WINDOW_UPDATE frame (type=9) is used to implement flow control in HTTP/2.0.
</t>
<t>
Flow control in HTTP/2.0 operates at two levels: on each individual stream and on the
entire session.
</t>
<t>
Flow control in HTTP/2.0 is hop by hop, that is, only between the two endpoints of a
HTTP/2.0 connection. Intermediaries do not forward WINDOW_UPDATE messages between
dependent sessions. However, throttling of data transfer by any recipient can
indirectly cause the propagation of flow control information toward the original
sender.
</t>
<t>
Flow control only applies to frames that are identified as being subject to flow
control. Of the frames defined in this document, only data frames are subject to flow
control. Receivers MUST either buffer or process all other frames, terminate the
corresponding stream, or terminate the session. The stream or session is terminated
with a FLOW_CONTROL_ERROR code.
</t>
<t>
Valid flags for the WINDOW_UPDATE frame are:
<list style="hanging">
<t hangText="END_FLOW_CONTROL (0x2):">
Bit 2 being set indicates that flow control for the identified stream or session is
ended and subsequent frames do not need to be flow controlled.
</t>
</list>
</t>
<t>
The identifier field in the WINDOW_UPDATE frame header MUST contain a stream identifier
for an open stream, or the value 0. A zero value indicates that the WINDOW_UPDATE
applies to the session level flow control window.
</t>
<t>
The payload of a WINDOW_UPDATE frame contains a 32-bit value. This value is the
additional number of bytes that the sender can transmit in addition to the existing flow
control window. The legal range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes; the
most significant bit of this value is reserved.
</t>
<section title="The Flow Control Window">
<t>
Flow control in HTTP/2.0 is implemented by a flow control window kept by the sender of
each stream. The flow control window is a simple integer value that indicates how many
bytes of data the sender is permitted to transmit. The flow control window size is a
measure of the buffering capability of the recipient.
</t>
<t>
Two flow control windows apply to the sending of every message: the stream flow
control window and the session flow control window. The sender MUST NOT send a flow
controlled frame with a length that exceeds the space available in either of the flow
control windows advertised by the receiver. Frames with zero length that also end a
stream (for example, a data frame with the FINAL flag set) MAY be sent if there is no
available space in either flow control window.
</t>
<t>
For flow control calculations, the 8 byte frame header is not counted.
</t>
<t>
After sending a flow controlled frame, the sender reduces the space available in both
windows by the length of the transmitted frame.
</t>
<t>
The receiver of a message sends a WINDOW_UPDATE frame as it consumes data and frees up
space in flow control windows. Separate WINDOW_UPDATE messages are sent for the
stream and session level flow control windows.
</t>
<t>
A sender MUST NOT allow a flow control window to exceed 2^31 - 1 bytes. If a sender
receives a WINDOW_UPDATE that causes a flow control window to exceed this maximum it
MUST terminate either the stream or the session, as appropriate. For streams, the
sender sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code; for the
session, a GOAWAY message with a FLOW_CONTROL_ERROR code.
</t>
<t>
Flow controlled frames from the sender and WINDOW_UPDATE frames from the receiver are
completely asynchronous with respect to each other. This property allows a receiver to
aggressively update the window size kept by the sender to prevent streams from
stalling.
</t>
</section>
<section title="Flow Control for New Sessions">
<t>
When a HTTP/2.0 connection is first established, new streams are created with an
initial flow control window size of 65535 bytes. The session flow control window is
65536 bytes. Both endpoints can adjust the initial window size for new streams by
including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms
part of the session header.
</t>
<t>
Prior to receiving a SETTINGS frame that sets a value for
SETTINGS_INITIAL_WINDOW_SIZE, a client can only use the default initial window size
when sending flow controlled frames. Similarly, the session flow control window is
set to the default initial window size until a WINDOW_UPDATE message is received.
</t>
</section>
<section title="Reducing the Stream Initial Window Size">
<t>
A server that wishes to use a smaller flow control window than the default MUST be
prepared to receive the entire amount for the default initial window size, since the
client could immediately send the full default amount on every stream it opens. After
the SETTINGS frame from the server is received by the client, the window size
maintained by the client can become negative. A client MUST allow the available window
to become negative, refraining from sending new flow controlled frames until it
receives a WINDOW_UPDATE. The server has two options for handling any streams that
might have already exceeded this lower limit:
<list style="numbers">
<t>
The server can immediately send RST_STREAM with FLOW_CONTROL_ERROR error code for
the affected streams.
</t>
<t>
The server can accept the streams and tolerate the resulting head of line
blocking, sending WINDOW_UPDATE messages as it consumes data.
</t>
</list>
</t>
<t>
If a server decides to accept streams, both sides must recompute the available flow
control window based on the initial window size sent in the SETTINGS. For example, if
the server sets the initial window size to be 16KB, and the client sends 64KB
immediately on connection establishment, the client will recalculate the available
flow control window to be -48KB on receipt of the SETTINGS frame. The client retains
a negative flow control window until WINDOW_UPDATE frames restore the window to being
positive, after which the client can resume sending.
</t>
</section>
<section anchor="EndFlowControl" title="Ending Flow Control">
<t>
After a recipient reads in a frame that marks the end of a stream (for example, a data
stream with a FINAL flag set), it ceases transmission of WINDOW_UPDATE frames. A
sender is not required to maintain the available flow control window for streams that
it is no longer sending on.
</t>
<t>
Flow control can be disabled for all streams or the session using the
SETTINGS_END_FLOW_CONTROL setting. An implementation that does not wish to
perform flow control can use this in the initial SETTINGS exchange.
</t>
<t>
Flow control can be disabled for an individual stream or the overall session by
sending a WINDOW_UPDATE with the END_FLOW_CONTROL flag set. The payload of a
WINDOW_UPDATE frame that has the END_FLOW_CONTROL flag set is ignored.
</t>
<t>
Flow control cannot be enabled again once disabled. Any attempt to re-enable flow
control - by sending a WINDOW_UPDATE or by clearing the bits on the
SETTINGS_END_FLOW_CONTROL setting - MUST be rejected with a FLOW_CONTROL_ERROR error
code.
</t>
</section>
</section>
<section anchor="HeaderBlock" title="Header Block">
<t>
The Header Block is found in the SYN_STREAM, SYN_REPLY and HEADERS frames. Headers
consist of a set of name-value pairs. Headers are compressed using TBD.
</t>
<t>
Compression of headers is a work in progress, as is the format of this block.
</t>
</section>
</section>
</section>
<section anchor="HTTPLayer" title="HTTP Message Exchanges">
<t>
HTTP/2.0 is intended to be as compatible as possible with current web-based
applications. This means that, from the perspective of the server business logic or
application API, the features of HTTP are unchanged. To achieve this, all of the application
request and response header semantics are preserved, although the syntax of conveying those
semantics has changed. Thus, the rules from the <xref target="HTTP11">HTTP/1.1
specification in RFC2616</xref> apply with the changes in the sections below.
</t>
<section title="Connection Management">
<t>
Clients SHOULD NOT open more than one HTTP/2.0 session to a given <xref
target="ORIGIN">origin</xref> concurrently.
</t>
<t>
Note that it is possible for one HTTP/2.0 session to be finishing (e.g. a GOAWAY message
has been sent, but not all streams have finished), while another HTTP/2.0 session is
starting.
</t>
<section title="Use of GOAWAY">
<t>
HTTP/2.0 provides a GOAWAY message which can be used when closing a connection from
either the client or server. Without a server GOAWAY message, HTTP has a race condition
where the client sends a request (a new SYN_STREAM) just as the server is closing the
connection, and the client cannot know if the server received the stream or not. By
using the last-stream-id in the GOAWAY, servers can indicate to the client if a request
was processed or not.
</t>
<t>
Note that some servers will choose to send the GOAWAY and immediately terminate the
connection without waiting for active streams to finish. The client will be able to
determine this because HTTP/2.0 streams are determinstically closed. This abrupt
termination will force the client to heuristically decide whether to retry the pending
requests. Clients always need to be capable of dealing with this case because they must
deal with accidental connection termination cases, which are the same as the server
never having sent a GOAWAY.
</t>
<t>
More sophisticated servers will use GOAWAY to implement a graceful teardown. They will
send the GOAWAY and provide some time for the active streams to finish before
terminating the connection.
</t>
<t>
If a HTTP/2.0 client closes the connection, it should also send a GOAWAY message. This
allows the server to know if any server-push streams were received by the client.
</t>
<t>
If the endpoint closing the connection has not received any SYN_STREAMs from the remote,
the GOAWAY will contain a last-stream-id of 0.
</t>
</section>
</section>
<section title="HTTP Request/Response">
<section title="Request">
<t>
The client initiates a request by sending a SYN_STREAM frame. For requests which do not
contain a body, the SYN_STREAM frame MUST set the FLAG_FIN, indicating that the client
intends to send no further data on this stream. For requests which do contain a body,
the SYN_STREAM will not contain the FLAG_FIN, and the body will follow the SYN_STREAM in
a series of DATA frames. The last DATA frame will set the FLAG_FIN to indicate the end
of the body.
</t>
<t>
The SYN_STREAM headers block will contain all of the HTTP headers which are associated
with an HTTP request. The header block in HTTP/2.0 is mostly unchanged from today's HTTP
header block, with the following differences:
<list>
<t>
The first line of the request is unfolded into name-value pairs like other HTTP
headers and MUST be present:
<list>
<t>
":method" - the HTTP method for this request (e.g. "GET", "POST", "HEAD", etc)
</t>
<t>
":path" - the url-path for this url with "/" prefixed. (see <xref
target="URI"/>). For example, for
"http://www.google.com/search?q=dogs" the path would be "/search?q=dogs".
</t>
<t>
":version" - the HTTP version of this request (e.g. "HTTP/1.1")
</t>
</list>
</t>
<t>
In addition, the following two name-value pairs must also be present in every
request:
<list>
<t>
":host" - the hostport (see <xref target="URI"/>) portion of the
URL for this request (e.g. "www.google.com:1234"). This header is the same as the
HTTP 'Host' header. </t>
<t>
":scheme" - the scheme portion of the URL for this request (e.g. "https"))
</t>
</list>
</t>
<t>
Header names are all lowercase.
</t>
<t>
The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-Encoding headers
are not valid and MUST not be sent.
</t>
<t>
User-agents MUST support gzip compression. Regardless of the Accept-Encoding sent by
the user-agent, the server may always send content encoded with gzip or deflate
encoding.
</t>
<t>
If a server receives a request where the sum of the data frame payload lengths does
not equal the size of the Content-Length header, the server MUST return a 400 (Bad
Request) error.
</t>
<t>
POST-specific changes:
<list>
<t>
Although POSTs are inherently chunked, POST requests SHOULD also be accompanied
by a Content-Length header. There are two reasons for this: First, it assists
with upload progress meters for an improved user experience. More importantly,
failure to send a Content-Length header is incompatible with many existing HTTP
server implementations. Existing user agents do not omit the Content-Length
header, and server implementations have come to depend upon this.
</t>
</list>
</t>
</list>
</t>
<t>
The user-agent is free to prioritize requests as it sees fit. If the user-agent cannot
make progress without receiving a resource, it should attempt to raise the priority of
that resource. Resources such as images, SHOULD generally use the lowest priority.
</t>
<t>
If a client sends a SYN_STREAM without all of the method, host, path, scheme, and
version headers, the server MUST reply with a HTTP 400 Bad Request reply.
</t>
</section>
<section title="Response">
<t>
The server responds to a client request with a SYN_REPLY frame. Symmetric to the
client's upload stream, server will send data after the SYN_REPLY frame via a series of
DATA frames, and the last data frame will contain the FLAG_FIN to indicate successful
end-of-stream. If a response (like a 202 or 204 response) contains no body, the
SYN_REPLY frame may contain the FLAG_FIN flag to indicate no further data will be sent
on the stream.
</t>
<t>
<list>
<t>
The response status line is unfolded into name-value pairs like other HTTP headers
and must be present:
<list>
<t>
":status" - The HTTP response status code (e.g. "200" or "200 OK")
</t>
<t>
":version" - The HTTP response version (e.g. "HTTP/1.1")
</t>
</list>
</t>
<t>
All header names must be lowercase.
</t>
<t>
The Connection, Keep-Alive, Proxy-Connection, and Transfer-Encoding headers are not
valid and MUST not be sent.
</t>
<t>
Responses MAY be accompanied by a Content-Length header for advisory purposes.
(e.g. for UI progress meters)
</t>
<t>
If a client receives a response where the sum of the data frame payload lengths does
not equal the size of the Content-Length header, the client MUST ignore the content
length header.
</t>
</list>
</t>
<t>
If a client receives a SYN_REPLY without a status or without a version header, the
client must reply with a RST_STREAM frame indicating a PROTOCOL ERROR.
</t>
</section>
<section title="Authentication" anchor="Authentication">
<t>
When a client sends a request to an origin server that requires authentication, the
server can reply with a "401 Unauthorized" response, and include a WWW-Authenticate
challenge header that defines the authentication scheme to be used. The client then
retries the request with an Authorization header appropriate to the specified
authentication scheme.
</t>
<t>
There are four options for proxy authentication, Basic, Digest, NTLM and Negotiate
(SPNEGO). The first two options were defined in <xref target="HTTPAUTHN">RFC2617</xref>,
and are stateless. The second two options were developed by Microsoft and specified in
<xref target="SPNEGO">RFC4559</xref>, and are stateful; otherwise known as multi-round
authentication, or connection authentication.
</t>
<section title="Stateless Authentication">
<t>
Stateless Authentication over HTTP/2.0 is identical to how it is performed over
HTTP. If multiple HTTP/2.0 streams are concurrently sent to a single server, each will
authenticate independently, similar to how two HTTP connections would independently
authenticate to a proxy server.
</t>
</section>
<section title="Stateful Authentication">
<t>
Unfortunately, the stateful authentication mechanisms were implemented and defined in
a such a way that directly violates RFC2617 - they do not include a "realm" as part of
the request. This is problematic in HTTP/2.0 because it makes it impossible for a
client to disambiguate two concurrent server authentication challenges.
</t>
<t>
To deal with this case, HTTP/2.0 servers using Stateful Authentication MUST implement
one of two changes:
<list>
<t>
Servers can add a "realm=&lt;desired realm&gt;" header so that the two
authentication requests can be disambiguated and run concurrently. Unfortunately,
given how these mechanisms work, this is probably not practical.
</t>
<t>
Upon sending the first stateful challenge response, the server MUST buffer and
defer all further frames which are not part of completing the challenge until the
challenge has completed. Completing the authentication challenge may take
multiple round trips. Once the client receives a "401 Authenticate" response for
a stateful authentication type, it MUST stop sending new requests to the server
until the authentication has completed by receiving a non-401 response on at least
one stream.
</t>
</list>
</t>
</section>
</section>
</section>
<section title="Server Push Transactions">
<t>
HTTP/2.0 enables a server to send multiple replies to a client for a single request. The
rationale for this feature is that sometimes a server knows that it will need to send
multiple resources in response to a single request. Without server push features, the
client must first download the primary resource, then discover the secondary resource(s),
and request them. Pushing of resources avoids the round-trip delay, but also creates a
potential race where a server can be pushing content which a user-agent is in the process
of requesting. The following mechanics attempt to prevent the race condition while
enabling the performance benefit.
</t>
<t>
Server push is an optional feature. Server push can be disabled by clients that do not
wish to receive pushed resources by advertising a SETTINGS_MAX_CONCURRENT_STREAMS <xref
target="SETTINGS">SETTING</xref> of zero. This prevents servers from creating the streams
necessary to push resources.
</t>
<t>
Browsers receiving a pushed response MUST validate that the server is authorized to push
the resource using the <xref target="ORIGIN">browser same-origin</xref> policy. For
example, a HTTP/2.0 connection to <spanx style="verb">example.com</spanx> is generally not
permitted to push a response for <spanx style="verb">www.example.org</spanx>.
</t>
<t>
If the browser accepts a pushed response (e.g. it does not send a RST_STREAM), the browser
MUST attempt to cache the pushed response in same way that it would cache any other
response. This means validating the response headers and inserting into the disk cache.
</t>
<t>
Because pushed responses have no request, they have no request headers associated with
them. At the framing layer, HTTP/2.0 pushed streams contain an "associated-stream-id"
which indicates the requested stream for which the pushed stream is related. The pushed
stream inherits all of the headers from the associated-stream-id with the exception of
":host", ":scheme", and ":path", which are provided as part of the pushed response stream
headers. The browser MUST store these inherited and implied request headers with the
cached resource.
</t>
<t>
Implementation note: With server push, it is theoretically possible for servers to push
unreasonable amounts of content or resources to the user-agent. Browsers MUST implement
throttles to protect against unreasonable push attacks.
</t>
<section title="Server implementation">
<t>
When the server intends to push a resource to the user-agent, it opens a new stream by
sending a unidirectional SYN_STREAM. The SYN_STREAM MUST include an
Associated-To-Stream-ID, and MUST set the FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST
include headers for ":scheme", ":host", ":path", which represent the URL for the
resource being pushed. Subsequent headers may follow in HEADERS frames. The purpose of
the association is so that the user-agent can differentiate which request induced the
pushed stream; without it, if the user-agent had two tabs open to the same page, each
pushing unique content under a fixed URL, the user-agent would not be able to
differentiate the requests.
</t>
<t>
The Associated-To-Stream-ID must be the ID of an existing, open stream. The reason for
this restriction is to have a clear endpoint for pushed content. If the user-agent
requested a resource on stream 11, the server replies on stream 11. It can push any
number of additional streams to the client before sending a FLAG_FIN on stream 11.
However, once the originating stream is closed no further push streams may be associated
with it. The pushed streams do not need to be closed (FIN set) before the originating
stream is closed, they only need to be created before the originating stream closes.
</t>
<t>
It is illegal for a server to push a resource with the Associated-To-Stream-ID of 0.
</t>
<t>
To minimize race conditions with the client, the SYN_STREAM for the pushed resources
MUST be sent prior to sending any content which could allow the client to discover the
pushed resource and request it.
</t>
<t>
The server MUST only push resources which would have been returned from a GET request.
</t>
<t>
Note: If the server does not have all of the Response headers available at the time it
issues the HEADERS frame for the pushed resource, it may later use an additional HEADERS
frame to augment the name-value pairs to be associated with the pushed stream. The
subsequent HEADERS frame(s) must not contain a header for ':host', ':scheme', or ':path'
(e.g. the server can't change the identity of the resource to be pushed). The HEADERS
frame must not contain duplicate headers with a previously sent HEADERS frame. The
server must send a HEADERS frame including the scheme/host/port headers before sending
any data frames on the stream.
</t>
</section>
<section title="Client implementation">
<t>
When fetching a resource the client has 3 possibilities:
<list>
<t>
the resource is not being pushed
</t>
<t>
the resource is being pushed, but the data has not yet arrived
</t>
<t>
the resource is being pushed, and the data has started to arrive
</t>
</list>
</t>
<t>
When a SYN_STREAM and HEADERS frame which contains an Associated-To-Stream-ID is received,
the client must not issue GET requests for the resource in the pushed stream, and instead
wait for the pushed stream to arrive. </t>
<t>
If a client receives a server push stream with stream-id 0, it MUST issue a <xref
target="SessionErrorHandler">session error</xref> with the error code PROTOCOL_ERROR.
</t>
<t>
When a client receives a SYN_STREAM from the server without a the ':host', ':scheme',
and ':path' headers, it MUST reply with a RST_STREAM with error code
HTTP_PROTOCOL_ERROR.
</t>
<t>
To cancel individual server push streams, the client can issue a <xref
target="StreamErrorHandler">stream error</xref> with error code CANCEL. Upon receipt,
the server MUST stop sending on this stream immediately (this is an Abrupt termination).
</t>
<t>
To cancel all server push streams related to a request, the client may issue a <xref
target="StreamErrorHandler">stream error</xref> with error code CANCEL on the
associated-stream-id. By cancelling that stream, the server MUST immediately stop
sending frames for any streams with in-association-to for the original stream.
</t>
<t>
If the server sends a HEADER frame containing duplicate headers with a previous HEADERS
frame for the same stream, the client must issue a <xref
target="StreamErrorHandler">stream error</xref> with error code PROTOCOL ERROR.
</t>
<t>
If the server sends a HEADERS frame after sending a data frame for the same stream, the
client MAY ignore the HEADERS frame. Ignoring the HEADERS frame after a data frame
prevents handling of HTTP's trailing headers
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.40).
</t>
</section>
</section>
</section>
<section title="Design Rationale and Notes">
<t>
Authors' notes: The notes in this section have no bearing on the HTTP/2.0 protocol as
specified within this document, and none of these notes should be considered authoritative
about how the protocol works. However, these notes may prove useful in future debates about
how to resolve protocol ambiguities or how to evolve the protocol going forward. They may
be removed before the final draft.
</t>
<section title="Separation of Framing Layer and Application Layer">
<t>
Readers may note that this specification sometimes blends the <xref
target="FramingLayer">framing layer</xref> with requirements of a specific application -
<xref target="HTTPLayer">HTTP</xref>. This is reflected in the request/response nature of
the streams and the definition of the HEADERS which are very similar to HTTP, and other
areas as well.
</t>
<t>
This blending is intentional - the primary goal of this protocol is to create a
low-latency protocol for use with HTTP. Isolating the two layers is convenient for
description of the protocol and how it relates to existing HTTP implementations. However,
the ability to reuse the HTTP/2.0 framing layer is a non goal.
</t>
</section>
<section title="Error handling - Framing Layer">
<t>
Error handling at the HTTP/2.0 layer splits errors into two groups: Those that affect an
individual HTTP/2.0 stream, and those that do not.
</t>
<t>
When an error is confined to a single stream, but general framing is in tact, HTTP/2.0
attempts to use the RST_STREAM as a mechanism to invalidate the stream but move forward
without aborting the connection altogether.
</t>
<t>
For errors occuring outside of a single stream context, HTTP/2.0 assumes the entire
session is hosed. In this case, the endpoint detecting the error should initiate a
connection close.
</t>
</section>
<section title="One Connection Per Domain">
<t>
HTTP/2.0 attempts to use fewer connections than other protocols have traditionally used.
The rationale for this behavior is because it is very difficult to provide a consistent
level of service (e.g. TCP slow-start), prioritization, or optimal compression when the
client is connecting to the server through multiple channels.
</t>
<t>
Through lab measurements, we have seen consistent latency benefits by using fewer
connections from the client. The overall number of packets sent by HTTP/2.0 can be as
much as 40% less than HTTP. Handling large numbers of concurrent connections on the
server also does become a scalability problem, and HTTP/2.0 reduces this load.
</t>
<t>
The use of multiple connections is not without benefit, however. Because HTTP/2.0
multiplexes multiple, independent streams onto a single stream, it creates a potential for
head-of-line blocking problems at the transport level. In tests so far, the negative
effects of head-of-line blocking (especially in the presence of packet loss) is outweighed
by the benefits of compression and prioritization.
</t>
</section>
<section title="Fixed vs Variable Length Fields">
<t>
HTTP/2.0 favors use of fixed length 32bit fields in cases where smaller, variable length
encodings could have been used. To some, this seems like a tragic waste of bandwidth.
HTTP/2.0 choses the simple encoding for speed and simplicity.
</t>
<t>
The goal of HTTP/2.0 is to reduce latency on the network. The overhead of HTTP/2.0 frames
is generally quite low. Each data frame is only an 8 byte overhead for a 1452 byte
payload (~0.6%). At the time of this writing, bandwidth is already plentiful, and there
is a strong trend indicating that bandwidth will continue to increase. With an average
worldwide bandwidth of 1Mbps, and assuming that a variable length encoding could reduce
the overhead by 50%, the latency saved by using a variable length encoding would be less
than 100 nanoseconds. More interesting are the effects when the larger encodings force a
packet boundary, in which case a round-trip could be induced. However, by addressing
other aspects of HTTP/2.0 and TCP interactions, we believe this is completely mitigated.
</t>
</section>
<section title="Unidirectional streams">
<t>
Many readers notice that unidirectional streams are both a bit confusing in concept and
also somewhat redundant. If the recipient of a stream doesn't wish to send data on a
stream, it could simply send a SYN_REPLY with the FLAG_FIN bit set. The
FLAG_UNIDIRECTIONAL is, therefore, not necessary.
</t>
<t>
It is true that we don't need the UNIDIRECTIONAL markings. It is added because it avoids
the recipient of pushed streams from needing to send a set of empty frames (e.g. the
SYN_STREAM w/ FLAG_FIN) which otherwise serve no purpose.
</t>
</section>
<section title="Data Compression">
<t>
Generic compression of data portion of the streams (as opposed to compression of the
headers) without knowing the content of the stream is redundant. There is no value in
compressing a stream which is already compressed. Because of this, HTTP/2.0 does allow
data compression to be optional. We included it because study of existing websites shows
that many sites are not using compression as they should, and users suffer because of it.
We wanted a mechanism where, at the HTTP/2.0 layer, site administrators could simply force
compression - it is better to compress twice than to not compress.
</t>
<t>
Overall, however, with this feature being optional and sometimes redundant, it is unclear
if it is useful at all. We will likely remove it from the specification.
</t>
</section>
<section title="Server Push">
<t>
A subtle but important point is that server push streams must be declared before the
associated stream is closed. The reason for this is so that proxies have a lifetime for
which they can discard information about previous streams. If a pushed stream could
associate itself with an already-closed stream, then endpoints would not have a specific
lifecycle for when they could disavow knowledge of the streams which went before.
</t>
</section>
</section>
<section title="Security Considerations">
<section title="Use of Same-origin constraints">
<t>
This specification uses the <xref target="ORIGIN">same-origin policy</xref> in all cases
where verification of content is required.
</t>
</section>
<section title="HTTP Headers and HTTP/2.0 Headers">
<t>
At the application level, HTTP uses name-value pairs in its headers. Because HTTP/2.0
merges the existing HTTP headers with HTTP/2.0 headers, there is a possibility that some
HTTP applications already use a particular header name. To avoid any conflicts, all
headers introduced for layering HTTP over HTTP/2.0 are prefixed with ":". ":" is not a
valid sequence in HTTP header naming, preventing any possible conflict. [[ED: Not a
security consideration.]]
</t>
</section>
<section title="Cross-Protocol Attacks">
<t>
By utilizing TLS, we believe that HTTP/2.0 introduces no new cross-protocol attacks. TLS
encrypts the contents of all transmission (except the handshake itself), making it
difficult for attackers to control the data which could be used in a cross-protocol
attack. [[Issue: This is no longer true]]
</t>
</section>
<section title="Cacheability of Pushed Resources">
<t>
Pushed resources do not have an associated request. In order for existing HTTP cache
control validations (such as the Vary header) to work, all cached resources must have a
set of request headers. For this reason, caches MUST be careful to inherit request
headers from the associated stream for the push. This includes the Cookie header field.
</t>
<t>
Caching resources that are pushed is possible, based on the guidance provided by the
origin server in the Cache-Control header field. However, this can cause issues if a
single server hosts more than one tenant. For example, a server might offer multiple
users each a small portion of its URI space.
</t>
<t>
Where multiple tenants share space on the same server, that server MUST ensure that
tenants are not able to push representations of resources that they do not have authority
over. Failure to enforce this would allow a tenant to provide a representation that would
be served out of cache, overriding the actual representation that the authoritative tenant
provides.
</t>
<t>
Pushed resources for which an origin server is not authoritative are never cached or used.
</t>
</section>
</section>
<section title="Privacy Considerations">
<section title="Long Lived Connections">
<t>
HTTP/2.0 aims to keep connections open longer between clients and servers in order to
reduce the latency when a user makes a request. The maintenance of these connections over
time could be used to expose private information. For example, a user using a browser
hours after the previous user stopped using that browser may be able to learn about what
the previous user was doing. This is a problem with HTTP in its current form as well,
however the short lived connections make it less of a risk.
</t>
</section>
<section title="SETTINGS frame">
<t>
The HTTP/2.0 SETTINGS frame allows servers to store out-of-band transmitted information
about the communication between client and server on the client. Although this is
intended only to be used to reduce latency, renegade servers could use it as a mechanism
to store identifying information about the client in future requests.
</t>
<t>
Clients implementing privacy modes can disable client-persisted SETTINGS storage.
</t>
<t>
Clients MUST clear persisted SETTINGS information when clearing the cookies.
</t>
</section>
</section>
<section title="Acknowledgements">
<t>
This document includes substantial input from the following individuals:
<list style="symbols">
<t>
Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin
Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin
Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton (SPDY
contributors).
</t>
<t>
Gabriel Montenegro and Willy Tarreau (Upgrade mechanism)
</t>
<t>
William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto
Peon, Rob Trace (Flow control)
</t>
<t>
Mark Nottingham and Julian Reschke
</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="TCP">
<front>
<title abbrev='Transmission Control Protocol'>
Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='Jon Postel'>
<organization>University of Southern California (USC)/Information Sciences
Institute</organization>
</author>
<date year='1981' month='September' />
</front>
<seriesInfo name='STD' value='7' />
<seriesInfo name='RFC' value='793' />
</reference>
<reference anchor="ZLIB">
<front>
<title>
ZLIB Compressed Data Format Specification version 3.3</title>
<author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
<organization>Aladdin Enterprises</organization>
<address><email>ghost@aladdin.com</email></address>
</author>
<author initials="J.-L." surname="Gailly" fullname="Jean-Loup Gailly"/>
<date month="May" year="1996"/>
</front>
<seriesInfo name="RFC" value="1950"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>
Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address><email>sob@harvard.edu</email></address>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="HTTP11">
<front>
<title>
Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization>University of California, Irvine</organization>
<address><email>fielding@ics.uci.edu</email></address>
</author>
<author initials="J." surname="Gettys" fullname="J. Gettys">
<organization>W3C</organization>
<address><email>jg@w3.org</email></address>
</author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization>Compaq Computer Corporation</organization>
<address><email>mogul@wrl.dec.com</email></address>
</author>
<author initials="H." surname="Frystyk" fullname="H. Frystyk">
<organization>MIT Laboratory for Computer Science</organization>
<address><email>frystyk@w3.org</email></address>
</author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization>Xerox Corporation</organization>
<address><email>masinter@parc.xerox.com</email></address>
</author>
<author initials="P." surname="Leach" fullname="P. Leach">
<organization>Microsoft Corporation</organization>
<address><email>paulle@microsoft.com</email></address>
</author>
<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
<organization>W3C</organization>
<address><email>timbl@w3.org</email></address>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
</reference>
<reference anchor="HTTPAUTHN">
<front>
<title abbrev="HTTP Authentication">
HTTP Authentication: Basic and Digest Access Authentication</title>
<author initials="J." surname="Franks" fullname="John Franks">
<organization>Northwestern University, Department of Mathematics</organization>
<address><email>john@math.nwu.edu</email></address>
</author>
<author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
<organization>Verisign Inc.</organization>
<address><email>pbaker@verisign.com</email></address>
</author>
<author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
<organization>AbiSource, Inc.</organization>
<address><email>jeff@AbiSource.com</email></address>
</author>
<author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
<organization>Agranat Systems, Inc.</organization>
<address><email>lawrence@agranat.com</email></address>
</author>
<author initials="P.J." surname="Leach" fullname="Paul J. Leach">
<organization>Microsoft Corporation</organization>
<address><email>paulle@microsoft.com</email></address>
</author>
<author initials="A." surname="Luotonen" fullname="Ari Luotonen">
<organization>Netscape Communications Corporation</organization>
</author>
<author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
<organization>Open Market, Inc.</organization>
<address><email>stewart@OpenMarket.com</email></address>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2617"/>
</reference>
<reference anchor="URI">
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'></author>
<date year='2005' month='January' />
</front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
</reference>
<reference anchor="SPNEGO">
<front>
<title>
SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</title>
<author initials="K." surname="Jaganathan" fullname="K. Jaganathan"/>
<author initials="L." surname="Zhu" fullname="L. Zhu"/>
<author initials="J." surname="Brezak" fullname="J. Brezak"/>
<date year="2006" month="June"/>
</front>
<seriesInfo name="RFC" value="4559"/>
</reference>
<reference anchor="ORIGIN">
<front>
<title>The Web Origin Concept</title>
<author initials='A.' surname='Barth' fullname='A. Barth'/>
<date year='2011' month='December' />
</front>
<seriesInfo name='RFC' value='6454' />
</reference>
<reference anchor="TLSNPN">
<front>
<title>Transport Layer Security (TLS) Next Protocol Negotiation Extension</title>
<author initials='A.' surname='Langley' fullname='Adam Langley'></author>
<date month='May' year='2012' />
</front>
<seriesInfo name='Internet-Draft' value='draft-agl-tls-nextprotoneg-04' />
</reference>
<reference anchor='HTTP-p1'>
<front>
<title>
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='Roy Fielding'></author>
<author initials='J.' surname='Reschke' fullname='Julian Reschke'></author>
<date month='February' year='2013' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-p1-messaging-22' />
</reference>
<reference anchor='HTTP-p2'>
<front>
<title>
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='Roy Fielding'></author>
<author initials='J.' surname='Reschke' fullname='Julian Reschke'></author>
<date month='February' year='2013' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-p2-semantics-22' />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC1323">
<front>
<title>
TCP Extensions for High Performance</title>
<author initials='V.' surname='Jacobson' fullname='Van Jacobson'></author>
<author initials='B.' surname='Braden' fullname='Bob Braden'></author>
<author initials='D.' surname='Borman' fullname='Dave Borman'></author>
<date year='1992' month='May' />
</front>
<seriesInfo name='RFC' value='1323' />
</reference>
</references>
<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
<section title="Since draft-ietf-httpbis-http2-01" anchor="changes.since.draft-ietf-httpbis-http2-01">
<t>
Removed zlib-based header compression mechanism.
</t>
<t>
Updated references.
</t>
<t>
Clarified stream identifier reuse.
</t>
<t>
Removed CREDENTIALS frame and associated mechanisms.
</t>
<t>
Added advice against naive implementation of flow control.
</t>
<t>
Added session header section.
</t>
<t>
Restructured frame header. Removed distinction between data and control frames.
</t>
<t>
Altered flow control properties to include session-level limits.
</t>
<t>
Added note on cacheability of pushed resources and multiple tenant servers.
</t>
<t>
Changed protocol label form based on discussions.
</t>
</section>
<section title="Since draft-ietf-httpbis-http2-00" anchor="changes.since.draft-ietf-httpbis-http2-00">
<t>
Changed title throughout.
</t>
<t>
Removed section on Incompatibilities with SPDY draft#2.
</t>
<t>
Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <eref
target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>.
</t>
<t>
Replaced abstract and introduction.
</t>
<t>
Added section on starting HTTP/2.0, including upgrade mechanism.
</t>
<t>
Removed unused references.
</t>
<t>
Added <xref target="fc-principles">flow control principles</xref> based on <eref
target="http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01"/>.
</t>
</section>
<section title="Since draft-mbelshe-httpbis-spdy-00" anchor="changes.since.draft-mbelshe-httpbis-spdy-00">
<t>
Adopted as base for draft-ietf-httpbis-http2.
</t>
<t>
Updated authors/editors list.
</t>
<t>
Added status note.
</t>
</section>
</section>
</back>
</rfc>
Jump to Line
Something went wrong with that request. Please try again.