Getting to Know Fiddler: Part IV: Simulate responses by engaging Fiddler's AutoResponders

Posted on Aug 18, 2014

Couldn't resist a cheap Star Wars reference. :P

Last week we figured out how to use Fiddler's breakpoints to let us edit traffic at will. While it is a powerful tool, if we are making the same edits each time, it can become as tedious as it is useful. And with that rather painful segue, we get to the AutoResponder.

Fiddler's AutoResponder tab

Fiddler's AutoResponder is represented by yet another tab hiding away in our detail view. When enabled, it can, among other things, automatically return a response for a given request. We'll start by clicking “Enable automatic responses”. When we turn it on, Fiddler will only respond to requests in the AutoResponder list, displaying an error for all other requests. To correct that, click “Unmatched requests passthrough.” 1

Exact Requests

With AutoResponders enabled, we can add a response by dragging it from the session list on the left into the responder list on the right. In our particular case, we've setup an AutoResponder for a call to Spotify's API.

We've added our first AutoResponder

As long as the AutoResponder is in place, we'll always get the exact same response for our request. I'll admit that doesn't sound like quite the world changing feat, but it can be useful from time to time. This is just the start though. Click on the response to open it up in the rule editor at the bottom of the detail pane.

The Rule Editor

Rather than using our response with its original request, I'll change it to respond to searches for Joshua Rogers, clicking “Save” afterward.

Our autoresponded results

If we jump back to our browser and search for tracks related to Joshua Rogers, you'll now find that among my many musical accomplishments, I released “Duran Duran (The Wedding Album)". Not bad considering I was seven in when it came out.

Regex Requests

While this will take care of a number of use cases, it never fails that at some point I'll want to respond the same way for a whole class of requests, usually because I can't guess an authentication or tracking token in advance. The Autoresponder is still great at handling this with the help of regexs. Click “Add Rule” to begin.

If we provide a regex for it, Fiddler will check to make sure that the URI contains our pattern. For our new rule, add the text “REGEX:” to indicate it is a regex match, not an exact match we're going for. Next, we'll add our pattern. I'd like to match everything at that particular endpoint, so I'll use “http://ws.spotify.com/search/1/track.json". 2

While we could use a previously captured response or we could edit one to our liking, in this case we'll just simulate a gateway timeout by using the precanned response “502_Unreachable.dat”.

Testing an AutoResponder with a 502 result code

Jumping back to the browser again, we should see that every request for details now appears come back with a 502.

Testing out our AutoResponder

Redirecting Requests

If you were paying attention at the beginning, you'll have noticed that I said that the AutoResponder could respond “among other things.” In fact, if we look at the list of responses we have provided for us, you'll see quite an enumeration of them.

Predefined Responses

Automatic responses are really only a small fraction of what the AutoResponder can do. At it's core, it allows us to take various actions when we get a new request. Using just the stock responses we can drop or reset the connection, add latency, add headers, highlight requests, or even redirect to another host entirely.

By putting a URL in the destination field, we can cause Fiddler to transparently redirect our request to a new location. If we mix that technique with the blanket regex from the previous section, we can redirect all requests from one website to another.

Google, now with 100% more Bing.

With our AutoResponder rule in place, Google's search results look a bit more… Bingish. 3

So, we redirected Google to Bing. Well, that was definitely a war crime.

Wrap Up

We've covered a lot of material this time, some of which probably has no obvious benefit. It does though. Every bit of it. I've used exact and regex requests loaded from .saz files generated on other networks to allow debugging client-side problems where I wouldn't have access to the services themselves. Other times I've used them to avoid the latency of certain requests. Once or twice I've used redirection to get around the Same-origin policy while developing. Every one of these techniques has gotten me out of a jam at least once. Now, I hope it does the same for you.

Footnotes


  1. Specifically, leaving the “Unmatched” checkbox unchecked causes all requests to get the response “[Fiddler] The Fiddler AutoResponder is enabled, but this request did not match any of the listed rules. Because the “Unmatched requests passthrough” option on the AutoResponder tab is not enabled, this HTTP/404 response has been generated.” ↩︎

  2. While this is a lousy example of the power of a regex, it did exactly what I wanted it to. It would have also worked if I wanted to find a URI that contained a GUID, had we wanted to show off a more complex pattern. That would be a little outside the scope of this article. ↩︎

  3. Redirecting Google search requests to Bing either made you giggle or facepalm. There was no third option. ↩︎