I\'m currently working on a website, which triggers a net::ERR_HTTP2_PROTOCOL_ERROR 200
error on Google Chrome. I\'m not sure exactly what can provoke this erro
For several weeks I was also annoyed by this "bug":
net :: ERR_HTTP2_PROTOCOL_ERROR 200
In my case, it occurred on images generated by PHP.
It was at header()
level, and on this one in particular:
header ('Content-Length:'. Filesize($cache_file));
It did obviously not return the exact size, so I deleted it and everything works fine now.
So Chrome checks the accuracy of the data transmitted via the headers, and if it does not correspond, it fails.
I found why content-length
via filesize
was being miscalculated: the GZIP
compression is active on the PHP files, so excluding the file in question will fix the problem. Put this code in the .htaccess
:
SetEnvIfNoCase Request_URI ^ / thumb.php no-gzip -vary
It works and we keep the header Content-length
.
I experienced a similar problem, I was getting ERR_HTTP2_PROTOCOL_ERROR on one of the HTTP GET requests.
I noticed that the Chrome update was pending, so I updated the Chrome browser to the latest version and the error was gone next time when I relaunched the browser.
In our case, the reason was invalid header. As mentioned in Edit 4:
Look for something similar:
HTTP2_SESSION_RECV_INVALID_HEADER
--> error = "Invalid character in header name."
--> header_name = "charset=utf-8"
I also faced this error and I believe there can be multiple reasons behind it. Mine was, ARR was getting timed-out.
In my case, browser was making a request to a reverse proxy site where I have set my redirection rules and that proxy site is eventually requesting the actual site. Now for huge data it was taking more than 2 minutes 5 seconds and Application Request Routing timeout for my server was set to 2 minutes. I fixed this by increasing the ARR timeout by below steps: 1. Go to IIS 2. Click on server name 3. Click on Application Request Routing Cache in the middle pane 4. Click Server Proxy settings in right pane 5. Increase the timeout 6. Click Apply
My team saw this on a single javascript file we were serving up. Every other file worked fine. We switched from http2
back to http1.1
and then either net::ERR_INCOMPLETE_CHUNKED_ENCODING
or ERR_CONTENT_LENGTH_MISMATCH
. We ultimately discovered that there was a corporate filter (Trustwave) that was erroneously detecting an "infoleak" (we suspect it detected something in our file/filename that resembled a social security number). Getting corporate to tweak this filter resolved our issues.
For me, it was the StackOverFlow Exception because of recursive code.