使用前导双斜杠继承URL中的协议是否有任何弊端？即src =“ // domain.com”

我有一个样式表，可从外部域加载图像，并且需要基于当前URL从安全订单页面的https：//和其他页面的http：//加载。我发现以双斜杠开头的URL会继承当前协议。所有浏览器都支持此技术吗？

html前：

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

css ex：

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

如果浏览器支持RFC 1808第4节，RFC 2396第5.2节或RFC 3986第5.2节，则它将确实使用页面URL的方案对以“ //”开头的引用。

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

从2014年起更新：

现在，所有人都应该鼓励使用 SSL ，并且不必担心性能问题，现在，这种技术已成为一种反模式。如果您所需的资产在SSL上可用，请始终使用https://资产。

如果您的URL是在网页上下文之外查看的，则可能会带来不利影响。例如，位于电子邮件客户端（例如Outlook）中的电子邮件实际上没有URL，并且当您查看包含相对协议URL的消息时，根本没有明显的协议上下文（消息本身是独立的（用于POP3，IMAP，Exchange，uucp或其他任何协议）获取URL的协议，因此该URL没有相对的协议。我尚未调查与电子邮件客户端的兼容性，以查看在缺少协议处理程序时电子邮件客户端的功能-我想大多数人都会在http上猜测。Apple Mail拒绝让您输入没有协议的URL。这类似于由于上下文相似而导致相对URL在电子邮件中不起作用的方式。

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

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

原因可能是提供便携式网页。如果外部页面未传输加密（http），为什么应该对链接脚本进行加密？这似乎是不必要的性能损失。万一外部页面被安全地传输加密（https），则链接的内容也应该被加密。如果页面已加密，则链接的内容未加密，IE似乎发出了混合内容警告。原因是攻击者可以在途中操纵脚本。请参阅http://ie.microsoft.com/testdrive/浏览器/MixedContent/Default.html?o=1讨论，。

EFF 的HTTPS Everywhere广告系列建议尽可能使用https。如今，我们具有服务器能力，可以服务始终加密的网页。

只是为了完整性。在另一个线程中提到了这一点：

“两个正斜杠”是“无论当前使用什么协议”的常用缩写。

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

请检查完整线程。

现在看来这是一种非常普遍的技术。没有缺点，它仅有助于统一页面上所有资产的协议，因此应尽可能使用。