麻豆小视频在线观看_中文黄色一级片_久久久成人精品_成片免费观看视频大全_午夜精品久久久久久久99热浪潮_成人一区二区三区四区

首頁 > 網站 > 網頁設計 > 正文

用 // 代替 http:// 有什么好處(自適應https)

2024-08-30 08:33:28
字體:
來源:轉載
供稿:網友

//缺省協(xié)議

/缺省協(xié)議的使用,代表資源訪問的協(xié)議和當前頁面保持一致,如果當前頁面是http ,采用http協(xié)議訪問,如果是https,則使用 https 協(xié)議訪問。這樣用就不管是http還是升級到https都不用改動代碼,現(xiàn)在很多CDN資源都是這樣引用。一般使用在內鏈中,外鏈的協(xié)議頭具有不確定性的原因。

 

//的含義?

//是缺省協(xié)議的寫法,例如

//VeVb.com/css/

缺省協(xié)議默認使用當前協(xié)議

當前頁面為HTTP時,等效

http://VeVb.com/css/

當前頁面為HTTPS時,等效

https://VeVb.com/css/

使用 // 代替 http:// 的條件和好處?

當前頁面和目標資源同時支持HTTP和HTTPS正在從http升級到https

這樣的好處就是能根據(jù)用戶打開頁面的方式自適應的選擇資源的請求協(xié)議,

對于https頁面的內容,瀏覽器默認會組織非https內容,可以避免這種情況

// 缺點

直接打開本地文件調試時,使用的協(xié)議是文件協(xié)議(file://)

這個時候這個協(xié)議會變成 file://VeVb.com/css/顯然是不存在的

與當前網站的協(xié)議保持一致,快速發(fā)布與你當前協(xié)議相匹配的版本,同時減少SSL或其它協(xié)議版本的部署成本。開發(fā)者不需要管服務器云端提供什么協(xié)議,只要用//符號來代表一切最適應的匹配,這和nodeJS的思維是一脈相承的。

優(yōu)點如下:

因為很多網站都將http升級為https,這樣就可以防止我們的網址被劫持,前期為了在轉換過程中我出差錯我們沒有強制跳轉,就是當用戶訪問http或https都可以正常訪問,那么里面的js,圖片,鏈接等都不能用https或http,那么有什么解決方法呢,那么解決方法來了就是用//,不要帶http:與https這樣就可以了。

//這種寫法是根據(jù)你請求的協(xié)議自動添加協(xié)議的。舉個栗子:你的網站是http協(xié)議,那么其實你訪問的就是http://xxxx 如果你的網站是https協(xié)議的,那么請求的地址會變成https://xxxx 要知道,如果你寫成了http://xxx. 那么如果你們的網站線上是https,那么可能會報安全警告,有的瀏覽器甚至沒法正常加載頁面。如果你直接寫成https,要知道,本地開發(fā)可是http啊...

下面的內容是來自知乎的一些經典回復

好處很多人都答過了。升級 https 當然最能感受到這種好處。我只是補充一個為什么前人不這么寫的理由。當然,確實有很多前端并不知道這種寫法。不過,就算知道也很可能無法這么寫。因為 UC 瀏覽器的許多較早版本不支持這種寫法,會把 //a.b/ 直接理解為 /a.b/,也就是說,如果你在 http://example.com 的頁面里寫了 //example-cdn.net/static-file 的地址,UC 實際訪問的是 http://example.com/example-cdn.net/static-file 。UC 過去的市占率大家是知道的。所以……

 

一看你就沒做過「全站 HTTPS 升級改造」。我給全站做 HTTPS 升級的時候,真的想把寫 http:// 的人砍死。尤其是數(shù)據(jù)庫里的鏈接和 JS 里拼接出來的 url。期間用了各種正則,還要人工核查。奈何寫 http:// 的程序員太多,只能作罷。有人還在評論里問原因,原因就是如果你全寫 //,我就不用改造數(shù)據(jù)庫里的數(shù)據(jù)和源碼了,直接升級 https 就行了。你可能會說 https 改造這種事情很少發(fā)生吧,巧了,我在騰訊和阿里都遇到了 https 改造 ಥ_ಥ 而且在阿里的時候我要負責 1688 整站(個別部門自行改造)的前端代碼改造(不只是 HTML,還有 CSS 、JS、Velocity 模板等!簡直就是臟活累活,我 TM 為什么要接這個活兒),你猜我罵寫 http:// 的人罵了多少次?有的前端還直接在 JS 里寫 http,沿用一下當前頁面的協(xié)議你會死啊?

 

還有的前端用正則判斷 url 時居然只接受 http:// 和 https:// 不接受 //,真的是沒常識。太多程序員,太智障了。也有可能是因為他們沒聽說過 HTTPS 而已。如果你還不懂,我就問你幾個問題:如果你用 http:// ,那你就是默認當前頁面是 http 協(xié)議了,你一個前端憑什么決定當前頁面的協(xié)議?難道你不知道 http 鏈接在 https 頁面里會報錯啊?你應該沿用當前頁面的協(xié)議,所以你要寫 //如果你用 https://,也是一樣的問題,你怎么知道三年后會不會出現(xiàn)一個 httpshe://,難道到時候你再全部改成 httpshe:// ?不要做任何明顯是錯誤的假設!你根本就不知道當前頁面會用什么協(xié)議打開!所以你要用 // 啊!類似的錯誤假設還有很多,比如很多中國程序員都以為電話號碼只含數(shù)字和括號,不含字母。真的是這樣嗎?

 

有人說全局替換不就完了嗎?舉例說明吧,假設淘寶要升級 https于是你將 http:// 全部替換成 //第一個 bug:你把 <a href="http://tmail.com"> 替換成了 <a href="//tmail.com"> ,然而當時 http://tmail.com 還不支持 https于是你將一定范圍內的域名替換,http://(taobao|taobao2|taobao3).com 替換成 //$1.com第二個 bug:有些 JS 是這樣寫的 url = "http://" + location.hostname + '/' + path,還有寫 JS 是這樣寫的 /^http://///.test(input)。你說這個就沒法用正則了,在所有 JS 里全局搜索 http 然后人工審查吧。你知道淘寶有多少 JS 文件嗎…… 而且這些文件是緩存十年的……就算你改了,也不一定能更新。而且一旦你改錯了,影響用戶下單,馬云損失一個億你賠得起嗎?第三個 bug:有些數(shù)據(jù)根本就不在代碼里,在數(shù)據(jù)庫里,比如 user.image 的值是 http 開頭的。于是你將 user.image 寫成 user.image.replace('http://', '//') 或者你直接改數(shù)據(jù)庫里的數(shù)據(jù)(當數(shù)據(jù)量很大的時候,這基本是不可能的)第四個 bug:你忘了改 nginx、crossdomain 里面的域名第五個 bug:你忘了改配置系統(tǒng)里面的 base_url第六個 bug:你的 https 頁面嵌入了一個外部的 http iframe……你就哭吧,這很難解決,運氣好直接改成 // (外部支持 https 即可),運氣不好就要改頁面邏輯了。第 N 個 bug……HTTPS 升級就是臟活累活,你說簡單你來做,你開始做就知道牽連的地方有多少了。最好的方案還是把協(xié)議做成很容易變更的方式,比如遵循當前頁面,或者用變量,反正寫死 http:// 肯定不好。有些程序員寫代碼的時候,明明知道有 HTTPS 卻不去兼容,心理想著「反正我在這個公司呆兩年就走了,HTTPS 至少還有三年呢」然后就寫出了垃圾代碼。

 

越來越多的開發(fā)者,在鏈接文件時,采用//來代替http://,即如< a href="http://VeVb.com……一般寫為 < a href = " //http://VeVb.com……,這與傳統(tǒng)帶http有什么區(qū)別?

原本你的網站是http的,所有的src都是 http開頭,以為遭到狗屎運營商大量劫持,在你的頁面塞了一大堆少兒不宜/和單純廣告的內容的時候,有人告訴你替換https可以改善這個問題,那么這個時候你就知道 之前的src和ajax寫得//而不是http://是當初多么明智的決定。。。

逐浪CMS官方

隨著越來越多開源和云平臺的涌現(xiàn)以及SSL協(xié)議的廣泛導入(如逐浪CMS已經全面啟用了SSL協(xié)議支持),人們在進行開發(fā)時不得不面對http協(xié)議的選擇和識別。眾所周知,過多的ssl引用,可能會造成普通站點的效率低下,但我們不能為此再去重新設計一個純SSL版本。表現(xiàn)在開源庫上,一般平臺都同時提供SSL版和非SSL版。如這兩個庫:https://code.z01.com/js/jquery-3.2.1.slim.min.jshttp://code.z01.com/js/jquery-3.2.1.slim.min.js其引用效果是一致的。于是開發(fā)者們直接用"//網址/文件"方法來替代前面的協(xié)議,使之自動識別。即具體是SSL協(xié)議還是普通http協(xié)議,交給瀏覽器去自動識別并自動與當前站點匹配,從而實現(xiàn)最佳的安全請求和最高效的加載方法。概言之,這是一種開發(fā)方法和開發(fā)思維,云計算的web與移動開發(fā)日益壯大。

發(fā)表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發(fā)表
主站蜘蛛池模板: 久久亚洲精品11p | 免费黄色在线 | 27xxoo无遮挡动态视频 | 欧美一级不卡视频 | wwwxxx视频 | 亚洲综合网站 | 美女一级毛片 | 一级免费黄色免费片 | 亚洲va久久久噜噜噜久牛牛影视 | 奶子吧naiziba.cc免费午夜片在线观看 | 欧美日韩中文字幕在线 | www久久国产| 欧美性猛交一区二区三区精品 | 一级一级一级毛片 | 欧洲成人精品 | 精品国产乱码久久久久久丨区2区 | 深夜福利视频免费观看 | 国产美女爽到喷白浆的 | 免费一级片观看 | 久草在线视频首页 | 亚洲国产高清一区 | 亚洲人成在线播放网站 | 美国黄色毛片女人性生活片 | 国产精品久久久久久久娇妻 | 免费香蕉成视频成人网 | 91久久精品一二三区 | 免费国产a| 一级免费观看 | 欧美 国产 亚洲 卡通 综合 | 亚洲午夜国产 | 久久精品超碰 | 国产午夜三级一区二区三桃花影视 | 欧美精品一级片 | 羞羞视频入口 | 被啪羞羞视频在线观看 | 毛片视| 日日做夜夜操 | 久久久久亚洲精品国产 | 黄色片在线免费播放 | 精品亚洲夜色av98在线观看 | 成人性生活视频在线观看 |