使用领先的双重斜杠在URL中继承协议是否有缺点？ ie src =“ // domain.com”

Question

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

html ex：

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

CSS ex：

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

Answer 1

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

Answer 2

当使用 link 或者 @import, ，IE7/IE8将两次下载文件 http://paulirish.com/2010/the-protocol-relative-url/

2014年更新：

现在SSL是 鼓励每个人 和 没有表现问题, 该技术现在是一种反模式. 。如果您需要的资产可在SSL上可用，则 总是 使用 https:// 资产。

Answer 3

如果在网页的上下文之外查看您的URL，则会发生一个缺点。例如，坐在电子邮件客户端中的电子邮件（例如Outlook）有效地没有URL，并且当您查看包含协议相关URL的消息时，完全没有明显的协议上下文（消息本身是独立的用于获取它的协议，无论是POP3，IMAP，Exchange，uucp还是其他），因此URL没有相关协议。我没有调查与电子邮件客户端的兼容性，以查看他们在与缺少协议处理程序展示时所做的事情 - 我猜大多数人都会在HTTP上猜测。 Apple Mail拒绝让您在没有协议的情况下输入URL。这类似于相对URL在电子邮件中无法在电子邮件中工作的方式。

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

更一般的解释是，匿名协议URL不能孤立地工作。那里 必须 成为相关背景。因此，在典型的网页中，可以以这种方式删除脚本库，但是任何外部链接都应始终指定协议。我确实尝试了一个简单的测试： //stackoverflow.com 地图 file:///stackoverflow.com 在所有浏览器中，我都尝试过，所以他们 真的 不要独自工作。

Answer 4

原因可能是提供便携式网页。如果未传输外页（HTTP），为什么要加密链接的脚本？这似乎是不必要的表现损失。如果外页被牢固地运输加密（HTTPS），则也应加密链接的内容。如果页面是加密的，则没有链接的内容，即 混合内容 警告。原因是攻击者可以在途中操纵脚本。看 http://ie.microsoft.com/testdrive/browser/mixedcontent/default.html?o=1 进行更长的讨论。

这 到处都是HTTP EFF的活动建议尽可能使用HTTP。如今，我们拥有服务网页始终加密的服务器容量。

Answer 5

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

“两个正向斜线是正确使用的任何协议的常见速记”

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

请检查完整线程。

Answer 6

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