Fiddler and the IE9 Release Candidate

I’m delighted to announce that the now-available IE9 RC includes three significant enhancements for users of proxy-based debuggers like Fiddler.

These improvements are:

1. The default Connections-Per-Proxy limit has been raised from 6 to 12, improving performance and in some cases reducing Observer Effect.
2. Debugging of traffic sent to Localhost / 127.0.0.1 now “just works”—configuration changes are not required.
3. Internet Explorer now can be configured to emit information about why a given HTTP request was issued, which helps you understand your web traffic.

I’ll explain each of these three improvements in this post.

Connections-Per-Proxy Limit

Browsers are typically designed to limit the number of connections made to a single server in order to prevent overloading it or incurring other problems. Some browsers have a different limit depending on whether the server being contacted is a proxy server or a normal host (web server). Internet Explorer 6 and 7 apply the “web server” connection limit to proxies as well; the two connection limit those versions use can severely impact your debugging performance when using Fiddler. Users still using those outdated browsers can re-configure the connection limit to mitigate this problem. Internet Explorer 8 limits the connections per proxy to six, which was a welcome improvement, but still could cause performance problems when debugging sites that “shard” their requests to many different hosts. Internet Explorer 9 maintains the existing connections-per-host limit of six, but also includes an specific connections-per-proxy limit which is set to 12 by default. This increased limit should help reduce the impact of connection limits upon your debugging scenarios.

For comparison, Firefox’s default value for the network.http.max-persistent-connections-per-proxy setting is eight, but the FiddlerHook extension kicks this value up to twenty-four.

Proxying Localhost Traffic

The WinINET networking component that is used by Internet Explorer and many other applications will automatically bypass a fixed proxy (like Fiddler) for traffic bound for //localhost and //127.0.0.1 because these “loopback” addresses point to the local machine and traditional proxy servers will not be able to interpret such addresses properly. However, for a debugging proxy running on the local computer, these are perfectly understandable addresses, and when developers are debugging against a local server (like IIS Express or the Visual Studio Test Server Cassini) they often test against these loopback addresses. To proxy loopback traffic from IE8 and below, somewhat awkward workarounds are needed.

IE9 RC introduces the ability to proxy loopback traffic. To do so, simply include the token <-loopback> (pronounced “minus-loopback”) in the proxy bypass list. When WinINET encounters this token in the bypass list, it will remove the loopback addresses (localhost, 127.0.0.1) from the list of hosts that bypass the proxy. Fiddler 2.3 and above automatically set this option when capturing traffic.

The FiddlerHook add-on automatically sets the equivalent version of this option for Firefox; for Opera, you can manually remove loopback addresses from the proxy-bypass list.

The System.Net networking component used by DotNet Framework applications does not yet support the minus-loopback token; I’ve filed a request that they do so, but if this is an important feature for your work, you might consider filing feedback on Connect.

Understanding Download-Initiator

Proxy-based debuggers have a few key strengths—chief among them is the ability to debug traffic from any application that supports a proxy (which is pretty much all of them). One downside of debugging at the proxy layer, however, is the loss of context—it can be very difficult to trace back to determine why a given HTTP request was issued.

Having said that, Fiddler includes a number of features to help you understand context. First, Fiddler attempts to map inbound requests back to the process that issued them. For browsers like Internet Explorer 8, with its “loosely-coupled” process architecture, this often means that each browser tab sends traffic from an individual process. The process information is shown in the Process column in the session list, and FiddlerScript and extensions may access the Process Name and instance ID (aka “PID”) using the Session object flag named X-PROCESSINFO.

Fiddler also uses the HTTP Referer header to help you associate traffic—type the “P” key on any session in the session list to jump back to the “parent” session. Fiddler assumes that the parent session is the session is the most recent request to the URL specified in the selected session’s Referer header. Or, push the “C” key to select all of the “child requests”, those requests after the current request that have a Referer of the currently selected session’s URL.

Internet Explorer 9 includes two new features that help add more context.

First, the Web Browser now sends a meaningful Accept header for most types of downloads. Previously, IE sent a long, registry-generated string for document downloads and Accept: */* for everything else. This limitation made it impossible to reliably distinguish between a request initiated by a <LINK REL=”STYLESHEET”> element and one initiated by <SCRIPT> element. IE9 RC will send the following Accept headers, depending on context:

For compatibility with legacy sites, the legacy Accept headers are sent when a site is configured to run in Compatibility View.

Within Fiddler, you can display the Accept header in the Session list as a column. To do so just for the current session, enter the following command in the QuickExec box:

cols add @request.Accept

This will add a column labelled “@request.Accept” and as each session is logged, the request’s Accept header, if any, will be listed. To add this column every time Fiddler starts, click Rules > Customize Rules. Scroll to the static function Main() block , and add the following line within:

FiddlerObject.UI.lvSessions.AddBoundColumn("Accept", 50, "@request.Accept");

Second, while understanding what class of Element initiated a request is useful, IE9 includes an even more valuable feature that conveys contextual information about why a request was made. You can see this feature at work in the Internet Explorer F12 Developer Tools, which you can open by pressing (you guessed it) the F12 key. On the Network tab, you’ll see the “Initiator” column that provides more information about the context in which a request was made:

This information, by default, is not sent to the network, but you may set a Feature Control Key to emit the information as a custom HTTP request header that Fiddler will see. Most Feature Control Keys, including this one, are simple flags stored in the registry that change the behavior of the Web Browser when set.

• Enable FEATURE_DOWNLOAD_INITIATOR_HTTP_HEADER
• Disable FEATURE_DOWNLOAD_INITIATOR_HTTP_HEADER

You can display this information in Fiddler using the same technique described previously:

cols add @request.X-Download-Initiator

This will add a column labelled “@request.Accept” and as each session is logged, the request’s Accept header, if any, will be listed. To add this column every time Fiddler starts, click Rules > Customize Rules. Scroll to the static function Main() block , and add the following line within:

FiddlerObject.UI.lvSessions.AddBoundColumn("Reason", 50, “@request.X-Download-Initiator");

Then, when you load a page, you will see the initiator information:

Interpretation of these tokens is as follows. First, there’s a token (e.g. image, script, html) indicating what type of content is being downloaded. Next, an indicator of which document object “owns” the download. Information about what element made the request is present, and in some cases, information about what the exact download trigger was. For instance “html tokenizer” means that the download request occurred during the parsing of HTML. “html lookahead” indicates that the Lookahead parser is making the request. On the other hand, “src property change” means that the download occurred because script changed the SRC property of an <img> tag.

I hope that you find these new features useful, and enjoy an improved debugging experience with the IE9 Release Candidate!

-Eric Lawrence