Monthly Archives: June 2012

Active-Filtering of the Session List in Fiddler2

I use Fiddler2 daily – it’s one of the greatest debugging tools I’ve ever come across. You can hammer into the traffic coming and going across the tubes and tamper with the data as you like. You can substitute alternative local data in the place of remote server responses. You can modify headers on the fly. And this doesn’t even begin to scratch the surface of all you can do.

One of the problems I have is that, like many of you I’m sure, my browser is hardly ever doing one thing. Although I may be trying to debug a web-app, I may also be tied into my GMail inbox, streaming some music over Turntable, or watching the flow of tweets glide across @jonathansampson. All of these items cause sessions to be logged in Fiddler, adding a whole lot of noise to what I’m trying to work on.

So what do you do when you have specific hosts that you want to track? You make use of the Filters tab.

This highly-customizable tab will provide active filtering of the sessions coming across your screen. You can instruct it to show only intranet traffic, or only internet traffic. You can explicitly ignore particular hosts, or you can ignore everything but a select few. As my earlier summary of Fiddler didn’t begin to scratch the surface, neither does my explanation of this panel begin to touch on all that the Filter feature is capable of.

Have a look.

What I’ll be looking at here is the first part, the hosts section.

For starters, we need to click the “Use Filters” check-box to enable this feature. Now in my particular situtation all I want to see is anything that comes from a particular domain, such as This would include any subdomains as well.

The first thing I will do is select “Show only Internet Hosts” from the first dropdown. From the second dropdown, I’ll select “Show only the following Hosts”. This enables the textarea below, which will take a series of expressions or explicit domains to watch for.

Insert * and you should see the textarea turn yellow, informing us that “Changes not yet saved.” At this point, click the Actions button to the top-right, and select “Run Filterset now”. If you already had sessions from your target domain in your session list, those should be all you see in there at this point.

From this you can infer how to go about blocking only particular domains, and various other things. You might even dare to venture into the rest of the filter options, creating a highly-customized instruction set. If you do, be sure to save your filter from the same Actions button we used to run the filterset.

I find this to be an enormously helpful feature, and I’m sure you will as well. Now if you’ll excuse me, I’ve got some work to do and very little noise preventing me from getting it done, thanks to Fiddler.

The big problem with Microsoft’s Flash whitelist browser sniffing

In The big problem with Microsoft’s Flash whitelist, ars author Peter Bright shared some of his concerns with the forthcoming Windows 8 Metro version of Internet Explorer 10. He states “it’s neither a full desktop browser nor a detectable mobile browser” after being shafted by Sony Pictures for not using a Flash-enabled browser.

Peter expressed concerns that since IE10 Metro uses the same user-agent string as IE10 on the desktop, developers won’t be able to detect which is which, and as such, they’ll assume you’re on a desktop and that your desktop supports Flash. As was pointed out in the article, HTML5 content is commonly reserved for mobile browsers – which the Metro IE10 is not.

At the bottom of Peter’s article was a byline that stated Peter “covers programming and software development, Web technology and browsers,” and as such I am saddened to see such a defense of user-agent sniffing and absolutely no mention of feature-detection.

User-agent sniffing, or “browser sniffing”, is the act of examining the user-agent string sent with requests to a server and inferring the browser or system’s abilities from that information alone. For instance, if your user-agent string contains a reference to “iPad”, I can safely assume you support HTML5.

The bottom line is that this practice is unprofessional, and naive. The user agent string is not an immutable property of the browser. It changes with each browser release, it changes with certain plugins being installed, and it changes by the authority of the user if they happen to be tampering with their developer tools (perhaps trying to get around poorly-coded sites that require certain user agent strings for access).

The jQuery documentation, while providing $.browser.msie for IE detection states “We recommend against using this property; please try to use feature detection instead.”

The Popular Yahoo Library, YUI, also contains the UA class for detecting the users browser, but they too plead with the user: “Do not fork for a browser if it can be avoided. Use feature detection when you can. Use the user agent as a last resort.”

One is forced to ask, why didn’t any of this make its way into Peter’s article? The article was instead an attack on Metro IE10 for not being an enabler to poor development practices. As Peter pointed out, he wasn’t able to watch his video because the site he was visiting was sniffing his user agent string. If Sony Pictures had been doing things the correct way, we wouldn’t have these problems.

Feature detection isn’t hard to do. In fact, regarding HTML5 video it’s a very trivial task:

if ( !!document.createElement("video").canPlayType ) {
    // Load HTML5
} else {
    // Go for Flash

That is all it takes. Not too hard right? It is even more trivial if you use a feature-detection suite like Modernizr to handle the heavy-lifting for you. No tampering with user-agent strings, no screwing up your parsing and thus breaking your user’s experience – not of that. Just giving the browser what the browser can handle.

When you assume you know what the browser is capable of without actually making some attempts, you ruin things for everybody. Just ask Karl Dubost, a web developer working with the Opera browser. He expressed some of his frustration when CFABank unnecessarily blocked Opera users from gaining access to their accounts.

Or perhaps Rey Bango, a jQuery team member and Developer Evangelist for Microsoft who shared the story of Paydirt, a wonderful service that prevented IE users from knowing how great their product was because they assumed IE wouldn’t work, even though IE9 and 10 handled their product very well.

This is what Peter’s complaint should have been – people are developing terrible sites. And it’s not just some kid at his house, it’s large companies like Sony Pictures. It’s a call for education, and it’s something we in the development community are working very hard to remedy.

Kudos to Microsoft for taking the actions they’ve taken. Having plugins in the browser leads to security risks, unnecessary battery usage, and so much more. Not to mention, if people build things using the native features available in modern browsers today (with the many great polyfills and fallbacks where necessary), we find the need for major plugins like Flash practically vanish.

I, for one, eagerly await the arrival of the plugin-free browser.