[google-chrome] What's the net::ERR_HTTP2_PROTOCOL_ERROR about?

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 error, I just noticed it pops out only when accessing the website in HTTPS. I can't be 100% sure it is related, but it looks like it prevents javascript to be executed properly.

For instance, the following scenario happens :

1. I'm accessing the website in HTTPS

2. My Twitter feed integrated via https://publish.twitter.com isn't loaded at all

3. I can notice in the console the ERR_HTTP2_PROTOCOL_ERROR

4. If I remove the code to load the Twitter feed, the error remains

5. If I access the website in HTTP, the Twitter feed appears and the error disappears

Google Chrome is the only web browser triggering the error: it works well on both Edge and Firefox. (NB: I tried with Safari, and I have a similar kcferrordomaincfnetwork 303 error)

I was wondering if it could be related to the header returned by the server since there is this '200' mention in the error, and a 404 / 500 page isn't triggering anything.

Thing is the error isn't documented at all. Google search gives me very few results. Moreover, I noticed it appears on very recent Google Chrome releases; the error doesn't pop on v.64.X, but it does on v.75+ (regardless of the OS; I'm working on Mac tho).

Any clue at this point to investigate would be gladly appreciated !

Thanks in advance.

Tristan

Edit 1 : Might be related to Website OK on Firefox but not on Safari (kCFErrorDomainCFNetwork error 303) neither Chrome (net::ERR_SPDY_PROTOCOL_ERROR)

Edit 2 : Findings from further investigations are the following :

• error doesn't pop on the exact same page if server returns 404 instead of 2XX
• error doesn't pop on local with a HTTPS certificate
• error pops on a different server (both are OVH's), which uses a different certificate
• error pops no matter what PHP version is used, from 5.6 to 7.3 (framework used : Cakephp 2.10)

Edit 3 : As requested, below is the returned header for the failing ressource, which is the whole web page. Even if the error is triggering on each page having a HTTP header 200, those pages are always loading on client's browser, but sometimes an element is missing (in my exemple, the external Twitter feed). Every other asset on the Network tab has a success return, except the whole document itself.

Google Chrome header (with error) :

Firefox header (without error) :

A curl --head --http2 request in console returns the following success :

HTTP/2 200 
date: Fri, 04 Oct 2019 08:04:51 GMT
content-type: text/html; charset=UTF-8
content-length: 127089
set-cookie: SERVERID31396=2341116; path=/; max-age=900
server: Apache
x-powered-by: PHP/7.2
set-cookie: xxxxx=0919c5563fc87d601ab99e2f85d4217d; expires=Fri, 04-Oct-2019 12:04:51 GMT; Max-Age=14400; path=/; secure; HttpOnly
vary: Accept-Encoding

Edit 4 : Trying to go deeper with the chrome://net-export/ and https://netlog-viewer.appspot.com tools is telling me the request ends with a RST_STREAM :

t=123354 [st=5170]    HTTP2_SESSION_RECV_RST_STREAM
                      --> error_code = "2 (INTERNAL_ERROR)"
                      --> stream_id = 1

For what I read in this other post, "In HTTP/2, if the client wants to abort the request, it sends a RST_STREAM. When the server receives a RST_STREAM, it will stop sending DATA frames to the client, thereby stopping the response (or the download). The connection is still usable for other requests, and requests/responses that were concurrent with the one that has been aborted may continue to progress. [...] It is possible that by the time the RST_STREAM travels from the client to the server, the whole content of the request is in transit and will arrive to the client, which will discard it. However, for large response contents, sending a RST_STREAM may have a good chance to arrive to the server before the whole response content is sent, and therefore will save bandwidth."

The described behavior is the same as the one I can observe. But that would mean the browser is the culprit, and then I wouldn't understand why it happens on two identical pages with one having a 200 header and the other a 404 (same goes if I disable JS).

I had this problem when having a Nginx server that exposing the node-js application to the external world. The Nginx made the file (css, js, ...) compressed with gzip and with Chrome it looked like the same.

The problem solved when we found that the node-js server is also compressed the content with gzip. In someway, this double compressing leading to this problem. Canceling node-js compression solved the issue.

By default nginx limits upload size to 1MB.

With client_max_body_size you can set your own limit, as in

location /uploads {
    ...
    client_max_body_size 100M;
} 

You can set this setting also on the http or server block instead (See here).

This fixed my issue with net::ERR_HTTP2_PROTOCOL_ERROR

For me it was due to full disk space.

My application (server) was running on docker. Cleared some space and it started working.

I hit this issue working with Server Sent Events. The problem was solved when I noticed that the domain name I used to initiate the connection included a trailing slash, e.g. https://foo.bar.bam/ failed with ERR_HTTP_PROTOCOL_ERROR while https://foo.bar.bam worked.

In my case I have a kubernetes cluster with nginx ingress controller and nginx+php-fpm to handle drupal instance.

I notice this issue on one of my page, where my pictures was not loaded in chrome. After investigation I discovered that modsecurity module enabled in my nginx ingress somehow produce this issue. Not fully know why, but after disabling it, all pages are loaded fine.

Best Regards.

I am finally able to solve this error after researching some things I thought is causing the error for 24 errors. I visited all the pages across the web. And I am happy to say that I have found the solution. If you are using NGINX, then set gzip to off and add proxy_max_temp_file_size 0; in the server block like I have shown below.

 server {
  ...
  ...
  gzip off;
  proxy_max_temp_file_size 0;
  location / {
    proxy_pass http://127.0.0.1:3000/;
  ....

Why? Because what actually happening was all the contents were being compressed twice and we don't want that, right?!

For my situation this error was caused by having circular references in json sent from the server when using an ORM for parent/child relationships. So the quick and easy solution was

JsonConvert.SerializeObject(myObject, new JsonSerializerSettings { ReferenceLoopHandling = ReferenceLoopHandling.Ignore })

The better solution is to create DTOs that do not contain the references on both sides (parent/child).

This happened to me when I registered a new domain name, e.g., "new" for example.com (new.example.com). The name could not be resolved temporarily in my location for a couple of hours, while it could be resolved abroad. So I used a proxy to test the website where I saw net::ERR_HTTP2_PROTOCOL_ERROR in chrome console for some AJAX posts. Hours later, when the name could be resloved locally, those error just dissappeared.

I think the reason for that error is those AJAX requests were not redirected by my proxy, it just visit a website which had not been resolved by my local DNS resolver.

net::ERR_HTTP2_COMPRESSION_ERROR - WORDPRESS

Okay, I hope this will help many. I have been experiencing this for many weeks. My apology because I am using WordPress.

net::ERR_HTTP2_COMPRESSION_ERROR only occurs on Chrome:Incognito.

I have Cloudflare for my CDN and caching HTML - and W3 Total Cache - for minify js, css and Page Cache, OP-Cache, Object Cache, Browser Cache.

now, after countless of trouble shooting, I detected the issue when disabling the "Browser Cache" after that, I fixed the problem when

I modified the Browser Cache ( go to side panel )

find the ("HTTP Strict Transport Security policy") make sure its checked. under that is directive set the value to - max-age=EXPIRES_SECONDS; includeSubDomain: preload

take note that I am using sub-domain.

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.

EDIT

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 encountered this because the http2 server closed the connection when sending a big response to the Chrome.

Why? Because it is just a setting of the http2 server, named WriteTimeout.

In my case it was - no disk space left on the web server.

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 my case (nginx on windows proxying an app while serving static assets on its own) page was showing multiple assets including 14 bigger pictures; those errors were shown for about 5 of those images exactly after 60 seconds; in my case it was a default send_timeout of 60s making those image requests fail; increasing the send_timeout made it work

I am not sure what is causing nginx on windows to serve those files so slow - it is only 11.5MB of resources which takes nginx almost 2 minutes to serve but I guess it is subject for another thread

In my case, it was WordPress that now requires PHP 7.4 and I was running 7.2.
As soon as I updated, the errors disappeared.

I faced this error several times and, it was due to transferring large resources(larger than 3MB) from server to client.

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.

I had another case that caused an ERR_HTTP2_PROTOCOL_ERROR that hasn't been mentioned here yet. I had created a cross reference in IOC (Unity), where I had class A referencing class B (through a couple of layers), and class B referencing class A. Bad design on my part really. But I created a new interface/class for the method in class A that I was calling from class B, and that cleared it up.

I got the same issue (asp, c# - HttpPostedFileBase) when posting a file that was larger than 1MB (even though application doesn't have any limitation for file size), for me the simplification of model class helped. If you got this issue, try to remove some parts of the model, and see if it will help in any way. Sounds strange, but worked for me.

I'm not convinced this was the issue but through cPanel I'd noticed the PHP version was on 5.6 and changing it to 7.3 seemed to fix it. This was for a WordPress site. I noticed I could access images and generic PHP files but loading WordPress itself caused the error.

In our case, the reason was invalid header. As mentioned in Edit 4:

• take the logs
• in the viewer choose Events
• chose HTTP2_SESSION

Look for something similar:

HTTP2_SESSION_RECV_INVALID_HEADER

--> error = "Invalid character in header name."

--> header_name = "charset=utf-8"

We experienced this problem on pages with long Base64 strings. The problem occurs because we use CloudFlare.

Details: https://community.cloudflare.com/t/err-http2-protocol-error/119619.

Key section from the forum post:

After further testing on Incognito tabs on multiple browsers, then doing the changes on the code from a BASE64 to a real .png image, the issue never happened again, in ANY browser. The .png had around 500kb before becoming a base64,so CloudFlare has issues with huge lines of text on same line (since base64 is a long string) as a proxy between the domain and the heroku. As mentioned before, directly hitting Heroku url also never happened the issue.

The temporary hack is to disable HTTP/2 on CloudFlare.

Hope someone else can produce a better solution that doesn't require disabling HTTP/2 on CloudFlare.

I have been experiencing this problem for the last week now as I've been trying to send DELETE requests to my PHP server through AJAX. I recently upgraded my hosting plan where I now have an SSL Certificate on my host which stores the PHP and JS files. Since adding an SSL Certificate I no longer experience this issue. Hoping this helps with this strange error.

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

This error is currently being fixed: https://chromium-review.googlesource.com/c/chromium/src/+/2001234

But it helped me, changing nginx settings:

• turning on gzip;
• add_header 'Cache-Control' 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
• expires off;

In my case, Nginx acts as a reverse proxy for Node.js application.