Debugging HTTP with Replay

It's often useful when analyzing a failure to create a carefully controlled environment that reproduces the issue reliably. Using a controlled environment allows you to test hypotheses about the issue while eliminating some of the effects of random chance from the observations that you're making. Capturing an HTTP session for replay is one way to construct a controlled environment in which you can experiment with HTTP responses.

You can make an HTTP session capture in a variety of ways.

- Running Fiddler to intercept traffic and extracting the raw data from the Fiddler log

Using [STrace](https://www.microsoft.com/downloads/details.aspx?FamilyID=f5ec767f-27f2-4fb3-90a5-4bf0d5f4810a&displaylang=en) logging to intercept traffic  

• Installing a debug version of WinInet to produce a log

You can then replay the HTTP session capture at a later time using HTTPReplay.

Depending on the data available in the log you might construct various experiments using the captured responses. For example, STrace captures timing data for sending the response, which can be used to explore issues related to race conditions. As another example, HTTPReplay allows response files to be extracted from the log and modified to try sending back altered versions of the originally captured session.

Comments

• Anonymous
  April 17, 2009
  oh, 'Replay'?! Thanks for sharing! A smart idea!