Should the IETF ship or skip HTTP 2.0?

As the Internet Engineering Task Force (IETF) moves closer to finalizing the HTTP 2.0 standard (a.k.a. HTTP/2), there is a counter-call for the as-yet-unreleased standard to be dropped. Proponents of that move contend that effort should be put into a follow-up that fixes several problems that (it is argued) are intrinsic to HTTP 2.0. An Internet standard never seeing the light of day is nothing new, of course, but it is still an understandably difficult decision to make for those people who have put in considerable time and effort.

HTTP/2 has been in development since 2007. As we have noted before, the revised protocol adds techniques like request multiplexing and header compression to how HTTP is sent over the wire, but it intentionally does not change the semantics for requests, response codes, and so on. The goal is to better optimize HTTP traffic flow, such as reducing latency. The initial draft of the new specification was derived from Google's SPDY, which began as an in-house experiment.

Today, most browser vendors and quite a few high-traffic web services (including Google) support the yet-to-be-finalized HTTP/2. That plus, perhaps, general fatigue with the length of the standardization process, has led some people to ask that the new revision be declared done and given the official IETF seal of approval. On May 24, HTTP Working Group Chair Mark Nottingham proposed marking the latest draft as an Implementation Draft at the HTTP Working Group's upcoming June meeting, then issuing a Last Call (LC). If there is no major objection raised after the LC, HTTP/2 would make its way out of the working group and toward standardization by the Internet Engineering Steering Group (IESG), which makes the final call.

But not everyone in the HTTP Working Group is satisfied with the state of the HTTP/2 draft, and some of the criticisms run deep. In reply to Nottingham, Greg Wilkins said that "I do not see a draft that is anywhere near to being ready for LC [Last Call]." He enumerated what he sees as four major problems:

• The state machine described for processing multiplexed HTTP streams does not match the states that the rest of the specification describes for HTTP/2 streams.
• There are unsolved problems with the HPACK header compression algorithm, including inefficiencies and risks that incorrect implementations will leak information.
• The protocol allows data to be included in HTTP headers; since headers are not subject to flow control, segmentation, or size limits, malicious parties could exploit this to unfairly monopolize a connection.
• There is no clear layering between HTTP/2 frames, requests, and streams.

Several other members of the group concurred with Wilkins's concerns. Nottingham replied that there was still time to fix problems in the specification, but said that the pressure from implementers to establish and adhere to a schedule was important to consider, too:

As to the specific complaints, Nottingham acknowledged that some of the pieces may not be ideal, but remain the best that the participants have been able to create. HPACK, for instance,"is more complex than we’d like, in that there isn’t an off-the-shelf algorithm that we can use (as was the case with gzip)." Yet, after repeated discussions, the group has always decided to stick with it. Moreover, there have already been discussions about HTTP/3, and "while there was a ~15 year gap between HTTP/1.1 and HTTP/2, it’s very likely that the next revision will come sooner."

On May 26, Poul-Henning Kamp posted a rather pointed response (titled "Please admit defeat") to Nottingham's email, specifically the prospects for a sequel to HTTP/2. If the working group already knows that HTTP/2 will require a follow-up in HTTP/3 to fix important problems, he said, then the group should simply drop HTTP/2 and develop its successor.

Kamp argued that pushing out HTTP/2 would waste the time of numerous implementers, as well as introduce code churn that may carry unforeseen security risks. Unsurprisingly, Nottingham did not concur with that assessment. In addition to suggesting that Kamp's wording overstated matters (taking issue, for instance, with the "fiasco" sentence quoted above), Nottingham replied that HTTP implementers feel that the protocol draft is close to being ready to ship, despite any shortcomings. At this stage, he said, technical proposals are what are required.

Nottingham also pointed out that one of Kamp's objections was that HTTP/2 leaves unfixed some bad semantics that have been around since HTTP/1.1. Many people might agree, Nottingham said, but changing the semantics of HTTP is specifically out of scope for the HTTP/2 effort, since it would break compatibility with existing browsers and web servers.

There may be quite a few things about HTTP that still need fixing after HTTP/2, but that is one of the reasons Nottingham cited for wrapping up the HTTP/2 standardization process: once it is completed, the community can move on. There has been a fifteen-year (and counting) gap between HTTP/1.1 and HTTP/2; the longer the gap, the more difficult it is to not break compatibility with existing implementations—if for no other reason, there are simply more browsers and sites.

At this point, it is still possible that HTTP/2 will undergo more revision before it makes it to the final stage of standardization. Several other working group members had concerns about HPACK, and it has been proposed that the compression algorithm be made a negotiable parameter, so that future revisions could drop in an improvement. What does seem clear, however, is that HTTP/2 is moving forward even if not everyone is satisfied with it.

Lack of universal agreement, of course, is not an uncommon problem with standards. As Nottingham noted, the browser and web-server vendors are more-or-less ready to see HTTP/2 reach official approval—which would seem to place HTTP/2 well in line with the IETF's longstanding mantra of "rough consensus and running code." There may indeed be problems that are not discovered until implementation is widespread; perhaps the best option for dealing with them will be to start work on solutions well before another fifteen years have elapsed.

[Thanks to Paul Wise and James Andrewartha for bringing this story to our attention.]