Relative URL and HTTPS protocol

All of you are familiar with such browser warning message:


This usually happens when you load the page via HTTPS protocol, but some of the page’s resources were requested by HTTP protocol. It’s not an option to simply disable warning in a browser, because such references create vulnerabilities that put the privacy and integrity of an otherwise-secure page at risk. It could be achieved by modifying insecure content in transit. In addition, regular internet users could be scared by such message and leave the page.

Client Side Protocol Detection

This is why web developers should take care of the issue by following next rule: within HTTPS page never include a reference to HTTP-delivered resource. But things became more complicated with pages which could be accessed by HTTP or by HTTPS. In this case you don’t know in advance what protocol to use. Another good example is to have some widget, which could be included in third-party pages and some of them are secure while others – not. Google Analytics team solved this problem by the following JavaScript snippet:

<script type="text/javascript"> 
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); 
document.write(unescape("%3Cscript src='" + gaJsHost + "' type='text/javascript'%3E%3C/script%3E")); 

The script analyzes what protocol is used on a current page and creates URL to Google Analytics script by using the same protocol (in addition it changes subdomain, but it is not a topic of discussion).

Protocol-relative URLs

Another approach is to use protocol-relative URLs:

<script type="text/javascript" src=”//” />

If page-container was delivered via HTTPS protocol, the resource will be delivered by HTTPS as well, otherwise HTTP protocol will be used.

More interestingly, this approach is valid for CSS as well:

.foo {
     background-image: url(//;

One of disadvantages of protocol-relative URLs was found by Steve Souders. He discovered that IE7 and IE8 will download stylesheets twice when protocol is missing.

Another interesting disadvantage is related to IE6 (although who cares about this browser?):


Browser will show error message displayed above, because IE6 doesn’t support Server Name Indication in the HTTPS stack.

Use HTTPS for Resources all the time

Alternatively you may reference all your page resources via HTTPS, regardless of how the page was requested. It will save you from error message, but may cause slower page load because of HTTPS handshake.

In general, using different protocols for page resources has one disadvantage by itself – there will be separate cached copies for both HTTP and HTTPS based URLs. So this is a good topic to investigate.

So choose your protocol-based strategy carefully!


UPDATE: beaware, such script tag construction may cause mixed content error as well

<script type="text/javascript" src="javascript:void(0)" />