Minor Update to beta

I've made some minor fixes to the Latest Beta.

1> Better support for installs on Longhorn. The old version crashes during setup because an ActiveX control crashes regsvr32. I'm investigating, but for now, Fiddler on LH does not have the HexView. Also, Fiddler should no longer crash when disconnecting.

2> Support for configuration of the hotkey. By default CTRL+ALT+F brings up Fiddler's main window, but apparently CTRL+ALT is equivalent to ALTGr, a modifier used by many international users. So, you can now change the hotkey via the registry.

Using RegEdit, create new DWORDs under HKCU\Software\Microsoft\Fiddler:

Set Hotkey to the keycode (e.g. hex 48 is "H").
Set HotkeyMod to the modifier (e.g. 1=ALT, 2=CTRL, 8=Windows, 9=Windows+ALT, etc). Restart Fiddler and the new hotkey should take effect.

New Beta

I've posted a minor update at http://www.fiddlertool.com/dl/fiddlerbeta.exe. The only significant change is making menu options available on the main menus that were previously only available on the HTTP Sessions context menu.

New version

A new beta version of Fiddler has been posted:

http://www.fiddlertool.com/dl/fiddlerbeta.exe

It fixes a few issues in the Inspector plugins system. If you find any bugs, please contact me immediately, because I'd like this beta version to become the default version.

Thanks!

Other stuff I've written

If you like Fiddler, you might like some non-Microsoft stuff I've written over the years. Please see http://www.bayden.com/other/ for a list of utilities and tools.

Reverse-Engineering HTTP Attacks

David Ross over in the Windows Security group has written a good paper about using tools like Fiddler and others to take apart HTTP based exploits.

Good reading.

http://blogs.msdn.com/dross/archive/2005/06/13/428590.aspx

Using Fiddler for performance measurement

One of the comments on my Fiddler Performance article was

Using HTTP proxy for debugging sounds like 'destructive measurement': the measurement affects the results! IE sends different requests to proxies and to web servers directly.

This is partly true. One thing you might have noticed was that I didn't talk about using Fiddler to capture request timing: It's possible (via oSession["X-TTFB"] and oSession["X-TTLB"]) but it can be very misleading to measure this way. Why?

In Fiddler 0.9 and below, Fiddler never reuses sockets for anything, which may dramatically affect the performance of your site. Fiddler 0.9.9 (the latest beta) offers server-socket reuse, so the connection from Fiddler to the server is reused. Note that the socket between your browser and Fiddler is not reused, but since this is a socket->socket connection on the same machine, there's not a significant performance hit for abandoning this socket.

So, Fiddler isn't suitable for timing. But this doesn't impact your ability to check compression, conditional requests, Expires headers, bytes-transferred, etc. Other than the actual timings, the browser does not behave much differently with Fiddler than without (and chances are good that your visitors are using some type of proxy).

1. The browser will often send Proxy-Connection: Keep-Alive; this isn't sent without a proxy.
2. IE will send Pragma: no-cache if the user hits F5 or clicks the refresh button; without a proxy, you have to hit CTRL+F5 to send the No-Cache value.
3. The fact that a client-socket is abandoned can lead to extra authentication roundtrips when using the NTLM connection-based authentication protocol.

I'll post any additional differences if I come across them, but in general, you should find that Fiddler is suitable for many types of performance investigations.