HttpWatch version 8.0 has been released and is now available for download.
Any customers eligible for a free upgrade to HttpWatch Professional can install the latest version using their existing license key. If you’re not sure whether your license will work with version 8.0 go to Help->Check For Updates in HttpWatch and it will show you any available updates or upgrades.
What’s New?
Supports Firefox 10.0
HttpWatch 8.0 works with Mozilla Firefox 10.0:
Windows 7 Taskbar Previews
HttpWatch Studio supports Windows 7 taskbar previous making it easier to switch between log files:
New ID and Connection ID Values
The ID provides a simple way to uniquely identify entries in an HttpWatch log file:
and the Connection ID shows which TCP connection was used by each request:
Add Comments to Pages and Requests
You can now add comments to the log file within the browser or in HttpWatch Studio:
Supports HTTP Archive (HAR) 1.2 File Format
HttpWatch 8.0 supports the enhanced the HAR 1.2 file format for importing and exporting data to other tools and environments:
Add any Header, Cookie, Query String or POST data value as a Grid Column
Track changes to headers, cookies or other parameters more easily by adding them as a column to the main request grid:
Easily Add Data Items as a Grid Column
Almost every data item displayed in HttpWatch can be quickly added to the main request grid using a context menu item:
A more detailed list of changes is available in the version history.
Earlier this year Mozilla shifted from releasing a new version every year or so, to once every six weeks.
So in the previous four years we had five major new builds of Firefox, but this year we’ve already had versions 4, 5 and 6.
Releasing often seems like a good idea; unless you’re in a controlled corporate environment or you develop extensions for a living.
While changing to this new model, Mozilla largely gave up on backwards compatibility to speed up their development process. In the past many interfaces were said to be ‘frozen’ meaning that script based and native binary extensions could rely on using them at any point in the future. That’s all changed so anything can be updated. There’s no guarantee that code in an extension will work with a new version of Firefox.
For native binary components like HttpWatch the picture is much worse. Binary components must be recompiled to work with each new release:
That means it’s impossible for us to ship a version of HttpWatch that will work with a future release of Firefox. Also, we have to add at least one new DLL to our install program for every new Firefox release. It’s not just developer centric tools like HttpWatch that are affected. Even consumer focussed add-ons like RoboForm need updating for every Firefox release.
Of course, Chrome has always been frequently updated but it has a much smaller extension ecosystem because it doesn’t have the range of APIs available in Firefox or Internet Explorer. Therefore, the frequent updates to Chrome don’t cause as many issues because there are less extensions and the extension API is less likely to change as it is so much more restricted.
In comparison, Microsoft has been the master of backwards compatibility across versions of Internet Explorer. For example, HttpWatch 3.2 was last compiled nearly 5 years ago but still works with IE 9 on Windows 7:
IE’s longer release cycles and excellent backwards compatibility really appeal to corporate users compared to Firefox’s new release model.
There was even some talk of increasing the frequency of the Firefox releases to once every five weeks or less. The resulting discussion on Slashdot gave rise to these negative comments about the change:
Have they totally lost it? It’s not like the browser world is making sudden great progress. It’s a mature technology. The big problem today is getting stuff fixed.
Sorry i have other things to do than repackage FF for deployment every 5 weeks.
What FF user actually wants this model? Most of them don’t. Releasing at the same speed as Chrome isn’t going to win over Chrome users, but it will chase FF users off. That’s what we’re seeing here.
If they keep this up, I will remove it from our labs. I am not going to deal with this s**t. Release bug fixes as often as you need to, but new features need to be something that doesn’t happen too often. I can’t go and test this s**t every few weeks, nor do I want to deal with things that are outdated. I like FF, but this policy they have is pushing me to dump it. I haven’t yet, but we’ll see.
Extensions stop working at random without any good reason and in record time. So many of us use Firefox over Chrome because of extensions. This plan is just terrible.
Of course, we are biased because short release cycles for Firefox create more work for us. What do you think?
Firefox 6 is almost ready for release and we have updated HttpWatch to work with the latest beta versions . While doing this we noticed some unexpected behavior in the way that it creates new connections.
Normally, in HttpWatch you can see when a browser uses a new TCP connection by looking for the yellow Connect block in each request. You can also confirm this by adding a Client Port column to the main grid. Here’s screenshot from HttpWatch showing new client ports being used as new connections are made to the web server:
In Firefox 6 we noticed that existing connections were sometimes re-used even though a request had a Connect phase:
On closer examination we found that Firefox 6 may reuse an existing connection even though it has already started to connect a new socket. The new actions on the Overview tab show exactly what is happening:
Initially, there was no idle connection available for the CSS file download because the first connection was still being used by the request for the page’s HTML. Firefox 6 therefore started to create a new TCP connection to the host. In older versions of Firefox it would simply have waited for the new connection to be completed and then would use that connection to dispatch the second request.
However, in this case Firefox 6 reused the initial connection (port 51384) when it became available even though it was still in the process of setting up a new connection. This new connection (port 51385) wasn’t wasted though. Its setup was completed in the background and the connection was reused by another request further down the water fall time chart.
Sometimes, you’ll even see a case where the new connection is correctly setup but Firefox 6 still reuses an existing connection:
So why does Firefox 6 aggressively reuse existing connections instead of new connections? There are two main reasons:
If an existing connection becomes available before the new connection is setup it means the HTTP request can be sent off sooner
