# Summary
Mark Nottingham is the Document Shepherd and Working Group Chair. Barry
Leiba is the responsible Area Director.
This specification describes an optimized expression of the semantics of
the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient
use of network resources and a reduced perception of latency by
introducing header field compression and allowing multiple concurrent
messages on the same connection. It also introduces unsolicited push of
representations from servers to clients.
This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
We intend this to be published as a Proposed Standard.
# Review and Consensus
We have enjoyed active participation from a broad community, including
browser vendors, intermediaries (such as CDN and proxy vendors), server
vendors and protocol library authors; this includes both commercial
vendors and open source libraries.
Our current implementation list is at:
https://github.com/http2/http2-spec/wiki/Implementations
Additionally, we have had participation and review from the
non-implementing HTTP community itself. We have substantial external
interest from the Web performance community as well.
We have also coordinated with the W3C, giving them regular updates
through the liaison and the TAG.
Process-wise, we were chartered to do this work in August 2012, with a
submission deadline of November 2014. We have treated that date
seriously, so as to bound the commitment of the developers and
implementers involved. As a result, we had a fairly high frequency of
interim meetings (six in two years), used both to discuss issues and to
hold interop events.
Perhaps inevitably, there have been a number of contentious issues in
the development of HTTP/2. The most notable is listed below; a full
listing of design issues can be found at:
https://github.com/http2/http2-spec/issues?q=is%3Aissue+label%3Adesign
## Requiring Encryption
<https://github.com/http2/http2-spec/issues/314>
<https://github.com/http2/http2-spec/issues/315>
HTTP/2 used SPDY as a starting point, and SPDY was only ever implemented
over TLS for HTTPS URLs.
There were many in the Working Group who felt that this constraint
should be explicit in the new protocol. They were motivated not only by
the Snowden revelations, but also other common (and currently passive)
attacks upon HTTP, such as "FireSheep" coffee shop sniffing and the
Google "drive-by wifi" sniffing attacks.
Implementing the protocol over TLS also improves interoperability, since
middleboxes aren't generally able to manipulate the plaintext -- a
perennial problem for HTTP evolution and conformance.
The Working Group had a wide-ranging discussion about this topic, mostly
during and between the August 2013 (Berlin) and January 2014 (Zurich)
meetings.
We considered requiring the use of TLS (through https:// URIs) for
HTTP/2. However, some members of the community pushed back against this,
on the grounds that it would be too onerous for some uses of HTTP (not
necessarily CPU; cost and administration of certificates was cited as a
burden, as was the follow-on disruption to applications, since
transitioning from HTTP to HTTPS often requires non-trivial content
changes, due to the way that the browser security model works).
As a result, we decided to document the use of HTTP/2 for both https://
and http:// URLs, the latter in cleartext (the "h2c" protocol ID),
leaving it up to implementations to decide what they support.
The WG also discussed an "Opportunistic Security" approach to using TLS
for http:// URIs (but without authentication). This was a bit
controversial too, as some community members felt that having another,
weaker kind of security defined harms the long-term deployment of "full"
TLS.
After discussion in June 2014 (New York) we agreed to adopt this
document as an optional extension, but only with Experimental status:
<http://httpwg.github.io/http-extensions/encryption.html>. It's expected
that we'll ship it shortly after HTTP/2.
Overall, I would characterize the WG a having a somewhat uneasy (but
also pragmatic) consensus on this outcome.
To date, we've had one browser implementation express an intent to
requiring https:// URLs for HTTP/2 (i.e., no http://), one interested in
https:// as well as Opportunistic Security for http:// URLs (but not
cleartext http://), and one that is interested in https:// as well as
cleartext http://.
Note that most of the justification for our decision not to require
https:// for HTTP/2 seems to be predicated on this part of our charter
<http://datatracker.ietf.org/wg/httpbis/charter/>:
"The resulting specification(s) are expected to meet these goals for
common existing deployments of HTTP[.]"
... i.e., it was argued and accepted, based on this text, that requiring
people who can't use https:// to just stay on HTTP/1.1 was unacceptable.
This charter text was written before BCP188 (and the incidents leading
up to it), and also predates the IAB statement on Internet Confidentiality.
# Intellectual Property
Mike Belshe and Martin Thomson have confirmed that they have no direct,
personal knowledge of IPR related to this document.
Roberto Peon is currently working with Google's legal team to update
their disclosure <https://datatracker.ietf.org/ipr/1692/>. This
declaration has been brought to the Working Group's attention.
See <https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-httpbis-http2>
for a full list of disclosures regarding this document.
# Other Points
This document has the following downward references:
* FIPS186 (Non-RFC) - not in downref registry
* RFC2818 (Informational) - in downref registry
* RFC5289 (Informational) - not in downref registry
IDNits reports a few warnings; these appear to be spurious.
This document creates three new registries:
* HTTP/2 Frame Type
* HTTP/2 Settings
* HTTP/2 Error Code
The Working Group discussed and selected these policies in the process
of creating these fields; the choices of policy were not contentious.
IANA is advised to select experts that are familiar with HTTP/2 and its
operation, and with ties to the HTTP community.