Fiddler PowerToy - for Load runner

Fiddler PowerToy - Part 1: HTTP Debugging

Summary: Learn how to use the Microsoft Fiddler HTTP debugger when developing and testing Web applications and clients. (7 printed pages)

Contents

Introduction
Getting Started
Using Fiddler
Using Fiddler for Performance Testing
Using Fiddler for Debugging
Extending Fiddler
To be continued...

Introduction

Have you ever found yourself wondering how Microsoft Internet Explorer interacts with your Web application? Have you encountered a strange performance bottleneck that you can't track down? Are you curious about which cookies are being sent, or what downloaded content is marked as cacheable?

Microsoft Fiddler can help you answer these questions, and many more. Fiddler is an HTTP debugging proxy that logs all HTTP traffic between your computer and the Internet. Fiddler enables you to inspect all HTTP traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler is much simpler to use than NetMon or other network debuggers because it exposes only HTTP traffic and does so in a user-friendly format.

Fiddler includes a simple but powerful Microsoft JScript .NET event-based scripting subsystem flexible enough to support a broad array of HTTP debugging tasks. Written in C# on the Microsoft .NET Framework, Fiddler is available as an unsupported PowerToy for Internet Explorer.

Getting Started

Installation

• Fiddler requires Microsoft Windows 2000 or above, and approximately 10 megabytes of disk space.
• First you'll need to ensure that you have the .NET Framework version 1.1 installed. If you don't have it yet, you can visit Windows Update to download it.
• Next, download Fiddler from http://www.fiddlertool.com.
• When installation successfully completes, you'll find the Fiddler icon <쪴Ϫ>on the Internet Explorer toolbar.
• If the toolbar icon is missing, right-click the Internet Explorer toolbar and click Customize. You can also launch Fiddler from the Start menu.

Running Fiddler

After you start Fiddler, the program registers itself as the system proxy for Microsoft Windows Internet Services (WinInet), the HTTP layer used by Internet Explorer, Microsoft Office, and many other products. You can verify that Fiddler is correctly intercepting requests by checking the Proxy Settings dialog. From the Internet Explorer main menu, click Tools, click Internet Options, click Connections, click LAN Setting, and finally click Advanced.

Figure 1. Internet Explorer proxy settings

As the system proxy, all HTTP requests from WinInet flow through Fiddler before reaching the target Web servers. Similarly, all HTTP responses flow through Fiddler before being returned to the client application.

Figure 2. HTTP traffic flow

When you close Fiddler, it unregisters itself as the system proxy before shutting down.

Using Fiddler

Views

Fiddler's user interface contains a list of HTTP sessions and three tabs that allow you to view different aspects of the selected sessions.

Figure 3. The Fiddler user interface

Using Fiddler for Performance Testing

HTTP Statistics view

By exposing all HTTP traffic, Fiddler easily shows which files are used to generate a given page. Using the Statistics page, the user can multiselect to get a "total page weight"—the number of requests and the bytes transferred.

Figure 4. Statistics view

Additionally, by exposing HTTP Headers in the Session list, the user can see whether pages are missing HTTP Expiration headers that permit client or proxy caching. If a response does not contain Expires or Cache-Control headers, it might not be cached by the client.

Figure 5. HTTP Expiration column

Using Fiddler for Debugging

In addition to seeing all HTTP requests and responses, Fiddler supports the notion of breakpoints. When the Enable Single Step Debugging option is checked on the Rules menu, or when the properties of the HTTP Request or Response match the target criteria, Fiddler can pause HTTP traffic and allow edits. This feature proves useful for security testing, as well as for general functionality testing, because all code paths can be exercised.

Figure 6. Session Inspector view

Users can handcraft an HTTP request on the Builder page, or they can use a drag-and-drop operation to move an existing request from the session list to the Builder page to execute it again.

Extending Fiddler

Fiddler is extensible using the .NET Framework. There are two primary mechanisms for extending Fiddler: Custom Rules and Inspectors.

Extending Fiddler Using Scripted Rules

Fiddler supports a JScript .NET event-handling engine that allows the user to automatically modify the HTTP request or response. The engine can modify the visual appearance of the session in the Fiddler user interface (UI), to draw attention to errors or to remove uninteresting sessions from the list altogether.

The following sample code changes the UI to purple to show where cookies are uploaded.

static function OnBeforeRequest(oSession:Fiddler.Session)

{

   if (oSession.oRequest.headers.Exists("Cookie")){

      oSession["ui-color"] = "purple";

      oSession["ui-bold"] = "cookie";

   }

}

Extending Fiddler by Adding Inspectors

The user can add plug-in Inspector objects written in any .NET language. RequestInspectors and ResponseInspectors provide a format-specific or an otherwise specialized view of the HTTP request or response.

Inspectors can be read-only (RO) or read-write (RW). If an Inspector is read-write, it can be used to modify the HTTP request or response before the server or the client receives it.

By default, Fiddler ships with the following Inspectors:

Request Inspectors

• [RW] Headers—Shows request headers and status.
• [RW] TextView—Shows the request body in a text box.
• [RW] HexView—Shows the request body in a hexadecimal view.
• [RO] XML—Shows the request body as an XML DOM in a tree view.

Response Inspectors

• [RW] Transformer—Removes GZip, DEFLATE, and CHUNKED encodings for easier debugging.
• [RW] Headers—Shows response headers and status.
• [RW] TextView—Shows the response body in a text box.
• [RW] HexView—Shows the response body in a hexadecimal view.
• [RO] ImageView—Shows the response body as an Image. Supports all .NET image formats.
• [RO] XML—Shows the response body as an XML DOM in a tree view.
• [RO] Privacy—Explains the P3P statement in the response headers, if present.

To be continued...