Support Network Inspection

[eugeneo]

Network domain is what Chrome DevTools (and any other interested frontends) use for inspecting the HTTP and WS traffic in the browser. This document provides some insight into Chrome DevTools UI and here is a description of the protocol for obtaining that data.

We propose to introduce a Node specific agent that would expose the same (or subset) of this protocol to enable the UI. It does not seem possible to share the implementation between Blink and Node.js.

This agent would also introduce an API for the modules to report the events. E.g. WebSocket modules should be able to notify the agent when WS frames are sent or received.

[github-actions[bot]]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[mturley]

It would be nice to reopen this, as far as I can tell it's still an issue, and quite a frustrating one at that.

[jkrems]

It would be nice to reopen this, as far as I can tell it's still an issue, and quite a frustrating one at that.

I think the honest answer is that - bare anybody stepping up - this issue is a "won't fix". This could change in the future but especially in the context of nodejs/diagnostics (a working group), closing this issue expresses what action the working group is taking for the foreseeable future.

It may be worth opening an issue in Chrome devtools or nodejs/node but it's a good chunk of work, so I wouldn't be surprised if the issue just lingers (or is closed) there, too.

[mturley]

Fair enough, thanks for the reply @jkrems

[saivishnutammineni]

I had the same requirement to debug the network requests. This becomes a bigger problem when debugging a request requires me to check previous requests made too. So I created a NPM package to show network requests made from NodeJS app in a Chrome Dev tools like UI. Thought it might help someone.

Network Activity Viewer

[gkatsanos]

Please do this.

[quantuminformation]

I've moved to bun, lets hope they do it ><

[kettanaito]

Sharing my thoughts on this.

How to represent incoming/outgoing traffic?

As @mcollina asked, the Network panel in the browser's DevTools always represents client-side traffic. In Node.js, a server may both received and send requests, which has to be represented in the Network tab somehow.

Proposal: follow @nicoburns suggestion https://github.com/nodejs/diagnostics/issues/75#issuecomment-420719648 and add both incoming/outgoing traffic in the Network. I'm not aware if CDP supports custom tags for network entries so we could have a checkbox to filter out different kinds of traffic.

How to record the traffic?

I appreciate different third-party suggestions (proxies/interception libraries) but I believe the most straightforward way to do that would be using node:async_hooks and its HTTPINCOMINGMESSAGE and HTTPOUTGOINGMESSAGE events.

One must consider, however, that if a Node.js process has its request modules patches (e.g. when running tests that use API mocking solutions, those events will likely not be called by async_hooks. I believe there is also a tremendous value in being able to inspect mocked network, but for that to work we'd have to spy on higher-level request modules, like http. Once can use Proxy to do that in the least intrusive way possible.

What's to be done?

I have very little knowledge in the CDP but it looks like this is a rough roadmap:

1. Node.js has to implement the Network domain of the CDP.
2. Node.js has to use the Network domain to register outgoing/incoming requests based on the async_hooks listeners (such as invoking .requestWillBeSent() for an requests and .responseReceived() for responses).
3. Node.js has to differentiate between the outgoing and incoming requests somehow.
4. Tests.

Questions

1. @mcollina, to your best knowledge, does async_hooks provide sufficient data to be fed to the Network domain of the devtools? Is there any data that's missing/won't be observable?
2. I suppose with the WebSocket API landing natively in Node.js it will support async_hooks as well? Otherwise it won't be observable.
3. How to deal with third-party WebSocket implementations, if at all? Userland will take time to migrate to the standard WebSocket API, and until then, they will rely on Socket, I assume. It's observable in async_hooks, as far as I recall. Does that sound like a reliable strategy for implementing WebSocket support in the Network inspector?

[mcollina]

1. yes
2. if not it can be added
3. 3rd party would not be supported (or possibly)

tbh I would instrument everything with diagnostic_channel and scoop data from there

[starball5]

Related on Stack Overflow:

• (canonical) how to monitor the network on node.js similar to chrome/firefox developer tools?
• (duplicate) how to get a Network Panel show up when debugging Electron/Node applications
• (duplicate) Network Tab Node Inspect Chrome DevTools

[github-actions[bot]]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[starball5]

I would not like this issue to be closed. To that end, I bump.

[GrinZero]

Expect to be able to listen to requests with chrome devtools made by your own program? You can refer to my recently developed open source library: https://github.com/GrinZero/node-network-devtools. It edit the 'http' and 'https' module from your node program and use CDP to show the info in chrome devtools.

---

I also hope that the official can support it. It's exhausting to do this myself.

[cola119]

I hope https://github.com/nodejs/node/pull/53593 can be a starting point to discuss how we can realize network inspection. If you have any suggestions, If you have any suggestions, please feel free to share them!

[mcollina]

Thank you @cola119!