在电子邮件中使用协议相对URL是否安全？ [英] Is it safe to use protocol relative URL in email?
问题描述
现在有关于HTML中使用协议相对URL的讨论[1]，但电子邮件如何？
There are existing discussion [1] on the use of protocol relative URL in HTML, but how about email?
将电子邮件客户端或Gmail服务提供商或在HTML电子邮件中使用时修改协议相对URL？
Will email client, or service providers like Gmail strip or modify protocol relative URL when they are used in HTML email?
推荐答案
我通过Gmail发送了一封电子邮件，内容如下：
I sent an email through Gmail with this content:
<a href="//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js">link</a>
并且它未被修改。当我右键单击该链接以复制链接地址时，Chrome预先添加了 https：（因为Gmail使用安全HTTP），但是当我检查了元素的HTML时，显示了< a> 标签，因为我已经写过。
and it was received unmodified. When I right-clicked on the link to copy the link address, Chrome prepended https: to it (since Gmail uses secure HTTP), but when I inspected the element's HTML, it showed the <a> tag as I had written it.
电子邮件服务器更改电子邮件的内容
It's not normal for email servers to change the contents of emails.
省略协议旨在让Web浏览器在相同内容的安全和不安全版本之间进行选择。如果您通过https加载页面，并且包含以http开头的src的图像，则浏览器会警告用户加载不安全的内容是一个令人困惑和令人担忧的消息。如果您通过http加载页面，并且包含以https开头的src的图像，则可以防止其他效率低下的缓存。
Omitting the protocol is intended to let a web browser choose between secure and insecure versions of the same content. If you load a page via https and it contains an image with an src beginning in http, the browser warns the user that it is dangerous to load insecure content -- a confusing and worrying message. If you load a page via http and it contains an image with an src beginning in https, that prevents caching among other inefficiencies.
妥协是允许浏览器加载内容与安全性匹配的网页加载它 - 效率的不安全页面;完全保证安全页面的安全性。
The compromise is to allow the browser to load content with security matching the page that loads it -- efficiency for an insecure page; complete guarantee of security for a secure page.
但电子邮件客户端始终警告嵌入式内容（图像，脚本，...），意思是省略协议没有任何好处
But an email client always warns about embedded content (images, scripts, ...), meaning omitting the protocol has no benefit.
此外，非浏览器电子邮件客户端没有开始的协议。它下载信息，然后从磁盘加载它。如果您真的想让电子邮件客户端选择加载其加载电子邮件的安全级别的嵌入式内容，则可以让客户端在同一台计算机上查找信息。 （他们实际上会通过假设 // 意味着 file：/// 。）
Furthermore, a non-browser email client doesn't have a protocol to begin with. It downloads information and then loads it from the disk. If you really want to let the email client choose to load embedded content with the security level with which it loaded the email, you'd let the client look for the information on the same computer. (They'll actually do that by assuming // means file:///.)
在电子邮件中放置 // URI是否安全？我会说没有意义因此，没有成为非浏览器客户端处理它的标准方式，这意味着您正在查看未定义的行为。
So is it safe to put a // URI in an email? I'd say it doesn't make sense; therefore, there has not become a standard way for non-browser clients to handle it, meaning you're looking at undefined behavior.
更好地选择基于由URI识别的信息的敏感度。是财务数据图表吗？使用https。这是一个lolcat吗？使用http。
Better to choose the protocol based on the sensitivity of the information identified by the URI. Is it a chart of proprietary financial data? Use https. Is it a lolcat? Use http.
这篇关于在电子邮件中使用协议相对URL是否安全？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
