在https中引入http資源所致使的問題

前言

最近在週報系統和格子機項目中都出現了在測試服可以正常運行，部署到正式服以後就出現問題，這些問題的緣由就是：通常測試服都沒有安全性的需求，因此都是使用http協議。可是正式服如今通常都是使用更加安全的https協議。

問題

問題的關鍵就是在於這個協議的問題，瀏覽器默認是不容許在https裏面調用http資源的。在這裏根據我所遇到的狀況大概是這樣子的：

1. 在IE瀏覽器瀏覽器中使用連接加載資源時會彈出一個對話框：

avatar

2. 在微信的瀏覽器中引入圖片資源時會報一個警告(可是圖片會正常加載)：

avatar

3. 在https頁面中向http地址發起ajax請求時，瀏覽器會阻止掉這個請求，而後報一個Mixed Content的錯誤。
4. 在https頁面中使用webSocket時須要注意，必須使用wss協議纔可以發起鏈接，否則也會報錯：

avatar

問題分析

https協議與https協議的區別

在解決這個問題以前首先須要知道https是什麼，與http的區別在什麼地方。

https安全超文本傳輸協議：

它是一個安全通訊通道，它基於HTTP開發，用於在客戶計算機和服務器之間交換信息，它使用安全套接字層(SSL)進行信息交換，簡單來講它是HTTP的安全版。它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操做，並返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）做爲HTTP應用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通訊。）SSL使用40 位關鍵字做爲RC4流加密算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，若是須要的話用戶能夠確認發送者是誰。總的來講，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議要比http協議安全。

在URL前加https://前綴代表是用SSL加密的，你的電腦與服務器之間收發的信息傳輸將更加安全。 Web服務器啓用SSL須要得到一個服務器證書並將該證書與要使用SSL的服務器綁定。

https與http的區別：

• https協議須要到ca申請證書，通常免費證書不多，須要交費。
• http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議。
• http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。
• http的鏈接很簡單,是無狀態的。
• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全。

什麼是混合內容（Mixed Content）

很明顯上面報的錯都是與Mixed Content是有關係的，Mixed Content就是：

當用戶訪問使用HTTPS的頁面時，他們與web服務器之間的鏈接是使用SSL加密的，從而保護鏈接不受嗅探器和中間人攻擊。

若是HTTPS頁面包括由普通明文HTTP鏈接加密的內容，那麼鏈接只是被部分加密：非加密的內容能夠被嗅探者入侵，而且能夠被中間人攻擊者修改，所以鏈接再也不受到保護。當一個網頁出現這種狀況時，它被稱爲混合內容頁面。

詳情可見：https://developer.mozilla.org/zh-CN/docs/Security/MixedContent

解決方案

相對協議

若是你的網站同時準備了https資源和http資源，那麼使用相對協議能夠實現根據當前網站的協議，瀏覽器自行選擇經過https仍是http發起請求，而相對協議也是很是簡單的就是講URL的協議(http、https)去掉。<img src="//domain.com/img/logo.png">

這裏必定要注意必須是網站同時有https和http的資源纔會有效，不然請求會失敗，另一般在正式服上線時都會劉改HOST地址，因此通常的ajax請求並不會出現問題，主要要注意的是一些單獨的請求地址會出現這樣的問題，如七牛雲上傳所使用的地址是單獨的，因此有可能在正式服上線時沒有注意到，另外就是使用websocket時檢查一下正式服的socket地址是不是wss協議。

總結

此次第一個出現的問題是在週報系統七牛上傳文件部分出現的，因爲以前週報系統正式服能夠經過http訪問到，因此沒有出現問題，可是最近正式服換成了https，就致使文件無妨上傳，當時在碰到問題時感受比較奇怪，明明測試服是正常的，爲何正式服會不正常，因爲沒有正式服的帳號，因此調試的時候是在別人的電腦上面，當時控制檯好像並無打印報錯信息（有多是本身沒有注意到），只是發現了在上傳文件時的第二個請求沒法發送出去，當時也並無狀態碼（這裏實際上是請求根本就沒有發送出去，被瀏覽器給block掉了）。因此在解決問題的時候並無一個方向，最後是在老大的幫助下才瞭解到問題的所在的。

而在這一次問題中暴露出了一些問題，好比：

1. 在肯定測試服正常的狀況下自我感受正式服應該不會有錯，帶着這樣的心理去找問題就會忽視掉不少的細節問題。
2. 當時只是發現請求沒發送出去，卻沒有去找請求發送失敗的緣由。
3. 沒有去尋找控制檯的報錯信息（當時沒有發現有錯誤信息，不知道是用戶瀏覽器的問題仍是本身疏忽了，這個是本次沒有找到問題根源的關鍵所在），只是去關注了Network面板請求發送狀況。

第二次是格子機的socket鏈接失敗，這個問題主要是本身在拿到後端給的正式服socket地址時沒有檢查，沒有發現地址的協議是ws的致使在測試時才發現這個問題，在之後拿到後端給的地址時仍是須要檢查一下再去使用。

參考資料

• 相對協議URL

做者簡介：李成文，蘆葦科技web前端開發工程師，擅長網站建設、微信公衆號開發、微信小程序開發、小遊戲製做、企業微信製做、H5建設，專一於前端框架、交互設計、圖像繪製、數據分析等研究。

我的博客：LCW blog

歡迎和咱們一塊兒並肩做戰： web@talkmoney.cn
訪問 www.talkmoney.cn 瞭解更多

提供深圳微信公衆號製做，廣東釘釘開發，專業的企業微信外包，高性價比的微信小程序建設，靠譜的小遊戲製做，高質量的H5開發