When I was first working with UCWA I had trouble processing Batch messages (multipart/batching) as I would be constantly coping each individual message from Fiddler and dumping it into a JSON parser to see a prettier display of results. While a few batch messages might not seem to daunting, it is possible to wrap 20 requests into a single batch message. At this point I began to read up on creating Custom Inspectors Fiddler.
What is an Inspector
Fiddler includes a set of Inspectors by default and the ones I find myself readily using when debugging UCWA tend to include: Headers, TextView, Raw, and JSON. Inspectors implement an interface that provides the component with the Header/Body data for the message and from there the component can choose how to display. In the case of the Headers Inspector it separates the message headers into bold categories.
When it comes to processing Batch messages either TextView (view Body data) or Raw (Header & Body) is the place to grab the individual message. According to RFC 2046 each message in a multipart entry is separated by a boundary and in the example below the boundary is 07b2d3f3-9a8f-416c-a006-c489726f0660. It is possible to see that both responses in this Batch message have a Content-Type of application/json.
Custom Inspector at a Glance
Similar to extending Fiddler via FiddlerScript, it is possible to create a Custom Inspector for Request/Responses and this time with C#! Basic documentation exists on how to Build a Custom Inspector. When creating this extension there is a choice to make: support .NET 2.0 or .NET 4.0 (directly related to which Fiddler version is installed and the extension is built against). In my case I chose to support .NET 2.0 as it is compatible with the .NET 4.0 version (and potentially newer versions).
Typically a Custom Inspector would implement Inspector2 and IResponseInspector (Response handler) or IRequestInspector (Request handler), but with Batch messaging both the request and response are of type multipart/batching and it would be ideal to visually represent both in some readable fashion.
Request messages will be wrapping Content-Type of application/http; msgtype=request which should contain the following:
- Verb - GET, POST, PUT, DELETE
- Url - what data is being accessed
- Body - Optional
Response messages will be wrapping Content-Type of application/http; msgtype=response which should contain the following:
- Status code - 200, 301, 418 (if only)
- Status - text description of code
- Body - Optional
I had a good idea of what the data might look like, but was unsure how I wanted to visually present it to the user. A colleague of mine pointed me at JSON Viewer as it had a standalone control for displaying JSON. Another lucky feature is that it included a Custom Inspector and I was able to use that as a base for the creation of a new Custom Inspector. I would reuse the code that made use of the JsonViewer control and provide it with a JSON-formatted Batch message. JSON Viewer also has dependencies on Json.NET, so came along for the ride as well.
I browsed Fiddler reference in my project and discovered that IRequestInspector and IResponseInspector would only give me access to headers and I wanted to be able to process both headers and body. By having my main class (MimeInspector also implements Inspector2) implement IBaseInspector I was able to process body data. With a fair amount of string manipulation I was able to transform the header/body into a fairly readable JSON object rendered in a JSON Viewer control. All that was left to do was define classes implementing IRequestInspector2 and IResponseInspector2 inheriting from MimeInspector (to benefit from the header/body processing and display via a JSON Viewer control).
Using a Custom Inspector
Using a Custom Inspector is as simple as navigating to Fiddler's install location and placing the necessary files into the Inspectors folder (Fiddler should not be running if you are adding/removing Inspectors). The end result is a new tab in Fiddler, multipart/batching, that can render Batch messages into an easier to read/navigate JSON display.