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:
- The default Connections-Per-Proxy limit has been raised from 6 to 12, improving performance and in some cases reducing Observer Effect.
- Debugging of traffic sent to Localhost / 127.0.0.1 now “just works”—configuration changes are not required.
- 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. Read more: Fiddler Web Debugger
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. Read more: Fiddler Web Debugger
Posts
0 comments:
Post a Comment