今天在做頁面測試的時候，發現頁面無法刷出來，查看request報錯“CAUTION: Provisional headers are shown”.找到如下解決方案：
來源：http://segmentfault.com/q/1010000000364871
之所以會出現這個警告，是因為去獲取該資源的請求其實並（還）沒有真的發生，所以 Header 里顯示的是偽信息，直到服務器真的有響應返回，這里的 Header 信息才會被更新為真實的。不過這一切也可能不會發生，因為該請求可能會被屏蔽。比如說 AdBlock 什么的，當然了不全是瀏覽器擴展，具體情況具體分析了。
對了，別忘了用 chrome://net-internals 來幫助你查找被屏蔽的請求以及可能的原因。
Net Internals 是一套工具集合，用於幫助診斷網絡請求與訪問方面的問題，它通過監聽和搜集 DNS，Sockets，SPDY，Caches 等事件與數據來向開發者反饋各種網絡請求的過程、狀態以及可能產生影響的因素。
然而，原因千千萬，Net Internals 不可能那么聰明的就直接幫你分析出答案來，大多數情況下具體原因還是需要開發者通過抽絲剝繭自己來找原因的。
試舉例：我打開某 Web App，卻發現一直空白。打開 Developer Tools 的 Networking，發現如下圖所示
好吧，貌似是這個資源無法訪問了，但是具體原因能否知道呢？OK，打開 chrome://net-internals，重新刷一遍這個 Web App，然后你會看到 NI 的 events 蹭蹭蹭地變多了，進入 events 界面，試着搜索一下關鍵字（也就是在第一張圖里看到的請求地址中的關鍵字），看：
好吧……你要問我“IO Pending”代表出了什么問題？坦白地說在這個例子里我也不知道如何解釋，但是我知道它大概和 Amazon S3 有點關系，或許很多時候你還是得進一步借助 Google、StackOverflow、包括 SegmentFault
OK，實際上是因為被牆所以 Response 收不到，我翻了就好了……這個例子可能不具有代表性，再試舉一例：
還是一樣，先看到錯誤：
So why is that?
好的，這樣就清楚多了：連接超時。至於為什么連接超時，這就不是 NI 的職責范圍了，你需要進一步去探究造成連接超時的原因（好吧，其實還是因為 GFW）。
一時半會兒找不到更好的例子了，我知道還多人研究 NI 都是因為做 Chrome Extension 時產生的問題，無論如何試試用 NI 去過濾一遍你的應用所有的（出問題的）請求，那些反饋信息的確不是很好讀，你可能需要不斷借助 Google 大神，花費很多力氣。不過相信我，嘗試幾次就會慢慢抓住竅門，也會慢慢體會到 NI 各種功能的用處。