If you have an SSL website like AutoRef, you probably already know about mixed-content warnings like the one above. For those unfamiliar, this warning occurs when a page resource, like an image or JavaScript file, is served over a non-SSL channel when the main page was served over SSL.
Why It Matters
It’s important to realize that this warning changes the browser UI. In Chrome, the lock icon changes from a happy green 
to a much-less-happy 
. It also changes the green ‘https‘ back to a grey ‘https‘. These UI changes can change the user’s perception of the security of your site, and could make them trust you less.
Why It Happens
While the scenario in which this happens is pretty specific, it happens far more than it should. The main page is loaded over SSL, and references a resource with a full URL using the http (non-SSL) protocol. If you use path-relative URLs (e.g. /css/home.css) to reference all your assets, you should be fine. But you should probably be using a CDN for your static assets, in which case path-relative URLs are not possible.
There is a Solution
Luckily there is an easy solution: protocol-relative URLs. This underused type of URL isn’t seen very frequently in the wild, but is immensely useful for ensuring you never have to worry about mixed-content warnings. Because they provide a (very) small benefit by shaving 5 bytes your regular URLs, you should start using them today even if your site is not currently using SSL. They are super easy to use, just drop the ‘http:’.
<link rel="stylesheet" type="text/css"
href="http://d2hfzk3haocl4j.cloudfront.net/static/css/home-484a72f22b.less"/>
becomes…
<link rel="stylesheet" type="text/css"
href="//d2hfzk3haocl4j.cloudfront.net/static/css/home-484a72f22b.less"/>
(what’s up with those weird filenames?)
That’s all there is to it! Even if your site is not currently served over SSL, you should start using this type of URL immediately. Later down the road if you need to serve all or part of your site over SSL (the only secure way to do user accounts), it will be much much easier.
Of Course, Then There’s IE…
The most-hated browser in the world strikes again. Turns out there is a bug in IE 7 and 8 where stylesheets referenced with protocol-relative URLs are downloaded twice. This has no effect other than slightly slowing down the page load. IE 7 and 8 have a combined worldwide market share of 14.81% as of August 2012 according to StatCounter. You should look at the browser stats for your own website to get a better idea for your own user population. Is this something you should worry about? Maybe, depends on how much you care about IE users. There’s also a pretty easy solution: explicitly use https when referencing CSS.
Craig Younkins
The problem this DOESN’T solve is that if the resource is not availale over SSL, then this won’t work at all and will show broken links.
I’ve got a project that addresses this by converting any URL to SSL:
http://www.fixweb.co/
Just take whatever URL you want to access, like
http://example.com/test.gif
add the FixWeb.co address in front of it like this:
https://fixweb.co/example.com/test.gif
^^^^^^^^^^^^^^^^^^
and it will return the file over SSL.
It’s not designed for high security file delivery, obviously, but it will get you around a normal Mixed-Content warning.
> There’s also a pretty easy solution: explicitly use https when referencing CSS.
No no no! This is bad, very bad. If you don’t need your content to be encrypted, then all this will do is slow down page loads. SSL handshakes are very slow, so if you’re hosting content from say 4 different domains, this will slow down your page load a noticeable amount than if the entire page was loaded over http.
And if you do need it encrypted, you should explicitly specify https when referencing CSS.