Why Fiddler is like a Sonic Screwdriver

The post was going to be initially titled, why Visual Studio 2008 is like a VW Bora, in reference to the clip_image001current fun I’ve been having with my current Silverlight adventures. Unfortunately that particular episode will have to wait although I might give it as my Ignite presentation at our companies away day, watch this space as I’ll only give it if we don’t get enough other presenters. Anyway I digress, or should that be ramble, the current post has been sparked by two things, watching Doctor Who episodes with my daughter and fixing a simple connectivity problem in Silverlight.

Sonic What?

imageJust in case you’re not a Doctor Who fan, and I know it’s hard to believe that there are a number of them out there, or maybe you’re not British and been brought up with good time lord for the last 40 years (give or take a few gaps) then a little explanation is in order about imagethe sonic screwdriver. The sonic screwdriver is a plot device which allows the good Doctor to fix or interrogate any system or machine to find out information about it, fix it or damage it. Usually it’s just a flick of the wrist, a press of button and a flash of light and its job done, procedure complete, information acquired. Now unfortunately in the real world we don’t have a sonic screwdriver that can do this, but we do have fiddler.

So what has this got to do with Fiddler?

imageFiddler is a free tool that allows you to view the requests made from a browser (usually IE). It can be used to interrogate the requests and responses and to visually give you an indication about what might be wrong with a particular application. Like a sonic screwdriver it can gather information just running in the background without any interaction and can tell you how web applications work at the browser level. This can be useful to see why something might be failing in an application even though you might not have access to the code or to see what a system is requesting even though the code is not you own.

This can allow you to see exactly the information a website is sending and receiving from the browser very useful in an era where the logic is maintained within the browser as JavaScript applications or Silverlight/Flash programs. Here it is often useful to see the responses back from the server or more importantly why a request is failing and often this is to do with security issues or cross site access rights.

It’s screwdriver time!

Often the time you break fiddler out to diagnose the problem is the same time that Doctor Who breaks out the screwdriver. System calls failing, applications not working properly once installed on a remote site or map services not responding. Panic starts to set in hours go by as you try and vainly debug the application then someone (usually me) pipes up ‘have you seen what you get in fiddler’?


Now looking into fiddler is like staring into the matrix, when you have done it enough you start being able to see the woman in the red dress even though the screen just shows the weird green dots. You can start to pick out anomalies in the calls, fiddler helps you, it highlights file not found and errors in bright red and it shows you cached items in grey, both of which can give an indication of possible problems.

Authentication issues or caching problems can both cause errors that can be hard to track down, can manifest themselves in esoteric ways and can end up burning a lot of time to diagnose. Fiddler can be your sonic screwdriver in those moments.

Divining a problem.image

Now this post could equally be titled, how many times does a man need to forget to place a crossdomain.xml file on a web server before it stops being funny, but it does serve as a good example of  where fiddler could have shown a problem well before the final issues were resolved. Crossdomain.xml and its Microsoft equivalent of clientaccesspolicy.xml are used by Flash and Silverlight (which can use both) to tell their particular run time environments that they can access services and data on a particular server. This is particularly important when a rich internet application needs to access services or files from a server that it is not served (downloaded) from initially. Without these files present at the root of the server then the request will fail often with unforeseen consequences.

I must admit after going through the story the reason why there were problems becomes obvious, but the feature layer was coming from another server which I had not used before and I had no idea that there might be an issue with it. But it serves as a reasonable simple example nonetheless.

In my particular case I was using the ESRI Silverlight API in conjunction with the most excellent (and free!) Blacklight control library. Now my application was working without issue when I decided to add another layer into my map using a feature layer. I merrily put the lines of XAML into my page to add the feature class (notice server names have been changed to spare the innocent, any maps generated are done by actors).

image Having set up the right renderers and such like I proceeded to run the application. Nothing came back; I checked the code, double checked, triple checked, but nothing. The base maps came up but no features on the top. I then proceeded to add the new map service as a normal dynamic layer as such to check there wasn’t something wrong with the FeatureLayer class. The XAML looked as such:

image Now this gave me an error in Visual Studio:

imageDoh! I think. I had made the classic schoolboy error of not adding the cross domain file onto the new server. I can see this in fiddler as such, so just waving fiddler at the requests has allowed me to divine the problem, much like (in my head anyway) the sonic screwdriver.

image Now this is a good example of being able to see the problem in fiddler even though the application wasn’t reporting any issues. Being able to diagnose problems in this way should often be the first port of call with any issue that doesn’t get picked up by Visual Studio, especially when calling remote services.

Adding the following cross domain file to the server (it’s internal so it doesn’t require too much security, but don’t use this in the wild verbatim) allowed the application to work fine with both the dynamic layer and the feature layer, problem solved, Daleks defeated (again in my head).


Every time I use fiddler it saves me time, the key is remembering to use it earlier in the problem solve! That way you can save time being burnt on things that have simple solutions and concentrate on the other time killers like getting agreement on the UI design, as we know everyone’s a critic!

So where do I get my screwdriver?

Whilst fiddler is written by a Microsoft employee (Eric Lawrence) it’s not actually a Microsoft product ‘per imagesey’, but it does have some good information about how to use it here (msdn) and here (msdn).

If fiddler isn’t your thing, or you just think that pointing a glowing blue light at a computer might be able to fix any communication problem even in the real world, then you can get your own from Amazon here, in fact if I could get a Wi-Fi one maybe I could hook them both up <goes off to tinker in the shed>.

The banana of doom or 404 with style.

I’ve been hyper busy in the bat cave (aka the garden office) with end of year projects, Christmas parties and general shenanigans (who sounds like an Irish military commander). It’s times like this when it’s good to see another site straining under the weight of usage and the imaginative page showing that times are imagegood, yet the server load isn’t. Many sites (the tr.im one is too the left) now put up fun pictures when there servers are taking the strain. These pictures let you down gently, but thoroughly (no slow response just no response) with a promise that coming back later will make everything alright.

We begin to rely on many web sites to provide instant responses to our every whim and when they don’t it’s somewhat of a shock. We never expect a Google application to break so when Gmail is sometimes down everyone gets all of a twitter on how it’s terrible, especially given for most people it’s a free service.image This is the same when services such as Bing go down, TechCrunch said it well ‘Its one thing when startups, like Twitter, go down, which happens all the time. It’s another when a major search portal does it’.

In fact Twitter has one of the most recognisable site unavailable images on the interweb that of the fail whale. This charming graphic, which has often been seen by those people twittering via the website as the popularity of the site has grown, even has its own fan club (‘the fail whale fan club’) where you can buy mugs and t-shirts with the little whale plastered all over it. It’s amazing what a bit of imagination can do to endear people to what actually is a site failure (for whatever reason).

Under the hood

Now all these nice pages are doing are hiding the HTTP error codes that we have all seen emitted by our favourite application, that when not altered from its natural state tends to make their way to our web browsers which then renders it with the minimum amount of eye candy possible. Whilst it’s not only a sign of a poorly developed application to have raw error messages delivered back to the browser, it’s also bad to allow raw HTTP errors to fly around without even a little bit of window dressing.

This is a two stage process:

imageFirstly any web application or end point should emit the right codes when returning information, such as 200 for success and 404 if something isn’t found. REST services need to use HTTP codes appropriately to allow for the proper caching of information, through the use of conditional get, and the identification of bad requests for information. The RESTful web services bible gives an appendix dedicated to understanding which of the 41 HTTP codes that are needed (go on it’s an interesting read, honest guv!).

Secondly the web server needs to be configured to use a nicely formatted and informative imagepage to return so as the user is nicely calmed and reassured as their application is going down in flames. In IIS you can configure the error pages that are sent by a whole server or an individual site through the admin pages and then craft the appropriate response that you wish your users to see.

There for by the grace..

Whilst it’s easy to mock a site that’s having scalability woes especially if it’s run by one of the major internet companies (the Bing error page wasn’t too comforting at first) it only takes a simple post by Slashdot to bring all but the best designed or resourced sites to their knees. Hopefully now if it’s one of your sites at least you’ll look good on your knees and your customers will remain calm. If your stuck for ideas Smashing Magazine has a list of cool 404 error pages that might give you some, even some off the wall ones such as my favourite: