I recently enabled SPDY on this blog, and once in a while I got the following “err_spdy_protocol_error” error in my browser, causing chunks of the page (javascript, CSS, …) to stop loading.
The err_spdy_protocol_error error: what it looks like
You see the error in your browser like this.
net::ERR_SPDY_PROTOCOL_ERROR
In the Network Tab of your inspector, it looks like this.
That’s not good, right.
Where does the err_spdy_protocol_error error come from?
The solution to the “err_spdy_protocol_error” problem turned out to be really simple, at least in this case, by just looking at the error logs produced by this vhost.
$ tail -f /var/www/site.be/logs/error.log 2014/12/18 00:15:01 [crit] 1041#0: *3 open() "/usr/local/nginx/fastcgi_temp/4/00/0000000004" failed (13: Permission denied) while reading upstream, client: 1.2.3.4, server: ma.ttias.be, request: "GET /page.php?..."
To enable SPDY I had upgraded my Nginx to the latest available 1.7.8, but in the process of that installation it seems some file permissions were incorrectly modified. For instance, the FastCGI cache – the one that holds the responses for the PHP-FPM upstream – were owned by user nobody, with only write permissions to the owner.
$ ls -alh /usr/local/nginx/fastcgi_temp drwx------ 12 nobody root 4096 Feb 11 2012 fastcgi_temp
And as an obvious result, Nginx couldn’t write to that cache directory. Modified the permissions to grant the user nginx write permissions, and all errors were gone.
$ chown nginx:nginx /usr/local/nginx/fastcgi_temp/ -R
And all SPDY protocol errors were gone. Conclusion? Check the errors logs when you implement a new protocol in the middle of the night.
If you get the err_spdy_protocol_error error as a user, and don’t manage the site you’re visiting, there isn’t much you can do. The problem is with the server, so if you can’t change that, you can’t fix the err_spdy_protocol_error error. If you really want to visit that site, try another browser (one that doesn’t support SPDY/HTTP2).