Preventing secure/insecure errors by using protocol relative URLs for image source

Question

Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.

For example linking an image like:

<img src="//domain.com/img.jpg" />

instead of:

<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />

In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.

EDIT i've seen it throw errors when using PHP's getimagesize function.

Hammer

Answer 1

Found an interesting gotcha for the use of protocol relative URLs:

You have to be careful to only use this syntax in pages destined for browsers. If you put it in an email, there will be no base page URL to use in resolving the relative URL. In Outlook at least, this URL will be interpreted as a Windows network file, not what you intended.

from here

Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.

more info from here:

A relative URL without a scheme (http: or https:) is valid, per RTF 3986: Section 4.2. If a client chokes on it, then it's the client's fault because they're not complying with the URI syntax specified in the RFC.

Your example is valid and should work. I've used that relative URL method myself on heavily trafficked sites and have had zero complaints. Also, we test our sites in Firefox, Safari, IE6, IE7 and Opera. These browsers all understand that URL format

Hammer

Answer 2

IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.

Jampacked

Answer 3

The following should be considered when using Protocol-Relative URLs:

1) All modern browsers support this feature.

2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.

3) Internet Explorer 6 does not support this feature.

4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.

Kayleen