42

这是 StackOverflow 上经常讨论的问题，这意味着什么：

 <script src="//cdn.example.com/somewhere/something.js"></script>

这样做的好处是，如果您通过 HTTPS 访问它，您会自动获得 HTTPS，而不是那种可怕的“此页面上的不安全元素”警告。

但是为什么要使用协议相关的 URL 呢？为什么不在 CDN URL 中始终使用 HTTPS？毕竟，如果您决定通过 HTTPS 加载 HTTP 页面的某些部分，则没有理由抱怨。

（这更适用于 CDN；几乎所有 CDN 都具有 HTTPS 功能。而您自己的服务器可能不一定具有 HTTPS。）

4

5 回答 5

47

截至 2014 年 12 月，Paul Irish 的关于协议相关 URL 的博客说：

2014.12.17：现在大家都鼓励使用 SSL 并且没有性能问题，这种技术现在是一种反模式。如果您需要的资产在 SSL 上可用，则始终使用该https://资产。

除非您有特定的性能问题（例如 Zakjan 的回答中提到的慢速移动网络），否则您应该使用它https://来保护您的用户。

于 2015-02-11T12:18:53.770 回答
7

因为性能。HTTPS 连接的建立比 HTTP 需要更长的时间，TLS 握手增加了高达 2 RTT s 的延迟延迟。您可以在移动网络上注意到它。因此，如果您不需要，最好不要使用 HTTPS 资产 URL。

于 2015-02-11T05:25:59.013 回答
4

有许多潜在的原因，尽管它们都不是特别重要：

  • 下次每家有议程的企业都推出新协议时怎么样？那么我们是否将不得不再次交换数千个字符串？不，谢谢。
  • HTTPS 比同版本的 HTTP 慢
  • 如果caniuse.com 上列出的任何关于 HTTP/2 的注释有问题
  • 从概念上讲，如果服务器强制执行协议，则首先没有理由对其进行具体说明。不可知论就是这样。它涵盖了你所有的基地。
于 2018-11-15T17:22:13.447 回答
1

需要注意的一点是，如果您使用的是 CSP upgrade-insecure-requests，您可以安全地使用与协议无关的 URL ( //example.com)。

于 2018-11-09T14:52:39.160 回答
0

协议相关的 URL 有时会破坏试图检测 location.protocol 的 JS 代码。极旧的浏览器也无法理解它们。如果您正在开发需要最大向后兼容性的 Web 服务（即提供可以在慢速连接和/或旧设备上接收/发送的关键紧急信息），请不要使用 PRURL。

于 2021-07-28T06:19:34.593 回答