HTTP/2 Approved
ietf.org
ietf.org
Personally I think we'll see a few big players jump in and then we'll see a domino effect as all the big servers complete their implementations (Apache, NGINX, Tomcat etc).
Of course HTTP/1.1 systems are going to be around for a loooong time...
Try never.
Too much embedded devices out there which 1. won't get updated, 2. doesn't have enough storage for a crypto-stack and 3. doesn't have the computational power to process a crypto-stack should it even be updated to have one.
Internet-standards are published, approved and then stays forever. You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it.
Well, it depends on how you define "switchover". Enabling HTTP/2 doesn't necessarily mean turning HTTP/1.1 off.
What HTTP/2 does define is a way for the client to say "I support HTTP/2" and the server to say "Sure, talk HTTP/2 to me" in a way that allows the client to fall back to HTTP/1.1 if the server doesn't know about HTTP/2.
The fact that HTTP/2 retains HTTP/1.1's message semantics, as the note points out, means that they have a lot to do with each other, and that implementations will be able to share much (probably most) of their core logic. This is important -- it means that if you implement HTTP/1.1, you've done a lot of the work of implementing HTTP/2, and vice versa.
Or until all the old devices have reached the end of their useful life; the internet hasn't been in general use that long, and what seems like "forever" looking back on a few decades of history may not going forward. And, anyway, even that's only true if the particular thing you are building is the kind of general purpose infrastructure that needs to support everything that might talk some form of HTTP anywhere, no matter how old or limited-purpose that device is. Plenty of things people actually build don't have that requirement.
Of course, and you addressed this, this doesn't mean that HTTP/1.1 disappears. Heck, my web properties still see HTTP/1.0 requests, almost a decade after HTTP/1.1. But that is a very small minority.
Do you have a link to any development Apache are doing on HTTP/2? I asked about it in the previous HTTP/2 thread but there wasn't any replies and I haven't been able to find any myself.
I know there is mod_spdy but that appears to be abandoned now [1].
But Apache is hardly alone is having a "wait and see" attitude towards HTTP/2; both HAproxy and Varnish see HTTP/2 as a solution for the wrong problem.
I expect to see 1.0, 1.1 and 2.0 continue to live on basically forever.
Of course, the interesting question will be how fast will the majority of users, and servers, be running 2.0?
On the software side, Google-derived Android comes with Chrome by default, which already support SPDY and HTTP/2 support is imminent. Safari on iOS 8 supports SPDY, ditto on HTTP/2 coming soon. Both those software updates can be done instantly (via Google Play Services) or within a year (yearly iOS updates).
So I'd think mobile support is coming very quickly.
Disagree. Phone manufacturers adopt Android versions slowly, especially at the low end, and on PC both Firefox and Chrome update themselves.
I'm also guessing a majority of the top 500 sites will support it pretty quickly (on the order of a year or two). Everything else, will be a long tail of a decade or more.
Edit: Just wanted to add that, I think the better goal is "majority of traffic using HTTP/2" - that's probably 5 years because the majority of traffic probably comes down to the top 500 sites.
Even for the cases it optimizes, one's recommended to verify if there's really any performance enhancement after deploying it, because there are several variables that could make it worse.
Never.
Like IPv6, HTTP/2 is a broken standard that doesn't solve any problems.
The problem with the Web isn't a lack of out-of-order requests, the problem with the Web are those horrible ever-present Javascript frameworks.
(Likewise, the problem with IPv4 isn't a lack of address space, the problem with IPv4 is a lack of a standard and simple way for managing VPNs and tunnels. I don't want my lightbulbs to be connected to the global Internet. What I _do_ want is a way to tunnel remotely and securely into my home's LAN and control the lightbulbs from the inside.)
To the extent that's a problem with the web (its hardly as if the web can only have one problem), that's the domain that progressive HTML (and JS) standards can address (and are addressing.) The more core HTML does, the less JS you need, the more core JS does, the less framework you need when you need JS at all.
Agreed. Javascript should become web assembly, evolving into an intermediate language which other languages are compiled to. Callback heavy code is a huge barrier to entry for people that want to get things done with the web. Likewise, the industry hasn't been satisfied with the framework abstractions built on such a model (hence the constant, near daily flux in framework fads).
It's been said here before that the web needs to consult TCL's ~25 year old TK framework for guidence on how a simple GUI framework can be accomplished without OO. Programming TK is akin to "heaping up" a shell script from small components. Anyone can do it, and they needn't resort to the sophistry of FactoryFactories et. al.
...your preferred javascript framework.
IPv6 requires not just the endpoints, but the routers in between to be on board with it. HTTP/2 only requires end-points. There's a lot less friction for HTTP/1.1 -> HTTP/2 upgrades than IPv4 -> IPv6 upgrades.
[1] http://www.infoworld.com/article/2612478/html5/berners-lee-a...