Is it safe to use protocol relative URL in email?

Question

There are existing discussion [1] on the use of protocol relative URL in HTML, but how about email?

Will email client, or service providers like Gmail strip or modify pr

Answer 1

No , its not safe to use protocol relative URL in email. because its change protocol so that browser can fetch a resource from whatever protocol the site is telling it to use.

but some email clients (Outlook especially, as usual) won’t try to use HTTP or HTTPS as the protocol. Instead they’ll use the file:// protocol and assume the resource you’re referring to is on the local machine. But it won’t be. So don’t use these in emails. You have to be sure that the server you’re requesting from is capable of serving content over both HTTP and HTTPS. If not you might end up fetching content from an unsecured or nonexistent server port.

IE6 does not know how to handle this. If you care about supporting Internet Explorer 6 then you shouldn’t use these.

IE7-8 support protocol relative URLs but they’ll end up fetching the resource twice. Once from HTTP and once over HTTPS. This can slow things down a bit but the way I see things it’s not much of a problem for anyone except the person using IE7-8 and if you’re using IE you’ve got more important things to worry about.

its browser dependent so its depends what browser you are using GMAIL working fine in crome but not in IE6.

Answer 2

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>

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.

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.

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:///.)

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.

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.