Saturday, 31 March 2012
What's Next for HTTP
We had two great meetings of the HTTPbis Working Group
in Paris this week — one to start wrapping up our work on HTTP/1.1, and another to launch some exciting new work on HTTP/2.0.
The HTTP/1.1 specification (RFC2616
) was standardised in the mid-to-late 90’s. At the time, there was a lot of pressure to produce something quickly, because the Web was getting popular, and swamping a lot of networks in the process. As a result, the spec is somewhat garbled.
Fast-forward to about five years ago, when it became clear to me and a bunch of other folks that this wouldn’t last. People were reading things into 2616 which were an artefact of how it was written, rather than the deeper truth they thought had been carefully recorded. I found myself answering a lot of questions of interpretation of the spec, and realised (along with many others) that we needed to open the box back up and write it down much more carefully.
Now we’re almost finished that work; the sections on Conditional Requests
, Range Requests
are in Working Group Last Call, and the editors expect to have the remaining sections join them soon. On Tuesday, we started discussing those Working Group Last Call issues
, and the early feedback seems to verify that these documents are in good shape.
What’s exciting to me its that this work is already proving valuable; cache implementers tell me that the re-write of part six has greatly simplified their task, and several other clarifications have had impact on browsers and other implementations.
Right now the editors are working on the final re-writes of the core sections, and part of that work is stepping back and looking at how they’re organised. Just yesterday, Julian Reschke
heroically spent several hours combining part two (semantics) and part 3 (payload) into one document
, since they’re often confused; the result looks good.
If all goes well in the WGLC stage, we should have these documents stable in short order. Many thanks to the editors as well as Working Group participants.
We weren’t chartered to work on new things, but that limitation was based on the situation at the time; much has changed since.
and Roberto Peon’s launch of SPDY (formerly, FLIP) two and a half years ago (see my comments at the time
) created a rush of interest in revising how HTTP gets put onto the wire. At the time I put together a quick implementation in Python
and was impressed with how easy it was to get up and running.
Mike then presented SPDY to the Working Group a year ago
, at the Prague IETF, where it got significant interest. Soon afterwards, it became apparent that this was reaching a tipping point; lots of implementers and deployers expressed interest, often putting it into code.
So, over the (Southern) summer, I started talking to the IETF leadership about modifying our charter, as well as talking to and visiting implementers that I knew (as well as dropping by the W3C
) to gauge their support for working on HTTP/2.0. It also became clear that people were interested in SPDY, but wanted to talk through the requirements that led to them, to make sure we were serving the needs of the whole Web.
On Thursday, we started executing on a new charter that will see us do that by gathering requirements, soliciting proposals and — with a lot of work and a bit of luck — start working on HTTP/2.0 in a few months. See the overview presentation
We also had presentations from not just SPDY
, but also three other proposals; Microsoft’s S+M
, the requirements of a loose coalition of intermediary implementers
, and finally an overview of Waka
from Roy Fielding.
So, we’ve got a lot of work to do. I’m encouraged that most participants are coming to the table with an open mind, rather than demanding their solution be used unchanged; we’re going to see a lot of compromise, and focus on our common goals if we want to succeed. Some of that spirit was reflected at a very enjoyable dinner on Thursday night, at Roger La Grenouille