使用前面的双斜杠继承 URL 中的协议有什么缺点吗

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

HTML 格式:

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

CSS 例如:

.class { background: url(//cdn.domain.example/logo.png); }
50317 次浏览
小开
最佳答案

如果浏览器支持 RFC 1808第四部分、 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 没有可以相关的协议。我还没有研究与电子邮件客户端的兼容性，看看他们在缺少协议处理程序的情况下会做什么——我猜大多数人都会猜测 http。Apple Mail 拒绝让你在没有协议的情况下输入 URL。它类似于相对 URL 在电子邮件中无法工作的方式，因为缺少类似的上下文。

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

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

小开

原因可能是为了提供便携式网页。如果外部页面没有进行加密传输(http) ，为什么要对链接的脚本进行加密？这似乎是一个不必要的性能损失。如果外部页面是安全传输加密的(https) ，那么链接的内容也应该是加密的。如果页面被加密，链接内容没有，IE 似乎发出 混合内容警告。原因是攻击者可以在路上操纵脚本。有关更长的讨论，请参见 http://ie.microsoft.com/testdrive/Browser/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'
}

请检查完整的线程。

小开

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


提交答案