ERR_SPDY_PROTOCOL_ERROR #151

Closed
nubela opened this Issue Feb 3, 2015 · 22 comments

Projects

None yet

5 participants

@nubela
nubela commented Feb 3, 2015

As you can see, this is the error: http://i.imgur.com/bZGOEiQ.png

Running on SPDY reverse proxy on Chrome 40, Windows XP. @tatsuhiro-t, any idea on why this happens?

@tatsuhiro-t
Collaborator

Did you enable SPDY/4 (aka HTTP/2 draft) in Chrome 40? Then it must be disabled or configure nghttpx with --npn-list=spdy/3.1 so that it only negotiates spdy/3.1.
This is because Chrome's HTTP/2 proxy is broken. I reported this issue https://code.google.com/p/chromium/issues/detail?id=433784 but no progress at this moment.

@bekoli
bekoli commented Apr 24, 2015

I see ERR_SPDY_PROTOCOL_ERROR in Chrome 42 as well but with nghttpd 2-0.7.12

Enabling or disabling SPDY/4 in Chrome does not have any effect on this.

I compiled nghttpd against openssl-1.0.2a too for ALPN but that doesn't seem to make any difference to Chrome.

Firefox 37 however doesn't seem to have a problem with this. It reports X-Firefox-Spdy h2 so I digged a little bit and the problem seems to raise with the usage of --trailer.

When I run nghttpd with --trailer='http2:test' Chrome dies with ERR_SPDY_PROTOCOL_ERROR
When I run nghttpd without --trailer Chrome connects just fine.

@tatsuhiro-t
Collaborator

Your description suggests that Chrome does not support HTTP/2 trailer fields. Did you raise an issue about this in Chromium bug tracker?

@bekoli
bekoli commented Apr 24, 2015

@tatsuhiro-t Not yet. Seems like the right place though (still very very new to this).

@tatsuhiro-t
Collaborator

Yeah, trailer fields are not so popular in HTTP/1.1 since it requires chunked encoding and not all implementation supports trailer. I don't see how it is used in practice.
But HTTP/2, we have framing and trailer is always available.
Google's gRPC utilizes trailer field to send something already.

@bekoli
bekoli commented Apr 24, 2015

I raised https://code.google.com/p/chromium/issues/detail?id=481033 - hope this describes it well.

@tatsuhiro-t
Collaborator

Thanks! Let's wait and see..

@cnrat
cnrat commented Apr 27, 2015

@bekoli Same problem in Chrome 41. You can just set 'npn-list=spdy/3.1' in nghttpx.conf to avoid it.
It seems h2-14 is not implemented via ssl proxy in Chrome.

@tatsuhiro-t And in FireFox 37, there is another problem. When access to a website via ssl proxy (e.g. nghttpx), FireFox show 'sec_error_unknown_issuer' error, because it got certificate issues to proxy's domain.

@cnrat
cnrat commented Apr 28, 2015

@tatsuhiro-t Correction, FireFox shows 'sec_error_unknown_issuer' just because I did not use an right cert contains root CA. My apologies for the oversight.

@bekoli
bekoli commented Apr 28, 2015

@cnrat I got this error with nghttpd. The daemon has no npn-list parameter. The problem in my case could be ommitted when trailer fields are not used.

I see I wrote the command wrong above. Going to correct this.

@cnrat
cnrat commented Apr 28, 2015

@bekoli I got a reply 3 days ago in issue 433784 https://code.google.com/p/chromium/issues/detail?id=433784, it is said this bug will be fixed soon.
PS: they said this is NOT about ALPN implement.

@bekoli
bekoli commented Apr 28, 2015

@cnrat Oh, so this is really the same bug? In that case is my ticket a duplicate. Thanks for posting. I'll watch this as well.

@tatsuhiro-t
Collaborator

Probably they are different bugs. The original bug reported here is due to prohibited header field sent by chrome. While the bug @bekoli reported is chrome drops connection if it sees trailer field.
Server should not send trailer if chrome didn't ask, but at the same time, there is no reason for chrome not to close connection after just seeing trailer field.

@catatnight

I got ERR_CONNECTION_CLOSED when I added npn-list=spdy/3.1 in nghttpx(1.0.0) command line in Chrome 43.

@cnrat
cnrat commented May 23, 2015

@catatnight will you please run telnet command to prove the connectivity?

@catatnight

@cnrat Yes, connectivity on both sides is surely OK.
I met with error ERR_SPDY_PROTOCOL_ERROR in chrome without npn-list=spdy/3.1 in nghttpx, so I searched on google and found the solution here. But I wonder if it is still effective on Chrome 43.

@tatsuhiro-t
Collaborator

@catatnight Please make sure that you have built nghttp2 with libspdylay. nghttpx --npn-list can accept anything, without considering libspdylay support.

@cnrat
cnrat commented May 23, 2015

@catatnight if you set nothing with npn-list witch means it will use 'h2,h2-16,h2-14,spdy/3.1,http/1.1' as default. Due to the bug mentioned above, Chrome 43 still can not work with h2 protocol(also the same Chrome Canary 45).
I think what @tatsuhiro-t said might be the problem. Plz check result after run './configure', witch should be look like this:
...
Libs:
OpenSSL: yes
Libxml2: yes
Libev: yes
Libevent(SSL): yes
Spdylay: yes
Jansson: yes
Jemalloc: yes
...

@catatnight

@tatsuhiro-t Thanks. Problem solved.
@cnrat Thank you for your instruction.

@tatsuhiro-t
Collaborator

Thank you for heads up. Let's close this issue.

@tatsuhiro-t tatsuhiro-t closed this Sep 9, 2015
@cnrat
cnrat commented Sep 10, 2015

Confirmed. Chrome Canary 47 now working good with H2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment