Opened 7 years ago

Closed 3 years ago

#1209 closed defect (worksforme)

Weird net::ERR_SPDY_PROTOCOL_ERROR errors when http2 emabled

Reported by: till.vollmer@… Owned by:
Priority: minor Milestone:
Component: other Version: 1.10.x
Keywords: Cc:
uname -a: Linux xxx 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.10.3
built with OpenSSL 1.1.0d 26 Jan 2017 (running with OpenSSL 1.1.0e 16 Feb 2017)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-F3HeH5/nginx-1.10.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/ --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-F3HeH5/nginx-1.10.3/debian/modules/nginx-auth-pam --add-dynamic-module=/build/nginx-F3HeH5/nginx-1.10.3/debian/modules/nginx-dav-ext-module --add-dynamic-module=/build/nginx-F3HeH5/nginx-1.10.3/debian/modules/nginx-echo --add-dynamic-module=/build/nginx-F3HeH5/nginx-1.10.3/debian/modules/nginx-upstream-fair --add-dynamic-module=/build/nginx-F3HeH5/nginx-1.10.3/debian/modules/ngx_http_substitutions_filter_module
root@mm-preview:~# type nginx
nginx is hashed (/usr/sbin/nginx)


Chrome version 6.0.2924.87 (64-bit)
but also happens on Firefox but with a different error message

When I add http2 to my configuration some users get net::ERR_SPDY_PROTOCOL_ERROR
error.log is empty and access.log shows successfully requests

The weird thing is that it seems to be location dependent, meaning that I have locations where it never happens and in our office in Vienna always have it. Also the amount of files (images) seems to be relevant. up to 5 seem to work, but more fail. See screenshot of Chrome.

We use upstream to a unicorn Ruby in Rails server.

nginx config for this:

server {

	# SSL configuration
    	listen ssl http2 default_server;

        # ca-bundle merge and ciphers etc

        ssl_certificate /etc/nginx/cert/unkown.cacrt;
        ssl_certificate_key /etc/nginx/cert/unkown.key;
	root /home/unkown/server/mymind/current/public;

#app and cdn is redundant
    	server_name ~^cdna\d+\.unkown\.com$;

        access_log /var/log/nginx/unkown-access.log;
        error_log /var/log/nginx/unkown-error.log;

        add_header X-Request-Origin xpreview;

# assets 

       location ~*  ^/(assets|images|javascripts|stylesheets)/.*\.(svg|ico|gif|jpe?g|png|js|css|html|ttf|ttc|otf|eot|woff|font.css)$ {
	     expires 365d;
     	 add_header Access-Control-Allow-Origin *;
         add_header etag "";
         add_header cache-control public;

# normal requests

	location / {

		try_files $uri @rails_normal;


        location @rails_normal {
            proxy_pass      http://single_rest;
            proxy_redirect off;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_set_header X_FORWARDED_PROTO "https";
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_connect_timeout      120;
            proxy_send_timeout         120;
            proxy_read_timeout         120;
            proxy_set_header CLIENT_IP $remote_addr;
            proxy_buffer_size   128k;
            proxy_buffers   4 256k;
            proxy_busy_buffers_size   256k;


Here the log from chrome http2 network internals attached as file

Change History (8)

comment:1 by till.vollmer@…, 7 years ago

Files on request. Too big for attachments.

comment:2 by WarriorXK@…, 7 years ago

Since chrome 58 i get the same error, IE, Safari and Firefox work fine for me. However other subdomains also using http2 don't have this issue.

comment:3 by dave.g.bell@…, 7 years ago

I'm finding the same as WarriorXK, a previously working site stopped after a Chrome update. The error exists from all attempted connections in Chrome, different machines, networks and even a phone running Chrome give the same result.

The site runs fine in other browsers, and the server is also running a few other sites, using copied & pasted configs (tweaked only for domain, folder & "friendly URLs"), and these are running fine in the same Chrome browsers.

comment:4 by Valentin V. Bartenev, 7 years ago

Please, provide a debug log from nginx as described here: and an HTTP/2 session log from chrome://net-internals tab.

comment:5 by dave.g.bell@…, 7 years ago

After hours of searching Nginx files, testing, clearing every cache I could find, it turned out that one of our programmers had written header('/RedeemVoucher'); in the index.php, creating an invalid header because it should have been header('Location: /RedeemVoucher');

After putting the Location: bit in, it worked straight away.

comment:6 by ericlaw1979@…, 7 years ago

Maybe there should be some sort of basic linter or other tool to flag these? Two other recent instances occurred due to an errant space or colon in the header name:!topic/hstspreload/_uGEnwt_1_E

comment:7 by ayeshaggupta@…, 6 years ago

Mistake code err_spdy_protocol_error may likewise emerge because of some issue in your antivirus. On the off chance that you are utilizing Avast Antivirus on your gadget then you can include the address of the site which is giving this mistake to the execution rundown of Avast Antivirus. Avast antivirus helps in settling this issue just by overlooking the pages which are demonstrating this mistake. For settling this mistake with the assistance of Avast Antivirus you can simply take after the means given underneath

comment:8 by Maxim Dounin, 3 years ago

Resolution: worksforme
Status: newclosed

Feedback timeout. Likely an issue with headers returned by the upstream server. With changes in 41f4bd4c51f1 (nginx 1.21.1), nginx should be able to better detect and reject such broken headers from upstream servers.

Note: See TracTickets for help on using tickets.