我可以将所有http：//链接更改为//吗？

240

戴夫·沃德（Dave Ward）说，

阅读的内容不完全准确，但是RFC 3986的4.2节提供了完全省略协议（HTTP或HTTPS）的标准URL。当省略URL的协议时，浏览器将改为使用基础文档的协议。

简而言之，这些“无协议” URL允许这样的引用在您将在其中尝试的每种浏览器中使用：

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

乍一看似乎很奇怪，但是此“无协议” URL是引用可通过HTTP和HTTPS进行访问的第三方内容的最佳方法。

假设我们的资产可以通过HTTP和HTTPS进行访问，那么这肯定会解决我们在HTTP页面上看到的一系列混合内容错误。

这是完全跨浏览器兼容的吗？还有其他警告吗？

http  url  https  protocol-relative 
— 付费书呆子
source
不久前，我在IE博客上阅读了有关此技术的信息。但是，当我尝试时，效果并不理想。如果我的网站使用HTTPS服务，则浏览器（Chrome）仍将HTTP用于无协议URL。
— ChristopherRamírez2012年
10
警告：切记永远不要在HTTP 3xx重定向中使用用户无方案URI！HTTP标头与此URL格式不兼容。如果需要根据方案进行重定向，请使用mod_rewrite或类似方法。
— user2596282 2013年
1
@ user2596282在现代版本的Chrome和Firefox中进行的实验与您不同意，对HTTP 1.1的（仍处于草案中）修订也是如此。HTTPbis工作组定义的规范（请参阅svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/…）。不过，也许您说的对某些浏览器是正确的。您是否特别知道在位置标头中相对协议URL失败的任何消息？
— Mark Amery
— 阿尔瓦罗·冈萨雷斯
不要使用它们，它们丑陋且多余。
— IllidanS4希望莫妮卡回到2014年

Answers:

204

我在发布之前进行了彻底的测试。在所有可用于在Browsershots上进行测试的浏览器中，我只能找到一个不能正确处理协议相对URL的浏览器：一种不起眼的* nix浏览器，称为Dillo。

我收到有关以下两个缺点的反馈：

  1. 当您在浏览器中“打开”本地文件时，无协议URL可能无法按预期方式工作，因为该页面的基本协议将是file：///。尤其是当您将无协议URL用于外部资源（例如CDN托管的资产）时。不过，使用本地Web服务器（如Apache或IIS）针对http：// localhost地址进行测试可以正常工作。
  2. 显然，至少有一个iPhone feed阅读器应用程序无法正确处理无协议URL。我不知道哪个人有问题或它有多受欢迎。对于托管JavaScript文件而言，这不是一个大问题，因为RSS读者通常无论如何都会忽略JavaScript内容。但是，如果您将这些URL用于需要通过RSS联合的内容中的图像之类的媒体（如图像），则可能会出现问题（尽管单个平台上的单个阅读器应用可能只占很少的阅读器）。
— 戴夫·沃德
source
33
尽管IE7 / 8在大多数情况下都能很好地处理相对于协议的URL（又称无方案URI），但是当使用此类URL指定样式表时，它将下载两次。（因此，史蒂夫·
— 索德斯
3
我发现IE6尝试将URI转换为相对的URI（即，删除前导斜杠之一）。这是一个link元素。例如，当指定时//fonts.googleapis.com/css?family=Rokkitt:400,700，IE6尝试加载http://mysite.com/fonts.googleapis.com/css/<...>。不太好！
— CBono 2011年
2
我从日志实例中发现了似乎是网络蜘蛛机器人（来源不明）的实例，这些实例试图使用无协议链接，并且未正确处理它们。
— 卡扎伊2011年
3
我在日志中看到了很多与无协议URL不相关的信息。这些蜘蛛很多都写得非常差。
— 戴夫·沃德，
11
要明白，这两个网址是很重要的不是与协议少，但与协议相关。他们从自己的上下文中获取协议，并且缺少上下文，它们在大多数浏览器中的行为都像文件url，实际上意味着它们会因为无法加载预期内容而中断。尽管它们通过http传递时可以工作，但是您会发现，如果保存页面并从本地文件中加载完全相同的HTML，则它们不会，因为上下文是不同的。您应该在其中使用的唯一上下文是http vs https。
— 同步
37

考虑是否应该这样做，是否可以将其所有链接更改为相对于协议的问题可能是没有意义的。根据保罗·爱尔兰（Paul Irish）：

2014.12.17：既然我们鼓励所有人使用SSL，并且不存在性能问题，那么此技术现在是一种反模式。如果您需要的资产在SSL上可用，则始终使用https：// 资产。

— 奥哈德·施耐德
source
我当时的想法完全一样。如果通过http也可以通过http下载外部资产，那有什么意义-即使主站点使用的是http（本不应该，但这是另一个主题）。
— joonas.fi，2015年
1
@ joonas.fi我唯一想到的就是避免某些浏览器可能生成的HTTP / HTTPS混合警告
— Ohad Schneider 2015年
3
仅当文档通过安全（https）加载但资产通过不安全（http）加载时，才会触发@Ohad_Schneider警告。我的建议是，即使文档是通过不安全的方式加载的，也始终可以通过安全性加载资产。没有警告，也没有理由不使用安全性，因此不需要整个“协议相对URL”。
— joonas.fi，2015年
1
@Ohad_Schneider哦，抱歉，我想我误解了你在说什么。当文档位于http之上时，通过https加载资产不会产生任何警告。但是，当文档通过https加载时，会通过http加载资产（并且至少在Chrome中默认情况下可能被阻止）。您是否指的是您通过https服务站点而外部资产仅在http下可用的情况？是的，这可能是个问题，但我认为没有任何严肃的第三方服务无法通过https提供其内容，否则它们应该仍然倒闭。:)
— joonas.fi 2015年
@ joonas.fi是吗？O_o如果某人拥有HTTPSed站点（则），则协议相对URL将无助于解决通过HTTP获取第三者资产的问题-没办法。而且无论如何，最好不要在HTTPS页面上使用绿色的SSL徽标，否则最好只归因于第三方不支持HTTPS而再次将其放弃给HTTP。
— poige
15

是的，网络路径引用已在RFC 1808中指定，并且应可用于所有浏览器。

— 秋葵
source
11
甚至推荐并在HTML5样板代码中使用它：html5boilerplate.com
— Felipe Lima
1
是的，您不会对“还有其他警告吗”回答“是”。？;）
— Caspar Kleijne 2011年
2
@Caspar Kleijne：我在句子的其余部分解释了“是”。
— Gumbo
1
Casper，Gumbo实际上回答了两个问题：“这个完全跨浏览器兼容吗？还有其他警告吗？” 是的，这是第一个问题的答案。
— 达伦·格里菲斯
4

这是完全跨浏览器兼容的吗？还有其他警告吗？

只是为了混合使用，如果您在本地服务器上进行开发，则可能无法正常工作。您需要指定一个方案，否则浏览器可能会假定src="//cdn.example.com/js_file.js"为src="file://cdn.example.com/js_file.js"，因为您不在本地托管此资源，所以该方案会中断。

Microsoft Internet Explorer似乎对此特别敏感，请参阅以下问题：无法在localhost（WAMP）的Internet Explorer中加载jQuery

您可能总是会尝试找到一种在您的所有环境中都能以最少的修改量运行的解决方案。

HTML5Boilerplate所使用的解决方案是在资源未正确加载时进行后备，但是只有在合并检查后才能起作用：

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

我也在这里发布了这个答案。

更新：现在，HTML5Boilerplate<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">在决定弃用协议相对URL后使用，请参见此处。

— bg17aw
source
1

使用：//domain.com时，我还没有遇到这些问题-但您确实需要在开始时添加冒号。约斯特（Yoast）在这方面写得很好。但是，他的博客文章却迷失了它。

— 用户1431784
source
否决票，因为没有说明额外的：有用的地方。我到处无意间离开了“：”
— 抢劫
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.