Possible bug http2 module

[Jim Ohlstein]

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.

-- 
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain