SSL handshake timings are now displayed in Firefox:
and in-depth information about the SSL protocol used by each connection:
We’ve also made some other SSL related improvements that are available in the Firefox/IE plugins and the HttpWatch Studio log file viewer. The first is that SSL information can now be added as columns in the main request grid:
There’s also a new warning that can be used to highlight HTTPS connections that have potential vulnerabilities:
Mozilla Firefox 13 was released today and includes a significant performance related feature. By default, it now uses the SPDY protocol with any supporting web site.
The SPDY protocol was developed as part of Google’s ‘Lets make the web faster’ initiative to overcome these performance related problems in HTTP:
Item 1) is particularly significant as the round trip time to the server has a large impact on the amount of throughput that can be achieved on an HTTP connection. The SPDY protocol overcomes these problems by adding a multiplexing and header compressing layer between SSL and HTTP:
Although, few companies currently use SPDY it is now enabled on all Google servers that use HTTPS. For example, if you access Gmail or a secure version of the Google search page with Google Chrome or Firefox 13+ you will be using SPDY.
This also applies to any web components served by Google over HTTPS. For example, if your secure site uses the Google Ajax libraries or Google Analytics these will be served with SPDY when possible.
When we updated HttpWatch with Firefox 13 support, we also added SPDY support because it will now be frequently used due to Google’s influence on the web.
The main difference you see in HttpWatch with SPDY is that it displays the SPDY stream ID on the Overview page:
The Stream tab now shows the raw SPDY request and response messages. The compressed headers appear as unreadable character sequences at the start of each message. The tab also shows how many SPDY data frames were used to send or receive the content:
There are also some new columns so that SPDY related data can be displayed in the main grid and exported to CSV files:
A full list of changes in version 8.3 is included in the version history.
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.
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.
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:
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:
Here’s what ZDNet had to say about the 32-bit and 64-bit versions of IE 9:
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.