Working Group Last Call

HTTP/2 and HPACK are now in Working Group Last Call.

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.

What is HTTP/2?

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.

See our charter for more details of the scope of the work, as well as our Frequently Asked Questions.

Specifications

Our deliverables include:

These documents are available in our specifications repository.

You can track changes to the documents using the commit log, also available in Atom and on Twitter.

Implementations

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:

  1. draft-04 - references HPACK-00 (interop in Hamburg)
  2. draft-06 - references HPACK-02 (interop in Seattle)
  3. draft-09 - references HPACK-05 (interop was in Zurich)
  4. draft-12 - references HPACK-07 (interop in New York)
  5. draft-13 - references HPACK-08
  6. draft-14 - references HPACK-09 (current)

See also the WGLC milestone for outstanding issues.

Participate

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.

We also meet face-to-face at most IETF meetings, and sometimes in between at “interim” meetings. During those meetings, we use an XMPP (Jabber) channel (logs) provided by the IETF.

Meeting records and details of upcoming meetings can be found in our Working Group materials repository.

Issues

Discussion is most productive when it focuses on identified issues. Our issues list is kept on Github. Please see the guidelines for contributing before raising an issue.

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.