3 ms·
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
by 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 agoThanks 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 agoWe'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 agoI 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 agoIf 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.
- hannob 11y agoThis issue was already brought up the last time Chome announced the NPN deprecation - and they delayed it because of that. But should they keep around a deprecated technology forever because distributions don't keep up? The problem is imho the Linux distributions here. They should backport ALPN support if they decide to keep old openssl versions around.
- JoshTriplett 11y ago> Many sites offer HTTP/2 with NPN instead of ALPN right now. According to https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html https://blog.chromium.org/2016/02/transitioning-from-spdy-to..., "ALPN is already used 99% of the time to negotiate HTTP/2 with Chrome".