Telerik blogs

One of Fiddler’s most-useful but least-used features is its ability to playback previously-captured web-traffic to debug website issues reported by customers “in the field.” In today’s post, I’ll explain the recent Fiddler improvements supporting this scenario.

One benefit to joining Telerik to work on Fiddler full-time is that I get to work with the Test Studio support team, who sometimes use Fiddler to simulate customer environments as a part of support engagements. Their process is pretty simple: the customer clears their browser history and then uses Fiddler or FiddlerCap to capture the interactions between the client browser and the target website. The customer then emails the traffic capture (in SAZ Format) to Telerik’s support team for debugging.

The support team loads the SAZ file into Fiddler’s AutoResponder and then visits the root URL at the start of the captured traffic. Fiddler dutifully replays the captured traffic back to the client, allowing the support analyst to see exactly what the customer is seeing.

After talking to the support analysts, I learned of a number of issues that could prevent clean repro playback:

  1. If the customer’s environment uses authentication, replaying captured HTTP/401 or HTTP/407 responses causes the analyst’s debugging session to fail (because the client would receive a credential demand (e.g. “Login with your Acme Co. credentials”) that the client couldn’t possibly satisfy.
  2. If the site uses AJAX techniques to post multiple bodies to the same URL, Fiddler plays back only the first response (over and over), because the first rule matching a given URL is always used.
  3. Any HTTPS CONNECT Tunnels captured in the SAZ file are ignored by the AutoResponder. That means that unless the HTTPS site in question is public, the analyst’s browser’s attempt to connect to the target results in a HTTP/502.


To address these issues, Fiddler 2.4.2 introduces a new Import for Playback mode that can be used when loading a .SAZ file into the AutoResponder for replay. When this mode is activated, the following changes are made to the AutoResponder’s behavior:

  1. Sessions which resulted in HTTP/401 and HTTP/407 responses are ignored and rules are not created for them.
  2. Each rule is automatically disabled (unchecked) after it has been used one time. This enables more accurate replay of captures that contain multiple sessions with the same URL but different response bodies.
  3. Any CONNECT Tunnels in the capture generate a rule (limited to once per hostname) with a *ReplyWithTunnel action. When Fiddler sees a CONNECT Tunnel matching this rule, it informs the client that the connection was successful without actually creating a tunnel.


To use this new mode, select the AutoResponder tab and tick the Enable Automatic Responses box at the top. Click the Import… button and in the Import file dialog box, choose SAZ for Playback from the type dropdown:


Then, select the SAZ file to import and click Open. The AutoResponder creates  rules corresponding to the captured traffic. Right-click the rule for the root page and choose Open URL… from the context menu:


Your default browser will load, and playback will begin. As Rules are matched, each response will be played back and its rule will uncheck, disabling it. (Tip: If you’d like to re-run a repro, hit CTRL+A in the Rules list and hit spacebar to toggle the checkbox on all of the Rules.)

If you find that playback is incomplete and you see HTTP/404 responses in the Web Sessions list, there are two possibilities:

  • The user didn’t clear their cache before capturing and thus the SAZ file doesn’t include all of the needed responses.
  • The traffic includes Sessions with a random component in the URL.

The latter problem commonly occurs when using AJAX methods that try to perform “cache-busting” by providing a random number in the URL—commonly, the current timestamp is used for this purpose.

You can usually identify such requests by looking for a long number stuck somewhere in (usually at the end of) the URL, like so:


To fix this, you can update the rule so it does not require an exact URL match. For instance, use the Rule Editor’s textboxes to remove the EXACT: from the front and delete the timestamp from the end, like so:


Be sure to click the Save button after you’ve updated the rule:


The rule will now match regardless of the timestamp in the request URL.


I hope you find this enhanced functionality helpful!

About the Author

Eric Lawrence

(@ericlaw) has built websites and web client software since the mid-1990s. After over a decade of working on the web for Microsoft, Eric joined Telerik in October 2012 to enhance the Fiddler Web Debugger on a full-time basis. With his recent move to Austin, Texas, Eric has now lived in the American South, North, West, and East.


Comments are disabled in preview mode.