Wednesday, 25 September 2013

Alternative Uses for Fiddler

A few days ago I realised that one of my use cases for Fiddler, did not stem from a need for debug proxying.

Since I work on a variety of client sites, I periodically have issues with restrictive proxy servers where a .pac file somewhere sets up the browser config, and you have username and password issues etc. etc.

In those circumstances some tools need configuring to use the client site proxy - I recently tried to use httpgraph based on a suggestion from James Lyndsay

Like many tools that allow you to configure the proxy httpgraph has a url and port. Nothing else. No http or https config, no usernames, no passwords.

And like many tools, it didn't work out of the box with a restrictive client side proxy.

So, choose your own adventure time:
  1. Game Over? Stop using the tool?
  2. Mess around with config settings for a few hours trying to get it to work?
  3. Use Fiddler?
1. Stop using the tool

You sit back in your chair and sigh. Nothing ever works out of the box. Why don't vendors make technical tools easy to use. Oh well, nothing lost except a few minutes downloading the tool. Time to get on with the hum drum day to day work with no advantages.

You finish your tasks, and complete the day, but leave with a nagging sense of unfulfilled potential. 

Game Over.

2. Mess around with the settings

You try everything you know. You tweak the registry. You setup system variables. You run the app from the command line with -D proxy settings. You even mess around with the Windows Routing table. Sadly to no avail. You look at the clock. Crikey, its 4pm already, and you still have to finish the test strategy, distribute it, add it to version control, setup the review meeting, and respond to emails. 

Looks like you need to get your priorities in order and stay here till midnight.

You Lose. Game Over.

3. Use Fiddler

"I'll do what I always do first" you think. 

Start up fiddler.

Fiddler hooks in to the Windows internet controls seamlessly, it handles all the proxy stuff, including passwords. Then I'll configure the new tool, to use Fiddler as its proxy. This way the tool has a simple proxy server to connect to, where I control the port and protocol config, and as a bonus, I can see the traffic sent.

So you start up fiddler, and point your new tool's proxy to "127.0.0.1:8888", the Fiddler defaults. 

You know you can use other Fiddler urls if this doesn't work 
But it does work.

Leaving you plenty of time to get on with today's necessary todo list items.

A Double point win. Congratulations. Adventure completed.

Do you have any use cases for debug proxies that you take for granted, that don't immediately involve debug proxying? If so, leave a comment to let me and the world know.

3 comments:

  1. An example of Fiddler as a utility for getting stuff done easier due to outside restrictions.

    I test mobile apps. When I work from home, I VPN to the office for today's build of the various apps. With the VPN connected on the laptop and Fiddler running to allow external connections, a device connected to said Fiddler proxy can install the latest apps directly from the server in the office.

    ReplyDelete