"CAUTION: provisional headers are shown" in Chrome debugger

Question

I noticed a strange caution message when looking at downloaded resources using Google chrome inspector (F12):

Caution provisional headers are shown

I found something possibly relevant, Network Panel: add caution about provisional request headers, but I could not fully understand it. Related questions can be found Chrome block requests as well as XMLHttpRequest cannot load. Unloaded resources show caution: Provisional headers are shown.

Similar to the first question, my resource was blocked, but later automatically loaded the same resource. Unlike the second question, I don't want to fix anything; I want to know what this message means and why I received it.

Solution 1

The resource could be being blocked by an extension (AdBlock in my case).

The message is there because the request to retrieve that resource was never made, so the headers being shown are not the real thing. As explained in the issue you referenced, the real headers are updated when the server responds, but there is no response if the request was blocked.

---

The way I found about the extension that was blocking my resource was through the net-internals tool in Chrome:

For Latest Versions of chrome

• Type chrome://net-export/ in the address bar and hit enter.
• Start Recording. And save Recording file to local.
• Open the page that is showing problems.
• Go back to net-internals
• You can view Recorded Log file Here https://netlog-viewer.appspot.com/#import
• click on events (###) and use the textfield to find the event related to your resource (use parts of the URL).
• Finally, click on the event and see if the info shown tells you something.

For Older Versions of chrome

• Type chrome://net-internals in the address bar and hit enter.
• Open the page that is showing problems.
• Go back to net-internals, click on events (###) and use the textfield to find the event related to your resource (use parts of the URL).
• Finally, click on the event and see if the info shown tells you something.

Solution 2

I believe it happens when the actual request is not sent. Usually happens when you are loading a cached resource.

Solution 3

For chrome v72+ what solved it for me was only this:

go to chrome://flags/ and disable this 3 flags

• Disable site isolation
• Enable network service
• Runs network service in-process

or you can do it from command line :

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

---

why this happen?

It seems that Google is refactoring their Chromium engine into modular structure, where different services will be separated into stand-alone modules and processes. They call this process servicification. Network service is the first step, Ui service, Identity service and Device service are coming up. Google provides the official information at the Chromium project site.

is it dangerous to change that?

An example is networking: once we have a network service we can choose to run it out of process for better stability/security, or in-process if we're resource constrained. source

Solution 4

I encountered this issue, and I managed to identify a specific cause, which isn't mentioned above either in answers or the question.

I am running a full js stack, angular front end and node back end on SSL, and the API is on a different domain running on port 8081, so I am doing CORS requests and withCredentials as I am dropping a session cookie from the API

So specifically my scenario was: POST request, withCredentials to port 8081 caused the "CAUTION: provisional headers are shown" message in the inspector and also of course blocked the request all together.

My solution was to set up apache to proxy pass the request from the usual SSL port of 443 to the node SSL port of 8081 (node has to be on a higher port as it cannot be ran as root in prod). So I guess Chrome doesn't like SSL requests to unconventional SSL ports, but perhaps their error message could be more specific.

Solution 5

This can also happen (for cross-origin requests only) because of a new feature called site isolation

This page details the issue and a work-around. Which is to go to chrome://flags/#site-isolation-trial-opt-out in chrome and change that setting to "Opt-out" and reload chrome.

It's a known issue. However that page says it's fixed in chrome 68, but I'm running chrome 68 and I still have the issue.

View more solutions