“CAUTION: provisional headers are shown” in Chrome debugger

前端 未结 30 3017
滥情空心
滥情空心 2020-11-22 11:52

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

Caution provisional headers a

相关标签:
30条回答
  • 2020-11-22 12:05

    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    
    });
    
    0 讨论(0)
  • 2020-11-22 12:07

    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.

    0 讨论(0)
  • 2020-11-22 12:08

    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.

    0 讨论(0)
  • 2020-11-22 12:08

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

    0 讨论(0)
  • 2020-11-22 12:09

    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.
    0 讨论(0)
  • 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.

    0 讨论(0)
提交回复
热议问题