在URL中使用前导双斜杠继承协议是否有任何缺点？例如，src =“//domain.example”

Question

我有一个样式表，它从外部域加载图像，并且我需要它从安全订单页面加载 https://，从其他页面加载http://，具体取决于当前URL。我发现使用双斜杠开始URL会继承当前协议。所有浏览器都支持这种技术吗？

HTML ex:

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

CSS ex:

CSS例子：

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

- Rob Volk

---

这会减慢网站的速度吗？ - TheBlackBenzKid

除了Meder在她的回答中列出的情况外，这不应该对性能产生任何影响。 - Rob Volk

看起来我正在做某件事情。几个月前，Google Developers 在他们的托管JavaScript库页面上开始使用这个约定。https://developers.google.com/speed/libraries/devguide - Rob Volk

如果这样一个HTML文件被本地加载（直接在浏览器中打开），会发生什么？看起来Firefox（在这种情况下是28版本）不会加载远程资源。这很有道理，因为那时HTTP不是父协议。但在我看来，这将是一个劣势。 - Dr. Jan-Philip Gehrcke

Answer 1

如果浏览器支持RFC 1808第4节, RFC 2396第5.2节或RFC 3986第5.2节, 那么它将确实使用页面URL方案来引用以"//"开头的内容。

- Remy Lebeau

---

这在所有主要的浏览器上都支持吗？（IE7、IE8、FF、Chrome、Safari） - Rob Volk

考虑到最早描述URL引用的RFC 1808已经写于15年前，而URL引用对于网站功能至关重要，我认为现在可以肯定地说，几乎所有主流浏览器都支持它。但是确保的方法就是亲自尝试并查看结果。 - Remy Lebeau

这个问题是从某人问类似的问题中链接过来的，我在RFC 1630中找到了它（用不同的措辞表述，但仍允许所讨论的格式）。它很可能出现在1991年开始的ftp://info.cern.ch/pub/www/doc/http-spec.txt文档的某种形式中，如果有人有存档副本的话。 - Jon Hanna

2014年12月17日：由于现在人人都被鼓励使用SSL并且不再存在性能问题，因此这种技术现在已经成为一种反模式。如果所需资源可以通过SSL获取，则始终使用https://资源。 - joonas.fi

@joonas.fi 这种推理是幼稚的。SSL仍然会对性能产生影响，并且在许多应用程序中是不必要的。我喜欢使用它，当然，但我不希望在我部署的代码中强制执行它。 - Otheus

Answer 2

当在link或@import上使用时，IE7/IE8将每次下载文件两次http://paulirish.com/2010/the-protocol-relative-url/ 2014年更新：

现在SSL已经鼓励所有人使用且没有性能问题, 这种技术现在是一种反模式。如果所需的资源在SSL上可用，则始终使用https://资源。

- meder omuraliev

---

@EricLaw 这个问题在IE9中是不是无论呈现模式都已经修复了，还是只在标准模式下修复了，在怪异模式下仍然存在问题？ - scunliffe

我几乎可以确定这个问题在前向扫描仪的所有模式中都已经解决了。你在其他地方看到过不一样的情况吗？ - EricLaw

SSL确实会对性能产生影响。EFF不编写服务器间接口，而该网站的技术专业知识也很少。此外，假设网站供应商将强制执行此类限制是一种反模式。因此，编写CSS和JavaScript应用程序的人不应该仅依赖于协议。 - Otheus

Answer 3

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

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

更一般的解释是：匿名协议URL无法单独使用；必须有相关的上下文环境。因此，在典型的网页中，通过那种方式拉入脚本库就可以，但任何外部链接都应该明确指定协议。我尝试了一个简单的测试：//stackoverflow.com在我尝试过的所有浏览器中都映射到file:///stackoverflow.com，因此它们真的不能单独使用。

- Synchro

---

这是一个非常好的观点，昨晚我入睡时也在考虑这个问题。另一个问题是https或http版本可能并不实际可用，你不能总是假定它是可用的。 - Wesley Murch

在浏览器之外，你可以说是自己一个人了。无法确定电子邮件或其他客户端是否了解JavaScript或CSS等内容。因此，关于相对URL，这基本上是一个无意义的问题？ - chris

不是无意义的观点。许多电子邮件客户端支持JS，当从file://加载时，浏览器肯定也可以支持。这只是一个小用例，但当它出现时，它非常重要。 - Jun-Dai Bates-Kobashigawa

我希望有一种方法可以指定“使用HTTP，除非当前URL是HTTPS，在这种情况下使用HTTPS”，而不是指定“使用与当前页面加载的协议相同”，这实际上就是//的作用。 - Jun-Dai Bates-Kobashigawa

如果您指定例如<base href="https://www.google.com">，则可以在网站外查看内容。无论是<img src="//www.google.com/images/srpr/logo11w.png">还是<img src="images/srpr/logo11w.png">。 - zig

@zig - 除非您使用的是像hotmail这样从电子邮件中剥离head标签的邮件客户端... base标签也可能会使URL片段表现不正确，将它们转换为绝对外部链接而不是内部链接。 - Synchro

Answer 4

可能的原因是为了提供可移植的网页。如果外部页面没有加密传输（http），那么为什么链接的脚本要加密呢？这似乎是一种不必要的性能损失。但是，如果外部页面是安全传输加密的（https），那么链接的内容也应该被加密。如果页面被加密，而链接的内容没有，IE会发出混合内容警告。原因是攻击者可能在传输过程中篡改脚本。有关更长的讨论，请参见http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1。

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

- koppor

Answer 5

仅为完整起见。这在另一个线程中提到：

“两个斜杠”是一种常见的缩写，表示“当前正在使用的任何协议”

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

请查看完整的线程。

- escapedcat

Answer 6

这似乎是一种相当常见的技术。它没有任何缺点，只有帮助统一页面上所有资产的协议，因此应尽可能使用。

- Ramashish Baranwal