Breakpoints in Fiddler

Fiddler is so named because it allows you to tamper with requests and responses. Tampering can be performed automatically (using the FiddlerScript engine or extensions) or manually, using the Inspector objects.

In order to tamper with a request or response manually, the first step is to set a breakpoint on the traffic so that Fiddler will pause processing of the Session at the appropriate time to allow you to use the Inspectors to modify the response. There are several ways to set a breakpoint:

1. Using the Rules > Automatic breakpoints menu option
2. Using the QuickExec box’s bpu or bpa commands
3. Using the Filters tab
4. Using the AutoResponder tab
5. Using FiddlerScript/extensions to set a X-BreakRequest or X-BreakResponse Session flag

Approach #1 allows you to easily set a request or response breakpoint for all subsequent traffic, but it has the downside that it’s a very blunt instrument—breakpoints will very often be set for traffic you don’t care about, requiring that you frequently click the resume button () in the toolbar to unpause traffic that isn’t of interest to you.

Approach #2 allows you to quickly set a request breakpoint (bpu example) or a response breakpoint (bpafter example) for Sessions’ whose URL contains the text you supply to the command. You can subsequently clear these breakpoints by issuing the command without an argument (e.g. bpu or bpafter). While this approach is far more surgical than the Automatic breakpoints feature, it has the downside that only two breakpoints may exist at one time—one request breakpoint and one response breakpoint. There’s also no easy way to see what breakpoints are currently active.

Approach #3 allows you to easily breakpoint requests or responses based on commonly-selected criteria:

While these breakpoints are powerful, they aren’t very flexible.

To address the shortcomings of approaches #2 and #3, use approach #4, the AutoResponder tab. The AutoResponder tab allows you to create a list of request and response breakpoints and easily enable and disable them using the checkboxes to the left of each rule. Additionally, you can use the full matching functionality of the AutoResponder engine, which means you can breakpoint Sessions based on regular expressions, the HTTP method, or text in the request body. When creating breakpoints in this way, be sure to leave the Unmatched requests passthrough box checked at the top of the tab.

You can also export your list breakpoints using the Export all… command on the list’s context menu.

The only downside to breakpointing with the AutoResponder is that there’s no way to breakpoint based on an attribute of the response – for instance, you cannot create a response breakpoint based on the Content-Type returned by the server.

Lastly, if all else fails, you can use approach #5 and set breakpoints using FiddlerScript or an extension based on any criteria you choose. Simply add code to the OnBeforeRequest, OnPeekAtResponseHeaders, or OnBeforeResponse events to set the X-BreakRequest or X-BreakResponse flags on the Session objects that match your target criteria. For instance:

   if (oSession.uriContains("/sandbox/")) {
        oSession["x-breakrequest"] = "FiddlerScript: URI contains sandbox";
   }

or

   // Place in OnPeekAtResponseHeaders
   if (oSession.uriContains("app.com") &&
       oSession.oResponse.MIMEType.Contains("script"))
   {
        oSession["x-breakrequest"] = "FiddlerScript: app.com returned script";
   }

 

Breakpoints are one of the most powerful features in Fiddler, and you can set them in whatever way you find most convenient.

ProTip: If you're using Fiddler's Composer tab, simply SHIFT+Click the Execute button to immediately breakpoint on the newly-issued request.