[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.