使用前导双斜杠继承 URL 中的协议有什么缺点吗？即 src="//domain.com"答案

【问题标题】：Is there any downside for using a leading double slash to inherit the protocol in a URL? i.e. src="//domain.com"使用前导双斜杠继承 URL 中的协议有什么缺点吗？即 src="//domain.com"
【发布时间】：2011-06-07 06:11:07
【问题描述】：

我有一个从外部域加载图像的样式表，我需要它根据当前 URL 从安全订单页面的 https:// 和其他页面的 http:// 加载。我发现以双斜杠开头的 URL 继承了当前协议。是否所有浏览器都支持这种技术？

html 例如：

<img src="//cdn.domain.com/logo.png" />

css 例如：

.class { background: url(//cdn.domain.com/logo.png); }

【问题讨论】：

这会减慢网站速度吗？？？
没有理由这会对性能产生任何影响，除非 Meder 在下面的回答中列出了这些情况。
看起来我在做某事。几个月前，Google 开发人员开始在他们的托管 Javascript 库页面 developers.google.com/speed/libraries/devguide 上使用此约定
如果本地加载这样的HTML文件（直接用浏览器打开）怎么办？看起来 Firefox（在这种情况下为 28）然后不加载远程资源。有道理，因为 HTTP 不是父协议。但在我看来，这将是一个劣势。

标签： http url https url-protocol

【解决方案1】：

如果浏览器支持RFC 1808 Section 4、RFC 2396 Section 5.2 或RFC 3986 Section 5.2，那么它确实会使用页面 URL 的方案来处理以“//”开头的引用。

【讨论】：

所有主流浏览器都支持这个吗？（IE7、IE8、FF、Chrome、Safari）
考虑到第一个描述它的 RFC RFC 1808 是 15 年前编写的，并且 URL 引用是网站功能的关键，我认为可以肯定地说几乎所有主要浏览器都支持现在它。但唯一确定的方法就是自己尝试一下，看看会发生什么。
这个问题是从提出类似问题的人那里得到的，我在前一年的 RFC 1630 中找到了它（说明不同，但仍然允许有问题的格式）。如果有人有存档副本，它很可能是从 1991 年开始在ftp://info.cern.ch/pub/www/doc/http-spec.txt 上使用的文档的一种或其他形式。
"2014.12.17：现在大家都鼓励使用 SSL，并且没有性能问题，这种技术现在是一种反模式。如果您需要的资产在 SSL 上可用，那么请始终使用https:// 资产。” （引用自stackoverflow.com/a/27999789）
@joonas.fi 这种推理太幼稚了。 SSL 仍然会对性能产生影响，并且在大量应用程序中是不需要的。当然，我更喜欢使用它，但我不希望在例如我部署的代码中强制执行它。

【解决方案2】：

在link 或@import 上使用时，IE7/IE8 将根据http://paulirish.com/2010/the-protocol-relative-url/ 下载文件两次

2014 年更新：

既然 SSL 是 encouraged for everyone 和 doesn’t have performance concerns，这种技术现在是一种反模式。如果您需要的资产在 SSL 上可用，则始终使用 https:// 资产。

【讨论】：

@EricLaw 是在 IE9 中修复的，无论呈现模式如何，还是仅在标准模式下，但在 Quirks 模式下仍然损坏？
我几乎可以肯定，这已在前瞻扫描仪的所有模式中得到修复。你在其他地方见过吗？
SSL 当然确实会影响性能。 EFF 不编写服务器-服务器接口，并且其他站点几乎没有技术专长。此外，假设网站的供应商将强制执行此类限制是一种反模式。因此，人们编写 CSS 和 javascript 应用程序时不应依赖协议问题。

【解决方案3】：

如果在网页上下文之外查看您的 URL，则会出现一个缺点。例如，位于电子邮件客户端（例如 Outlook）中的电子邮件实际上没有 URL，当您查看包含协议相关 URL 的消息时，根本没有明显的协议上下文（消息本身是独立的用于获取它的协议（无论是 POP3、IMAP、Exchange、uucp 还是其他），因此 URL 没有相关的协议。我还没有调查与电子邮件客户端的兼容性，以查看它们在缺少协议处理程序时会做什么——我猜大多数人会猜测 http。 Apple Mail 拒绝让您输入没有协议的 URL。这与电子邮件中的相对 URL 因同样缺少上下文而无法工作的方式类似。

类似的问题可能出现在其他非 HTTP 上下文中，例如在推文、SMS 消息、Word 文档等中。

更一般的解释是匿名协议 URL 不能单独工作；必须有相关的上下文。因此，在典型的网页中，以这种方式引入脚本库是可以的，但任何外部链接都应始终指定协议。我确实尝试了一个简单的测试：//stackoverflow.com 在我尝试过的所有浏览器中都映射到file:///stackoverflow.com，所以它们真的不能自己工作。

【讨论】：

这是一个非常好的观点，我昨晚睡着时实际上正在考虑这个问题。另一个问题是https 或http 版本实际上可能不可用，你不能总是假设它是可用的。
可以这么说，在浏览器之外，您只能靠自己。没有说电子邮件或其他客户端是否知道 javascript 或 css 等。所以这几乎是关于相对 url 的一个有争议的问题？
没有争议。从file:// 加载时，许多电子邮件客户端都支持JS，浏览器当然也可以。这是一个小用例，但当它出现时很重要。
我希望有一种方法可以指定 使用 http，除非当前 url 是 https，在这种情况下使用 https，而不是指定 使用与当前页面已加载，这实际上就是//。
如果您指定一个例如<base href="https://www.google.com">，可以在网页外查看内容。 <img src="//www.google.com/images/srpr/logo11w.png"> 或 <img src="images/srpr/logo11w.png">

【解决方案4】：

原因可能是提供可移植的网页。如果外页没有加密传输（http），为什么要加密链接的脚本？这似乎是不必要的性能损失。如果外部页面被安全传输加密（https），那么链接的内容也应该被加密。如果页面是加密的，链接的内容没有，IE 似乎会发出 Mixed Content 警告。原因是攻击者可以在途中操纵脚本。请参阅http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 进行更长时间的讨论。

来自 EFF 的 HTTPS Everywhere 活动建议尽可能使用 https。如今，我们拥有服务器容量来提供始终加密的网页。

【讨论】：

【解决方案5】：

只是为了完整性。这在另一个帖子中提到过：

The "two forward slashes" are a common shorthand for "whatever protocol is being used right now"

if (plain http environment) {
    use 'http://example.com/my-resource.js'
} else {
    use 'https://example.com/my-resource.js'
}

请查看全文。

【讨论】：

【解决方案6】：

现在这似乎是一种相当普遍的技术。没有缺点，它只有助于统一页面上所有资产的协议，因此应尽可能使用。

【讨论】：