Click the Save button to generate and display the manifest in your text editor:

161 | Storing, Importing, and Exporting Traffic 9. If you’re happy with the manifest, save it to your web server in the appropriate location. Ensure that your

web server is configured to return the manifest file type with Content-Type: text/cache-manifest 10. In your web page, ensure that your page will run in Standards mode (e.g. using the HTML5 doctype) and

add a manifest attribute on the HTML element pointing to your application’s manifest.

Keep in mind that when the browser is using AppCached content, those resources will be reused from the cache and not pulled from the network (until the cache is expired). Because the content is cached locally, you will not see requests to re-download that content in Fiddler. If you wish to use Fiddler to modify such content, you will need to clear your browser’s cache so that the browser is forced to re-download the content from the network on next use.

HTTPArchive v1.1 and v1.2

The HTTPArchive format is a JSON format that contains Web Sessions’ headers, some bodies, and timing infor-mation. The primary difference between versions 1.1 and 1.2 of the format is that the newer version permits the inclusion of small binary bodies.

By default, Fiddler will store text bodies up to 1MB in length, and binary bodies up to 32768 bytes in length; these values can be changed by setting the appropriate preferences:

fiddler.importexport.HTTPArchiveJSON.MaxTextBodyLength fiddler.importexport.HTTPArchiveJSON.MaxBinaryBodyLength

If a body is too long, it will not be stored in the file and instead a comment will be added to the Session noting the omission.

162 | Storing, Importing, and Exporting Traffic MeddlerScript

Meddler (http://webdbg.com/Meddler/) is a HTTP Traffic generation tool which I developed to allow building of tiny, self-contained reproductions of HTTP traffic. Meddler is essentially a “scripted socket” which allows very low-level manipulation of sockets, a capability useful for debugging browsers or other clients.

When you export Web Sessions to MeddlerScript, the result is an .MS file that can be loaded into Meddler to “play back” that traffic. Conceptually, this is very similar to using Fiddler’s AutoResponder tab to play back previously captured traffic from a SAZ file, but Meddler scripts can be easier to automate and they permit low-level tweaks (e.g.

“Wait 300ms between sending the headers and the first byte of the body, then write the body in 2048 byte chunks each 10 seconds apart”) which cannot be easily replicated using Fiddler itself.

Unless you’re building a browser or other HTTP client, exporting MeddlerScript probably will not be very useful for you.

Raw Files

The Raw Files Exporter allows you to store individual response bodies to files on disk. This can be tremendously useful when dumping media content to disk. For instance, say you’ve browsed around a photography website and collected a bunch of photos in the Web Sessions list. You can use filters and other features in Fiddler to select only the photos of interest (e.g. JPG files over 20k). You can then select File > Export Sessions > Selected Sessions and choose Raw Files in the Select Export Format box.

The File Exporter window allows you to configure the export process.

The Path box allows you to select the base path under which a new folder will be created. The folder will be automat-ically named \Dump-MonthDay-Hour-Minute-Second\.

The Options box contains two checkboxes. Recreate Folder Structure will create subfolders for each resource based on the hostname and path of the file. Use this to mimic a site’s hierarchy on your local disk. The Open folder when complete option will open Windows Explorer to display the root folder into which files were exported when the export has completed.

Click the Export >> button to begin the export.

Beyond dumping media files, the Raw Files Exporter allows you to easily mirror a captured website to your disk.

You can then drag/drop the contents of that folder to the AutoResponder tab, and Fiddler will then be able to play

163 | Storing, Importing, and Exporting Traffic back that local content mirror based on inbound requests. This practice can be very convenient for debugging a website when you want to use other tools (e.g. Expression Web or Visual Studio) to edit HTML content locally.

Visual Studio WebTest

Generating a Visual Studio .WebTest file allows you to use the Visual Studio Web Test product to reissue previously captured requests for functional-testing and load-testing purposes. Visual Studio Web Test is included in some editions of Visual Studio 2008 and later.

WCAT Script

As explained on the tool’s website:

Web Capacity Analysis Tool (WCAT) is a lightweight HTTP load generation tool designed to measure the performance of a web server within a controlled environment. WCAT can simulate thousands of concurrent users making requests to a single web site or multiple web sites. The WCAT engine uses a simple script to define the set of HTTP requests to be played back to the web server.

Fiddler’s WCAT Exporter allows you to easily generate request-generation scripts for WCAT to replay against your servers to verify their ability to handle load.

You can download the 32bit or 64bit WCAT installer from http://fiddler2.com/r/?WCAT.

FiddlerScript

166 | FiddlerScript

E X T E N D I N G F I D D L E R W I T H F I D D L E R S C R I P T

The earliest versions of Fiddler had no extensibility model at all; the features I coded were all that users had availa-ble. It didn’t take long to recognize that I would never be able to keep up with the myriad feature requests coming in from Fiddler users who were using the tool to solve a huge variety of problems.

One of the biggest early limitations was that Fiddler only offered one filter (Hide Images) and thus it was easy to get overwhelmed by the sheer volume of traffic flowing through the tool. I had planned to build a filtering interface full of dropdown fields and textboxes which would allow users to filter traffic based on boolean criteria that I would make available. There were two obvious problems with this approach: first, it would require that I do a lot of tedious UI development, and second, I knew that most users wouldn’t be happy with it. Advanced users find it very cumbersome to build complicated queries using UI controls, and novice users would be easily confused when trying to build complicated queries that involved nested AND, OR, and NOT operators.

Fortunately, laziness often leads to better engineering. I remember thinking one night: “It’s so easy for me to build complicated filter expressions inside Fiddler’s code itself. If only users could just write code to do filtering.” Happily, this thought led to a “eureka” moment-- the recollection that the .NET Framework makes it very easy to build a script engine into an application, and exposing the application’s object model to that script engine is easy. With a few dozen lines of code added in late 2003, Fiddler got infinitely more powerful.

Even as Fiddler was modernized over the last 9 years, including the introduction of Fiddler extensions and many built-in filtering capabilities, the FiddlerScript engine has remained an indispensable component of Fiddler. By mastering FiddlerScript, you will get much more out of Fiddler.