Using Fiddler as a simple http development server


Fiddler’s AutoResponder

Lately I’ve been playing around with Fiddler (version 2.3.4.4). Fiddler it is a free packet analyzer for web debugging HTTP and HTTPS traffic. It acts as a proxy between your web browser and a web server so you direct your web browser to it using a plugin (for Firefox) and it enables you to analyze and tamper with the HTTP requests and responses between the server and client. Very cool and very useful.

Screenshot of Fiddler user interface

Although Fiddler is packed with lots of useful functionality for analyzing and tampering with HTTP traffic I also found a new use for it when working with jQuery and JSON.

Just recently I was looking in to the jQuery UI Autocomplete plugin and wanted to play around with the functionality that uses JSON returned from the server. To simplify, my idea was to test the Javascript client code without writing any server-side code. Of course I could have simulated something similar by creating JSON in the Javascript code, but that’s not what I wanted here since I it was important to get familiar with the code making the JSON request over the wire. The client code that I ended up creating with can easily be deployed to a proper web server without modification.

Fiddler’s AutoResponder functionality

Fiddler includes something called AutoResponder. As the name gives away, you use it to automatically send a response to a calling browser client. The idea is to get Fiddler to intervene and return something useful when the browser makes a request for a particular URI. In my case I was aiming at making Fiddler return static JSON to the browser when making a call to http://server.anywhere.com/json. I created the contents of a HTTP response that I wanted to be returned to the browser in a file and stored it to disk. Then I redirected the AutoResponder to return this file when the browser request was made. I made no modifications to my hosts file.

Screenshot of the configured AutoResponder in Fiddler

Very simple really. As you can see from the screenshot above. I have configured two URIs. One is for the index.html file and the other for the JSON “service”. When one of the URIs is hit by the browser the corresponding file on the file system will be returned. The AutoResponder also lets me set latency so I simulated a 3000 ms sleep for the service before responding.

The tricky part was actually making a valid HTTP file for the JSON service. In my case it looked as shown below and saved as UTF-8. For this purpose I found Notepad++ to be very useful. When selecting the actual HTTP content text in the file it tells you exactly how many bytes are needed as value for the content length header. In my case it was 87 bytes.

A screenshot of calculating the number of bytes in the html response with Notepad++

Now, when opening the browser and making a call to http://server.anywhere.com/json the AutoResponder will step in and return the JSON to the browser. The code I used for invoking the call to return the JSON is shown below. Of course this code ignores what is typed in the input field and results the same JSON regardless, but for my purpose that’s okay.

<html>
    <head>
        <title>jQuery Autocompletion with JSON call</title>
        
        <link rel="stylesheet" 
              type="text/css" 
              href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/themes/ui-lightness/jquery-ui.css" />

        <script type="text/javascript" 
                src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>
              
        <script type="text/javascript" 
                src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/jquery-ui.min.js"></script>
        
        <script type="text/javascript">
            $(document).ready(function() {
                $( "#tags" ).autocomplete({
                    source: function(request, response) {                                               
                        var url = "json";
                        var param = "";
     
                        $.getJSON(url, param, function(data) {
                            response(data);
                        });
                    }
                });
            });
            </script>        
    </head>

    <body>
        <div class="demo">
            <div class="ui-widget">
                <label for="tags">Tags: </label>
                <input id="tags" />
            </div>
        </div>
    </body>
</html>

Same origin policy

When requesting data using Javascript there are some security limitations that the browser enforces, one being the same origin policy. This policy restricts Javascript from accessing JSON from a different domain than the one hosting the script making the call. So if I want to request JSON from http://server.anywhere.com/json then the Javascript which makes the JSON call needs to originate from the same domain, http://server.anywhere.com/.

Again, AutoResponder to the rescue. I set up the AutoResponder to call my html page (the file which includes my Javascript) and mapped this file to a known URI from the same domain as the simulated JSON service. When the browser makes the initial request to http://server.anywhere.com/index.html, Fiddler’s AutoResponder intercepts the request and redirects a file from my local drive to the browser. The browser thinks it’s getting files from the web, but in fact Fiddler is just redirecting files from my local hard drive. When the time comes to trigger the script requesting the JSON from the simulate service at http://server.anywhere.com/json the AutoResponder steps in and returns my static JSON file. Notice the host name in the screen shot below and the jQuery autocomplete plugin in action.

Screenshot of the resultsing page in browser

Maybe a little clumsy to set up, but once done you can tweak everything in the files and no need to deploy any code or install any servers. I thought it was a nice touch that the AutoResponder can simulate latency so you can test any timeout functionality on the client side without having to add thread sleeps which usually is the case for service development.

Conclusion

I am really happy with Fiddler. I have used WireShark in the past, but for working with HTTP traffic it is a little too heavy. Fiddler has a lot of interesting features for web development and analysis work.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s