2012-11-03 19 views
14

我想用相同的方案(大概是「http:」或「https:」)來構造加載當前運行的JavaScript的頁面。現代瀏覽器支持簡單地省略該方案(例如,src="//example.com/test.js"),但這不是完全跨瀏覽器兼容的。 (我讀過IE 6是唯一不支持它的瀏覽器,但我仍然需要與該版本兼容。)是否location.protocol無效?

跨瀏覽器的方式來做這個似乎是檢查location.protocol。例如,谷歌Analytics使用:

('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + ... 

在谷歌的情況下,他們想用不同的域取決於請求是否使用SSL,所以該模式纔有意義。但我已經看到即使只有協議是不同的人使用相同的模式:(。一個例子是在「最終Wufoo項目片段」在http://css-tricks.com/thinking-async/

('https:' == location.protocol ? 'https:' : 'http:') + "//example.com" 

我寧願使用這個簡單的表達,而不是:

location.protocol + "//example.com" 

我應該真正關心的location.protocol承擔比其他一些價值的可能性「https:」開頭或「HTTP:」當我的代碼的網站上用我不要管?

回答

13

它總會被設置爲某種東西,但有時可能會設置爲既不是「http」也不是「https」的值。您最有可能看到的另外三個值是file:(對於HTML文件),about:(對於涉及about:blank的iframe魔法),或許還有ftp:

+0

哦,iframe的魔術包括人們以編程方式構建一個iframe,然後從父框架的JavaScript填充它的情況嗎?現在你提到它了,雖然我可以想象'file:'或者'ftp:'不時出現,我敢打賭,iframe魔法是最常見的情況。 –

+1

正確 - 這正是您最有可能遇到'about:'協議的地方。 – duskwuff

2

當我的代碼在我不控制的站點上使用時,我應該真的關心document.location.protocol採用「https:」或「http:」以外的值的可能性嗎?

不是特別的,但是再次說明,您的方法沒有特別的傷害(在協議之前預先掛起)。 Google Analytics可能會盡可能多地進行實際檢測,因爲它們使用與其他任何主機不同的主機。

5

注意:這不是關於document.location.protocol的返回是否有效,而是描述了一個非常難以發現的錯誤(您可以在不寫任何javascript的情況下覆蓋document.location.protocol的行爲)。

我碰到了一個看起來很奇怪的情況,其中document.location.protocol似乎沒有像應該那樣工作。該網站有一個跟蹤JavaScript代碼在用下面的代碼片段,以解決目前的協議:

var proto = ('https:' === document.location.protocol ? 'https://' : 'http://') 

該網站的HTTPS,但在一些網頁上的協議會變成是HTTP而不是預期的HTTPS

大量的時間花費在谷歌搜索和調查應用程序棧配置之後,一個顯影劑斑發生的協議解決問題的網頁,具有一個HTML形式的具有以下屬性:

name="location" 

這導致協議解析行爲不當並錯誤地將協議推斷爲http而不是https(不,表單沒有稱爲協議的字段,也不應該有)。

+0

非常感謝你的回答!我發現這個確切的問題與我的代碼,並不知道爲什麼document.location.protocol是「http:」,當它應該是HTTPS。看起來很直觀 - 爲什麼它不僅僅分析瀏覽器中的地址欄字符串?奇怪的。 – binderbound

+0

因爲如果有一個名稱爲'location'的表單,那麼'document.location'是表單元素,它根本沒有'protocol'屬性。因此,https:'=== document.location.protocol'爲false。 – duskwuff

+1

使用適當的'location'全局而不是舊的'document.location'。瀏覽器一直都有,使用'document.location'沒有意義。 – Krinkle