[pilif]

While in general I understand where he is coming from, I believe his main argument about adoption is flawed.

What do you think is more likely going to be adopted? A protocol that's not backwards compatible at all (heck, it even throws out cookies) or something that works over the existing protocol, negotiating extended support and then switching to that while continuing to work the exact same way for both old clients and the applications running behind it?

See SPDY which is a candidate for becoming HTTP 2.0. People are ALREADY running that or at least eager to try it. I don't think for a second that SPDY is having the adoption problems of ipv6, SNI issues aside.

Even if native sessions would be a cool feature, how many years do you believe it takes before something like that can be reliably used? We're still wary of supporting stuff that a 11 years old browser didn't support.

[nl]

I don't think for a second that SPDY is having the adoption problems of ipv6, SNI issues aside.

Google being able to modify both the client (Chrome) as well as few fairly significant server installations has kind of helped there a little bit...

[obtu]

The key difference with IPv6 is that SPDY is opaque to routers and only needs changes at the endpoints. IPv6 has the chicken-and-egg problem that it only becomes usable once everyone (hosters, ISPs, core networks, home networks, web frameworks, client devices) has deployed it, and most of those actors don't bother with things that bring no immediate benefit.

[phkamp]

You do know that when IPv6 roll-out was initially contemplated, it would happen on IPv4-convertible addresses only, until everybody had converted. That would have allowed seamless IPv6/IPv4 interop and made migration a breeze. Lacking any "must have" features, nobody could see a reason to bother. Now we have to do the migration without the benefit of seamless conversion.

[comex]

Luckily, HTTP only requires the browser (which tend to be frequently updated) and server to be upgraded, not some random aging routers, there is little reason to fear adoption, there is minimal harm in keeping both protocols around for some time, and there is something much closer to a "must have" feature - speed.

[ryanpetrich]

A lot of hardware (proxies, DPI gear, hotel wifi hotspots, cellular carriers, etc) sniffs/mangles HTTP in transit and must be verified to be compatible with new HTTP features. HTTPS doesn't have this constraint.

[nl]

Browsers are frequently updated only since Google moved the game on with Chrome auto-update.

[obtu]

I regret missing out on that. Using those addresses? https://tools.ietf.org/html/rfc5156#section-2.3

That doesn't make the chicken-and-egg problem disappear. The best I could imagine is that it would allow IPv6 to downgrade to IPv4 using some sort of addition to the routing table. There's still no incentive to upgrade.

[cbr]

> SNI issues aside

What SNI issues? In practice any client that supports SPDY is going to support SNI.

[pilif]

Yes. But SPDY requires SSL, so in order to get any advantages of SPDY at all, you have to serve your site over SSL which requires one IP address per site due to the lack of SNI support in non-SPDY browsers.

So you either only provide SSL+SPDY for browsers you know support SNI, or you don't provide either SSL or SPDY to all of the browsers.