"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.

Skippet

This issue can also appear if the reuqest wasnt send due to domain switching e.g. sending data via ajax from www.domain.tld to domain.tld or vice versa. – Buenabuenaventura

@wvega There is a similar issue posted in this SO question but there doesn't seem to be any possible explanation for this Provisional Headers Sent issue. Any concrete solution for this? really annoying! I posted this question some time before. – Headsail

@Headsail There is a good explanation by wvega. And I actually was not looking for a solution. I was curious about a reason. – Skippet

It helped me when I turned it off: chrome://flags/#site-isolation-trial-opt-out – Chantay

Read my answer, it's not as complicated as it looks: #21177887 – Whit

Answer 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.

Bur

Shazz's answer is better. You see this message in the debugger whenever the resource was retrieved from the browser's cache without asking the server if the content has changed. – Arredondo

I think both answers are right, they tell two sides of the same story. The message is shown when a request is blocked or the resources are loaded from the cache, but also after every request is initiated and while the browser is waiting for a response from the server. As soon as the response arrives, the message goes away and the real headers are shown. – Bur

If a primarily analyzed page is redirected, e.g. example.com/a ->301->example.com/b, and the target page answers with 200, and then you click in an inspector the target page /b to see the header data, you will get them, labeled with "Provisional headers are shown". It is correct, because, you don't analyzed the target page directly. If you do it, you get the header data without the label. – Lickerish

I was able to determine that this was my problem because when I did the above. My https site was calling an https css file that was doing a 302 redirect to an http page. Security wouldn't allow the file to load and only showed the provisional headers. – Notional

There's a very good explanation of multiple reasons why this may happen: #12009923 – Alternation

chrome://net-internals was removed, any other way to view this? – Weinrich

Sometimes you can just check Disable cache checkbox in DevTools. It is located near Preserve log in Network section. – Librarianship

This answer wrong. You claim it's because the request was never made but I have the cache off and can clearly see the response taking 2-5 seconds (large requests). – Gwynethgwynne

For me, Video Downloader PLUS chrome plugin has blocked the request. – Cadent

Answer 2

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

Enshroud

No, 304 not modified comes from the server in response to a conditional request. If you are loading a cached resource and your browser does not have to contact the server, you won't get a 304 not modified or any HTTP status at all because a HTTP request won't be made. – Inunction

This works for me, when I saw "Provisional headers are shown" in the debugger panel, the status code of the request was "200 OK (from cache)" – Corr

I saw this with a service worker response, so I think at least in some cases, you're right about the cache response :) – Ethbinium

I switch cache off in the dev tools and still get this message. Status for all files is 200, no "(from cache)". So it might sometimes be due to cache, but certainly not always. – Gravitation

It's loading data from cache in my case. – Ocampo

Answer 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

Livy

I was able to get this to work with just "Enable network service" and "Runs network service in-process." – Sector

I just disabled site isolation and that worked for me. – Tunis

This worked in regular Chrome (v74), however the latest version of Chrome Canary (v76) is now missing the "#network-service" flag... Can't get this to work in Canary without it. – Speech

I saw this issue on both localhost:8080 and google.com(!?). Disabling site isolation fixed google.com, but not localhost. Disabling only the other two options fixed it for all cases. – Sangsanger

I only had to turn this off: chrome://flags/#site-isolation-trial-opt-out – Chantay

In Chrome (v77), only disable Runs network service in-process works well for me. – Slum

Answer 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.

Lucrece

That's the browser's same-origin policy - your webpage and the resources you are reading must be on the same port. developer.mozilla.org/en-US/docs/Web/Security/… – Beery

Awesome thanks for the help. I am using webpacks dev server and i was able to just add a rewrite rule. '/graphql': { target: 'http://10.10.1.38:4000', changeOrigin: true } – Clear

Similarly, I solved this problem by adding "proxy": "http://192.168.98.110:1234" to my package.json in a create-react-app project. Unlike the answer, I'm not using HTTPS anywhere in dev, but this was required because my app and api are on different IPs. – Usurious

Answer 5

My situation is cross-origin related.
Situation: Browser sends OPTIONS request before sending the real request like GET or POST. Backend developer forgets to deal with the OPTIONS request, letting it go through the service code, making the processing time too long. Longer than the timeout setting I wrote in the axios initialization, which is 5000 milliseconds. Therefore, the real request couldn't be sent, and then I encountered the provisional headers are shown problem.
Solution: When it comes to OPTIONS request, backend api just return result, it makes the request faster and the real request can be sent before timeout.

Frauenfeld

Answer 6

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.

Arcature

If your requests aren't blocked (200 OK), its only happen with CORS requests, and the missing header is Cookie, you want to check this answer. Thanks, @Arcature – Dinsdale

@semako, can you please explain this in a little more detail? i am encountering a similar problem, but i do not fully understand why. for more information, please see my most recent post. thank you. – Recrudescence

Answer 7

HTTP/2 Pushed resources will produce Provisional headers are shown in the inspector for the same theory as @wvega posted in his answer above.

e.g: Since the server pushed the resource(s) to the client (before the client requested them), the browser has the resources cached and therefore the client never makes/needs a requests; So because...

...the real headers are updated when the server responds, but there is no response if the request was blocked.

Lazuli

Answer 8

I doubt my answer is in time to help you but others might find it helpful. I experienced a similar issue with a jQuery Ajax Post script that i created.

It turned out that i had a typo in the href attribute of the A tag that i was using to fire the post. I had typed href="javacsript:;" (reversing the 's' and the 'c' ).. this caused the script to try to refresh the page while the post was attempting to fire. corrected the typo and it worked perfectly fine for me.

Hang

Ran into the same kind of issue, there was no typo but I had a script reloading the page before the POST was fired/complete. – Adali

Answer 9

This message can occur when the website is protected using HSTS. Then, when someone links to the HTTP version of the URL, the browser, as instructed by HSTS, does not issue an HTTP request, but internally redirects to the HTTPS resource securely. This is to avoid HTTPS downgrade attacks such as sslstrip.

Benito

I disabled HSTS and the original headers showed up again. Thank you! – Amblyoscope

I test my website using http:// , it works well. Now I test it using https:// , then it failed to load some resources. At last, I found that the url of the resources should changed to https. – Kastner

Answer 10

A common reason this happens is if you are tracking an event and you don't prevent the default action. For example, if you have a click event, then you will want to include:

e.preventDefault();

or

return false;

If you don't, you will see the provisional headers warning as well as a "canceled" status in the Network tab of your web console.

Yakutsk

Answer 11

This issue occurred to me when I was sending an invalid HTTP Authorization header. I forgot to base64 encode it.

Snood

My case was the Authorization header was too long – Predestinate

Answer 12

Use this code fist of your code:

header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

This works for me.

Borders

This one worked for me through all the answers. I'm having problems with THREE.js loading file from a remote source and chrome caching it automatically. – Mascia

@Mascia If your problem is with static file caching, that is of course another matter. You can solve it by putting a random value at the end of the address. Like: examples/THREE.js?12345 – Borders

Thank you this is actually an interesting workaround for me – Mascia

Answer 13

That might because you sent an Ajax request, at the same time you jump your page to another one using location.href or something like that. So the previous request failed.

Metaphysic

Answer 14

This caution message also occurs if the response is invalid and therefore dropped by the browser.

In my case the request was correctly sent to the server, the server-side code then produced an error and my custom error handling returned the error message in the HTTP status message field. But this error was not received on the client side, due to invalid characters in the error message (described here http://aspnetwebstack.codeplex.com/workitem/1386) which resulted in corrupt response headers.

Joh

Answer 15

I ran into this issue with an AJAX call that would never complete. I followed wvega's advice and tip about debugging with chrome://net-internals to eventually determine another click event handler in the page, listening on a parent node, was causing the browser to navigate to the same URL (so it wasn't easily noticeable).

The solution was to add event.stopPropagation() in a click handler on the form submit button to keep the click from bubbling up the DOM and canceling the AJAX request in progress (initiated via a submit handler on the form).

Avlona

Answer 16

I've had this come up very recently (today in fact) where I've had an AJAX call go out to the server and Chrome fires off the "Caution: Provisional headers are shown." In the server side PHP scripting, there are MySQL queries that can be pretty much instant or take a few seconds depending on the given scenario. My server response isn't sent back to the browser until the queries are completed. I've found I get this error only when time consuming queries (up to a few seconds total) are being done and prevent the response from being sent back.

My scenario involves the very rare possibility of having to alter a table by adding/removing hundreds of columns for weather model output...hence the response lag from iterating through a loop of ALTER TABLE queries.

Backgammon

PHP Workers would be maybe something for you – Savanna

Answer 17

In my case it was just a false set path in to a resource (svg / img)

Embattled

Yes - for me, missing permissions when using a file input for the request. – Unctuous

Answer 18

The reason why this header shows is that: your request don't send to remote.

It usually caused by

1. Extension has blocks your request
2. Chrome use own cache to fetch your resource

Chrome cannot get your request headers from a request that haven't made.

A recent version of chrome has indicate these:

Only Provisional headers are avaliable because this request was not sent over the network and instead was served from a local cache, which doesn't store the original request headers.

Disable cache to see full request headers

Foucquet

Answer 19

I came across this and it went away when I switched from https to http. The SSL certs we use in dev aren't verified by a 3rd party. They're just locally generated dev certs.

The same calls work just fine in Chrome Canary and Firefox. These browsers don't appear to be as strict about the SSL cert as Chrome is. The calls would fail in Chrome with the "CAUTION: Provisional headers..." message.

I think/hope that when we use a legit SSL cert in stage and prod, we won't see this behavior in Chrome anymore.

Help

i tried to curl, and receive 60. from this answer find out missing chain at SSL installation. add chain and problem gone. thanks dude! please use this to check: curl -s -D- https://<yourcomain.com> – Unsay

Answer 20

Just throwing in my two cents. I'm writing a Web Application using CORS requests and a full RESTful web service. I have found chrome will throw this error when I have an unhanded exception or a PHP Error thrown. Just incase anyone else runs into the problem. I found that when this happens I can fire up the Chrome App "Postman - Rest Client" and run the exact same request but in the Chrome App I'll actually get the PHP Error thats being thrown instead of this non descriptive error.

Hullo

Answer 21

I ran this issue when I tried to load main.js for require js for the second time after I made changes as a result from error . I just turned on in Developer Tools Settings "Disable Cache (When DevTools is Open)" . and that did the charm.

Willis

Just had a similar issue where a html5 video would not load when the Chrome dev tools were open as i keep 'Disable cache (while DevTools is open)' enabled. Disabling the setting solved the issue. – Philine

Answer 22

Another possible scenario I've seen - the exact same request is being sent again just after few milliseconds (most likely due to a bug in the client side).
In that case you'll also see that the status of the first request is "canceled" and that the latency is only several milliseconds.

Pardoes

Answer 23

This was happening for me, when I had a download link and after clicking on it I was trying also to catch the click with jquery and send an ajax request. The problem was because when you are clicking on the download link, you are leaving the page, even it does not look so. If there would no file transfer, you would see the requested page.. So I set a target="_blank" for preventing this issue.

Prud

Answer 24

I got this error when I tried to print a page in a popup. The print dialog was show and it still waiting my acceptance or cancellation of the printing in the popup while in the master page also was waiting in the background showing the message CAUTION provisional headers are shown when I tried to click another link.

In my case the solution was to remove the window.print (); script that it was executing on the <body> of the popup window to prevent the print dialog.

Rheinland

Answer 25

I saw this occur when the number of connections to my server exceeded Chrome's max-connections-per-server limit of 6.

Urba

Answer 26

In my case the cause was AdBlock extension.

The request to server went through and I got the response but I could not see the request cookies due to "Provisional headers.." being shown in Dev tools. After disabling AdBlock for the site, the warning went away and dev tools started to show the cookies again.

For the change to take effect, it was also necessary to close the Dev tools and refresh the page

Spadefish

Answer 27

Here is another solution.

If you encounter this issue with $ajax() call, add http:// before your serverhost will solve your problem.

var requestURL = "http://" + serverHost;
$.ajax({
    dataType: "json",
    url: requestURL,
    data: data,
    success: success    
});

Glycol

Answer 28

If you are developing an Asp.Net Mvc application and you are trying to return a JsonResult in your controller, make sure you add JsonRequestBehavior.AllowGet to the Json method. That fixed it for me.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

Lorenalorene

Answer 29

"Caution: provisional headers are shown" message can be shown when website hosted on HTTPS invokes a calls to WebApi hosted on HTTP. You can check all if all your Api's are HTTPS. Browser prevents to do a call to insecure resource. You can see similar message in your code when use FETCH API to domain with HTTP.

Mixed Content: The page at 'https://website.com' was loaded over HTTPS, but requested an insecure resource 'http://webapi.com'. This request has been blocked; the content must be served over HTTPS.

Carboniferous

Answer 30

I had a similar issue with my MEAN app. In my case, the issue was happening in only one get request. I tried with removing adblock, tried clearing cache and tried with different browsers. Nothing helped.

finally, I have figured out that the api was trying to return a huge JSON object. When I have tried to send a small object, it was working fine. Finally, I have changed my implementation to return a buffer instead of a JSON.

I wish expressJS to throw an error in this case.

Chiapas

Answer 31

This issue will also occur while using some packages like webpack-hot-middleware and open multiple pages at the same time. webpack-hot-middleware will create a connection for each page for listening to the changes of code then to refresh the page. Each browser has a max-connections-per-server limitation which is 6 for Chrome, so if you have already opened more than 6 pages in Chrome, the new request will be hung there until you close some pages.

Undenominational

Answer 32

I had this issue when sending parameters in the AJAX URL propertylike http://10.165.10.160:82/services?param1=xxxx&param2=xxxx

If you want to perform a get request (e.g. send parameterized url), do not add them in the url property, do it in data object instead:

        <script>
        $.ajax({
        url: "http://10.160.10.160:82/services/STD_ERROR.php",
        data: {
            StatusText: StatusText,
            Status: Status,
            UserCode: UserCode,
            FUNC_CODE: FuncCode,
            ErrorDescription: ErrorDescription
        },
        type: "GET",
        crossDomain: true,
        cache: false
    }).done(data => {
        console.log(data)
    }).fail(function(xhr, status, error) {
        console.log(xhr.ErrorDescription)
    });
</script>

Whit

Answer 33

This could be a CORS issue. try enabling CORS for you api.

For WebApi

  var cors = new EnableCorsAttribute("*", "*", "*");
            config.EnableCors(cors);

Japeth

Answer 34

Try reloading the page with ctrl + shift +F5 and then check the request headers again

Full headers are not shown because there can be a chance that request is not going to the servers and instead is served directly from Browser's cache for example using service workers

Harbard

Answer 35

I was using LiteSpeed Cache Plugin in WordPress. There, I enabled Browser Caching. Disable this feature worked for me. Then, later I enabled it for improving performance.

Nottage

Answer 36

My problem was related to the improper use of data in an HTTP URL.

More specifically, I had neglected to encode an email address in Base64, which is essential to ensure its correct integration into an HTTP URL.

In the case of the email address, by inserting it as is, I risked encountering errors due to the presence of special characters like "@" or ".", which have specific meanings in the context of URLs.

Base64 strings are URL-safe, and that's why they can be used to encode data in Data URLs.

exemple in js :

let safeDataURL = encodeToBase64(email)

Columbarium

Answer 37

In my case, the body parameters I was sending in the post request, and logic I have writting depending on the body parameters were wrong, so the response was not able to be sent. so I was getting this error.

 example: post request body (a: alsldfjfj) which I was sending

but I had written the code for validating "b" instead of "a"

Philbert