In a previous post we described how to interact with a web page using WatiN 1.3 while recording HTTP/HTTPS traffic in HttpWatch. It was a popular post, used by many customers to build automated web page tests that used HttpWatch to provide performance metrics, check for HTTP level errors and to look for opportunities to improve performance.

Since then, WatiN 2.1 has been released providing significant improvements and the ability to interact with Firefox 3.6 as well as Internet Explorer. Unfortunately, a change in the WatiN assembly caused a type conflict with HttpWatch over the definition of IE’s IWebBrowser2 type. This could give rise to the compilation errors in a Visual Studio C# project:

error CS1758: Cannot embed interop type ‘SHDocVw.CommandStateChangeConstants’ found in both assembly ..\WatiN\bin\net20\Interop.SHDocVw.dll’ and ‘…\obj\Debug\Interop.SHDocVw.dll’. Consider setting the ‘Embed Interop Types’ property to false.

If you had marked the project to build against .Net 2.0 there isn’t even an option to set ‘Embed Interop Types’ to false.

The way to avoid this error is to delete the ‘Interop.SHDocVW’ reference that you may have added from the WatiN bin directory:

In HttpWatch 8.3.19 we’ve added a WatIN sample program and documentation to provide a starting point for using WatiN 2.1.

The sample program shows you how to fill out a simple web form:

and retrieve values from the resulting page:

There are two ways to get HttpWatch and WatiN to work on the same instance of IE. The first is to create the new instance with WatiN and then attach HttpWatch:

// Attach HttpWatch to an instance of IE created through WatiN
WatiN.Core.IE watinBrowser = new WatiN.Core.IE();
HttpWatch.Plugin plugin = control.IE.Attach((SHDocVw.IWebBrowser2)watinBrowser.InternetExplorer);

Or you can create the instance in HttpWatch and attach WatiN:

// Attach WatiN to an instance of IE created through HttpWatch
HttpWatch.Plugin plugin = control.IE.New();
WatiN.Core.IE watinBrowser = new WatiN.Core.IE(plugin.Container);

For more information about using WatiN with HttpWatch please take a look at the sample program that is installed with HttpWatch Basic and Professional Editions:

http://apihelp.httpwatch.com/#WatiN Form Fill Sample.html

One of the first things we noticed when using HttpWatch in Firefox 13 was that Google servers do not compress content in SPDY responses:

HTTP compression is usually the most important optimization technique a site can use because it drastically reduces the download size of textual resources such as HTML. It therefore seems surprising that the Google servers do not use it with SPDY responses to Firefox.

In fact, the Google home page tries to determine if the browser supports compression by downloading a gzip compressed javascript file to see if it executes. You can see the compression test URL highlighted in the screen shot above.

Normally, a browser indicates that it supports content compression using the Accept-Encoding request header. Firefox 13 doesn’t send this header in SPDY requests. Presumably, Mozilla believes it is not required:

Perhaps, it is the lack of this header that prevents the SPDY enabled Google servers from returning compressed content.

Twitter’s SPDY implementation takes a different approach. It assumes that if the browser supports SPDY then by implication it also supports compression:

So why do Mozilla and Twitter have a different approach to Google over SPDY content compression? The difference is probably down to the way they have interpreted the relevant sections of the SPDY protocol definition.

The SPDY Draft 3 spec has two things to say about compression. First, for headers it clearly states that it is always on:

2.6.10.1 Compression 

The Name/Value Header Block is a section of the SYN_STREAM, SYN_REPLY, and HEADERS frames used to carry header meta-data. This block is always compressed using zlib compression. …

However, for data compression it’s not so easy to work out what is required. The main section about content compression reads as follows:

4.7 Data Compression

Generic compression of data portion of the streams (as opposed to compression of the headers) without knowing the content of the stream is redundant. There is no value in compressing a stream which is already compressed. Because of this, SPDY initially allowed data compression to be optional. We included it because study of existing websites shows that many sites are not using compression as they should, and users suffer because of it. We wanted a mechanism where, at the SPDY layer, site administrators could simply force compression – it is better to compress twice than to not compress.

Overall, however, with this feature being optional and sometimes redundant, it was unclear if it was useful at all. We removed it from the specification.

That suggest that content compression is optional but does say if the client must support it.

In section 3.2.1 there’s a statement that supports the Twitter/Mozilla approach:

User-agents MUST support gzip compression. Regardless of the Accept-Encoding sent by the user-agent, the server may always send content encoded with gzip or deflate encoding.

However, the Overview section seems to imply that the normal Accept-Encoding / Content-Encoding handshake should be used:

SPDY attempts to preserve the existing semantics of HTTP. All features such as cookies, ETags, Vary headers, Content-Encoding negotiations, etc work as they do with HTTP; SPDY only replaces the way the data is written to the network.

The most sensible approach seems to be the one adopted by Mozilla and Twitter. It seems inconceivable that a SPDY aware client would not support content compression given that compression is always used for the headers.

The advantage of forcing all SPDY clients to support content compression is that the Accept-Encoding header is redundant and can be dropped saving a few bytes in each request message.

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:

1. Only a single HTTP request can be active on an HTTP connection at a given time. Although HTTP pipelining was intended to overcome this, it still uses a FIFO queue and it is not well supported by existing HTTP infrastructure.
2. Headers in HTTP request and responses messages are never compressed.

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:

There’s more information about SPDY in the white paper and specification.

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.