This is the home page for the effort to define HTTP/2, a major revision of the Web’s protocol. It is maintained by the IETF HTTPbis Working Group.
See also HTTP/2 JP, maintained by the Japanese HTTP/2 community.
HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics will be the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.
The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.
The basis of the work is SPDY. However, we will be collecting issues against this document, as well as confirming consensus over individual portions.
Our deliverables include:
These documents are available in our specifications repository.
We track known implementations of HTTP/2. Right now the protocol is still changing quickly, so we do not expect every draft we publish to be implemented; instead we nominate implementation drafts for interop work.
Our implementation drafts have been:
See also the WGLC milestone for outstanding issues.
ALL contributors and participants in the Working Group (whether on a mailing list, in physical meetings or on Github) MUST read and understand the NOTE WELL statement.
As with all IETF Working Groups, almost all discussion and decisions are made on our WG mailing list. Joining this list is “joining” the Working Group, and is the best way to participate. If you’re new to this, you may also want to read the Tao of the IETF.
Discussion about implementations and testing takes place on the DevOps mailing list. This list is for developers, operators and testers of implementations; discusion of the specifications themselves needs to happen on the WG mailing list.
Meeting records and details of upcoming meetings can be found in our Working Group materials repository.
We have two basic types of issues; “design” and “editorial”.
Design issues need to be discussed by the Working Group to reach consensus. This generally happens on the mailing list when the issue is raised, but the editors sometimes incorporate a proposed resolution to a design issue in a draft, so that the WG can see it in-situ. Such tickets aren’t fully closed until the group confirms the proposal after it is published.
Editorial issues can be resolved by the editors without consultation with the group, although sometimes an editor will poll the group for advice.
Additionally, some issues are marked as liaison issues. This means that we don’t expect to resolve these on our own, but might reference (or even require) the results of work elsewhere.