用<script src =“http：// …”>replacehttp：//是否有效？
我有以下元素：
<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:
这似乎在我testing过的任何地方都能正常工作，但是在任何情况下，它都不起作用。
根据RFC 3986：“统一资源标识符（URI）：通用语法”（第4.2节） ，没有scheme（http：或https :)的相对URL是有效的。 如果一个客户端扼杀它，那么这是客户端的错，因为它们不符合在RFC中指定的URI语法。
你的例子是有效的，应该工作。 我已经在stream量很大的网站上使用了这种相对的URL方法，并没有任何投诉。 此外，我们在Firefox，Safari，IE6，IE7和Operatesting我们的网站。 这些浏览器都了解URL格式。
这是保证在任何主stream浏览器（我不考虑浏览器低于0.05％的市场份额考虑）工作。 哎呀，它在Internet Explorer 3.0中工作。
RFC 3986将URI定义为由以下部分组成：
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment
在定义相对URI（ 第5.2节 ）时，可以忽略任何这些节，总是从左边开始。 在伪代码中，它看起来像这样：
result = "" if defined(scheme) then append scheme to result; append ":" to result; endif; if defined(authority) then append "//" to result; append authority to result; endif; append path to result; if defined(query) then append "?" to result; append query to result; endif; if defined(fragment) then append "#" to result; append fragment to result; endif; return result;
您所描述的URI是一个无scheme的相对URI。
有没有任何情况下，它不工作？
如果父页面是从file://加载的，那么它可能不起作用（它会尝试获取file://cdn.example.com/js_file.js ，这当然也可以在本地提供）。
许多人称这是一个协议相对URL。
它导致在IE 7和8中CSS文件的双重下载 。
在这里我重复HTML的隐藏function的答案：
使用独立于协议的绝对path：
<img src="//domain.com/img/logo.png"/>如果浏览器正在通过HTTPS查看SSL中的页面，则会使用https协议请求该资产，否则将使用HTTP请求该资源。
这可以防止在IE中出现可怕的“本页包含安全和非安全项目”错误消息，将您的所有资产请求保留在相同的协议中。
警告：在样式表的
<link>或@import上使用时，IE7和IE8 下载文件两次 。 但是，所有其他用途都很好。
离开协议是完全有效的。 这个URL规范多年来一直很清楚，我还没有find一个不理解它的浏览器。 我不知道为什么这个技术不是更好的了解; 它是跨越HTTP / HTTPS边界的棘手问题的完美解决scheme。 更多这里： http-https转换和相对URL
有没有任何情况下，它不工作？
只是把这个混在一起，如果你正在本地服务器上开发，它可能无法工作。 您需要指定一个scheme，否则浏览器可能会认为src="//cdn.example.com/js_file.js"是src="file://cdn.example.com/js_file.js" ，将会中断因为你不是在本地托pipe这个资源。
Microsoft Internet Explorer似乎对此特别敏感，请参阅此问题： 无法在本地主机上的Internet Explorer（WAMP）中加载jQuery
您可能总是试图find一个适用于所有环境的解决scheme，并且所需的修改量最less。
HTML5Boilerplate使用的解决scheme是在资源未正确加载时有一个回退，但只有在合并检查时才有效：
<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在决定弃用协议相对URL后，现在使用<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js ，参见[here] [3] 。
遵循gnud的参考， RFC 3986第5.2节说：
如果scheme组件被定义，指示引用以scheme名称开始，则引用被解释为绝对URI，并且我们完成了。 否则，引用URI的scheme是从基URI的scheme组件inheritance的 。
所以//是正确的:-)
是的，这是在RFC 3986第5.2节中logging的：
（编辑：哎呀，我的RFC参考已经过时了）。
正如其他答案所述，这确实是正确的。 不过，你应该注意到，一些networking爬虫将通过在你的服务器上请求它们，如同一个本地URL一样，为这些爬虫设置404s。 （他们无视双斜线，把它当作一个斜线）。
您可能需要在您的networking服务器上设置一个规则来捕获这些规则并redirect它们。
例如，用Nginx，你可以添加如下内容：
location ~* /(?<redirect_domain>((([az]|[0-9]|\-)+)\.)+([az])+)/(?<redirect_path>.*) { return 301 $scheme:/$redirect_domain/$redirect_path; }
但请注意，如果在URI中使用句点，则需要增加特殊性，否则将最终将这些页面redirect到不存在的域。
此外，这是一个相当大规模的正则expression式来运行每个查询 – 在我看来，这是值得惩罚不合规的浏览器与404s超过（略）性能打击大多数兼容的浏览器。
当使用//somedomain.com作为JS文件的引用时，我们在日志中看到404错误。
导致404s的引用出现如下所示：ref：
<script src="somescript.js" />
404请求：
http://mydomain.comsomescript.js
有了这些定期在我们的Web服务器日志中显示，可以肯定地说：所有的浏览器和机器人不遵守RFC 3986第4.2节。 最安全的select是尽可能包括协议。
我在html5-boilerplate上看到的模式是：
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script> <script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>
它运行在不同的计划，如http ， https ， file 。
