Provisional headers are shown ошибка

If you’re familiar with Chrome DevTools, you certainly have seen the “Provisional headers are shown” warning message popped up in certain network requests.

In this article, we will explain what exactly “Provisional headers” are, and what does “Provisional headers are shown” means in Google Chrome/Chromium-based browsers.

HTTP headers are the name or value pairs that are displayed in the request and response messages of message headers for Hypertext Transfer Protocol (HTTP). Request headers contain more information about the resource to be fetched, or about the client requesting the resource. Response headers hold additional information about the response, like its location or about the server providing it. These headers are usually invisible to the end-user and are only processed or logged by the server and client applications.

HTTP Headers displayed for pending requests are provisional. They represent what request was sent from Blink to Chromium/Chrome. To those of you who didn’t know, Blink is the open-source browser layout engine that powers Chromium (and therefore Chrome as well).

Chromium/Chrome do not update headers until server responds to avoid additional notification used only by DevTools. In short, provisional headers mean the requests they are not yet responded to. Please do note that this is just a notification, not an actual error message.

If the request is meant to be responded properly, but in reality, “Provisional headers are shown” are displayed, it’s usually because one of these reasons:

• An extension has blocked your request
• Chrome use its own cache to fetch your resource. The request was not sent over the network and instead was served from a local cache, which doesn’t store the original request headers.
• Internal error which made Chrome cannot get your request headers from a request that haven’t made.

Check your adblockers

One of the most common reasons that causes “Provisional headers are shown” are Chrome extensions. The resource you’re trying to load could be being blocked by an extension, usually ad-blockers such as AdBlock, uBlock Origin or Adguard.

Most adblockers work the same way, which is blocking the requests based on pattern matching. If an URL contains the word “advert”, “ads” or something similar, it would be blocked from loading.

In order to make “Provisional headers are shown” disappear, you’ll have to whitelist the URL out of adblockers block list. Below are instructions on how to do that with popular extensions like Adblock Plus and uBlock Origin.

Whitelist your site from Adblock Plus

1. Navigate to the URL which have been blocked and shown “Provisional headers are shown”.
2. Click on the AdBlock Plus icon in the Chrome toolbar. If you don’t see the icon, it may be hidden by Chrome/Chromium itself. Clicking the “jigsaw” icon will bring you the full list of all installed extensions.
3. Click the toggle in Block ads on this website section to whitelist the whole domain out of Adblock Plus blocklist. Alternatively, you can whitelist only the URL you’re visiting by clicking the smaller toggle on This page section.

Whitelist your site from uBlock Origin

1. Navigate to the URL which have been blocked and shown “Provisional headers are shown”.
2. uBlock circumvents immediately and show you a message which notify you that the URL has been blocked. You can either click Temporarily to unblock the URL until you close the browser, or click Permanently to unblock the URL forever.

Find the troublesome extension (Advanced)

In case your adblocker isn’t the cause of the error, there might be another extension interfering with the request-response cycle.

In order to pinpoint the exact troublesome extension, you have to use Chrome net-internals tools. How to access the tool depends on which version of Chromium/Chrome you’re using.

Latest Versions of Chrome

• Navigate to chrome://net-export/.
• Click Start Logging to Disk to save the logs to the hard drive. The button should change to Stop Logging
• Open the page that is was thrown “Provisional Headers are shown”.
• Go back to net-export page and click Stop Logging.
• Go to https://netlog-viewer.appspot.com/#import and drag-drop the log file you’ve just saved into the webpage.
• Click on Events (###) section in the sidebar and use the input box to find the event related to your resource (tips: use parts of the URL as search query).
• Finally, click on the event and see if the info shown tells you something interesting.

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 search using input box to find the event related to your resource.
• Finally, click on the event and see if the info shown tells you something. From these information, you can pinpoint exactly what happened and if there’s any extension breaks the request-response cycle.

Disable site isolation/network service

“Provisional Headers are shown” can also happen (for cross-origin requests only) because of a Chrome feature called site isolation. If none of the above methods work for you, you may have to try messing with site isolation/network service.

First, open up the Disable site isolation setting by navigating to chrome://flags/#chrome://flags#Disable%20site%20isolation and disable it.

Then, open up Enable Network Service setting by navigating to chrome://flags/#chrome://flags#Enable%20network%20service, and disable that:

Once you’re done, relaunch the browser and check if the issue still persists. In a few cases, users have reported that disabling cache in Chrome DevTools also help.

Alternatively, you can start Chrome with the aforementioned settings disabled by running the following command (either in Command Prompt or Linux terminal):

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

We hope that the article offer useful information about “Provisional headers are shown” notification in Chromium/Chrome.

We’ve also written a few other guides for fixing common Chrome errors, such as Fix ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION error in Google Chrome/Microsoft Edge, Fix “Requests to the server have been blocked by an extension” in Chrome/Microsoft Edge or Fix “Access to XMLHttpRequest has been blocked by CORS policy” in Chrome . If you have any suggestion, please feel free to leave a comment below.

Recently I worked on a PHP webservice project and I saw this

in Google chrome browser and Opera browser.
I digged some research on Google and find out mixed responses and at last I got it fixed by removing window.print() in script.
Check out all the fixed Provisional headers are shown answers from stackoverflow.

Few developers say that it is because of Chrome plugins like Adblock and VPN. Anyways check out all the responses.

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.

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

I had similar problem. I changed my button type=”submit” to type=”button”. It worked for me.

I’ve faced with the same issue while working through VPN. To solve the problem had to change the MTU value.

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.

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.

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.

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.

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.

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 });

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

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.

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.

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.

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.

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 tag of the popup window to prevent the print dialog.

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.

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 } When chrome redirect to a new url, some http requests will be canceled immediatly, you will find ‘provisional headers are shown’ in debug console.

Above anwers are took from stackoverflow and other sites for only informational purpose.

Based on your response, I have modified the test case. The request from TestWorker.js is now to a different endpoint that
has NEVER been hit before:

starter.js

// open background page devTools
chrome.developerPrivate.openDevTools({
    renderViewId    : -1,
    renderProcessId : -1,
    extensionId     : chrome.runtime.id
});

// timeout just to let devTools open before making requests
setTimeout(() => {
    fetch('https://reqbin.com/echo/get/json')
        .then(response => response.json())
        .then(response => {
            console.log('background page response', response);
        });

    new Worker('TestWorker.js');
}, 6000)

TestWorker.js

fetch('https://jsonplaceholder.typicode.com/posts/3')
    .then(response => response.json())
    .then(response => {
        console.log('worker response', response);
    });

The problem persists, as the worker request still shows the provisional headers message.

You can see in this screenshot of devTools that the first request is now cached (size column shows «(disk cache)»), as we have made it before. The second request from the worker indicates that it is NOT from cache, as it has the size.

Looking at the details for the first request, you will see «Provisional headers are show. Disable cache to see full headers»:

Now looking at the details for the second request, we see a slightly different message, «Provisional headers are shown», but nothing about caching:

We have also run a proxy to confirm that the worker request is actually going out.

Here is another test case, in which I have turned on the «Disable cache (while DevTools is open)» option in settings. I make the same request twice from the background page, and a third time from the worker:

starter.js

setTimeout(() => {
    fetch('https://reqbin.com/echo/get/json')
        .then(response => response.json())
        .then(response => {
            console.log('background page response 1', response);

            fetch('https://reqbin.com/echo/get/json')
                .then(response => response.json())
                .then(response => {
                    console.log('background page response 2', response);

                    new Worker('TestWorker.js');
                });
        });

}, 3000)

TestWorker.js

fetch('https://reqbin.com/echo/get/json')
    .then(response => response.json())
    .then(response => {
        console.log('worker response', response);
    });

Now, none of the requests show «(disk cache)» in the size column:

Details on the background page requests DO NOT show provisional headers warning, as expected:

BUT, looking at the details for the request made from the worker, it still shows «Provisional headers are shown»:

In conclusion, we are confident the worker request is not cached, yet the provisional headers message is still shown. We are unable to get accurate details on the headers when this message is present.