Attempting to use HTTP resources on an secure web page is a guaranteed way to annoy IE users, because it generates a confusing security warning for anyone running with the default IE settings. Our previous post on fixing this message in IE 8 is responsible for more than 50% of the traffic and comments on this blog. Hopefully, Microsoft will take note and change this in a future version of IE.

In the meantime, it’s important to avoid this warning by ensuring that every image, CSS and Javscript file on a secure page is accessed using HTTPS. For content on the same domain it’s quite straightforward – you just need to use relative URLs. A relative URL contains the ‘offset’ URL that needs to be applied to the page’s absolute URL in order to find a resource.

For example, here’s a screen shot from HttpWatch accessing our home page over HTTPS:

Searching for one of the images in HttpWatch shows that it was specified with a relative URL and the switch to HTTPS happened automatically:

A problem arises though, if you attempt to access a resource from a different domain because you can’t use the simple path-relative URL to access the resource. This often happens when you attempt to use a third party service such as Google Analytics or a third party Ajax library CDN.

Google Analytics solves the problem with its external javascript file by recommending the use of this code to dynamically switch protocols:

var gaJsHost = (("https:" == document.location.protocol) ?
    "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost +
    "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));

Another solution is to hard code the external resource with an HTTPS based URL regardless of how the containing page is accessed. This avoids any security warnings in IE, but does mean that the HTTPS resource download will consume more CPU resources in cases where the HTTP download would have been sufficient.

The solution we prefer to use is to specify a Protocol Relative URL. It’s just like a regular URL except that you leave out the protocol prefix. For example, when Microsoft recently announced SSL support for their Ajax CDN the recommended script tag for secure pages was:

<script src=”https://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js” type=”text/javascript”></script>

But if you change this to a protocol relative URL:

<script src=”//ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js” type=”text/javascript”></script>

You get the automatic use of HTTPS on secure pages and avoid the overhead of HTTPS on non-secure pages.

We put together a simple jQuery demo page using this technique. In HttpWatch, you can see that the resource is automatically downloaded with HTTP for non-secure access:

and HTTPS with secure access:

One downside of this approach is that there will be separate cached copies for both the HTTP and HTTPS based URLs. If a vistor to your site first uses a non-secure HTTP based URL and then switches to HTTPS they would have to download fresh copies of resources that had already been accessed over HTTP.

UPDATE: Steve Souders pointed out another downside to using protocol relative URLs; they cause a double download of CSS files in IE 7 & 8.

You can check SSL/TLS configuration our new SSL test tool SSLRobot . It will also look for potential issues with the certificates, ciphers and protocols used by your site. Try it now for free!

A significant change in IE 8 was the increase in the number of active connections per hostname from two to six. This allowed pages with many embedded resources (e.g. images, CSS or JavaScript) to be loaded much more quickly because more requests could be executed in parallel; reducing queuing and the amount of Blocked time seen in HttpWatch:

Recently, we noticed that IE 8 sometimes reverts back to the earlier limit of two connections per hostname. The connectivity enhancements in IE 8 are documented as requiring broadband connections:

But we were seeing the number of active connections being reduced over a fast broadband connection.

Eventually, we found that this occurred whenever a VPN connection was active. Suprisingly, the VPN connection was not actually being used by IE 8 because it did not have the default gateway flag set:

Unchecking this option ensures that only traffic for the target network goes over the VPN connection. Other traffic, such as access to public internet web sites, will go through your normal network connection even when the VPN is connected.

It appears that the dialup/broadband detection in IE 8 is too simplistic. If you are using any non-network card based connection, including VPNs or connections through high speed 3G modems, then IE 8 assumes you are using a slow dialup connection. This applies even if no network traffic from IE 8 goes through the connection.

The effect on performance can be significant. For an unoptimized site that requires lots of round-trips, page load time may be increased by 50% or more. Here’s a screen shot from HttpWatch of this blog being loaded in IE 8:

With a Windows VPN client connected the load time nearly doubles due to the change in connection limiting:

This is definitely something to watch out for if you are working remotely using a VPN connection into your office. Fortunately, there are some simple workarounds:

• Use Firefox as it is not affected by connection speed. It always uses up to six connections per hostname.
• Use a third party VPN client (e.g. OpenVPN) instead of the standard Windows VPN client. IE 8 shouldn’t detect this as a dialup connection.

We have previously written about the pointless and confusing ‘Do you want to view only the webpage content that was delivered securely‘ message in IE 8. It is displayed by default when a secure web page attempts to use non-secure content such as images, javascript or CSS. That post has been so popular that it attracts 40% of the traffic to this blog.

The IE 8 mixed content dialog is pointless because 99.9% of web users just want it to go away and let them get on with what they were doing. For the 0.1% of web surfers who do care, it is confusing because of the way it is worded:

The blog post described how you can disable this warning and from the comments it looks like many users are now doing this.

Even if you do this, IE still silently performs the check and hides the re-assuring padlock icon that you normally see on HTTPS pages:

This could be disturbing for anyone on a checkout page who is about to enter their credit card details. So if you’re web site developer you really need to avoid using mixed content – even for users who have disabled this warning. Firefox has the mixed content warning turned off by default. Let’s hope Microsoft do the same turn in the next version of IE.

You can normally fix the mixed content warning by ensuring that all the content on a secure page is served up with HTTPS. In HttpWatch you can quickly check a page by using a forced refresh to look for URLs starting with ‘http;’ :

However, a customer contacted us recently because they were still getting the mixed content warning even though they had no HTTP URLs on their secure page. After some investigation it was found that this commonly used javascript technique was causing the problem:

// Causes mixed content message in IE on a secure page
document.write("<script id="__ie_onload" src="javascript:void(0)"></script>");
document.getElementById("__ie_onload").onreadystatechange = function()
{
     if (this.readyState == "complete") domReady();
};

It’s a trick used to emulate a DOMContentLoaded event in IE.  A security warning occurs because of the use the “javascript:” protocol even though no download occurs.

The fix is to use //: in the src attribute in the same way as popular javascript libraries such as jQuery and prototype. This does cause a harmless ERROR_INVALID_URL entry in HttpWatch, but it avoids the mixed content message:

// Does not cause a mixed content message in IE on a secure page
document.write("<script id="__ie_onload" src="//:"></script>");
document.getElementById("__ie_onload").onreadystatechange = function()
{
     if (this.readyState == "complete") domReady();
};