Chrome does not always send WebSocket Close Frame when refreshing or closing the tab/browser
Reported by
a.grossa...@gmail.com,
Apr 13 2018
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. set up a simple websocket server and run it on a webserver (you can probably use EchoWebSocksServer.php from Issue 392534 : https://bugs.chromium.org/p/chromium/issues/detail?id=392534) 2. Open a websocket test page (eg. https://www.websocket.org/echo.html) in several tabs and connect all tabs to your server. 3. close all tabs one by one. 4. server will not get all Close Frames. (in my test I got 5 out of 33, with a .net Core Application hosted on Microsoft Azure as App Service) Note: this seems to be a timing problem, so if you run the WebSocket server on localhost, it will probably get all Close Frames because communication is much faster. What is the expected behavior? WebSocket Close Frames should also be sent if the server is not superfast. What went wrong? Chrome does not always send WebSocket Close Frame when refreshing or closing the tab/browser depending on the speed of the WebSocket server. Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: 10.0 Flash Version: Probably related issues: - https://bugs.chromium.org/p/chromium/issues/detail?id=392534 - https://bugs.chromium.org/p/chromium/issues/detail?id=426798
,
Apr 16 2018
This is a known issue. When a tab is closed, we send a GoingAway (1001) Close frame to the server, and immediately close the socket. Windows really hates it when you close the socket immediately after a write, and will often throw the data away rather than transmit it. This is what you are seeing. In general, we consider the sending of the GoingAway Close frame to be best-effort. We won't send it if the whole browser is closed, and we can't send it if there is data queued for transmission when the tab is closed. In other words, server software needs to be able to deal with not having the GoingAway frame anyway, so there's not a lot of benefit in working around Windows' behaviour. There are ways we could keep the socket alive longer after sending the Close frame to make it more reliable on Windows. However, this would lead to extra complexity in the code, leading to more bugs. The bugs we introduced in fixing this would almost certainly be more serious than the original issue. Issue 392534 was related but issue 426798 is different (it is about close behaviour with non-compliant servers). Older versions of Windows had this issue but for some reason it got much more frequent with Windows 10. |
||
►
Sign in to add a comment |
||
Comment 1 by schenney@chromium.org
, Apr 13 2018