我有以下元素:
<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>
在这种情况下，站点是HTTPS，但站点也可能只是HTTP。(JS文件在另一个域中。)为了方便起见，我想知道是否可以这样做:
<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>
我想知道是否可以删除http:或https:?
它似乎在我测试过的所有地方都有效，但是否有任何情况下它不起作用?
当前回答
由于您的示例链接到外部域，如果您使用的是HTTPS，那么您应该验证外部域也为SSL设置了。否则，您的用户可能会看到SSL错误和/或404错误(例如，旧版本的Plesk将HTTP和HTTPS存储在单独的文件夹中)。对于cdn，这应该不是一个问题，但对于任何其他网站，这可能是一个问题。
另一方面，在更新旧网站时进行测试，也可以在META REFRESH的url=部分中工作。
其他回答
有没有什么情况下它不起作用?
如果您是在本地服务器上开发，那么它可能无法工作。您需要指定一个方案，否则浏览器可能会假设src="//cdn.example.com/js_file.js"是src="file://cdn.example.com/js_file.js"，这将破坏，因为您没有在本地托管这个资源。
微软ie浏览器似乎对这一点特别敏感，看这个问题:无法在本地主机上加载jQuery (WAMP)
您可能总是试图找到一种解决方案，该解决方案适用于所有环境，所需的修改最少。
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，见[这里][3]。
没有方案的相对URL (http:或https:)是有效的，根据RFC 3986:“统一资源标识符(URI):通用语法”，章节4.2。如果客户端阻塞了它，那么这是客户端的错，因为它们没有遵守RFC中指定的URI语法。
你的例子是有效的，应该可以工作。我自己在访问量很大的网站上使用过相对URL方法，没有人抱怨。此外，我们还在Firefox、Safari、IE6、IE7和Opera上测试我们的网站。这些浏览器都能理解URL格式。
1. 总结
2019年的答案是:你仍然可以使用相对于协议的url，但这种技术是反模式的。
另外:
你可能在发展方面有问题。 一些第三方工具可能不支持它们。
从协议相对的url迁移到https://，这将是很好的。
2. 相关性
这个答案与2019年1月有关。在未来，这个答案的数据可能会被淘汰。
3.反模式
3.1. 论证
Paul Irish -前端工程师和谷歌Chrome的开发倡导者-在2014年12月写道:
既然SSL是鼓励所有人使用的，并且没有性能问题，那么这种技术现在是一种反模式。如果您需要的资产在SSL上可用，那么总是使用https://资产。 允许代码片段通过HTTP请求，为最近的GitHub man -on- side攻击打开了大门。即使您的站点是在HTTP上，请求HTTPS资产也总是安全的，然而反过来就不正确了。
3.2. 另一个链接
使用协议相对uri加载页面资源 停止使用协议相对url
3.3. 例子
2017年，Stack Overflow从相对协议的url切换到https 2018年Chrome将把所有未加密的网站标记为“不安全”
4. 发展过程
例如，我尝试使用clean-console。
示例文件KiraCleanConsole__cdn_links_demo.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>clean-console without protocol demonstration</title>
<!-- Really dead link -->
<script src="https://unpkg.com/bowser@latest/bowser.min.js"></script>
<!-- Package exists; link without “https:” -->
<script src="//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>
<!-- Package exists: link with “https:” -->
<script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
Kira Goddess!
</body>
</html>
输出:
D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html
phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js)
phantomjs: phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js: The network path was not found.
phantomjs://code/runner.js:31 in onResourceError
phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser@2.1.0/bowser.min.js)
phantomjs: phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser@2.1.0/bowser.min.js - server replied: Not Found
phantomjs://code/runner.js:31 in onResourceError
phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html
phantomjs process exited with code 2
链接//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js是有效的，但我得到一个错误。
关注file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js，阅读Thilo和bg17aw关于file://的回答。
我不知道这种行为，也不明白为什么我的页面会出现这样的问题。
5. 第三方工具
我使用可点击的url崇高的文本包。使用它，我可以简单地打开链接从我的文本编辑器在浏览器。
示例中的两个链接都有效。但第一个链接，我可以成功地打开浏览器使用点击url，第二个链接-没有。这可能不太方便。
6. 结论
Yes:
如果您在开发流程项中遇到问题，您可以设置开发工作流。 如果你在第三方工具项目中遇到问题，你可以贡献工具。
但是你不需要这些额外的问题。通过反模式项中的链接读取信息:协议相对url已过时。
这的确是正确的，正如其他答案所陈述的那样。但是你应该注意，一些网络爬虫会通过在你的服务器上请求它们来设置404，就像一个本地URL一样。(他们忽略了双斜杠，将其视为单斜杠)。
你可能想要在你的web服务器上设置一个规则来捕捉这些并重定向它们。
例如，在Nginx中，你可以添加如下内容:
location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
return 301 $scheme:/$redirect_domain/$redirect_path;
}
但是要注意，如果在uri中使用句点，则需要增加特异性，否则最终会将这些页面重定向到不存在的域。
而且，对于每个查询来说，这是一个相当庞大的正则表达式——在我看来，对于大多数兼容的浏览器来说，用404来惩罚不兼容的浏览器是值得的。
不使用协议是完全合理的。URL规范多年来一直对此非常明确，我还没有发现一个浏览器不理解这一点。我不知道为什么这个技巧不为人所知;它是跨越HTTP/HTTPS边界这一棘手问题的完美解决方案。更多信息:Http-https转换和相对url
