Interacting with the web has gotten more fun in the last year or so. Browser technological improvements seem to be getting a higher priority as Firefox, Safari and Opera are competing to present a superior, standards-compliant environment that benefits both developers and end-users. This means that developers can spend less time working around stupid bugs and more time creating interesting content.
These days, if you are building a web application a sound strategy is to create it initially under Firefox or Safari and then apply workarounds to IE problems at the end. It doesn’t really matter if you start with Firefox or Safari as anything that works under one is highly likely to work under the other (and any failure is more likely the developer’s fault, not the browser’s fault! yay!)
This is is marked contrast to five years ago when making a sophisticated website work in both Netscape and IE ususally meant deep sacrifices in functionality, or writing two separate websites.
This post, and likely a few more that follow, will detail the Firefox extensions that I consider to be the most useful, primarily to web developers but also to general users. Eventually, I hope to also cover a few that are interesting, but not useful or good enough for regular use in my opnion.
And so, without further ado, I present…
This is the first Firefox plugin I ever installed and I still use it routinely today. Live HTTP Headers adds a new tab to the Page Info dialog that shows details of the HTTP request/response for that page. To see it, install the extension, visit a page and select Page Info (via the Tools menu, via the context menu, or via Cmd-I on Mac). Then select the Headers tab to see the HTTP headers panel.
This panel shows the full HTTP message exchanged between the browser and the web server, less the actual content. This data can be critical for debugging anything deeper than HTML/JS glitches. For example, I maintain the Perl module called CGI::Compress::Gzip which transparently compresses dynamic web content when the browser says that it can support it. I used the HTTP headers to determine what the browser was telling the web server regarding compression — in this case “Accept-Encoding: gzip” was the important one. Then I looked at the web server response, which would tell me the Content-Length (should be smaller when compressed!) and the “Content-Encoding: gzip” message.
The HTTP headers can also tell you what web server and platform is being employed at the other end. Finally, you get to see the raw cookie data that went over the wire.
On the command line, you can get easily see the response headers via something like
wget -S -O /dev/null http://www.chrisdolan.net/
curl -I http://www.chrisdolan.net/
but that’s not as real-world as viewing the browser transaction directly.
Viewing response headers can also be amusing. For example, visitors to Slashdot receive a random Futurama quote like the following:
X-Bender: Farewell, big blue ball of idiots!
Next time: the Web Developer extension