Getting to Know Fiddler: Part VIII: It isn't all rainbows and unicorns

Roughly a year ago I posted what I expected to be the last entry in my Fiddler series. Each of the seven entries had focused on various ways that Fiddler could help improve our development life cycle. They represented the highlight reel.

All isn't perfect though, and where there is a highlight reel, there tends to be outtakes as well. So, here goes: here's a few ways you can use Fiddler to slow down your development process.

Fiddler: The Mostly Transparent Debugging Proxy

Yesterday I had a rather interesting question posed to me: Is there any particular reason that Firefox would ignore a <script> tag on a page?

Okay. That was a bit unusual, but the debugger seemed to corroborate the story: scripts before and after our problematic line were loading. This particular line didn't even get attempted. At least not according to Fiddler.

Why would Firefox ignore this one particular script though? And why hadn't anyone else seen this problem before?

What was different about it? Well, it was the only script that was being loaded from this particular server. But why would Firefox ignore this server?

Scanning back up through the log, it wasn't ignoring it entirely. There were a number of HTTPS tunnels being created to the server. After the tunnel was created, no data was requested. That didn't seem right. After a connect, it should proceed to request the script. Well… unless the connect had a problem.

A few seconds later, things started to click.

Have you tried reproducing this issue without Fiddler running?

A moment later, our heisenbug was confirmed. Without Fiddler, it worked fine. But why?

In order to decrypt HTTPS sessions, Fiddler's root certificate needs to be added to the machine's, or at minimum the browser's certificate store. It hadn't been though, and since Fiddler was effectively a man-in-the-middle, Firefox properly detected that the connection was not secure, in turn terminating the request. JS from the other server worked however, because Fiddler's certificate had manually been approved for connections to the that machine.

Is the Internet Down?

Getting pounced first thing in the morning is never a good thing. Doublely so if my coffee hasn't had a chance to make it from pod to mug. When this happens, it isn't uncommon to start the day with this unusual greeting:

Hey, is the network down? I can't hit ANYTHING.

Good Morning to you as well. The network is fine. This isn't exactly the way I wanted to start my morning, but sure, I'll play along. Let's take a look at the problem.

A quick ping google.com shows that we've got connectivity. Chrome shows a different picture, however: “504 Gateway Timeout.”

Excellent. I might just get my coffee yet.

Did you leave Fiddler running when you left work yesterday?

Yes. The answer is always yes.

Fiddler works by, during its initialization, setting itself as the default proxy for the system. When Fiddler is closed, it removes the proxy configuration it added, allowing requests to go their own merry way again.

So what happens if Fiddler crashes, or the system restarts for any of a dozen different reasons? Nothing. More precisely, nothing removes the proxy configuration. When the system starts back, the default proxy is still localhost:8888. This time, however, there isn't actually a proxy running there, so all of our outgoing requests timeout.

Try starting Fiddler and then closing it again.

We've just given Fiddler a chance to cleanup after itself. Invariably, the network troubles are behind us.

Do What I Mean, Not What I Say

I'm told that the definition of insanity is trying the same thing over and over again while expecting a different outcome. While that might be the case, few things are as maddening as its inverse: repeatedly trying different things but getting the same outcome.

After assisting support with an issue from one of our customers, I returned to my codebase to find myself in a rather maddening position: no matter what changes I made to a certain service end point, I couldn't observe any behavioral changes.

My descent into madness started with simple recompiling. Then clean and rebuild. Then connecting the debugger. Oddly, I couldn't debug requests for this particular end point.

Ah! A DLL must be cached by IIS. Bounce IIS. Nothing. Manually delete the cache. Nothing. Stop the web server. Nothing. I still get the old results.

Wait. IIS isn't running. How am I getting ANY response at all? It's like it… oh.

In part six of our series, we went over how a few carefully placed rules for Fiddler's AutoResponders could “allow debugging client-side problems where I wouldn’t have access to the services themselves.”

More precisely, how it could aid the kind of debugging that I had just performed for support. The problem was that Fiddler does exactly what you tell it. And if you say “Always respond to this request with this exact response”, that's what you get, even when you are done debugging.

After removing the latent AutoResponder rules added for the support ticket, services immediately started behaving as expected again.