10 ms·

Chrome Will Drop SPDY Support on May 15

70 points by cujanovic 11y ago

dbalan 11y ago
Is there anything SPDY can do that http/2 can't now?
- mobilio 11y ago
  No. Only notable change is header compression. SPDY uses dynamic stream compression, HTTP/2 uses Huffman. And SPDY can be vulnerable to CRIME attack.
dbalan 11y ago
Original announcement: https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html https://blog.chromium.org/2016/02/transitioning-from-spdy-to...
Ambroos 11y ago
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 11y ago
  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 11y ago
    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.
- deleted 11y ago
  [deleted]
- andmarios 11y ago
  I am not 100% sure, but I think nginx only needs to be compiled with openssl 1.0.2, but does not otherwise care about the presence of 1.0.2 in the system. So maybe the solution will be to just use the nginx repository when it start providing binaries compiled against openssl 1.0.2.
  - Ambroos 11y ago
    If nginx is built with a statically linked bundled OpenSSL that works, otherwise nginx still fails to negotiate over ALPN when OpenSSL 1.0.1 is present on the system.
raverbashing 11y ago
More worrying is that Chrome is dropping support for older versions of Mac OS X
- TheCoreh 11y ago
  Which versions are they dropping ng support for? Is there a significant number of users still on them?
  - anon1385 11y ago
    http://chrome.blogspot.co.uk/2015/11/updates-to-chrome-platform-support.html http://chrome.blogspot.co.uk/2015/11/updates-to-chrome-platf... OS X 10.6, 10.7 and 10.8 are all being dropped and won't get security updates. netmarketshare.com suggests that's about 13% of current OS X users.
    - CJefferson 11y ago
      Those versions of OS X aren't getting security updates from Apple either, which is (I believe) why Google is stopping too -- there is only so much they can do as the OS and system libraries start to fall behind.
- anon1385 11y ago
  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.
  - 11y ago
donatj 11y ago
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 11y ago
  > This seems like a strange and arguably poor decision. Chrome team in a nutshell

70 points by cujanovic 11y ago

dbalan 11y ago

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

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

dbalan 11y ago

Original announcement: https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html https://blog.chromium.org/2016/02/transitioning-from-spdy-to...

Ambroos 11y ago

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 11y ago
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 11y ago
  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.
deleted 11y ago
[deleted]
andmarios 11y ago
I am not 100% sure, but I think nginx only needs to be compiled with openssl 1.0.2, but does not otherwise care about the presence of 1.0.2 in the system. So maybe the solution will be to just use the nginx repository when it start providing binaries compiled against openssl 1.0.2.
- Ambroos 11y ago
  If nginx is built with a statically linked bundled OpenSSL that works, otherwise nginx still fails to negotiate over ALPN when OpenSSL 1.0.1 is present on the system.

raverbashing 11y ago

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

TheCoreh 11y ago
Which versions are they dropping ng support for? Is there a significant number of users still on them?
- anon1385 11y ago
  http://chrome.blogspot.co.uk/2015/11/updates-to-chrome-platform-support.html http://chrome.blogspot.co.uk/2015/11/updates-to-chrome-platf... OS X 10.6, 10.7 and 10.8 are all being dropped and won't get security updates. netmarketshare.com suggests that's about 13% of current OS X users.
  - CJefferson 11y ago
    Those versions of OS X aren't getting security updates from Apple either, which is (I believe) why Google is stopping too -- there is only so much they can do as the OS and system libraries start to fall behind.
anon1385 11y ago
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.
- 11y ago

donatj 11y ago

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 11y ago
> This seems like a strange and arguably poor decision. Chrome team in a nutshell