Provisional headers are shown что это
Provisional headers are shown and pending requests
i have a problem with vue-resource causing a Provisional headers are shown on chrome, using Jquery on the other hand work without any problem
the problem only happens with chrome + vue-resource
Reproduction Link
Chrome 57.0.2987 Windows 7
i dont have adblock or origin installed, and it happen even on guest mode on chrome
a simple call set with setInterval
Steps to reproduce
usually it happens when i leave the page open for a few hours
What is Expected?
a 200 code response with content served
What is actually happening?
i get a request with these headers
Provisional headers are shown Accept:application/json, text/plain, / Content-Type:application/json;charset=utf-8 Origin:http://127.0.0.1:8080 Referer:http://127.0.0.1:8080/monitor/ User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 X-Requested-With:XMLHttpRequest
and looking at chrome://net-internals/#events the cause of failure is
1 Answer 1
I believe this happens when the actual request is not sent, usually when you are loading a cached resource.
Basically you sent a POST request to port 8080 which caused the «CAUTION: provisional headers are shown» message as seen in the inspector and then it seems the request was blocked all together.
Based on that, one possible solution is to setup nginx to proxy pass the request from the usual SSL port of 443 to the node SSL port of 8080 (node has to be on a higher port as it cannot be ran as root in prod). I guess Chrome doesn’t like SSL requests to unconventional SSL ports, though I definitely agree their error message could be more specific.
Provisional headers are shown in Google Chrome Browser Debugger
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.
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).
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:
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.
Related Articles
HTTP Codes Web Page Errors While Browsing
5 Websites to Check Keywords For Free Online
If you have a website then struggling to get good traffic or earning less from the sites it is due to the Traffic to get good traffic the quality of an article is very important, so if you are writing an article for your website it is always good to research the keyword for the […]
10 Mistakes Which PHP MySQL Developers Make
1. Using MyISAM rather than InnoDB MySQL has a number of database engines, but you’re most likely to encounter MyISAM and InnoDB. MyISAM is used by default. However, unless you’re creating a very simple or experimental database, it’s almost certainly the wrong choice! MyISAM doesn’t support foreign key constraints or transactions, which are essential for […]
Network features reference
Published on Monday, April 13, 2015 • Updated on Thursday, August 12, 2021
Technically, I’m a writer
Discover new ways to analyze how your page loads in this comprehensive reference of Chrome DevTools network analysis features.
Note: This reference is based on Chrome 58. If you use another version of Chrome, the UI and features of DevTools may be different. Check chrome://help to see what version of Chrome you’re running.
# Record network requests
By default, DevTools records all network requests in the Network panel, so long as DevTools is open.
Figure 1. The Network panel
# Stop recording network requests
To stop recording requests:
# Clear requests
Click Clear 
on the Network panel to clear all requests from the Requests table.
Figure 2. Clear, outlined in blue
# Save requests across page loads
To save requests across page loads, check the Preserve log checkbox on the Network panel. DevTools saves all requests until you disable Preserve log.
Figure 3. The Preserve Log checkbox, outlined in blue
# Capture screenshots during page load
Capture screenshots to analyze what users see as they wait for your page to load.
To enable screenshots, open Settings inside the Network panel and check Capture screenshots.
Reload the page while the Network panel is in focus to capture screenshots.
Once captured, you can interact with screenshots in the following ways:
Figure 4. Capture screenshots enabled, showing loading screenshots over time.
# Replay XHR request
To replay an XHR request, right-click the request in the Requests table and select Replay XHR.
Figure 5. Selecting Replay XHR
# Change loading behavior
# Emulate a first-time visitor by disabling the browser cache
To emulate how a first-time user experiences your site, check the Disable cache checkbox. DevTools disables the browser cache. This more accurately emulates a first-time user’s experience, because requests are served from the browser cache on repeat visits.
Figure 6. The Disable Cache checkbox, outlined in blue
# Disable the browser cache from the Network Conditions drawer
If you want to disable the cache while working in other DevTools panels, use the Network Conditions drawer.
# Manually clear the browser cache
To manually clear the browser cache at any time, right-click anywhere in the Requests table and select Clear Browser Cache.
Figure 7. Selecting Clear Browser Cache
# Emulate offline
There’s a new class of web apps, called Progressive Web Apps, which can function offline with the help of service workers. When you’re building this type of app, it’s useful to be able to quickly simulate a device that has no data connection.
Check the Offline checkbox to simulate a completely offline network experience.
Figure 8. The Offline checkbox, outlined in blue
# Emulate slow network connections
Emulate 2G, 3G, and other connection speeds from the Network Throttling menu.
Figure 9. The Network Throttling menu, outlined in blue
You can select from a variety of presets, such as Regular or Good 2G. You can also add your own custom presets by opening the Network Throttling menu and selecting Custom > Add.
DevTools displays a warning icon next to the Network tab to remind you that throttling is enabled.
# Emulate slow network connections from the Network Conditions drawer
If you want to throttle the network connection while working in other DevTools panels, use the Network Conditions drawer.
# Manually clear browser cookies
To manually clear browser cookies at any time, right-click anywhere in the Requests table and select Clear Browser Cookies.
Figure 10. Selecting Clear Browser Cookies
# Override the user agent
To manually override the user agent:
# Filter requests
# Filter requests by properties
Use the Filter text box to filter requests by properties, such as the domain or size of the request.
If you can’t see the text box, the Filters pane is probably hidden. See Hide the Filters pane.
Figure 11. The Filters text box, outlined in blue
You can use multiple properties simultaneously by separating each property with a space. For example, mime-type:image/gif larger-than:1K displays all GIFs that are larger than one kilobyte. These multi-property filters are equivalent to AND operations. OR operations are currently not supported.
Below is a complete list of supported properties.
# Filter requests by type
To filter requests by request type, click the XHR, JS, CSS, Img, Media, Font, Doc, WS (WebSocket), Manifest, or Other (any other type not listed here) buttons on the Network panel.
If you can’t see these buttons, the Filters pane is probably hidden. See Hide the Filters pane.
To enable multiple type filters simultaneously, hold Command (Mac) or Control (Windows, Linux) and then click.
Figure 12. Using the Type filters to display JS, CSS, and Doc[ument] resources.
# Filter requests by time
Click and drag left or right on the Overview pane to only display requests that were active during that time frame. The filter is inclusive. Any request that was active during the highlighted time is shown.
Figure 13. Filtering out any requests that weren’t active around 2500ms
# Hide data URLs
Data URLs are small files embedded into other documents. Any request that you see in the Requests table that starts with data: is a data URL.
Check the Hide data URLs checkbox to hide these requests.
Figure 14. The Hide Data URLs checkbox
# Sort requests
By default, the requests in the Requests table are sorted by initiation time, but you can sort the table using other criteria.
# Sort by column
Click the header of any column in the Requests to sort requests by that column.
# Sort by activity phase
To change how the Waterfall sorts requests, right-click the header of the Requests table, hover over Waterfall, and select one of the following options:
These descriptions assume that each respective option is ranked from shortest to longest. Clicking on the Waterfall column’s header reverses the order.
Figure 15. Sorting the Waterfall by total duration. The lighter portion of each bar is time spent waiting. The darker portion is time spent downloading bytes.
# Analyze requests
So long as DevTools is open, it logs all requests in the Network panel. Use the Network panel to analyze requests.
# View a log of requests
Use the Requests table to view a log of all requests made while DevTools has been open. Clicking or hovering over requests reveals more information about them.
Figure 16. The Requests table, outlined in blue
The Requests table displays the following columns by default:
# Add or remove columns
Right-click the header of the Requests table and select an option to hide or show it. Currently displayed options have checkmarks next to them.
Figure 17. Adding a column to the Requests table.
# Add custom columns
To add a custom column to the Requests table, right-click the header of the Requests table and select Response Headers > Manage Header Columns.
Figure 18. Adding a custom column to the Requests table.
# View the timing of requests in relation to one another
Use the Waterfall to view the timing of requests in relation to one another. By default, the Waterfall is organized by the start time of the requests. So, requests that are farther to the left started earlier than those that are farther to the right.
See Sort by activity phase to see the different ways that you can sort the Waterfall.
Figure 19. The Waterfall column of the Requests pane.
# Analyze the frames of a WebSocket Connection
To view the frames of a WebSocket connection:
To refresh the table, re-click the name of the WebSocket connection under the Name column of the Requests table.
Figure 20. The Frames tab, outlined in blue
The table contains three columns:
Messages are color-coded according to their type:
# View a preview of a response body
To view a preview of a response body:
This tab is mostly useful for viewing images.
Figure 21. The Preview tab, outlined in blue
# View a response body
To view the response body to a request:
Figure 22. The Response tab, outlined in blue
# View HTTP headers
To view HTTP header data about a request:
Figure 23. The Headers tab, outlined in blue
# View HTTP header source
By default, the Headers tab shows header names alphabetically. To view the HTTP header names in the order they were received:
# Provisional headers are shown
There are times where the headers will show a warning message «Provisional headers are shown. «.
It could be due to the request not sent over the network (served from a local cache), which doesn’t store the original request headers. In this case, you can disable caching to see the full request headers. 
It could also be due to the network resource not valid (e.g. Try fetch(«https://jec.fyi.com/unknown-url/») in the Console). DevTools could also display only provisional header due to security reasons. 
# View query string parameters
To view the query string parameters of a URL in a human-readable format:
Figure 24. The Query String Parameters section, outlined in blue
# View query string parameters source
To view the query string parameter source of a request:
# View URL-encoded query string parameters
To view query string parameters in a human-readable format, but with encodings preserved:
# View cookies
To view the cookies sent in a request’s HTTP header:
See Fields for a description of each of the columns.
Figure 25. The Cookies tab, outlined in blue
# View the timing breakdown of a request
To view the timing breakdown of a request:
See Preview a timing breakdown for a faster way to access this data.
See Timing breakdown phases explained for more information about each of the phases that you may see in the Timing tab.
Figure 26. The Timing tab, outlined in blue
Here’s more information about each of the phases.
See View timing breakdown for another way to access this view.
# Preview a timing breakdown
To view a preview of the timing breakdown of a request, hover over the request’s entry in the Waterfall column of the Requests table.
See View the timing breakdown of a request for a way to access this data that does not require hovering.
Figure 27. Previewing the timing breakdown of a request
# Timing breakdown phases explained
Here’s more information about each of the phases you may see in the Timing tab:
# View initiators and dependencies
To view the initiators and dependencies of a request, hold Shift and hover over the request in the Requests table. DevTools colors initiators green, and dependencies red.
Figure 28. Viewing the initiators and dependencies of a request
When the Requests table is ordered chronologically, the first green request above the request that you’re hovering over is the initiator of the dependency. If there’s another green request above that, that higher request is the initiator of the initiator. And so on.
# View load events
DevTools displays the timing of the DOMContentLoaded and load events in multiple places on the Network panel. The DOMContentLoaded event is colored blue, and the load event is red.
Figure 29. The locations of the DOMContentLoaded and load events in the Network panel
# View the total number of requests
The total number of requests is listed in the Summary pane, at the bottom of the Network panel.
Caution: This number only tracks requests that have been logged since DevTools was opened. If other requests occurred before DevTools was opened, those requests aren’t counted.
Figure 30. The total number of requests since DevTools was opened
# View the total download size
The total download size of requests is listed in the Summary pane, at the bottom of the Network panel.
Caution: This number only tracks requests that have been logged since DevTools was opened. If other requests occurred before DevTools was opened, those requests aren’t counted.
Figure 31. The total download size of requests
See View the uncompressed size of a resource to see how large resources are after the browser uncompresses them.
# View the stack trace that caused a request
When a JavaScript statement causes a resource to be requested, hover over the Initiator column to view the stack trace leading up to the request.
Figure 32. The stack trace leading up to a resource request
# View the uncompressed size of a resource
Click Use Large Request Rows 
and then look at the bottom value of the Size column.
# Export requests data
# Save all network requests to a HAR file
To save all network requests to a HAR file:
Once you’ve got a HAR file, you can import it back into DevTools for analysis. Just drag-and-drop the HAR file into the Requests table. See also HAR Analyzer.
Figure 34. Selecting Save as HAR with Content
# Copy one or more requests to the clipboard
Under the Name column of the Requests table, right-click a request, hover over Copy, and select one of the following options:
Figure 35. Selecting Copy Response
# Change the layout of the Network panel
Expand or collapse sections of the Network panel UI to focus on what’s important to you.
# Hide the Filters pane
By default, DevTools shows the Filters pane. Click Filter 
to hide it.
Figure 36. Hide Filters, outlined in blue
# Use large request rows
Use large rows when you want more whitespace in your network requests table. Some columns also provide a little more information when using large rows. For example, the bottom value of the Size column is the uncompressed size of a request.
Open Settings and click Use large request rows to enable large rows.
Figure 37. Large Request Rows, outlined in blue
# Hide the Overview pane
By default, DevTools shows the Overview pane. Open Settings and uncheck the Show overview checkbox to hide it.
Figure 38. Hide Overview, outlined in blue
Last updated: Thursday, August 12, 2021 Improve article