Top 6 Fiddler tips for developers

Fiddler is one of those development tools that makes me wonder what I did before it was around. If you’ve been hiding under a rock for the last decade (or just getting into web development) Fiddler is a web debugging proxy and it’s super useful for developers to see all the HTTP network traffic. Once you start Fiddler up on a machine all web traffic (HTTP requests/responses) are routed through Fiddler before heading out to their destination, and then the responses come back through Fiddler and are routed back to the calling application.

This means Fiddler allows you to inspect all web traffic going out and coming back in. More than that however it lets you.. well.. fiddle with it!

All web traffic is shown much like a log listing in the Fiddler GUI.

I find most developers are familiar with the basics of using Fiddler to observe and do basic inspection of the requests and responses that are happening. I see far fewer developers utilizing some of the really powerful manipulation aspects that Fiddler is capable of.

These are some of the scenarios that I use Fiddler for that I think are really powerful to know about as a developer. I’ve been wanting to write this post for a long long time. I hope you pick up at least one new tip from this list!

#1 Replay a request to quickly debug back-end web methods

This great for when you are developing code that is triggered by a HTTP request, such as a Web API controller method or an Azure function.

Here’s the scenario, you have some front-end app that creates a request to your back-end code (Web API, Azure Function etc). You are debugging the back-end code and trying to determine what’s going on but each time you need to use the front-end (as a user) to get it into the state of issuing the request to your back-end. Sometimes this isn’t trivial to just mock up using something like Postman due to headers, authentication tokens, dynamic values etc.

This is a great scenario for using Fiddler’s ability to replay a request.

Here’s a super simple controller method so you can see the mechanics. It just returns the current server time.

Imagine we are trying to debug this, we run the project on our dev machine with a breakpoint in the controller code. Then we need to trigger our method by using whatever the front-end app is. If we have Fiddler running we will be able to see this request come through from the front-end app to our controller method.

The code will stop at our breakpoint and we can try to debug and figure out what’s going on in our code.

After you’ve gone through one execution of the method, when you want to trigger it again you don’t have to manually go through the front-end app again. Just go to request in Fiddler, right click | Replay | Reissue Requests

Fiddler makes a copy of the original request including headers and body content and makes the request.

This will result in the back-end method being called again and you are quickly into debugging again without having to worry about using your front-end app to have the request issued.

#2 Replay a request with modified request content

This follows on from the above scenario of being able to quickly get into debugging your back-end code triggered by a HTTP request. It’s great to be able to replay a request but what if your request contains a lot of dynamic data, either in headers, in the URL parameters or it may be a POST request with complex objects serialized in the body?

This is where we can use Fiddler’s super powerful Composer tab.

Select the Composer tab (on the right side of the Fiddler interface)

• 

You can then drag/drop any request from the left hand side. This takes a copy of the request (just like it did when we replayed an existing request).

Instead of executing the request immediately, you get to play with it in the composer tab. You can edit any part of it, the URL, headers or body.

Click execute and the request will be made and you can inspect it like any other request.

#3 Change the response of a service your code is calling using AutoResponder

You’ve written code (either front-end running the browser, or back-end running on a server) and it makes HTTP calls out to other services. The AutoResponder in Fiddler allows us to intercept specific calls that match a rule and return a pre-configured response without the call actually being made. This can be useful in many scenarios such as:

• Calling a service that takes a long time to return data
• Specifying your own data values in the response that would be hard or not possible to configure in the service so you can test how your code would behave for these values
• Testing error and edge case scenarios
• Being able to run your code without the dependent service being available.

I find the easiest way to set up an AutoResponder is to actually go through the process of making the actual call once with Fiddler running.

Here we can see our front-end app is making a call to our service (Web API controller from the previous examples). We can see the response of this request at the bottom right of the image where we return “Hello world…” and the server time.

Now select the AutoResponder tab, then drag and drop the existing request from the left hand side onto the AutoResponder tab.

If sets up an EXACT match rule which means if Fiddler sees a request with the same type to the same URL it will match this rule and a pre-configured response will be returned. But what response I hear you ask? Fiddler has taken the response from the request you drag/dropped. You can view/edit the response by right-clicking the rule | Edit Response…

Here you have full control to manipulate the response that will be sent back. Notice the JSON tab, if the response contains a collection of complex serialized object data this tab will be your friend.

So let’s change that response so we can see it’s actually working.

Make sure you enable rule and allow unmatched requests to passthrough (these will be off by default and the rule won’t be triggered)

Time to test it out, let’s return to our front-end app and get it to make the call to the service. We see the call come in and this time the breakpoint in the back-end service won’t be hit (because it doesn’t receive the request) instead if we inspect the response we will find our pre-configured response has been returned instead.

At this point you can see we don’t even need the back-end service running. We are effectively mocking the service and have full control over the response data.

#4 Manipulating requests and responses in flight with breakpoints

I call this one “The ultimate fiddle”. This gives you the ability to pause a request after the calling application has made it, inspect and manipulate it before either passing the manipulated request on to its intended destination, or provide your own response and not call the service at all. Then on the return trip you can do a similar thing with the response. We can pause the response as it comes back from the service, inspect or manipulate it before passing it back to the calling application. Sounds awesome right? IT IS.

All we need to do enable the breakpoint feature under Rules | Automatic Breakpoints | Before Requests

Now lets get our front-end app to make the call to the back-end service again. This time we see something different in Fiddler. We can inspect the request but it is paused (it has a different icon in the list). Here we have the opportunity to edit the request content (add URL parameters, change headers, change body if it was a POST). You could even redirect it off to another URL somewhere else!

You have 3 options at this stage after you’ve had the opportunity to edit the request:

• Break on Response – this will send your request off and pause (break) again when the response is received from the service.
• Run to Completion – this will send your request off , then pass the response back to the calling app without pausing
• Select a Response and Run to Completion – you can choose a pre-configured response from the drop-down and then select Run to Completion. The pre-configured response works much like AutoResponder in that the call is not made to the service and you provide the response to send directly back to the caller. What is super handy here is that Fiddler comes with some pre-baked responses for sending back common error code like 503 and 504. This let’s you test how your code handles scenarios where a service is temporarily unavailable.

I’m just going to Break on Response, we then see the service being called and the response coming back.

We can then manipulate the content of the response before clicking Run to Completion at which time the response is passed back to the calling application.

After reading all of this you may be saying to yourself, but I can do something similar to this in Visual Studio by setting breakpoints and changing variables on the fly. The big difference here is that you can do it without having access to the source code of either the front-end or back-end. In fact neither side knows that you are sitting in the middle manipulating the conversation that’s going on, and it’s so much easier that having to have the different projects running in Visual Studio. This makes a big difference, especially when that service you are calling isn’t yours.

#5 Use Fiddler to test how code handles HTTP error codes

We’ve really already covered the features that you would need to use. Either set up an AutoResponder rule so that you return a specific error response when a matching call is made OR what I find more convenient, use the breakpoint functionality to break on the request and select a pre-configured error response and Run to Completion. This prevents the call from even going out to the service and immediately returns the error response.

#6 Slow things down and test those UI loading spinners

Want to know how your app behaves over a slow connection or if a service you are calling takes a long time to respond? Fiddler makes this super easy. Since all requests from your code are going through Fiddler, you can simply delay the requests being issued under Rules | Performance | Simulate Modem Speeds

We’ve only just scratched the surface. Fiddler is awesomely powerful and I’m finding new capabilities all the time.

Share your Fiddler tips

Have you got a tip that should be on my list or that others may find useful? Please share in the comments below.