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