HTTPS的頁面發送不了HTTP請求？——關於混合內容

們都知道HTTPS的頁面是發送不了HTTP請求的，那麼是什麼緣由致使HTTPS頁面不能發送HTTP請求呢？若是有發送的需求，怎麼樣才能發送？最近恰好遇到了這個問題，並且搜了半天沒搜到靠譜的答案，因此有了本文。

1. 故事起源

我在《Jquery ajax, Axios, Fetch區別之我見》中提到過，Fetch做爲一種不一樣於XHR的請求方式，展現了它更多API，以及符合ES規範的良好前景；更不用說它能夠支持POST跨域。恰好工做上有用post方法上報效果數據的請求，我小手一揮，不用後臺兄弟們麻煩了，我能夠搞定，把效果上報換成了Fetch，美滋滋。

過了一段時間，後臺跑過來講，如今還有些其餘HTTP站點的數據上報。我試了一下，移動端根本就沒有發出這個請求，這……

2. 爲何HTTPS頁面發送不了HTTP請求

有些人說是跨域問題，真的是這樣嗎？

同源策略：1. 協議相同 2. 域名相同 3.端口相同

儘管HTTPS訪問HTTP確實不符合同源策略中的協議相同，可是在現代瀏覽器裏，即便是域名相同的請求，也是會出現如下報錯，而不是跨域報錯。

這也很好理解，畢竟混合內容的安全策略是在瀏覽器端斷定的，而是否能跨域要看服務器返回的Response頭，請求都被瀏覽器block掉了，也就不存在是否跨域的問題。

那什麼是混合內容？

混合內容：初始 HTML 內容經過安全的 HTTPS 鏈接加載，但其餘資源（例如，圖像、視頻、樣式表、腳本）則經過不安全的 HTTP 鏈接加載[1]。由於頁面經過 HTTPS 加載的初始請求是安全的，可是又加載了不安全的HTTP內容，所以稱之爲混合內容。

由於HTTPS的S自己就是Secure的意思，現代瀏覽器最初會針對此類型的內容顯示警告，以向用戶代表此頁面包含不安全的資源。可是即便顯示警告，頁面也已經加載，用戶的安全仍然受到了威脅。因此沒過多久，Chrome和Firefox就直接阻斷掉了這類的請求。

這就是HTTPS頁面爲何發送不了HTTP的緣由。

2. 突破方式

儘管如今主流瀏覽器都已經block掉了HTTPS頁面上的HTTP請求，可是咱們仍是能夠經過被動混合內容來發送get請求。

被動混合內容:指的是不與頁面其他部分進行交互的內容，包括圖像、視頻和音頻內容 ，以及沒法與頁面其他部分進行交互的其餘資源。

主動混合內容: 指的是能與頁面交互的內容，包括瀏覽器可下載和執行的腳本、樣式表、iframe、flash 資源及其餘代碼。[1]

由於攻擊者能夠經過不安全的HTTP內容來攻擊安全的HTTPS頁面，因此這類請求被嚴格阻斷掉了————這也是爲何咱們的Fetch請求被幹掉了。因此咱們能夠在無可奈何的狀況下，用img.src的方式來發送請求。固然，請求方法只能是get。

sendHttpRequest: () => { const img = new Image(); img.src = 'http://xxx.com//你的請求' } 

這時候，瀏覽器只會在控制檯報warning，而不會block咱們的請求。

總結

出於HTTPS的安全策略，瀏覽器會阻斷HTTPS上的非安全請求（HTTP）請求，可是咱們可使用被動混合內容的方式來跨越這個安全策略。