Open brianquinlan opened 1 year ago
@CoderDake @bkonyi could be similar to the issues with package:dio support
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.
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.
@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
?
@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.
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?
@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: https://github.com/flutter/devtools/issues/2860
If the issue you are seeing is that requests are not showing up in the inspector, it may be worth trying this workaround: https://github.com/flutter/devtools/issues/5194#issuecomment-1419408378
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)
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.
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
.
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.
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.
any update for this issue?
There is a design discussion here - feedback welcome!
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
.