Hi, @ylemkimon, we can see if there are any clues from our side.
In order to troubleshoot this, we need to be able to track the HTTP response with this issue. The simplest way to do this is to send us the x-nf-request-id header which we send with every HTTP response.
There more information about this header here:
If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:
This is still being worked on and I see one of our developers commenting in the chromium issue you linked to. It sounds like the root cause is now identified.
Reading though those comments it would seem enabling the -http2-grease-settings setting will trigger the issue reliably.
I didn’t know what HTTP/2 GREASE was and I found the following post explaining it:
I am posting this here as I found this quite informative. I hope that others tracking this issue will find it an interesting read as well.
Note, this has nothing to do with a solution or workaround but, for me at least, this was good reading material while a solution is in the works.
Yesterday we pushed an update to our CDNs that allows prerelease versions of Chrome to work again. Please let us know if your experience does not match my assertion!