Mark Needham

I mentioned previously that we're making use of Fiddler quite a lot on my current project, mainly to check the traffic going to and from the service layer, and I'm quite curious how it actually works.

In particular I wanted to know:

• How we're able to route requests through Fiddler and then through the corporate proxy
• How proxy settings work differently for Firefox and Internet Explorer

As far as I'm aware the source code for Fiddler isn't available so a colleague and I tracked the various proxy settings when Fiddler was turned on and off and also had a look at some registry settings.

As Internet Explorer is a WinInet based application it looks at the Local Area Network settings to check whether there are any proxies that it needs to route requests through. I believe any proxy defined in here would be known as the 'system proxy'.

We noticed that our application also routed its requests via the proxy defined in the LAN settings as well – it is a .NET application but I guess that even applications written in other languages but running on windows would make use of the system proxy too?

Firefox has its own proxy settings which are accessible via the preferences menu of the browser and are then configurable from the 'Advanced -> Network' tab.

If another proxy is defined in the LAN settings when Fiddler starts up it takes this value and stores it somewhere (in memory presumably) as the 'Upstream gateway proxy' (Tools -> Fiddler Options -> Connections) which it directs requests through before they go out to the internet.

It then changes the proxy defined in the LAN settings to point to itself – typically port 8888 locally.

The 'Upstream gateway proxy' always seems to be the same as the 'system proxy' so if a different proxy is defined on FireFox than Internet Explorer this won't be used even though on the latest version of Fiddler when it starts up the FireFox proxy will be changed to point to Fiddler.

When Fiddler is shut down it reverts the proxy settings to how they were previously although (unsurprisingly) if it crashes then we are left in a state where requests are being sent to 'http://localhost:8888′ and there is no application listening on that port anymore meaning that we end up with a 'Cannot find server or DNS Error'.

Restarting Fiddler gets rid of that problem although the 'Upstream gateway proxy' usually seems to get lost so if we want to make requests out to the internet then we need to go and reset that in our LAN settings before restarting Fiddler.

If there's anything inaccurate in what I've written or if you know of any resources that would help me understand this better if you let me know in the comments that'd be cool!

We've been using Fiddler to debug the requests and responses sent via web services to a service layer our application interacts with and it works pretty well when you run the application using Cassini but by default won't work when you run the website through IIS.

The key to this as one of my colleagues (who gives credit to Erik) showed me today is to ensure that IIS is running under the same user that Fiddler is running under which in our case is the 'Administrator' account.

The default user for IIS is 'Network Service' but as far as I'm aware you can't actually launch an application such as Fiddler from that account.

We therefore changed IIS to run under the 'Administrator' account on local development machines since this is where we typically use Fiddler.

To do this we need to:

• Create a new application pool by going to the 'Application Pool' menu in IIS Manager and setting the 'Identity' of the new pool to be the Administrator account.
• Change the application pool for our application to match that new application pool.
• Go to 'Computer Management > Local Users and Groups > IIS_WPG' and add the Administrator as a user of that group.

Fiddler should now capture requests/responses!

I'm not sure running IIS as the Administrator account is such a great idea although it's only on the local development environment so maybe it's a reasonable trade off for the benefits we get from being able to debug web service communication.