HTTPbis is holding an Interim Meeting January 22-24 in Zurich, CH.
This is the home page for the effort to define HTTP/2.0, a major revision of the Web’s protocol. It is maintained by the IETF HTTPbis Working Group.
HTTP/2.0 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.
See our charter for more details of the scope of the work.
Our deliverables include:
Both documents are available in our specifications repository.
We track known implementations of HTTP/2.0. 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 fourth implementation draft milestone for upcoming issues.
As with all IETF Working Groups, almost all discussion and decisions are made on our 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.
ALL contributors and participants in the Working Group (whether on the mailing list, in physical meetings or on Github) MUST read and understand the NOTE WELL statement.
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.