provisional headers are shown 知多少

時間 2019-11-20

標籤 provisional headers shown 多少简体版

原文原文鏈接

前言

請求裏面provisional headers are shown(顯示臨時報頭) 出現的狀況不少，但緣由是多樣的。
若是你去直接匹配關鍵字搜索，獲得的結果可能與你本身的狀況截然不同。
網上大部分都是在跨域時出現，或者是請求被插件攔截，但關於緩存時的請求不多。
我在上文查看緩存的時候發現了這個問題,當時查找資料都是聚焦於請求被攔截，
因此本文就簡單整理一下相關狀況。css

問題描述

當刷新頁面時，想要查看http請求header中相關信息時，
發現使用緩存的請求（from disk cache或者from memory cache）header相關信息不能查看html

第一次看到確實有點疑惑，那麼就去搜索了下。
碰到這個提示的狀況挺多，但細看下與咱們的場景不太符合。

基本上遇到的都是provisional headers are shown，阻止了請求的正常加載。
而咱們只是在使用緩存的時候遇到，而看起來請求沒有被block掉。好像不太符合。chrome

問題定位

雖然沒有看到匹配度十分相關的信息，但看到了有啓發的一篇文章(詳情點擊)。跨域

摘抄部分以下：瀏覽器

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.緩存

資源可能被一些擴展程序攔截。服務器

另外還有一句：app

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

真正請求並未被髮送，當使用緩存時常常發生。post

之因此會出現這個信息是由於獲取相關資源的請求並無發出，
因此headers被展現並非真正的信息。
就像提到的那樣，真正的header只有在服務端返回的時候會更新。
當請求被攔截後，並無返回。
基於這個狀況開始猜想緣由所在：

猜想1、請求跨域被攔截

雖然如今網站的靜態資源都會存在專門的靜態域名下面，和html域名可能不一致。
可是基本都是基於CORS來解決這個問題，因此不存在這個問題。
再有就是，咱們這種狀況首次請求的時候不會發生，若是有跨域，應該都被block。
另外若是是被攔截，那麼請求應該不會被響應的，咱們這裏顯然獲得了正確的響應。
這種被排除。

猜想2、服務器未及時響應

這種猜想和一差很少，特定狀況下才會出現，跟服務器關聯不大。

猜想3、被擴展程序攔截

做爲一個開發人員，你們的chrome上確定裝了很多的插件。這種緣由仍是有可能的。
咱們能夠經過 chrome://net-internals 來根據關鍵字查找相關請求，
而後具體去看相關狀態。
例如咱們http://xxdy.tech/css/main.css?v=5.1.4請求

能夠看到並無出現block，timeout等字段，只能看到比較明顯的DISK_CACHE。
所以這種狀況也不知足，咱們應該是和本地緩存強烈相關的。