我想用相同的方案构造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/中的"最终wufoo sprippet"中。）
我更喜欢使用此简单的表达式：
location.protocol + "//example.com"
除了" https："或" http："我无法控制的站点时，我是否真的要关心location.protocol的可能性。
它将始终设置为某物，但有时可以将其设置为" http"或" https"的值。您最有可能看到的其他三个值是file:（用于HTML文件），about:（对于涉及about:blank的iFrame Magic），也许是ftp:。
注意：这不是严格涉及document.location.protocol的返回是否有效，但描述了很难发现错误（您可以覆盖的行为document.location.protocol而不编写任何JavaScript）。
我遇到了一个看似奇怪的情况， document.location.protocol 似乎没有工作。该站点具有跟踪javascript，该网站使用以下片段来解决当前协议：
var proto = ('https:' === document.location.protocol ? 'https://' : 'http://')
该网站在HTTPS上，但在某些页面上，该协议将是 http ，而不是预期的 https 。
。在谷歌搜索和调查应用程序堆栈配置花费了很多时间之后，一个开发人员发现了"协议解决问题的页面"，具有以下属性的HTML形式：
name="location"
这导致协议解决方案不正确，错误地将协议推导为HTTP而不是https（否，表单没有称为协议的字段，也不应具有）。
我是否真的应该担心文档的可能性。location.protocol采用以外的其他值，而不是" https："或" http："当我无法控制的网站上使用我的代码时？
不是特别的，但话又说回来，您的方法没有特别的危害（预先序言是什么协议）。Google Analytics（Analytics）可能会执行实际检测，因为它们使用了其他主机与其他任何主机。