使用领先的双斜杠来继承URL中的协议有什么缺点吗？即src ="// domain.com"

Question

我有一个样式表从外部域加载图像,我需要它从https://从安全订单页面加载http://从其他页面加载,基于当前的URL.我发现使用双斜杠启动URL会继承当前协议.所有浏览器都支持这种技术吗？

html ex:

<img src="//cdn.domain.com/logo.png" />

css ex:

.class { background: url(//cdn.domain.com/logo.png); }

Answer 1

如果浏览器支持RFC 1808第4节,RFC 2396第5.2节或RFC 3986第5.2节,那么它确实将页面URL的方案用于以"//"开头的引用.

Answer 2

当用于link或者@import,IE7/IE8将根据http://paulirish.com/2010/the-protocol-relative-url/下载文件两次

2014年更新:

现在,每个人都鼓励使用 SSL ,并且没有性能问题,这种技术现在已成为一种反模式.如果您需要的资产在SSL上可用,则始终使用该https://资产.

Answer 3

如果您的网址是在网页上下文之外查看,则会出现一个缺点.例如,位于电子邮件客户端(例如,Outlook)中的电子邮件实际上没有URL,当您查看包含协议相对URL的邮件时,根本没有明显的协议上下文(邮件本身是独立的)用于获取它的协议,无论是POP3,IMAP,Exchange,uucp还是其他什么)所以URL没有相关的协议.我没有调查与电子邮件客户端的兼容性,看看他们在提供丢失的协议处理程序时所做的事情 - 我猜大多数人都会猜测http.Apple Mail拒绝让您输入没有协议的URL.它类似于相对URL在电子邮件中不起作用的方式,因为同样缺少上下文.

其他非HTTP上下文中也可能出现类似问题,如推文,短信,Word文档等.

更一般的解释是匿名协议URL不能孤立地工作; 有必须是一个相关背景.在一个典型的网页中,以这种方式引入脚本库是很好的,但任何外部链接都应该始终指定一个协议.我确实尝试了一个简单的测试:在我尝试过的所有浏览器中//stackoverflow.com映射file:///stackoverflow.com,所以它们真的不能自己工作.