Repository navigation
webSocketDebuggerUrl returned by v8_inspector in /json is invalid #7227
Description
Activity
@nodejs/diagnostics
Yes, it is a bug in inspector_agent.cc. Would you be able to send a PR?
@pavelfeldman would this be against the v8 repo? @auchenberg if you do not have time to do this I'd be more than happy to, just let me know
It'd be nice if we could extract hash into a const and reuse it as well. I can see that entire block is wrong. Should be using same hash as https://github.com/nodejs/node/blob/master/src/inspector_agent.cc#L37
@pavelfeldman I'm digging into this right now. It seems like it isn't going to be straight forward afaict as
SendTargentsListResponseand a variety of callbacks that call it are all static. At the moment I cannot find a way to get the port in the static function.The call stack
SendTargentsListResponse(static)
RespondToGet(static)
Agent::OnInspectorHandshakeIO(static)
Agent::OnSocketConnectionIO(static) (last place we have access to uv_stream_t* server)
Agent::WorkerRunIO(first non static function in call stack, have access to port_)Agent::OnSocketConnectionIOis passed touv_listenso that is likely the end of the line here as to where we can do anything. I'm digging through the libuv docs right now but I'm not entirely sure if it is possible to get the port from uv_stream_t or not... I'm going to continue digging but would appreciate any helpedit: it is worth mentioning that the instance of
uv_stream_tis a recast instance ofuv_tcp_tLook at how
Agent::OnRemoteDataIOunwraps Agent from stream:inspector_socket_t* socket = static_cast<inspector_socket_t*>(stream->data); Agent* agent = static_cast<Agent*>(socket->data);@pavelfeldman thanks! figured it out and pushed a PR
- added a commit that references this issue
on Jun 9, 2016 Not sure if someone's already fixed this. In the latest nightly this is the url I get.
webSocketDebuggerUrl: "ws://localhost:9999/node"
The
webSocketDebuggerUrlreturned by v8_inspector in/jsonHTTP endpoint is invalid, and causes 3rd party clients like VS Code and Sublime to fail connecting to the new CDP endpoint.In addition then
devtoolsFrontendUrlis served without the?ws=querystring, which is returned by Chrome and Edge.Actual response from
http://localhost:5858/json:[{ "description": "node.js instance", "devtoolsFrontendUrl": "https://chrome-devtools-frontend.appspot.com/serve_file/@4604d24a75168768584760ba56d175507941852f/inspector.html", "faviconUrl": "https://nodejs.org/static/favicon.ico", "id": "27382", "title": "./node", "type": "node", "webSocketDebuggerUrl": "ws:///node" }]Expected response:
[{ "description": "node.js instance", "devtoolsFrontendUrl": "https://chrome-devtools-frontend.appspot.com/serve_file/@4604d24a75168768584760ba56d175507941852f/inspector.html?experiments=true&v8only=true&ws=localhost:5858/node", "faviconUrl": "https://nodejs.org/static/favicon.ico", "id": "27382", "title": "./node", "type": "node", "webSocketDebuggerUrl": "ws://localhost:5858/node" }](CC @ofrobots, @pavelfeldman)