I know their are answers about this subject (some are even fairly recent like this:
Chrome does not show request cookies when "Provisional Headers are shown"
Or this:
Chrome show Provisional headers are shown without cookies in request
unfortunately none of them worked for me since newer versions of chrome (in my case 76.0.3) don't have the Enable network service.
I did try to disable the site isolation AND Runs network service in-processand as I said, not with great results.
Image of possible network flags
Related
I have a website that supports HTTP2. If I use Firefox or Chrome in anonymous mode then all the calls are made with HTTP2 (shown as h2 in Chrome developer tools Network tab).
When I use ordinary Chrome though it does exactly the same call but uses HTTP1.1 for some reason. I have tried to turn of all extensions but it is still HTTP1.1.
Sometimes if I restart Chrome is starts using HTTP2 again but then falls back to HTTP 1.1 after a while or after one of the restarts. I cannot figure out what can be the problem and it looks very mysterious.
I did not change any settings explicitly in Chrome if they even exist. What can be the problem here?
P.S. I did "clear browser cache" and "clear browser cookies" and suddenly I got only http2, don't know how this ca affect protocol. This was a temporary improvement though and I got http1.1 after a while again
P.P.S. I have even got a case when loading a website that one request was http1.1 but the other one was http2 to exactly same server.
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,
Our website http://www.monfatec.com is using the navigator.geolocation.getCurrentPosition function to get the long and lat of the client.
But it always responds with a PERMISSION_DENIED status, this, whatever the browser and client, from both Firefox 58.0.1 and Chromium 64.0.32 on my Linux pc, as well as from Chrome 64.0.32 on my smartphone, and it is consistent and occurs on every request.
The website uses http and not https and that might be an explanation for the issue, but I'm not sure.
As of Chrome 50, the Geolocation API will only work on secure contexts such as HTTPS.
This will also be the case in update versions of most other browsers.
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.
I am having a small issue whereby Chrome (Version 60.0.3112.113, Mac OS) is returning a failed status response from a CORS preflight OPTIONS request.
The endpoint it is querying is a nodejs server which previously did not respond correctly to the preflight request. I have since fixed this.
The preflight request works in all other browsers, and works in Chrome on all other computers. I have tested using Browserling, and everything works as expected.
As such I am assuming (with 99% confidence) that this is some sort of caching issue with Chrome on my development computer. I have however been unable to resolve this, and have at this point tried deleting any/all cache options that I can find in the various Chrome options menus.
Can anyone share any insight?
I could not find a way of clearing whatever internal cache Chrome is using in this regard.
My resolution was simply to append a query string (based on the build time) to the request such that Chrome does not use this internal cache.
This is a good way of versioning resources (JS, CSS, API endpoints etc) anyway.