What does ERR_SPDY_PROTOCOL_ERROR mean in nginx?

Question

I and a few of my colleagues got the net::ERR_SPDY_PROTOCOL_ERROR error.

We use ngnix version 1.8.0. The error is not stable (hard to replicate), and t

Answer 1

Our current structure was

AWS ELB=>Nginx=>JBoss

It prompted us the the same crome error ERR_SPDY_PROTOCOL_ERROR

It worked properly without http2 which is by default enabled by ELB, we didn't want it to be disabled. On further investigation it was noticed that our JBoss server was compressing the response.We disabled the it and everything working fine.

Answer 2

As you can tell from the other answers, a lot of different things can cause this. For me, I had a malformed header that other browsers were just ignoring (an extra :). The only answer for this is a debugging tip, checkout Chrome's net-internals events while loading the broken page: chrome://net-internals/#events

For me, I knew it was a header issue when I saw this line

t=65422 [st=53]      HTTP_TRANSACTION_READ_HEADERS  [dt=4]
                 --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR) 

After removing the extra : from the header response, HTTP/2 began working in Chrome. I suggest getting a raw response from your server and doing very close inspection to ensure there are no syntax errors.

Answer 3

This is a known issue that exists between Chromium browsers and certain antivirus programs such as AVG and Avast, especially when using a SSL connection. It cannot be resolved on the user's end. It's up to website developers to prevent this issue from happening.

The documentation for web developers is here: http://dev.chromium.org/spdy/spdy-best-practices

Here are some helpful hints for developers that are not specifically mentioned in that article:

• Be extremely careful when using headers and redirects, especially 301 and 302's
• Keep all your includes in or under the same directory as your domain name access, not above the directory in the server. Antivirus cannot access them there. To protect your include files, create a .htaccess file in the includes directory and simply write one line: Deny from all
• Enable Gzip compression. If you use cPanel, this can be done in your Website Optimization settings.
• Keep your .htaccess file simple. Switching server outputs to create different file extensions and redirecting user clients will create unnecessary conflict.

In my experience, this issue only seems to occur when using Sessions to store and pass data. Cookies, Get and Post seem to not be affected.

Hope this helps.

Answer 4

I've seen this error recently after a server upgrade.

I was seeing it for all users in Chrome, but only intermittently.

I was able to resolve it for all users by getting them to use Chrome's 'Empty Cache and Hard Reload' refresh function for the site. (F12 for Chrome tools, right click on refresh button)

I suspect it related to something cached about the SSL certs being used.

Answer 5

As with the OP, this was an intermittent issue for me and only happening on AJAX requests > 2mb in size.

The problem started occurring after we moved from an AWS classic ELB to ALB.

I solved this by uninstalling Chrome, deleting my user profile (On mac delete the contents of ~/Library/Application Support/Google/Chrome), then reinstalling.

Answer 6

For me it was Nginx configuration that didn't allow OPTIONS method. I had whitelisted GET|PUT|POST|DELETE only, so when Chrome tried to send OPTIONS method, for God knows why**, the error was reproduced.

Open up Firefox and repeat the request, then look at the Network inspector to check if any OPTIONS requests are being sent.

** probably to check for X-Frame-Options or HSTS verification.