HTTP/2 Implementation Status
Monday, 15 June 2015
RFC7540 has been out for about a month, so it seems like a good time for a snapshot of where HTTP/2 implementation is at.
Browsers and HTTP/2
Apple was the last “major” browser vendor whose plans about HTTP/2 support were unclear, and last week they announced them for the upcoming iOS9 and OS X 10.11 at WWDC.
If you watch the recorded session, you’ll see HTTP/2 is paired with a push for stronger security. Yes, Apple is joining Firefox and Chrome in requiring HTTP/2 to be used over an encrypted connection. Interestingly, it appears that Microsoft’s HTTP/2 implementation will also only support encrypted HTTP/2, and Blink-based browsers (such as Yandex and Opera) are also supporting HTTP/2 over TLS.
Note that I didn’t say that they’ll require HTTPS URLs, because there is an experimental way to support HTTP URLs over TLS that Firefox has implemented (currently disabled due to a bug, but I’m assured it’ll be back very soon). However, it appears that Firefox is alone in supporting “opportunistic security” — Chrome is firmly against it, and I haven’t seen any evidence of adoption by other browser vendors.
So, the upshot is that HTTP/2 is (or will be soon) supported by all of the “major” browsers, and ** if you want them to use it with your Web site, you’ll need to have HTTPS URLs**. If that’s too difficult for you, you can use Opportunistic Security, but know that it’ll probably only work with Firefox for the foreseeable future.
If you know of a browser that supports h2c (the cleartext version of HTTP/2), I’d love to hear about it.
Servers and HTTP/2
From the start, there have been a large number of libraries for specific languages that support HTTP/2, but implementation in general-purpose Web servers — especially Open Source — has lagged.
That appears to be changing; Jetty, OpenLiteSpeed (beta), h20 and Apache Traffic Server (experimental) already implement it, mod_h2 for Apache is coming along nicely, and nginx has announced their intent to ship support by the end of the year. Adding in the non-open implementations like IIS, F5, and LiteSpeed, and we have a pretty healthy set of choices available for servers emerging. Another option is to use a CDN in front of your site to support HTTP/2; so far, Akamai (disclosure: my employer) has it in beta, and I doubt they’ll be alone for long.
Tools for HTTP/2
A Wireshark decoder for HTTP/2 has been available for a while, tracking each implementation draft as it comes out. It’s been recently joined by h2i, a command-line interactive HTTP/2 client that helps you understand how the protocol works and how your server behaves. You can also use curl to fetch things over HTTP/2 and get more information.
Browser developer tools are also getting better HTTP/2 support. Both Chrome and Firefox will show the protocol used, and Chrome will give a unique identifier for the connection a request occurred upon. Chrome also exposes a lot more detailed information in chrome://net-internals/#spdy.
Just Getting Started
It’s important to emphasise that all of these implementations have been largely focused on interoperability, stability, and basic performance so far, and as such, we’re likely to see them evolve considerably in the future. Advanced HTTP/2 features like server push and fine-grained prioritisation are unevenly supported, and I suspect a lot of refinement is still to take place.
This shouldn’t dissuade you from deploying them. It’s just important to remember that HTTP/2 is a infrastructure upgrade for the Web, and as such it’s going to take time to see the full benefit. That said, there’s still considerable benefit in adopting them now.