location.protocol是否无效？

Question

我想构建具有相同方案的URL(可能是"http:"或"https:")作为加载当前运行的JavaScript的页面.现代浏览器支持简单地省略该方案(例如,src="//example.com/test.js"),但这不是完全跨浏览器兼容的.(我已经读过IE 6是唯一不支持它的浏览器,但我仍然需要与该版本兼容.)

这种跨浏览器的方式似乎是检查location.protocol.例如,Google Analytics使用:

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

在Google的情况下,他们希望根据请求是否使用SSL来使用不同的域,因此该模式是有意义的.但是我看到其他人使用相同的模式,即使只有协议是不同的:

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

(一个例子是http://css-tricks.com/thinking-async/上的"Final Wufoo Snippet" .)

我宁愿使用这个更简单的表达式:

location.protocol + "//example.com"

location.protocol当我的代码在我无法控制的网站上使用时,我是否真的应该关注除"https:"或"http:"之外的其他值的可能性？

Answer 1

它将始终设置为某个值,但有时可能设置为既不是"http"也不是"https"的值.您最有可能看到的其他三个值file:(对于HTML文件),about:(对于涉及iframe魔法about:blank),或许也是如此ftp:.

Answer 2

注意:这并不严格关于document.location.protocol的返回是否有效,但描述了一个非常难以发现的错误(您可以在不编写任何javascript的情况下覆盖document.location.protocol的行为).

我遇到了一个看似奇怪的案例,其中document.location.protocol似乎没有按预期工作.该网站有一个跟踪-Javascript,它使用以下代码片段来解析当前协议:

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

该网站使用HTTPS,但在某些页面上,协议将变为http而不是预期的https.

在Googling花费了大量时间并调查应用程序堆栈配置后,一位开发人员发现协议解决问题发生的页面,有一个带有以下属性的HTML表单:

name="location"

这导致协议解析行为不当并错误地将协议推导为http而不是https(不,表单没有称为协议的字段,也不应该有).