Can you provide a net-internals log of when you get this error? Instructions are at https://dev.chromium.org/for-testers/providing-network-details.

Assuming you have access to the server where this is happening, is the server seeing the request Chrome is sending? Is the server sending a valid response to the request that Chrome has a ERR_CONNECTION_CLOSED error for?

Hi Attached the net-internals log file for further analysis.
When this error occurs, Browser is not sending the request out so obviously server cant send any response.

Looks like we're establishing an encrypted HTTP2 connection, sending a request for /assets/img/icon-default.png, and then the server is closing the connection on us.  I assume the "description = ABANDONED (stream_id=1): ..." just means we're mad that the server hung up on us, though I defer to those who know more about HTTP2 on that.

There are four abandoned streams in the netlog from comment #2.

On HTTP2_SESSION 29192, streams 65, 67, and 69 are opened by the client, but the
server never sends any frames on them.  The server sends a GOAWAY on this
connection with last accepted stream id = 63.  There is no information about why
the server sends the GOAWAY frame.

On HTTP2_SESSION 229878, Chrome only opens one stream, with id 1.  It receives
a SETTINGS frame and a WINDOW_UPDATE frame from the server.  Then the connection
is closed with ERR_CONNEcTION_CLOSED, which could be a network error, like TCP
reset.

I think the next step would be to get some server side debugging, as mentioned
in comment #1.

Reset would be ERR_CONNECITON_RESET, no?

Re #5: Oops, you are right.

Hi,
Thanks for your response. 
The same flow is working fine from mozilla firefox browser, I am wondering how this is possible if server is closing the connection. Firefox would be using http1.1?

Best Regards,
Raghu

Could be any number of things - they could be talking HTTP/1.1 instead of HTTP/2, the server could be doing different things when it talks to FireFox (Maybe it likes their SSL handshake more, so random connections don't die).  Maybe FireFox has retry logic that is tickled in this case, for whatever reason.

It could also be that the server doesn't like the H2 settings we send, some somesuch, though they do seem to work for other requests...And they also work for the exact same request that failed, a littler later, when the same URL is re-requested, and the second request looks exactly like the first one.

Could also be the FireFox makes the requests close enough together to reuse the same socket (We make a couple requests, the server closes the socket, and we make a new one 10 milliseconds later to request another file.  It could either be how short that duration is that's triggering some DoS protection, or just that since FireFox always requests things before the initial socket is closed, it never runs into issues trying to reconnect).

Thank you for providing more feedback. Adding requester "nharper@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot