Fiddler Breakpoints

Fiddler is an immensely powerful, and easy to use web debugger. It can do just about anything I’ve thought of, and tons of things that I still don’t know what are. Its my go to when doing any kind of web development. A lot of people don’t know just how powerful it is, or how much it can do. So this time, I thought I’d explore Fiddler’s breakpoint system.
If you already understand why you would need to use Fiddler’s breakpoints, or why you can use them to mock errors, or just don’t care about this longwinded section of the blog post, skip ahead.
Why would we need to use Fiddler’s breakpoints? As in most cases, because its useful. We can use Fiddler to test server failures without actually having to have a real server failure. We can test that the client responds properly when the server has a failure. We can test what happens when an iPhone is doing something, and suddenly loses cell service.

We can test things in a more efficient, more isolated manner. Whether you use Fiddler’s breakpoints (or an alternative application’s competing feature) gives us the tools we need in development, and quality assurance to do a better job.

Quick note about HTTPS traffic. When doing HTTPS traffic, there will be an HTTP CONNECT and then a subsequent HTTPS request/response. When using Fiddler’s automatic breakpoints, the HTTP CONNECT can get annoying. If you add something like this

to your
OnBeforeRequest
in your custom rules, it’ll reduce the amount of clicking. Since HTTP traffic will not show up in the UI, it will not get stopped by the automatic breakpoints. Just make sure you remove this when you want to see HTTP traffic again.

You can also create breakpoints to follow any complex criteria by using custom rules. You can use
x-breakrequest
or
x-breakresponse
on the Session object to do programatic breakpoints.

 

 

You can get more information here.