
Chrome Will Drop SPDY Support on May 15 - cujanovic
http://techcrunch.com/2016/02/11/chrome-will-drop-spdy-support-on-may-15/
======
Ambroos
The larger issue is that together with SPDY support they will also drop NPN in
favour of ALPN. This means that to provide HTTP/2, server administrators will
not only need a new version of Nginx (or their favourite webserver), but also
OpenSSL 1.0.2.

The big problem with that is that currently no common server distributions
provide an easy way to get OpenSSL 1.0.2. Many sites offer HTTP/2 with NPN
instead of ALPN right now. Those will no longer get HTTP/2 in Chrome when SPDY
and NPN are deprecated.

So, most web server administrators who do not want to deal with building their
own OpenSSL/Nginx/... will have no choice but to drop SPDY and HTTP/2
completely, or switch to a future distro that comes with OpenSSL 1.0.2 (Ubuntu
16.04 will be the first major one in a few months).

The deprecation of NPN should, in my opinion, be postponed a little more.
While you can easily upgrade your webserver with upstream packages, usually,
switching to a different OpenSSL version is way out of scope for most
administrators. Debian will have a stable release with OpenSSL 1.0.2 late 2016
or early 2017, CentOS 8 will probably take even longer. And even then, few
people will just switch their server operating systems. Instead of pushing
people to HTTP/2, deprecating NPN this soon will hurt adoption instead.

~~~
bryanlarsen
Thanks for the heads up. We're rebuilding some infrastructure now. We would
have defaulted to building on 14.04, but this gives us reason to switch to
15.10. That's a change I've been wanting to make for a long time anyways, but
I was waiting for 16.04 LTS. Yesterday a major portion of our site was down
for a few minutes because an `service nginx reload` silently failed because
upstart had lost track of the process. I assume that sort of thing wouldn't
happen with systemd because it uses cgroups.

~~~
Ambroos
We've switched to Debian Jessie over 14.04 a few months back for systemd and
more up-to-date dependencies too. I'm not much of a sysadmin guy (developer-
turned-Ansibleman), but our experience with systemd has been amazing so far
for managing our sockets, PHP pools and webservers. Much smoother than
anything we've had before.

We've prepared for this problem too. Our SSL termination is handled on a
completely independent server that basically just forwards requests to
internal application servers, and it's completely stateless. This way we can
just set up a new one on a less-stable distribution (we're experimenting with
Debian Stretch) and switch once we find it stable enough to do just that. It
means we can reap the benefits of possibly unstable HTTP/2 without affecting
our stable application/storage stack.

------
donatj
This seems like a strange and arguably poor decision. One would think it would
be in their interest to wait until HTTP/2 had a foothold or at least until
servers with support for it were included with common server OSs. I _can_
install nginx without Yum, but I'd rather not.

I think this shows their true colors in a sense. Chrome and SPDY exist purely
to save Google bandwidth. They don't care about everyone else.

~~~
easytiger
> This seems like a strange and arguably poor decision.

Chrome team in a nutshell

------
dbalan
Original announcement: [https://blog.chromium.org/2016/02/transitioning-from-
spdy-to...](https://blog.chromium.org/2016/02/transitioning-from-spdy-to-
http2.html)

------
raverbashing
More worrying is that Chrome is dropping support for older versions of Mac OS
X

~~~
anon1385
I'm not sure why you are being downvoted. There are a lot of people still on
Windows XP, Windows Vista, OS X 10.6, OS X 10.7 and OS X 10.8. This is
dropping support for about 14% of all desktops. That's a lot of people.

It's especially irresponsible that "Chrome will continue to function on these
platforms but will no longer receive updates and security fixes". They should
be strongly encouraging those users to switch to a browser that's still
supported on those platforms (which is probably only Firefox at this point).

Given Google's stance on autoupdating to be consistent they really should be
pushing out a final update that prevents Chrome from running on those
machines. A policy of "autoupdate till we don't care about you anymore"
undermines the entire idea of automatically updating browsers.

~~~
legulere
They should strongly encourage them to upgrade their operating systems, as the
underlying operating systems also don't get updates anymore.

~~~
true_religion
Some people's systems are unable to handle the memory or CPU requirements of
newer operating systems. Due to that, they are unlikely to upgrade.

That said, I think the question of how to serve these people is best left up
to website operators and the people themselves.

~~~
nisa
If your machine can deal with Vista it can deal with Windows 8 or Windows 10.
You have to disable some knobs like Cortana but usually it's not slower. I'm
having a Pentium M notebook with 2GB memory and it's working fine. Getting 2GB
memory for old machines is pretty cheap - a few dollars on eBay.

A desktop with at least some 64bit Core2Duo is actually pretty fast if not
even faster with Windows 10 instead of Windows 7 / Vista - 4GB is fine for
office on such a machine.

The only caveat are these privacy and spy addons. I've yet to read some
conclusive summary of these.

~~~
true_religion
I suppose it's anecdotal, but I had a desktop machine with 4GB of ram that was
bought for Windows XP. It dealt well with Windows 7, but the moment I upgraded
to Windows 8 I noticed it was very slow. Unwilling to spend time tweaking it,
I downgraded immediately.

Now I'm a developer.

My mother on the other hand kept a Windows XP laptop running on a Celeron M
processor and 1GB of memory. It felt snappy enough; but I wouldn't trust it to
run Windows 10 applications because while Windows itself might dial down
enough, something like Chrome will happily gobble 500GB of memory because it
thinks it can.

------
dbalan
Is there anything SPDY can do that http/2 can't now?

~~~
mobilio
No.

Only notable change is header compression. SPDY uses dynamic stream
compression, HTTP/2 uses Huffman. And SPDY can be vulnerable to CRIME attack.

