I am troubleshooting an issue where I believe an HTTP request is waiting an indefinite amount of time for a response. In Chromium's developer console, the Network tab does an excellent job at displaying completed traffic and events, but not current ones (that I can see).
How can I debug a lingering HTTP request using Chromium's developer console?
I have had the same issue for quite sometime. On the developer tools Network tab, I can see that all requests match the response on my server log and none is waiting. I even tried to shutdown the server while it is happening, and it still waits indefinitely.
This doesn't happen with Firefox and Opera so I'm inclined to say that it's a chrome bug.
Added: I have also noticed that when I close chrome then open it again, the issue disappears.
Related
Open Chrome and navigate to google.com
In Fiddler use the "Any Process" button to select that Chrome tab
In Fiddler the "Any Process" button changes to something like "chrome: 11788"
In the Chrome tab search for something
I expect traffic to be captured by Fiddler but no sessions are displayed. If I use "Any Process", traffic is captured from all applications.
The "Use Filters" checkbox is unchecked in the Filters tab.
I uninstalled and reinstalled Fiddler.
I have the latest version installed.
What else could I do?
Modern versions of Google Chrome use separate process for making requests; so the process of the main window, detected by the 'Any Process' tool, is different.
The team is considering a fix, but it is currently not implemented, see "Target Any Process" feature no longer working with Chrome.
Possible workarounds meanwhile are:
Use other filtering functionality - e.g. capture a request from Chrome, and from the Sessions view choose right click -> Filter now -> Show only process=<process number>.
Filter everything else. In Fiddler, uncheck Tools -> Options -> Connections -> Act as system proxy on startup. Then Start Chrome with manually specified proxy settings, pointing to the port on which Fiddler is listening:
chrome --proxy-server=http://localhost:8888
This way the only captured traffic will be from this instance of Chrome.
Detailed version: Why Fiddler's Process Picker tool doesn't work with Chrome anymore
Brief version: For security and performance reasons Chrome now handles network requests through a separate network service. So when you are pointing the 'Any Process' tool of Fiddler on any Chrome window/tab, you are actually pointing to the UI (browser process) of Chrome browser.
There is one quick workaround for this:
Navigate to chrome://flags/#network-service-in-process in your Chrome browser. You would see Runs network service in-process and its value would be set to Default.
Change the value from Default to Enabled. By doing this you are telling Chrome to handle network requests from the browser process which also handles the UI.
Restart Chrome. You should now be able to capture network requests by pointing the Any Process tool on any Chrome tab.
Once you are done with your development activities do not forget to set the flag back to Default. This would give better performance.
NOTE: At the point of writing this, I am using Chrome 84.
On Linux Debian 10 (Buster), I am using the http(s) client google-chrome-stable.
I was configuring (nginx) and testing (chrome) a reverse proxy and it got cached using a wrong domain.
I fixed the configuration but it still resolve to the wrong domain.
I have tried to go chrome://net-internals/#dns and click on Clear host cache but that didn't change anything.
I have tried to go chrome://net-internals/#sockets and click on Flush socket pools but that didn't change anything.
I am not working with FireFox, so FireFox can resolve correctly (so does curl).
After about 10 minutes, without restarting chrome. I did F5 (refresh) and it was loading the proper page. I haven't found a manual way to immediatly clear chrome cache.
I am doing devops and I haven't solved this issue for years.
Would love to know how to do one day :O
What happens if you open developer console F12 and then hold down on the refresh button and then select empty cache and hard reload?
Take a look at this gif for an example.
Normal js code (no service worker, but the app has a manifest with an empty service worker).
A simple timeout to an ajax call that's the code.
I close all chrome tabs, I close the process in task manager, no more chrome processes and yet I still get requests on my server. This happens locally and on the server, I know this because I can see the cookies sent and for which user id is needed.
Also I know that chrome is running the code because there is a date in the request and is updated as it go.
Triple checked that chrome is closed on all users and all processed in task manager.
Is not a coincidence because at this moment I have 2 different users (different chrome profiles) doing this. Also in my dev server there are a lot of users with the same behaviour.
I'm also not sure is chrome, but has to be, node.js alone can't change the time of the request.
Win 10 and Chrome Version 60.0.3112.90 (Official Build) (64-bit)
Terrible and I don't know what to do...
if I restart my node.js server all the requests stops.
Was my mistake! As I have server side rendering (with react) I forgot that the timeout was also run on the server side. The fix was to don't run any timeouts on the server side.
Thanks anyway for the answers. I was concerned how chrome was still running my js code even shut down, made no sense at all!
Fiddler had worked well on my laptop, but all of a sudden it cannot capture anything from my browsers. I have no ideas about what I have done may cause this problem.
The version of my fiddler is v4.6.0.5, it cannot capture http requests from all of my browsers, chrome, IE and Edge. My system is Windows 10.
I've carefully read the webpage Fiddler not capturing traffic from browsers
However, solutions works well for others do not work in my situations.
I've tried reinstalled fiddler and reset chrome hundreds of times
http://localhost.fiddler:8888/ cannot be found
http://127.0.0.1:8888 returns "This page returned a HTTP/200 response
Originating Process Information: chrome:79748"
I didn't use any filters
I have no extensions on chrome and close all kinds of VPN software.
I've checked 'Decrypt HTTPS traffic'
Anybody knows how can I solve the problem? Thank you!
I found that some of the software's http request is captured. It seems like that only the browsers' requests are not captured.
I temporarily use the developer tools in chrome for replacement(Ctrl+Shift+I, choose "NetWork"). It can capture the requests missed in Fiddler.
Your output indicates that:
Fiddler is running, and
It isn't blocked by a firewall or other software
Fiddler is not set as your system's proxy
On Fiddler's File menu, does the Capture traffic item have a checkmark next to it? While Fiddler is running, if you click Tools > WinINET Options > LAN Settings, what do you see?
Do you have any third-party antivirus software installed? Is this machine under the control of Group Policy (e.g. on a corporate network)?
If you start Chrome like so: chrome --proxy-server=http://127.0.0.1:8888, what happens?
I'm fighting against a strange behavior in our office network.
Every morning when we switch on our computers, our network was overload on outbound traffic.
After several test I found a possible cause.
I noticed that when we start Chrome (and gmail?) there is a high traffic generated from my computer to Google servers (e.g.: 74.125.133.132). Here a resource monitor screenshot:
The network traffic doesn't go down until I stop chrome and I start it again.
No extensions installed and every possible traffic generating feature is disabled.
Monitoring the network and restart Chrome every morning is quite annoying. Does someone have a similar behavior and a solution/workaround?
On start up chrome checks weather new update or fixes are available or not..
Or you might be having an chrome extension like _toolbar type, these type of extensions causes a lot of traffic..
Go to settings => extensions => and disable unnecessary and unrecognized extensions..
Hope it solve your problem..