netlify.com and sites served on Netlify can’t be accessed from Chrome 85 dev (85.0.4158.4).
It fails with the error
ERR_CONNECTION_RESET and the netlog shows:
t=3877 [st=3876] HTTP2_STREAM_ERROR
--> description = "Abandoned."
--> net_error = "ERR_ABORTED"
--> stream_id = 1
@ylemkimon This sounds like a problem for the Chrome dev team, not for Netlify support.
The issue seems to be sporadic, i.e., only occurs for few hours. This seems to be caused by misconfiguration on Netlify CDNs.
It still sounds like an issue to report to the Chrome team. I wouldn’t expect Netlify to respond to a problem with yet-to-be-released software.
@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:
Last reviewed by Netlify Support: October 2021
What is the x-nf-request-id header?
Web servers and web browsers communicate using a protocol called HTTP - which stands for “HyperText Transfer Protocol”. Both web browsers and web servers use a feature called headers as part of this protocol.
The headers that web browsers send are called “request headers” because the browser in making an “HTTP request”.
The web servers headers are called “response headers” because web servers send an “HTTP res…
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:
the complete URL requested
the IP address for the system making the request
the IP address for the CDN node that responded
the day of the request
the time of the request
the timezone the time is in
x-nf-request-id header is not available since the connection is never established.
One instance is:
Client IP: 175.123.one-hundred-three.168
Server IP: 126.96.36.199
Request time: 2020-06-13 03:20:20.818 UTC
Many thanks for the report and linking to the Chromium bug tracker. We’ll look into it next week and share what we find.
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:
For the first few years of the web, developers pretty much coded whatever they thought was cool and shipped it. Specifications, if written at all, were an after thought. Then, for the next two deca…
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!