摘要：https是當下的網站的主流趨勢，然而對于以前http鏈接來說，我們往往就存在一個兼容性問題，應該在很長一段時間內，https與http將共存，就用到CSP設置upgrade-insecure-requests...

https是當下的網站的主流趨勢，然而對于以前http鏈接來說，我們往往就存在一個兼容性問題，因為你不可能一下就全部切換過去，應該在很長一段時間內，https與http將共存。

https與http共存的場景如：

1. app已經發布出去，其調用接口的地址為http的，那么這是必須兼容的。

2. app中嵌入了h5頁面，而這頁面在以前的設計中是使用http訪問的，如果換成https地址，極有可能將導致h5頁面無法打開。

3. 對于流量推廣一類的業務，可能原有的http推廣地址已經發送給第三方，而且即使你通知到第三方要求改為https，也不排除有http地址的訪問。

針對以上場景，我們肯定是要https與http共存的。

改https初看起來，其實就是一個域名指向的問題，也許我們只要將http的請求，直接跳轉到https地址去，那么也就完成了https的切換。實際并不是這么簡單的。

因為https地址中，如果加載了http資源，瀏覽器將認為這是不安全的資源，將會默認阻止，這就會給你帶來資源不全的問題了，比如：圖片顯示不了，樣式加載不了，JS加載不了。因為樣式類，基本上都是寫在本地的，所以一般還可以，但是一些公共的js文件，往往就是存在于cdn或者其他服務器上，這時候，如果訪問不了，可能就導致了業務就完全操作不了。比如：jquery效法加載失敗，可能所有的操作、請求都將無效了。

如項目中的js文件無法加載，直接導致JS報錯。如下圖所示：

CSP設置upgrade-insecure-requests

好在W3C工作組考慮到了我們升級 HTTPS 的艱難，在2015年4月份就出了一個 Upgrade Insecure Requests 的草案，他的作用就是讓瀏覽器自動升級不安全請求為https。

PHP響應代碼：

header("Content-Security-Policy: upgrade-insecure-requests");
header('Upgrade-Insecure-Requests: 1');

例如我們的網站是https的，而頁面中包含http資源，瀏覽器一旦發現存在上述響應頭，將會在加載http資源時自動替換成https請求。

當然，如果我們不方便在服務器上操作，也可以在頁面中加入 meta 頭：

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

加上以上響應頭后，瀏覽器將自動http升級為https請求，以上報錯信息將會消失，并且這個設置不會對外域的a鏈接做處理，所以可以放心使用。