From the dev tools, is it possible to tell Chrome to return, for example, a 404 when a specific url is requested (leaving other requests to process normally)?
You can block specific request URLs or patterns of URLs from the Network panel.
Manage your blocked URLs from the Request Blocking tab.
Official feature announcement: https://developers.google.com/web/updates/2017/04/devtools-release-notes#block-requests
Blocking the request with chrome devtools is the easiest solution. But if you want to mock a specific error code, let say 401 or 404 you can use a chrome extension to do it.
There are plenty of them in the store, I just tried one randomly and it allowed me to mock a specific error code https://chrome.google.com/webstore/detail/mokku-mock-api-calls-seam/llflfcikklhgamfmnjkgpdadpmdplmji?hl=en
Related
My web client application is setting HTTP POST requests via fetch API.
I see that OPTIONS preflight requests are sent via debugging proxy (Charles Proxy), but they are not displayed in Google Chrome Developer Tools\Network tab.
I don't have any filters setup on the network tab. I remember OPTIONS requests being visible there, but not anymore. How do I bring them back?
You'll need to go to: chrome://flags/#out-of-blink-cors, disable the flag, and restart Chrome.
This is an expected behavior change according to:
https://bugs.chromium.org/p/chromium/issues/detail?id=995740#c1
I originally came across this via:
https://support.google.com/chrome/thread/11089651?hl=en
As of 2021 in CHROME the OPTIONS request is visible in the NETWORK tab filter OTHER requests
To see it together with XHR just CTRL+click and pick the request filters you want to see.
UPDATE (April 17) Chrome Version 90.0.4430.72 has made the options requests hidden again :(
Chrome 81 does not seem to display anything even after changing the option and restarting on my computer.
As an alternative solution, I started to use Firefox and its Network tab for development.
https://getfirefox.com
I'm Takashi from Chromium Project, and drove the Out-Of-Blink/Render CORS project.
The project intended to introduce a process isolated CORS implementation for better security and privacy, and many of new network related features rely on this new implementation. Unfortunately we temporarily disabled preflight support in DevTools as it turned out continuing to support it weakens security and privacy. Sorry for inconvenience during this period.
Good news is now Chrome 83 implements the CORS preflight DevTools support again in a security preserved way. So you can monitor the CORS preflight requests as you could do before the Out-Of-Blink/Renderer CORS.
Best,
If you are building a website and put a breakpoint in your server code so that a page cannot be returned until you move past the breakpoint and you (for instance) reload the page in Chrome or Firefox (haven't tested others), you can't see any information about the request.
While debugging, sometimes it's easier to view information about the HTTP request in the browser's dev tools than it is to find that information in the server code. Why am I not able to see HTTP request information until a response is returned by the server?
From: https://bugs.chromium.org/p/chromium/issues/detail?id=294891:
Headers displayed for pending requests are provisional. They represent
what request was sent from Blink to Chromium.
We do not update headers until server responds to avoid additional
notification used only by DevTools.
To watch real network activity you can use chrome://net-internals
It's not clear what that means, but that's the cited reason.
UPDATE: If I go back to 'All' tab and then back to 'XHR' I see both requests, so I guess it's some kind of chrome bug?
The GET request completes successfully but I cannot inspect the response. This occurs randomly in some of the endpoints of my api.
Firefox always logs the response.
You can always have a better view of the network communication via
chrome://net-internals/#events
Maybe you'll find something blocking it before reaching the dev tools..
On the network tab, you can remove the tick infront of this menu 3rd-party-request
I developed a chrome extension which communicates with IP phones.
The communication is done in a event page which is sending POST requests via the XMLHttpRequest object.
Because the hostname or IP address of the phone is configured in the options page I added optional_permissions to the manifest file and request them from the user after saving the options with chrome.permissions.request.
Cross-Origin XHR works now without any problems until I restart chrome...
After restarting chrome it seems like the requested permission is lost and I get the typical
is not allowed by Access-Control-Allow-Origin error.
When I click on the extensions permissions I can also see that my requested permission is no longer listed.
Because the chrome.permissions.request is only working for a user gesture I can't request it during the load of my extension or on the fly. If I request the permission again in my options page I don't get asked again whether I want to allow it or not put the permission is granted and everything works again as usual.
Is there a way to get this permission granted persistent after requesting it? I only want the extension to have access to the endpoints it needs.
Thank you very much.
For me the following reported issue answered my question:
Issue 158004: chrome.permissions.request support for user-supplied URL.
To make it clear: It is not possible to request a subset of the permissions defined in optional_permissions. If you define http://*/* then you need to request exactly this string! A subset like http://example.org/* wont work!
Here is a quote from a comment in the issue description which makes that clear:
"There's no wildcard handling, just plain string comparison between the URLPatterns"
The Issue has been fixed in Revision 182287
The only thing left is to cross your fingers that this fix gets included in a upcomming chrome release soon. We'll have to use the bloody Access your data on all websites permission in the meanwhile.
I would like to view HTTP POST data that was sent in Chrome.
The data is in memory now, and I have the ability to resubmit the form.
I know that if I resubmit the server will throw an error. Is there anyway I can view the data that is in Chrome's memory?
Go to Chrome Developer Tools (Chrome Menu -> More Tools -> Developer Tools)
Choose "Network" tab
Refresh the page you're on
You'll get list of http queries that happened, while the network console was on. Select one of them in the left
Choose "Headers" tab
Voila!
You can filter for HTTP POST requests with the Chrome DevTools. Just do the following:
Open Chrome DevTools (Cmd+Opt+I on Mac, Ctrl+Shift+I or F12 on
Windows) and click on the "Network" tab
Click on the "Filter" icon
Enter your filter method: method:POST
Select the request you want to debug
View the details of the request you want to debug
Screenshot
Tested with Chrome Version 53.
You can use Canary version of Chrome to see request payload of POST requests.
Another option that may be useful is a dedicated HTTP debugging tool. There's a few available, I'd suggest HTTP Toolkit: an open-source project I've been working on (yeah, I might be biased) to solve this same problem for myself.
The main difference is usability & power. The Chrome dev tools are good for simple things, and I'd recommend starting there, but if you're struggling to understand the information there, and you need either more explanation or more power then proper focused tools can be useful!
For this case, it'll show you the full POST body you're looking for, with a friendly editor and highlighting (all powered by VS Code) so you can dig around. It'll give you the request & response headers of course, but with extra info like docs from MDN (the Mozilla Developer Network) for every standard header and status code you can see.
A picture is worth a thousand StackOverflow answers:
On Chrome 96 DevTools Network Tab;
After clicking the request, there is a "Payload" tab that shows the Form Data:
You can view the data as url encoded / decoded:
You can view the data as source / parsed:
Even if the method is GET you can see the Payload as Query String Parameters:
It has a tricky situation: If you submit a post form, then Chrome will open a new tab to send the request. It's right until now, but if it triggers an event to download file(s), this tab will close immediately so that you cannot capture this request in the Dev Tool.
Solution:
Before submitting the post form, you need to cut off your network, which makes the request cannot send successfully so that the tab will not be closed. And then you can capture the request message in the Chrome Devtool(Refreshing the new tab if necessary)
The Network tab is all you need...
The other people made very nice answers, but I would like to complete their work with an extra development tool. It is called Live HTTP Headers and you can install it into your Firefox, and in Chrome we have the same plug in like this.
Working with it is queit easy.
Using your Firefox, navigate to the website which you want to get your post request to it.
In your Firefox menu Tools->Live Http Headers
A new window pop ups for you, and all the http method details would be saved in this window for you. You don't need to do anything in this step.
In the website, do an activity(log in, submit a form, etc.)
Look at your plug in window. It is all recorded.
Just remember you need to check the Capture.