Now that IE 9 has been released and is widely used, we wanted to follow up on some of our previous IE related blog posts to see how things have changed.

1. Using a VPN Still Clobbers IE 9 Performance

We previously reported about the scaling back of the maximum number of concurrent connections in IE 8 when your PC uses a VPN connection. This happened even if the browser traffic didn’t go over that connection.

Unfortunately, IE 9 is affected by VPN connections in the same way:

There is a subtle difference though. IE 8 would dynamically change it’s behavior as you connected or disconnected the VPN. In IE 9 it just seems to look for dialup or VPN connections at startup to determine the connection behavior for the rest of the session. For example, any active dial-up or VPN connection found when IE 9 starts will cause it to use a maximum of two connections per hostname. This limit remains until IE 9 is closed regardless of whether the dialup or VPN connections remain active.

2. IE 9 Mixed Content Warning Improved But Needs PRG

In previous blog posts we’ve covered the mixed content warning issues in IE and the problems it causes. It got even worse in IE 8 as the modal dialog was worded in a way that caused a great deal of confusion with no apparent benefit for ordinary web users.

A big step forward was taken in IE 9 by using a modeless dialog. It displays a simple message to indicate that not all the content was downloaded because some resources used unencrypted HTTP connections:

You can now ignore the message or simply click on the X to dismiss the warning.

Watch out for the ‘Show all content’ button though. Previous mixed content warning dialogs just blocked the download of non-secure content until you clicked the appropriate button. In IE9 ‘Show all content’ causes a complete refresh of the page. If your page was the result of a POST (e.g. form submit) and you didn’t use the POST-Redirect-GET pattern then the user will see this dialog instead of the updated page:

3. Another Reason to Favor IE 9 32-bit over IE 9 64-bit

We previously wrote about why IE 8 64-bit was the not the default version of IE on Windows Vista 64-bit. This was because commonly used plugins such as Flash, Silverlight and Java did not support 64-bit.

IE 9 32-bit remains the default version used on Windows 7 x64 for exactly the same reason:

However, there’s another reason to favor IE 9 32-bit. That’s because IE 9 ships with an advanced JIT compiler that compiles JavaScript into native assembly language code for improved performance. However, this JIT compiler only supports the x86 instruction set at the moment and therefore most Javascript bench marks run much more quickly in IE 9 32-bit than in the 64-bit version.

Here’s what ZDNet had to say about the 32-bit and 64-bit versions of IE 9:

OK, so what conclusions can we draw? Well, let’s begin with the obvious and say that Internet Explorer 9 64-bit is an absolute dog when it comes to JavaScript performance. This is to be expected given that IE 9 64-bit is using an older, slower JavaScript engine, while IE 9 32-bit was using the newer, more efficient Chakra JIT.

4. IE 9 Pinned Sites Are Great But They Disable All Add-ons

One nice feature of IE 9 is the ability to create pinned sites in Windows 7. A pinned site sits on the taskbar like a pinned application and can be quickly accessed when required. The web site can also provide customizations such as jump lists.

Unfortunately, all add-ons including HttpWatch are disabled when you do this. The reason given for this is:

The reason Add-ons don’t run on pinned sites is that we wanted to remove any non-site specific extension points (like toolbars and BHOs) from altering the original browsing experience created by the site.

It doesn’t seem unreasonable to block a debugging tool like HttpWatch, but it’s a shame that productivity tools such as Roboform are not available.

Stoyan Stefanov, the creator of smush.it, architect of YSlow 2.0 and engineer at Facebook, has written an excellent three part guide to controlling HttpWatch from PHP:

• Automating HttpWatch with PHP
• Automating HttpWatch with PHP #2
• Automating HttpWatch with PHP #3

He’s even published a class that wraps the HttpWatch API and makes it easier to use from PHP.

In the rest of this blog post we wanted to follow up on a few points mentioned in Stoyan’s blog posts. These items don’t just apply to PHP. You may find them useful when automating HttpWatch using other languages such as C# or Ruby.

Hiding the IE window

The ‘A better experience in IE’ section of Automating HttpWatch with PHP shows how you can hide the IE browser window during tests by separately creating IE and attaching HttpWatch to it.

It’s also possible to do this using the Container property without having to separately create and attach to IE:

$controller = new COM("HttpWatch.Controller");
$plugin = $controller->IE->New();
$browser = $plugin->Container; // Only works with IE
$browser->Visible = false;

If you do decide to do this in order to stop windows popping up during a test please bear these points in mind:

1. Orphaned instances of iexplore.exe will be left running in the background if your script ever terminates before calling CloseBrowser.
2. In IE 8 and earlier, HttpWatch will not record a Render Start event because the hidden IE window does not get updated by Windows. However, the event will be recorded in Firefox 3.5+ and IE 9.
3. Your performance measurements may not directly match user experience. It’s possible that current or future browsers may avoid certain rendering and processing actions if they detect that the output will not be in a visible window. For that reason, we recommend running tests in visible browser windows on a normal interactive desktop either on a physical machine or VM. Also, viewing a browser test through Remote Desktop is likely to have a significant negative impact on performance as the graphics and text making up the page have to be transferred over the network.

Opening the HttpWatch Plugin Window

It’s often handy to open the HttpWatch window in the browser when you are developing an automation script so that you can check that it is working as expected.

The OpenWindow method allows you to do this and specify whether you want the HttpWatch window docked or undocked. For example, here is the PHP code to open HttpWatch as an embedded window in the browser:

...
// Open docked HttpWatch window in browser
$plugin->OpenWindow(false);
...

Handling Differences Between HttpWatch Basic and Professional Editions

In part 3, Stoyan mentions using try-catch to handle the errors that occur when attempting to access data that is restricted in HttpWatch Basic Edition. While this is a valid approach, there is a risk of hiding other errors that might be occurring that are not due to the restrictions in HttpWatch Basic edition.

There are a couple of properties in the HttpWatch automation interface that help you handle the differences. The first is the IsBasicEdition property on the Controller class.

For example, here’s a high level test in PHP:

$controller = new COM("HttpWatch.Controller");
if ( $controller->IsBasicEdition )
{
    echo "\nThis test requires HttpWatch Professional Edition";
}

At a lower level, you can also check each request to see if it has been restricted using the IsRestrictedURL property:

...
if ( $entry->IsRestrictedURL)
{
    // Goes here in HttpWatch Basic Edition for URLs outside Alexa Top 20
    echo "\nSome of the properties for this request are restricted";
}
else
{
    // Goes here in HttpWatch Basic Edition for URLs in Alexa Top 20
    // or in HttpWatch Professional Edition for any URL
    echo "\nAll the properties of this request are available";
}
...

Myth #7 – HTTPS Never Caches

People often claim that HTTPS content is never cached by the browser; perhaps because that seems like a sensible idea in terms of security. In reality, HTTPS caching is controllable with response headers just like HTTP.

Eric Lawrence explains this succinctly in his IEInternals blog:

It comes as a surprise to many that by-default, all versions of Internet Explorer will cache HTTPS content so long as the caching headers allow it. If a resource is sent with a Cache-Control: max-age=600 directive, for instance, IE will cache the resource for ten minutes. The use of HTTPS alone has no impact on whether or not IE decides to cache a resource. (Non-IE browsers may have different default behavior for caching of HTTPS content, depending on which version you’re using, so I won’t be talking about them.)

The slight caveat is that Firefox will only cache HTTPS resources in memory by default. If you want persistent caching to disk you’ll need to add the Cache-Control: Public response header.

This screenshot shows the contents of the Firefox disk cache and the Cache-Control: Public response header in HttpWatch:

Myth #6 – SSL Certificates are Expensive

If you shop around you can find SSL certificates for about $ 10 a year or roughly the same cost as the registration of a .com domain for a year.

(UPDATE: you can get domain validated SSL certificates for free. See comment #1)

The cheapest certificates don’t have the level of company verification provided by the more expensive alternatives but they do work with nearly all mainstream browsers.

Myth #5 – Each HTTPS Site Needs its Own Public IP Address

With the pool of IPv4 addresses running low this is a valid concern and it’s true that only one SSL certificate can be installed on single IP address. However, if you have a wildcard SSL certificate (from about $ 125 yr) you can have as many sub-domains as you like on a single IP address. For example, we run https://www.httpwatch.com, http://www.httpwatch.com and https://store.httpwatch.com on the same public IP address:

On IIS 7 there is a trick though to making this work. After adding a certificate you need to find it and rename it in the certificate manager so that the name starts with a *. If you don’t do this you cannot edit the hostname field for an HTTPS binding:

UPDATE: UCC (Unified Communications Certificate) supports multiple domains in a single SSL certificate and can be used where you need to secure several sites that are not all sub-domains.

UPDATE #2: SNI (Server Name Indication) allows multiple certificates for different domains to be hosted on the same IP address. On the server side it’s supported by Apache and Nginx, but not IIS. On the client it’s supported by IE 7+, Firefox 2.0+, Chrome 6+, Safari 2.1+ and Opera 8.0+.  See comment #4 and comment #5.

UPDATE #3: IIS 8 now supports SNI

Myth #4 – New SSL Certificates Have to be Purchased When Moving Servers or Running Multiple Servers

Buying an SSL certificate involves:

1. Creating a CSR (SSL Certificate Signing Request) on your web server
2. Purchasing the SSL certificate using the CSR
3. Installing the SSL certificate by completing the CSR process

These steps are designed to ensure that the certificate is safely transferred to the web server and prevents anyone from using the certificate if they intercept any emails or downloads containing the certificate in step 2).

The result is that you cannot just use the files from step 2) on another web server. If you want to do that you’ll need to export the certificate in other format.

In IIS you can create a transferrable .pfx file that is protected by a password:

This file can be imported onto other web servers by supplying the password again.

Myth #3 – HTTPS is Too Slow

Using HTTPS isn’t going to make your site faster (actually it can – see below) but the overhead is mostly avoidable by following the tips in our HTTPS Performance Tuning blog post.

The amount of CPU resource required to encrypt the data can be reduced by compressing textual content and is usually not a significant on servers with modern CPUs.

Extra TCP level round-trips are required to setup HTTPS connections and some additional bytes have to be sent and received. However, you can see in HttpWatch that this overhead is small once the HTTPS connection has been made:

The initial visit to an HTTPS site is somewhat slower than HTTP due to the longer connection times required to setup SSL. Here’s a time chart of the page load for an HTTP site recorded in HttpWatch:

And here’s the same site accessed over HTTPS:

The longer connection times caused the initial page load to be about 10% slower. However, once the browser has active keep-alive HTTPS connections a subsequent refresh of the page shows very little difference between HTTP and HTTPS.

First, the page refresh with HTTP:

and then with HTTPS:

It’s possible that some users may even find that the HTTPS version of a web site is faster than HTTP. This can happen if they sit behind a coporate HTTP proxy that normal intercepts, examines and records web traffic. An HTTPS connection will often just be forwarded as a simple TCP connection through the proxy because HTTPS traffic cannot be intercepted. It’s this bypassing that can lead to improved performance.

UPDATE: A blog post by F5 challenges the claim the CPU overhead of SSL is no longer significant, but most of their arguments are refuted in this follow up.

Myth #2 – Anything can go in Cookies and Query Strings with HTTPS

Although, a hacker cannot intercept a user’s HTTPS traffic on the network and read their cookie or query string values directly, you still need to ensure that their values can’t be easily predicted.

For example, one of the early UK banking sites used simple counter based numeric values for the session id:

A hacker could use a dummy account to see how this cookie worked and find a recent value. They could then try manipulating the cookie value in their own browser to hi-jack other sessions with nearby session id values.

Query string values are also protected on the network by HTTPS but they can still leak their values in other ways. For more details see How Secure Are Query Strings Over HTTPS .

Myth #1 – My Site Only Needs HTTPS for the Login Page

This is a commonly held view. The theory being that HTTPS will protect the user’s password during login but HTTPS is not needed after that.

The recently released Firesheep add-on for Firefox demonstrated the fallacy of this approach and how easy it is to hi-jack someone’s else session on sites like Twitter and Facebook.

The free public WiFi in a coffee shop is an ideal environment for session hi-jacking because:

• The WiFi network doesn’t normally use encryption so it’s very easy to monitor all traffic
• The WiFi network probably uses NAT through a single IP address to access the internet. This means that a highjacked session appears to come from the same network address as the original login

There are lots of examples of this approach to security. For example, by default the Twitter signin page uses HTTPS but it then switches to HTTP after setting up the session level cookies:

HttpWatch warns that these cookies were setup on HTTPS but the Secure flag wasn’t used to prevent them being used with HTTP:

Potentially someone in a coffee shop with Firesheep could intercept your twitter session cookies and then hi-jack your session to start tweeting on your behalf.

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!