Yesterday, an updated Fiddler Beta was released, targeting .NET2 or .NET4. This update contains the usual set of bug fixes as well as a number of small features that I hope you’ll find useful.
Fiddler has always permitted you to customize the set of displayed columns to show information you’re interested in directly inside the Web Sessions list. However, adding new columns isn’t as easy as it could be, and this Beta includes the first steps toward simplifying this process. Simply right-click on the column headers and choose Customize columns…
A simple popup will open to allow you to easily add new columns based on the contents of Request headers, Response headers, or Session flags. The Name box offers autocomplete for commonly-referenced header and flag names:
When you click Add, the new column is added:
If there are fewer than 500 entries in the Web Sessions list, the new column’s contents will be automatically filled for the existing items; otherwise, items can be manually updated by selecting them and pressing F5.
The Windows8 EnableLoopback utility included with Fiddler v4 has been updated to support command-line arguments to automate its operation. It now supports the following arguments:
-all Enable exemptions for all AppContainers
-none Remove all AppContainer exemptions
-manual Launch GUI but skip listing AppContainers
<no arg> Launch the GUI
Fiddler Echo Service
Unknown to many, Fiddler operates an “echo service” webpage which you can visit at http://localhost:8888/ or http://ipv4.fiddler:8888 when Fiddler is running. Ordinarily, this page simply echoes back whatever HTTP request it receives, and provides links to the instructions for configuring Fiddler as a reverse-proxy and to a downloadable copy of Fiddler’s root certificate.
In the latest beta, the echo service page has been updated to support simplistic “faking” of server responses. The feature works by examining the URL path and returning any HTTP response code it finds.
For instance, http://localhost:8888/404 will return a HTTP/404 response, while http://localhost:8888/201 will return a 201 response. If you use any redirect status code (e.g. http://localhost:8888/304) Fiddler will include a Location header so that the client has something to follow.
For non-trivial server faking, use the AutoResponder or FiddlerScript instead.
The Echo Service may be disabled entirely by setting the fiddler.echoservice.enabled preference to false.
Replay and Verify
The Web Sessions list’s “Replay” context menu now contains a new Reissue and Verify command that offers a simple way to perform quick unit-tests of Web Services or pages.
After selecting one or more Web Sessions in the list, hit V to reissue the chosen requests. As each response is returned, Fiddler will verify that its Response code and uncompressed / unchunked response body bytes match the original response to the original request.
For instance, when verifying Sessions #12, #13, and #15:
…you can immediately see that only #22 was verified as an exact match for its original session, #15. The new session is marked in green and the original is crossed out. In contrast, the responses for Sessions #20 and #21 do not match their originals, and a succinct explanation is shown in the Comments column. You can then use the Compare command on the Web Sessions list’s context menu to compare the new response to the original to determine whether a regression has occurred.
Fiddler’s Reissue and Verify feature offers a lightweight way for you to ensure that a set of web requests have not changed in behavior. By storing a set of “known good” responses in a SAZ file, you can later replay and verify those responses after making updates to your services.
Of course, some scenarios, particularly those involving authentication and cookies, might not verify correctly with Fiddler’s simplistic matching. For more intricate automated test scenarios, you’ll want to look into more sophisticated products like Telerik’s Test Studio.
Speaking of Test Studio…
Test Studio Load Test Import
After joining Telerik’s testing tools division, I’ve occasionally been called upon to help pitch in on support calls to help troubleshoot unusual server behaviors encountered when customers run their tests. Customers often provide HTTP/HTTPS captures of the faulting test-run using FiddlerCap, after configuring system services to proxy their traffic for capture.
When diagnosing failing tests, it’s often useful to be able to compare the failing results against the original traffic that was used as the basis of the Load Test. Fortunately, Test Studio stores its tests in a custom XML format, and Fiddler’s simple Import and Export architecture made it easy to build an importer that reads *.tstest load test files and displays the original requests and responses in Fiddler’s Web Sessions list.
After loading the original test’s capture and the faulting test-run’s capture, I can often quickly diff the traffic to find out where something has gone awry.
Developers: If your tool imports or exports web traffic in a custom format, you may find it very helpful to build a transcoder that imports or exports using your format.
In Progress: WebSockets Enhancements
Looking ahead, Fiddler’s HTML5 WebSockets support continues to grow. WebSocket messages are now losslessly round-tripped from the SAZ format, enabling you to analyze WebSocket messages captured on a different PC or during an earlier debugging session. Each message now includes a Timers collection which contains timestamps showing when the message was received and retransmitted.
FiddlerScript can now modify WebSocket messages as they flow through Fiddler:
static function OnWebSocketMessage(oMsg: WebSocketMessage)
var sPayload = oMsg.PayloadAsString();
// oMsg.Abort(); // <-- Do this to "eat" the message
oMsg.SetPayload(sPayload + "... bazinga!");
An upcoming build of Fiddler will include a full-fledged WebSocket Inspector UI, enabling you to easily inspect and modify WebSocket messages as Fiddler captures them:
Thanks for using Fiddler!