Lloyd, I apologize if I'm not communicating my point... I have read and see exactly what you're saying, however the issue I mention directly involves only Chrome 51 stable(incl further versions), the most used browser worldwide, and Plesk/Centos/NGINX.
Plesk wrote:
Answer: ALPN support for NGINX web-server is available out-of-the-box since Plesk 12.5.30 MU#35 for the following operating systems: CentOS-7, Rhel-7, Ubuntu 14, Debian 8
This means that HTTP/2 powered by Plesk works in all modern browsers including Google Chrome!
Unfortunately as of yesterday this is no longer true.
reference: Chrome 51 released June 1st / NGINX posted the issue June 7th / Plesk post is from May 30th
The above
was true at the time it was written in the Plesk post, however this issue was just announced yesterday by NGINX, so I'm still unclear how a Plesk server that runs CentOS 6.7 will not revert each http2 site back to http/1 unless OpenSSL 1.0.2 is forced into CentOS, and how this would affect Plesk.
Even with ALPN added to Plesk's NGINX, without OpenSSL 1.0.2 on the Plesk server running CentOS, Chrome will still force the site back to http/1.
Regards,
Shawn
@themew, Shawn,
You are confusing a lot of unrelated topics, making it very difficult to see the essence of the whole Google story (if there is any essence).
First of all, Plesk uses a custom Nginx binary, compiled with OpenSSL 1.0.2h, so you are fine, as
@Lloyd_mcse pointed out already (many times).
Second, most OSes do use their own OpenSSL build, that is: they have a OpenSSL package that may have or many not have ALPN extension compiled into it.
Note the OS vendor packages for OpenSSL have version numbers that do not necessarily indicate information about the presence of ALPN. Consider, Ubuntu 14.04.4 LTS, which contains a package that includes the proper ALPN extension (at least, the last time I checked).
Third, the OS Vendor OpenSSL package and the OpenSSL package, compiled into Nginx, are not related at all and that is stating the obvious.
Note that this third point and statement is relevant, since the OS Vendor OpenSSL package can have some impact on the web server installed.
Consider the scenario in which no Nginx proxy is activated, with Apache serving all requests: mod_http2 is available as from version 2.4.17, but that still does not imply that the proper version of OpenSSL is being used, in the sense that all depends on the OpenSSL version used at build time.
In the current Apache version for Plesk, there is no HTTP/2 support, implying that fiddling with Nginx in the view of the Google story can be "dangerous". Nginx should remain a proxy!
In summary, the general rule of thumb is that you will be fine, irregardless of what you think.
The only thing you have to do now is to activate Nginx as a reverse proxy, for all domains (that is, if you want to use HTTP/2).
Note that it really does not matter what you do, you can still expect the situation around the HTTP/2 protocol to change (again, over and over again).
By the way, I would recommend to have a look at your distro´s packages and determine whether the OS vendor OpenSSL package contains a patch for the ALPN extension.
As a final note, wait and see, Google´s pushing of the HTTP/2 protocol will have consequences for the market share of Google Chrome and the existence of alternatives.
If we all have to do want Google wants us to do, the hosting industry has to invest billions worldwide (in certificates, upgrades, OS changes etc.) in order to have sites working on a HTTP/2 protocol in Chrome browser, a browser that really does not have the largest market share.
Do the maths and you will probably see that it does not make any sense at all.
And do not forget the problems at the OpenSSL side: as a result of the push for HTTP/2 protocol, the latest OpenSSL release are less secure and less well-development, as would otherwise be the case and/or as would be expected.
Brace yourself for future security vulnerabilities, upgrades, patches.......and the nice thing is: they are always discovered relatively late.
In short, let´s go party with HTTP/2 (or just stick to the old, familiar, cheap and relatively reliable????)
Regards.........