The "Network" tab should provide visibility into non-HttpClient HTTP traffic

[brianquinlan]

The "Network" tab doesn't provide any visibility into HTTP traffic sent through clients other than HttpClient e.g. package:cupertino_http, package:cronet_http.

[kenzieschmoll]

@CoderDake @bkonyi could be similar to the issues with package:dio support

[bkonyi]

I'm not sure about package:dio (it might be using HttpClient internally), but package:cupertino_http and package:cronet_http are FFI packages that hook into some native libraries.

[hanskokx]

I experienced the same thing. Here's a super simple piece of code to demonstrate:

Even when using the http package and http.Client I was unable to see anything in the Network page.

[brianquinlan]

@kenzieschmoll : package:dio uses HttpClient internally so I would expect it's traffic to be visible in the Network tab - isn't it?

@hanskokx : The default Client in package:http also uses HttpClient for it's implementation (except on web) so I would also expect it's traffic to be visible in the Network tab. Are you using a different Client?

[fennelhans]

@brianquinlan Nope. Just the default. There's nothing particularly exciting about the code or environment, either. About as simple of an app as you can write, running on Windows.

[brianquinlan]

Do I understand correctly that the Networking tab is driven from data collected in HttpProfiler

and then consumed by network_profiling.dart using a pull model?

[CoderDake]

@brianquinlan yes those are the basics of it :)
I have some fixes coming through the pipe that may end up fixing some of the issues you are seeing.
There was an issue with request id's overflowing in devtools so requests were sometimes not showing up at all.

I've been updating this issue when I make progress:
#2860

If the issue you are seeing is that requests are not showing up in the inspector, it may be worth trying this workaround: #5194 (comment)

Running Devtools on desktop avoids that overflow error so you may then be able to see the requests showing up in the list.
(unfortunately the response tab will still be a bit buggy for now though)

[brianquinlan]

Hey @CoderDake , I think that the issues that you are referring to only apply to clients based on dart:io HttpClient.

This issue is about clients not based on HttpClient (e.g. package:cupertino_http, which is based on Apple's NSURLSession APIs).

To accommodate clients like that, it seems like we'd need a new public API that those clients case use to record relevant events. I'd love to talk about designing one.

[brianquinlan]

How about we move HttpProfiler (and the supporting classes) to dart:developer?

To be useful to 3p HTTP client implementations, we'd have to make generic versions of some methods e.g. formatConnectionInfo.

[bkonyi]

Moving this functionality to dart:developer makes sense to me, but we'll want to do some design work beforehand since HttpProfiler was only written with dart:_http in mind.

[brianquinlan]

It seems like the classes in vm_service would be a good starting point e.g. HttpProfileRequest.

The classes in dart:developer would have to be mutable though. And have different names to avoid confusion - though these names are the obvious ones.

[mirabo-vuongnt1]

any update for this issue?

[brianquinlan]

There is a design discussion here - feedback welcome!