Code available: http://fiddlerhtmlinspector.codeplex.com
With thanks to HAP (http://htmlagilitypack.codeplex.com/) and Eric Lawrence (http://www.fiddler2.com)
Sometimes there’s a certain task that you need to undertake when debugging HTTP traffic that you can’t do with out of the box features of Fiddler. Fiddler has a huge range of tools that you can try, but for this example we’ll assume you have found one unique use case that you can’t fulfil with the base implementation of Fiddler. In this post I’ll make the assumption that instead of brand new functionality, we want instead to improve some existing functionality within Fiddler, or at least do it in a slightly different way.
The functionality we’re looking to improve is the Statistics graph – visible when looking at the statistics tab for a web request and clicking “Show Chart” at the bottom of the tab. This brings up a small pie chart, showing how the request is composed; how much header info and how much html payload. This is a simple way of checking how much of the http request is dedicated to content and how much to metadata. Note that the “header” in this context is the http header (like Set-Cookie and Content-Type) rather than html <head> body. The <head> is contained within the <html> section of the chart.
This graph is useful, but it cannot provide any measures of how efficient the HTML within the HTTP request is. There may be a large amount of pointless whitespace, overly long identifiers, large paths to script includes or other poor practises.
Therefore this blog details the creation of an extension who’s point is to chart the efficiency of HTML.
Step One – Setup
Firstly we need a version of Visual Studio running – you can use Express or one of the full professional editions. I am using 2008 Professional – v 9.0.30729.1 SP. In this, we create a new Project, of the type “Class Library” to give us a .dll assembly when compiled. To this we will add a reference to Fiddler, the HtmlAgilityPack for inspecting HTML and System.Windows.Forms.DataVisualization for generating our chart.
Once we have done this, we can add an Installer to simplify our debugging and make our extension distributable when we get to that point. The only thing we need to do with the installer is to add a reference to our class library and make the primary output from our project go to a particular location. If we want the extension to be available for everyone, we can install into the location %Program Files%Fiddler2Scripts, whereas if we want it to be only available to the person who has installed it, we can install into the location %USERPROFILE%My DocumentsFiddler2Scripts
I’ve chosen that the extension should only be available to those who install it, so my output will be to the My Documents sub folder.
One tip – it is possible to launch Fiddler in a debugging friendly way. If you try to run the application as you have it in VS 2008- it will complain that you cannot start a class library.
Instead, setup the debugging info as per the below, and if you make sure Tools|Options|Debugging|Enable Just My Code (Managed only) is unchecked then you will get Fiddler loading and all the code within your extension is available to be stepped through.
Step Two – Linking to Fiddler
As it stands, Fiddler will be able to find the extension in its deployed assembly (provided it has been installed on the local machine) – but without a little extra work it won’t load it.
The loading is controlled by adding an assembly scoped Attribute. This Attribute can be put anywhere, but good practise to me it to put it in assemblyInfo.cs located inside the Properties folder of Solution Explorer.
The line of code looks like the following:
[assembly: Fiddler.RequiredVersion("2.2.2.0")]
This tells Fiddler that the assembly is to be loaded by any Fiddler version later than the specified version. If your version of fiddler is older than that you specify in the constructor of this attribute, then the extension will not load.
Step Three – Implementing Interfaces
We have to implement an interface in a class in our assembly, for that is what Fiddler looks for when it comes to loading classes. The interface I’m working with is:
IFiddlerExtension
This provides two methods to implement:
public void OnBeforeUnload()
and
public void OnLoad()
Most of our work will be done in OnLoad, where we will add a new page to the Tabs on the right hand side of fiddler. Our whole code is very simple, and then we can move on to implementing the control.
Step Four – implementing the control
The code supporting this blog is posted on Codeplex, and so I won’t go into too much detail about the code itself – most of it is standard anyway. The bit that is interesting is how Fiddler interacts with your control. In this instance, the data is passed to your control by way of dragging and dropping, and so the events are wired up as follows:
Once you have wired up the events, you can add code into the DragDrop method to handle the data and do the work.
Fiddler will pass you data in the event handler by using e.Data.GetData(“Fiddler.Session[]“);
When you have filled out the methods DoInspect – you will have some kind of UI that you can use inside Fiddler for inspecting HTML:
The buttons on the top row that sit over the label are a bit annoying – but I couldn’t wait to blog this! Here’s a short video.
That’s all, thanks!
Andy
Andy Cross
azurecoder
Beth Martin
2 comments
Do you want to comment?
Comments RSS and TrackBack URI
Trackbacks