Fiddler is a fantastic tool that allows developers and IT professionals to see what’s happening under the hood when a web page is requested by a user. Somewhat simplified, when a user visits a web page, whether she knows it or not, she is using the HTTP protocol to request a web resource, and then the web server is using HTTP to respond with the HTML of the page itself. This HTML is rendered by the browser into a pretty page, after any source files such as images or style sheets that were referenced in the HTML are downloaded, also using HTTP.
For the first time in my career, I came across a situation today where a user’s computer was crashing the moment that user visited a web page using Internet Explorer 9. While this is apparently some issue with that particular computer–no browser should allow its host to crash, regardless of what HTML is returned–I wanted to see some Fiddler output in order to confirm that the HTML request and response causing this crash were not being intercepted and modified somewhere along the way. The problem was this: the Fiddler log could not be analyzed or saved, because the computer was crashing the moment the web page was requested!
Fortunately, Fiddler has a scripting technology called FiddlerScript that offers hope in a situation like this.
Step 1: Click “Customize Rules”
Step 2: Add code to decode the response, and then save the response body, into the CustomRules.js file that pops up when you click “Customize Rules”:
static function OnDone(oSession: Session) {
// Put the URL you want to save here
if(oSession.url.Contains("hub.securevideo.com/Pass/Join")) {
oSession.utilDecodeResponse();
oSession.SaveResponseBody();
}
}
This will write the response, after Fiddler has received it, and before it is passed to the browser, to your My DocumentsFiddler2Captures folder.
Step 3: Request the crash page, and hopefully after you recover from the crash, you will have one or more HTML files in your My DocumentsFiddler2Captures folder.
Step 4: You can then compare the HTML returned in the capture to the HTML which is returned by any other computer. If it is the same HTML, then the computer is clearly having some problem, and needs to be fixed. If the HTML is different, then some process either on the host computer (such as a worm) or on the host network is most likely modifying the HTML to cause the crash.
Note, depending on the timing and cause of the crash, this code might need to be placed in different functions. I started with the code in OnDone so that it would run once the entire request and response were available, but depending on the crash timing, it might have to be placed earlier. This whole idea also might or might not work in some cases, depending again on the crash cause and timing.