WebSocket closing handshake does not work properly when page is refreshed
Reported by
luigipi...@gmail.com,
Dec 31 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Steps to reproduce the problem: 1. Run the Node.js script in the attachment which will start an HTTP server listening on port 8080. 2. Go to http://localhost:8080 and then refresh the page. 3. An ECONNRESET error is emitted on the server socket. What is the expected behavior? No error emitted on the server socket. What went wrong? A close frame is correctly sent to the server when the page is refreshed. The server responds with a close frame as specified by the closing handshake but it seems that the TCP connection is closed without reading the data that the server sent, thus the error. Did this work before? Yes 62 Does this work in other browsers? Yes Chrome version: 63.0.3239.108 (Official Build) (64-bit) (cohort: 63_win_108) Channel: stable OS Version: 10.0 Flash Version:
,
Jan 2 2018
Able to reproduce this issue on reported version 63.0.3239.108 and on latest canary 63.0.3309.0 using windows 10,Mac 10.13.1 and Ubuntu 14.04 with steps mentioned below. But issue is inconsistent while doing manual bisect.i.e; Sometimes error is seen in console and sometimes not for same build 1. Downloaded nodejs from https://nodejs.org/en and installed 2. In cmd prompt typed node -v and observed version. 3. Downloaded index.js file from bug, In cmd prompt changed directory to downloaded location, used node index.js and observed Listening on:8080 4. Opened browser and typed localhost:8080 and observed blank space with no error in console. 5. Reloaded page and observed error in console as Listening on *:8080 { Error: read ECONNRESET at exports._errnoException (util.js:1020:11) at TCP.onread (net.js:568:26) code: 'ECONNRESET', errno: 'ECONNRESET', syscall: 'read' Removing Needs-Bisect label and marking as Untriaged as issue is inconsistent from TE-end. Could someone from Blink>Network team take a look into this issue. Thanks!
,
Jan 3 2018
Correcting canary build number 65.0.3309.0.
,
Jan 5 2018
,
Jan 5 2018
I'm surprised to hear that it changed. I thought it always behaved this way. When the page is destroyed (as happens when reload is clicked) we make a best-effort to send a Close frame but the WebSocket is torn down without waiting for a response. While it would be possible to wait for a Close frame back from the server in some cases, it would come at a considerable cost in complexity and servers still wouldn't be able to rely on it happening in all cases. Speculatively, changed behaviour may be due to changes in garbage collection. I will leave this issue open for the time being in case anyone has any insights.
,
Jan 5 2018
> While it would be possible to wait for a Close frame back from the server in some cases, it would come at a considerable cost in complexity and servers still wouldn't be able to rely on it happening in all cases. Fair enough, I honestly have no idea, but perhaps that's what other browsers do? I can only consistently reproduce this issue on Chrome.
,
Jan 9 2018
> Fair enough, I honestly have no idea, but perhaps that's what other browsers do? I can only consistently reproduce this issue on Chrome. Other browsers are architected differently, so in some cases what is easy for them may be difficult for us.
,
Jan 9 2018
I understand. The only "sad" thing is that it was working as expected on older versions (maybe too old) of the browser. Thanks though. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Jan 1 2018