On Saturday 06 February 2016 12:44:08 Jim Ohlstein wrote: > On 2/6/16 12:22 PM, Валентин Бартенев wrote: > > On Saturday 06 February 2016 12:13:52 Jim Ohlstein wrote: > >> Hello, > >> > >> I am running a WordPress multisite install and recently turned off http2 > >> on the domain in order to use a third party module which evidently > >> doesn't play nicely with http2 (echo module). In testing I noticed that > >> the site was still being served with http2 enabled according to both > >> Chrome and Firefox. I confirmed with curl. > >> > >> I recompiled nginx without any third party modules: > >> > >> # nginx -V > >> nginx version: nginx/1.9.10 > >> built with OpenSSL 1.0.2f 28 Jan 2016 > >> TLS SNI support enabled > >> configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > >> /usr/local/include' --with-ld-opt='-L /usr/local/lib' > >> --conf-path=/usr/local/etc/nginx/nginx.conf > >> --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > >> --error-log-path=/var/log/nginx-error.log --user=www --group=www > >> --with-file-aio --with-ipv6 > >> --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > >> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > >> --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > >> --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > >> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > >> --http-log-path=/var/log/nginx-access.log --with-http_stub_status_module > >> --with-pcre --with-http_v2_module --with-http_ssl_module > >> > >> > >> I then adjusted the config files so as not to reference any third party > >> modules and performed a binary "upgrade". > >> > >> I still see that http2 is in use on both Chrome and Firefox, and also > >> via curl. > >> > >> # curl -I -k https://my.ip4.add.ress/ > >> HTTP/2.0 302 > >> server:nginx/1.9.10 > >> date:Sat, 06 Feb 2016 16:49:44 GMT > >> content-type:text/html; charset=UTF-8 > >> > >> # curl -I https:/mydomain.net/ > >> HTTP/2.0 200 > >> server:nginx/1.9.10 > >> date:Sat, 06 Feb 2016 16:50:41 GMT > >> content-type:text/html; charset=UTF-8 > >> > >> There are other domains on that IPv4 which use http2. Disabling http2 on > >> all of them resulted in the expected behavior in the browsers and in > >> curl: > >> > >> # curl -I -k https:///my.ip4.add.ress/ > >> HTTP/1.1 302 Moved Temporarily > >> Server: nginx/1.9.10 > >> Date: Sat, 06 Feb 2016 17:03:39 GMT > >> Content-Type: text/html; charset=UTF-8 > >> Connection: keep-alive > >> > >> # curl -I https://mydomain.net/ > >> HTTP/1.1 200 OK > >> Server: nginx/1.9.10 > >> Date: Sat, 06 Feb 2016 17:05:05 GMT > >> Content-Type: text/html; charset=UTF-8 > >> Connection: keep-alive > >> > >> I don't see any reference to this at > >> http://nginx.org/en/docs/http/ngx_http_v2_module.html so I am guessing > >> this is unintended. > > > > [..] > > > > A quote from the documentation: > > | The http2 parameter (1.9.5) configures the port to accept HTTP/2 > > | connections. > > > > http://nginx.org/en/docs/http/ngx_http_core_module.html#listen > > Ahh. That's not in the http2 module documentation, where I looked and > where it should perhaps also be mentioned, and it's not clear that the > above applies to every server. > > So if I write: > > listen 443 ssl http2; > > in a server directive anywhere as dosumneted in > http://nginx.org/en/docs/http/ngx_http_v2_module.html#example, then > http2 is enabled in all servers on all IP's even if it's not > specifically enabled in a listen directive in a particular server? That > seems wrong, intuitively. There are (more and more) times when shared > IPv4's are necessary, and dictating this behavior for all servers on a > given IPv4 is probably less than optimal. If it's technically a > necessity it could perhaps be more explicitly documented.
It's pretty much the same as "ssl" parameter works. Ones connected an HTTP/2 client is able to request any host over the HTTP/2 connection, and in fact browsers do. So there's no proper way to disable HTTP/2 for one virtual server while keeping enable for others. Could you suggest a good phrase to improve the docs? wbr, Valentin V. Bartenev _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
