Subscribe
Blog
April 12, 2013 in
Automation , HttpWatch
Some customers have asked recently about whether HttpWatch can be automated with PowerShell. This is possible but we don’t have any samples or supporting documentation.
If you’re interest in driving HttpWatch with PowerShell please take a look at this excellent post on F5 DevCentral by Joe Pruitt:
Project Acceleration: Programmatic Performance Testing with HTTPWatch
Every six weeks a new version of Firefox is released by Mozilla. Unfortunately, binary extensions like HttpWatch need to be recompiled and ship a new DLL for each new release.
Currently, HttpWatch supports the following versions of Firefox:
2, 3, 3.5, 3.6, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
There’s 18 different version of Firefox that HttpWatch needs to support and be tested against. Also. every six weeks the HttpWatch installer increases in size, takes longer to install and takes up more space on the target machine.
We really need to start dropping support for older Firefox versions as we’ll get up to Firefox version 30 in about 18 months time!
One of Firefox’s key benefits is the range and power of the add-ons available compared to Chrome and Internet Explorer. However the rapid release cycle, and the emphasis on change rather than backwards compatibility, means that even non-binary extensions often need to be updated.
Depending on the extension, there may even be a period where the add-on does not work with the latest version of Firefox. So on the one hand you want to keep Firefox updated to ensure that you have the latest security fixes, but on the other you don’t want to keep breaking extensions that you use on a regular basis.
It turns out there is a way to keep your extensions working for longer and keep up with Firefox security fixes.
It’s called Firefox ESR (Extended Support Release):
The idea is that at every 7th major version from version 10 onwards is designated an ESR release.
If you run with this version of the browser you will be in the ESR update channel:
You’ll get all the latest security fixes without breaking compatibility with add-ons for approximately 42 weeks or 7 Firefox release cycles.
So users of Firefox 10.0 ESR would recently have moved to Firefox 17.0 ESR. They will stay on Firefox 17.0 and get security updates until Firefox 24 is released.
It’s not very well publicized by Mozilla, but Firefox 17 ESR is available for download from the Mozilla FTP server.
In future we’re planning on only supporting Firefox versions that include the last two Firefox ESR releases. So, in the update for Firefox 18 we would drop support for Firefox versions 2.0 to 9.0. Then when Firefox 24 is released next year we would drop support for versions 10 to 16.
We’ve studied Firefox version usage on our site and it looks like dropping version support in this way is likely to affect less than 1% of Firefox users.
What do you think? Please let us know in the comments below or by email if the change would significantly impact the way that you use HttpWatch
HttpWatch has been updated to support Firefox 15 and add some new features:
SPDY Version 3 is an updated version of the SPDY protocol and includes some performance related changes such as improved header compression. These changes have been included in Firefox 15 but are not enabled by default. To try out SPDY version 3 you need to enable the network.http.spdy.enabled.v3 setting in about:config:
There’s also a new SPDY Version column that you can add in HttpWatch 8.5 to show which version of the protocol is being used. Here’s a screen shot from HttpWatch looking at the HTTPS version of wordpress.com. You can see that wordpress uses version 2 of the SPDY protocol but the Google resources use SPDY version 3:
