HTTP Status: 101 Switching Protocols
Friday, 7 December 2012
The HTTPbis Working Group met in Atlanta last month; here’s how things are going.
We’re now out of Working Group Last Call on all of our “core” documents, so the editors are working through the issues that brought up. As soon as that’s done, we’ll go to IETF Last Call, and hopefully soon after well have a number of new RFCs defining HTTP/1.1.
Here, you can see the upswing in number of issues during our WGLC period:
To see for yourself, use the “work-in-progress” documents linked from our home page.
As part of that process, I also spent some time updating the parts of the documents that detail changes from RFC2616, since this will be the easiest way for most developers to get an idea of what’s changed. See:
- part 1: Messaging - Changes from RFC2616
- part 2: Semantics - Changes from RFC2616
- part 4: Conditional Requests - Changes from RFC2616
- part 5: Range Requests - Changes from RFC2616
- part 6: Caching - Changes from RFC2616
- part 7: Authentication - Changes from RFC2616 and RFC2617
Note that these lists are by no means complete, and they’ll likely change more before we publish.
We also started work in earnest on HTTP/2.0, with initial discussions focusing on header compression and the upgrade mechanism. We now have a first draft (which is just a straight copy of the SPDY document, to give us a decent basis for future diffs) and the beginnings of an issue list.
The rough approach to upgrade being discussed is to use something like NPN if the connection is using TLS; we’ve communicated that requirement to the TLS Working Group, and they have decided (with a little nudging from their AD ;) to begin work on that. Note that NPN is just one proposal in this space.
If TLS isn’t being used, we’re looking at using HTTP upgrade as a base; see Gabriel and Willy’s draft for a good description of the considerations around that. Furthermore, we want to be able to optimise it, potentially using a DNS record (see Eliot’s new draft for a proposal), and perhaps a header like SPDY’s Alternate-Protocol.
For compression, we have a number of proposals to replace zlib, since CRIME took it off the table. So far, the only one with an implementation is Roberto’s; we’d like to be able to do a bake-off and use a common set of sample headers to compare them.
To keep things moving, we’ve scheduled an interim meeting for HTTP/2.0 issues in late January. If you’d like to come, please respond by the deadline; be aware, however, that this will be very much a working session.
Finally, some people may be interested to know that we now have a http_2 twitter account that will occasionally spout HTTP/2.0-related news; for those who want to track the effort without all of the details, it may be what you’re looking for.
Here are a bunch of the HTTP-related folks having dinner in Atlanta at the conveniently in-hotel Trader Vic’s: