“This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage.”
Undoubtedly, you have seen this message while browsing a site over SSL using Internet Explorer. Chrome, Firefox, Opera, and Safari have similar messages. All the message means is that one or more of the resources referenced in the web page are being served via HTTP instead of HTTPS and that this could compromise security.
Most of the time, the violations come from innocuous image references. But this will make your end-users nervous and it can easily be avoided. If you are a coder, you may have written logic akin to “if this page is secured, then prepend the urls with https, if not, use http”. But there is no real need to do that. You can instead use protocol relative URLs. The solution is simple, instead of something like this:
<img src="<%=Protocol%>://contoso.com/image.png" alt="My Image" />
<img src="//contoso.com/image.png" alt="My Image" />
The details of protocol relative URLs can be found in the meat of Section 4.2 of RFC 3986.
This solution isn’t perfect. There are at least two “side-effects” of using protocol relative URLs:
- Resources could be “loaded twice” before your browser caches them: once when served from an unsecured page (http://) and again when served from a secured page (https://).
- CSS files are “double-loaded” in IE7 and IE8: If you watch the network activity with a tool like Fiddler, you will see that two requests are made for every protocol relative CSS in IE7 and IE8. Fortunately, these browsers are getting older by the minute.
And of course, you would only need protocol relative URLs if your site is switching contexts between HTTP and HTTPS. 🙂
Hope this helps!