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 protocol relative URL when they are used in HTML email?

[1] Can I change all my http:// links to just //?

Answer 1

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.