有什么理由不使用 src=“//domain.com/file.js”，这是协议动态的？
在我的一些电子商务应用程序中，当我需要引用我想要包含的外部托管脚本时，我开始使用 src="//domain.com/file.js"。在我的电子商务应用程序中，并非所有页面实际上都使用 https，因为并非每个页面都有表单。
我想知道总是使用它是否真的有什么缺点，因为它也是 http 的快捷方式，并且您始终可以避免不安全的 IE 警告。
In some of my E-Commerce applications I've started using src="//domain.com/file.js" in cases where I needed to reference externally hosted scripts that I wanted to include. In my E-Commerce applications not all pages actually use https as not every page has a form.
I'm wondering if there's really any disadvantage to always using this, as it's also a shortcut to http and you can always, always avoid the not-secure IE warning.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您的目的是从与页面加载相同的协议加载资源，那么使用它是实现它的完美方法。但是，即使您的页面当前在
https下提供服务，您也可能需要从http加载一些资源（假设资源仅在http上提供） > 或者您希望通过不加密页面上的每个图像来减少服务器的负载）。在这种情况下，您需要显式指定协议名称。If your intent is to load the resources from the same protocol as the page is loaded with, then using it is a perfect way to accomplish it. However, you may need to load some resources from
httpeven when your page is currently served underhttps(let's say the resouce is served only onhttpor you prefer to reduce load on your server by not making it encrypt every image on the page). In that case, you need to explicitly specify the protocol name.@Mehrdad_Afshari 从 HTTP 获取资源可能会打开来自 MITM 攻击的注入漏洞，而 HTTPS 是专门用来保护您免受攻击的。经典示例是通过 HTTP 获取脚本，但过去存在错误（请参阅 http://www.adambarth.com/papers/2009/barth-caballero-song.pdf），可能允许 MITM 通过 IMG 标签注入脚本。 ForceHTTPS 工作中特别推荐了与方案相关的链接 (https://crypto.stanford.edu/forcehttps/< /a>）因为这样的担忧。
@Mehrdad_Afshari Sourcing resources from HTTP can open up injection vulnerabilities from MITM attacks that HTTPS is specifically supposed to protect you from. Classic example is sourcing a script over HTTP, but there have been bugs in the past (see http://www.adambarth.com/papers/2009/barth-caballero-song.pdf) that could allow script injection through an IMG tag by a MITM. Scheme-relative links were specifically recommended in the ForceHTTPS work (https://crypto.stanford.edu/forcehttps/) because of concerns like this.