Troubleshooting and debugging Web applications starts with a basic question: what does the client experience, and what happens on the server? This article helps answer one of the first questions a troubleshooting professional would ask: what does the client “see” from the server?
Screenshots from the browser or client sometimes provide this answer. But many times, HTTP requests leave the client and responses are received long before a human could collect screen captures. Or maybe it is the sequence that matters, not only one request. And, with AJAX, a client may not display anything relevant at all. So, here we are: we need to collect some HTTP traces; an HTTP traffic recording for investigation.
Preferred method – HTTP Watch
As a browser add-on, HTTP Watch helps collect all information needed, with minimal interference and in a consistent manner. The steps:
- Download HttpWatch – the basic version is free – from www.httpwatch.com/download. It is a good practice to install the latest version.
- After installing the tool, launch an Internet Explorer browser. Select to launch a new window, do not just open a new tab; this ensures a new fresh session will be recorded for the target site.
- With the new browser instance, press Shift+F2 on the keyboard or select the View > Explorer Bars > HttpWatch Basic from the menu of the browser. This will bring up the HttpWatch extension:
- Make sure the Record button is pressed HttpWatch, then navigate and use the web application from the browser as normal, trying to reproduce the issue being investigated. Continue working on the site until you have reproduced.
- Once finished, stop and save the trace in HWL format. This is the format that HttpWatch proposes as default.
Second best – Fiddler
Fiddler is known as THE tool to be used in troubleshooting from the client side. It has been long used by engineers and developers for its features. But there are a couple of points I want to emphasize.
- Fiddler becomes a proxy for the system while it runs. And so...
- It may collect all HTTP traffic on the machine, if not filtered. While sometimes desirable, in most cases it may add some “noise” to the analysis.
- Because it is a proxy, it may interfere with network configuration or settings. I’ve seen cases where the issue could not be reproduced because of that. Fiddler seemed to be fixing the problem by temporarily changing how traffic is routed.
Steps to take:
- Download Fiddler from https://www.telerik.com/download/fiddler and in install.
- Before reproducing the problem, you might want to close all browser windows, to start a fresh session.
- Start the tool, then the browser or client app. Reproduce the problem.
- Do decrypt HTTPS. Don’t forget to decrypt HTTPS. If you send the encrypted session traffic to a support professional, most of the useful information may not be visible. Fiddler would warn about it (see below); alternatively, Menu > Tools > Options > HTTPS tab > Check Decrypt HTTPS traffic.
- Finally, Menu > File > Save... you know the drill. Send the resulting trace log file to support.
Browser’s developer tools, Network tab
Finally, using the features of the browser will do, assuming that the client is a browser, of course. There are some drawbacks, such as format inconsistencies from browser to browser.
We need to collect a HAR, HTTP Archive. My personal favorite is Firefox. Chrome may be fine. There is glitch in Egde/IE – they would not start developer tools with a new empty tab.
- You might want to close all browser windows, to start a fresh session.
- Open the new browser window. Then open its developer tools, going to network tab.
- Do enable Persist logs; make sure that the sequence of requests is kept and they don’t disappear with each navigation to a new page.
- Reproduce the problem; disabling cache may be relevant.
- Save the requests session as HAR, HTTP Archive. Right-click on a request, and the option should show up in the contextual menu.
- Send the resulting trace log file to support.
All the best!