Question

可能重复：
Is there any downside for using a leading double slash to inherit the protocol in a URL? i.e. src=“//domain.com”

我在许多地方看到了以下逻辑，f.ex分析脚本：

script.src = ('https:' == document.location.protocol ? 'https' : 'http') +
    '://example.com/cdn.js';

但据我所知，您也可以这样做：

script.src = '//example.com/cdn.js';

它应该使用当前使用的任何协议。或者我错过了什么？什么被认为是“最佳实践”？

我不是在寻找浏览器兼容性答案，谷歌已经为CDN脚本推荐了//，所以不应该这样。

这是一个小提琴，但它并没有说它似乎在这个设置中起作用：http://jsfiddle.net/6ZGyb/

Answer 1

一些背景知识：

其他JavaScript protocol包装器通常用于确保所有浏览器支持此类relative path URL。 无论如何，你认为大多数现有浏览器正确处理这些网址是正确的，但是为了能够以休息的心态入睡，一般认为并非全部用户代理访问您的网页与我们期望的一样精确（或支持RFC 1808第4节，RFC 2396第5.2节或RFC 3986第5.2节正如Is there any downside for using a leading double slash to inherit the protocol in a URL? thread中已经提到的那样@Bruno在评论中指出了

兼容性问题：

想象一下，包含此类相对路径的内容可以访问'out-of-context'，例如在电子邮件客户端。在这种情况下，这些相对路径可能以错误的方式被解析为它们的完全限定路径，并且导致各种问题，从用户不能正确地看到内容，到访问他们实际上不应该的内容。为了避免任何此类问题，相对路径的使用应始终限于上下文情况，其中父文档（开启应用程序）的解析器可以确定相关资源的完整绝对路径。您只应指望相对路径在被相同或兼容的协议访问时才能正常工作。

安全问题：

提出的另一个可能的问题是：

通过各种交换访问（解析的URL）父文档内容，可以以任何方式利用这些相对协议URL 协议，如果这样的JavaScript包装器有用的目的转移这种访问。

official IANA registered URL schemes 的（长）列表表明，开发人员可能会使用很多可能令人担忧的交换协议，但是 JavaScript对用户没有太大作用不支持JavaScript（或被用户禁用）的代理。考虑到这一点，我的答案必须是 - 否（对于使用其他协议的'JavaScript保护访问部分）。

至于引起关注的其余部分（'可以以任何方式利用此类相关协议网址），答案取决于考虑的程度在设置服务于任何此类内容的Web服务器时，它是否支持/处理此类请求（如果不支持/处理此问题），以及在部署之前考虑了哪些可能的攻击/内容盗窃传播。换句话说，这是一个Web服务器管理问题，当然也不是Web设计人员/程序员可以/应该回答的问题。每个最终用户可访问的协议都应该有自己的一组安全协议。< / p>

使用//而不是协议

1 个答案: