Debugging JavaScript/CSS/HTML from a remote server in remote browser with Fiddler

Configure Fiddler as a remote proxy to facilitate debugging on virtual machines.

As Aria Templates team, we provide a JavaScript framework used by numerous web applications in Amadeus. We may not be deeply familiar with some of that applications, and do not have them installed on our development machines, yet since they use our framework, we’re frequently asked for support to help on debugging some of the applications’ problems.

Debugging rich internet applications that are not served from your local webserver, and especially on a browser that you don’t have physically on your computer (e.g. IE9 or IE10, while you’re on Windows XP) might be a challenge. However there are tools like Fiddler which help greatly, and if configured properly, give us the possibility to work directly on our computers to debug, fix and test the problems without redeploying anything on the staging servers.


What is Fiddler

Fiddler is a (Windows-only) web debugging proxy with extended capabilities to alter the traffic for debugging purposes. You can create ad-hoc local files that will be returned for certain HTTP requests (e.g. altering specific file), or write a few lines of JScript.NET code (Microsoft’s flavor of JavaScript with some classical-OOP additions) to redirect requests matching certain regex to another URL / machine / possibly your localhost server.



To start with, you can install Fiddler on your machine, and once enabled, whole traffic from proxy-aware programs will go through it. Regarding the browsers: Chrome, Safari and IE integration is seamless; for Firefox there comes an add-on with Fiddler; Opera must be started only after Fiddler is started and activated.

This is all good, but there comes a moment when you need to test a browser you don’t have on your machine – e.g. debugging on a virtual machine with a particular version of Internet Explorer. You can obviously install Fiddler on all of your virtual machines, but once you develop your specific set of extensions, Fiddler scripts etc., maintaining them on all of those machines (and choosing same custom redirection settings from the Fiddler menu for all those instances — especially painful after a change in Fiddler script, which resets the hand-activated settings to defaults) becomes not that handy.

Luckily, since Fiddler is in fact a proxy server, you might configure your external virtual machines to target Fiddler on your machine as a proxy. That way, after properly configuring all the VMs, you can edit your JavaScript / HTML / CSS on your development machine, and change various Fiddler’s settings only once, and then only refresh a page on all remote browsers!

Let’s see an example how we can facilitate debugging in Internet Explorer running on a remote machine.


Configuring Fiddler as a remote proxy

First, you’ll need to alter Fiddler’s settings and restart Fiddler.


Check from your local machine and a remote machine that you can access Fiddler’s web server:


On a remote machine, open “Tools” > “Internet Options” in Internet Explorer to set up a proxy:


That’s it! Now open any page on a remote machine, and you will see the traffic in Fiddler window on your local machine. The only drawback is that for remote traffic, process name will not be displayed.

One of the useful things you can do with Fiddler is injecting a debugger; statement in a part of JavaScript code you may want to inspect. This might be a lot easier than looking for a proper place to put a breakpoint while in a browser (and you will need to do it in each of the instances of the browser).


Creating a simple autoresponder in Fiddler

Let’s get our hands dirty and try it out.

I’ll create an ad-hoc webserver on my machine at jakub:8000 serving a demo.htm page which loads a script from demo.js (Hint: you can use python -m http.server command to start a web server on port 8000 serving a current working directory if you have Python 3 installed). This is to simplify things for the demo sake, but think of it as an external webserver – let’s pretend I don’t have access to that code on my machine.

I’ll make a deliberate mistake there which creates a syntax error in IE7: add a trailing comma in an object literal:

var fruit = {
oranges : 2,
apples : 3, // trailing comma produces a syntax error in IE7 and older
document.write("We have " + fruit.apples + " apples.");

Let’s launch it in IE7 on a virtual machine:


Now let’s have a look at Fiddler sessions list. First I launched a page in a local instance of Chrome, then in IE7 on virtual machine (it’s remote hence process name field is empty):


I can create an autoresponder (above, right hand side section), to intercept the request coming for demo.js and serve my own file instead. To do that, I can drag an entry from session list to the Autoresponder tab (make sure to tick “Enable automatic responses” and “Unmatched requests passthrough” in the Autoresponder tab first), and then choose “Generate file” from context menu. Let’s create an autoresponder file and change our code, getting rid of a trailing comma in the array, and refresh the page in the browser:


As you can see, the traffic going through autoresponder has a different background color. Let’s get back to our IE7:


We’ve just fixed a remote problem, playing on a local development machine without redeploying anything. Of course this was just a trivial example, but same flow applies to much complex problems.

The problem has been solved for IE7, but will the fix not break things in other browser and other versions of IE? Just keep the autoresponders, configure the proxy accordingly on virtual machines, and launch the page in other browsers. No regressions? Head to your IDE / command line and check-in the fix!


That’s cool, I want to know more!

For more info on Fiddler, check out the tool’s website and Eric Lawrence’s blog.

3 responses on “Debugging JavaScript/CSS/HTML from a remote server in remote browser with Fiddler

  1. GAURAV Team Member
    on 19 March 2013, 9:37 am

    Thanks for the post… really helpful

Leave a Reply

Your email address will not be published. Required fields are marked *