Cannot access Netlify sites with Chrome 85

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.

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:

  • 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

The x-nf-request-id header is not available since the connection is never established.

One instance is:

  • URL: https://www.netlify.com/
  • Client IP: 175.123.one-hundred-three.168
  • Server IP: 157.230.43.191
  • Request time: 2020-06-13 03:20:20.818 UTC

The issue is tracked as https://bugs.chromium.org/p/chromium/issues/detail?id=1094308 in the chromium bug tracker.

1 Like

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:

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!