New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 718619 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

DevTools does not properly handle WS close frame

Project Member Reported by eostroukhov@chromium.org, May 4 2017

Issue description

Chrome Version: 60.0.3090.0
OS: Linux x64

What steps will reproduce the problem?
(1) Start node as "node --inspect-brk -e "process._debugEnd()"
(2) Navigate to chrome://inspect, attach to the Node

What is the expected result?
Node script runs to a completion, detaching the Chrome

What happens instead?
Node script hangs.


Please note that this only happens when connecting from the chrome://inspect. Connecting through chrome-devtools://... works as expected.

I debugged the issue and the problem being that Chrome does not respond to WebSocket close frame (https://tools.ietf.org/html/rfc6455#section-5.5.1).
 
Owner: eostroukhov@chromium.org
Components: Platform>DevTools
Project Member

Comment 3 by bugdroid1@chromium.org, May 10 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/22b6704f77638e8621311aa2c11e6ea1778885bf

commit 22b6704f77638e8621311aa2c11e6ea1778885bf
Author: eostroukhov <eostroukhov@chromium.org>
Date: Wed May 10 18:26:23 2017

[DevTools] Respond with a close frame

WS spec section 5.5.1:

If an endpoint receives a Close frame and did not previously send a
Close frame, the endpoint MUST send a Close frame in response.  (When
sending a Close frame in response, the endpoint typically echos the
status code it received.)  It SHOULD do so as soon as practical.  An
endpoint MAY delay sending a Close frame until its current message is
sent (for instance, if the majority of a fragmented message is
already sent, an endpoint MAY send the remaining fragments before
sending a Close frame).  However, there is no guarantee that the
endpoint that has already sent a Close frame will continue to process
data.

After both sending and receiving a Close message, an endpoint
considers the WebSocket connection closed and MUST close the
underlying TCP connection.  The server MUST close the underlying TCP
connection immediately; the client SHOULD wait for the server to
close the connection but MAY close the connection at any time after
sending and receiving a Close message, e.g., if it has not received a
TCP Close from the server in a reasonable time period.

BUG= 718619 

Review-Url: https://codereview.chromium.org/2871573011
Cr-Commit-Position: refs/heads/master@{#470649}

[modify] https://crrev.com/22b6704f77638e8621311aa2c11e6ea1778885bf/chrome/browser/devtools/device/android_web_socket.cc

Status: Verified (was: Assigned)

Sign in to add a comment