A few weeks ago I added some bug fixes for the Subtext blog engine to GitHub. One of the bugs was related to mixed mode content:

My initial fix for this issue was to change references like:

<script type="text/javascript" src="http://ajax.googleapis.com/.../jquery.min.js"></script>

...to detect a secure connection (in which case, specify "https://" instead):

<script type="text/javascript" src="<%= Request.IsSecureConnection ? "https" : "http" %>://ajax.googleapis.com/.../jquery.min.js"></script>

While this worked, Phil pointed out there is a more elegant solution:

Actually, we should simply use a protocol relative URL/network path reference.

For example:

src="//ajax.googleapis.com/..."

That removes the need do use <%= %> blocks here and is cleaner.

I responded that I didn't even know that was possible (before reading Phil's comment, I would have assumed a URL beginning with "//" would be interpreted as a server-relative URL).

Consequently I updated my fix to incorporate Phil's recommendation:

<script type="text/javascript" src="//ajax.googleapis.com/.../jquery.min.js"></script>

This just shows that there is always a valuable lesson to be learned each and every day -- especially in the world of software.

So, why do I bother to blog about this topic this morning? Well, I just discovered a similar bug on the Search page of TechnologyToolbox.com when accessing the site via HTTPS, due to the script reference for Google Site Search:

<script src='http://www.google.com/jsapi' type='text/javascript'></script>

The bug fix for TechnologyToolbox.com will be included in the next release to PROD.

Here are some good resources for understanding more about protocol-relative URLs (as pointed out in the first resource below, these are technically called network-path references according to RFC 3986, but "protocol-relative URL" seems more intuitive):

• The protocol-relative URL
• Using Protocol Relative URLs to Switch between HTTP and HTTPS

Apparently there are some known issues in Internet Explorer 6 with protocol-relative URLs (no surprise there). However, I honestly couldn't care less about IE6 these days. Especially since I occasionally struggle with issues in IE9 that don't occur in Firefox and Chrome -- such as the one pointed out in my previous post.