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:
jQuery references need to specify "https://" (not "http://") when
browsing Subtext pages using HTTPS
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.