Traffic Sniffing - Ajax Patterns

Traffic Sniffing

From Ajax Patterns

Revision as of 07:25, 28 November 2005; view current revision
←Older revision | Newer revision→

Evidence: 1/3

Tags: Capture Intercept Log Monitor Network Record Sniff Traffic


Goal Story

Dave hears a report that critical form data isn't being saved on the database. He turns a sniffer on and tries uploading the same data himself, which shows him an XML message being uploaded via XMLHttpRequest. Inspecting the message in an XML editor, he discovers the Javascript hasn't formatted it correctly.


How can you diagnose errors and strange behaviour?


Diagnose problems by sniffing Web Remoting traffic. Many Ajax problems arise because Web Remoting messages are either wrong or not sent at all. Debugging and general logging on either side of the network might help you infer what's being transmitted, but it's better to grab the traffic directly. There are various ways to do this:

  • In the browser, encapsulate XMLHttpRequest Calls in a wrapper which logs the request and response (see Logging). This may be the most convenient technique, because the programmer's probably already looking at the browser.
  • Employ a generic network traffic monitor, filtering on HTTP traffic to and from the server.
  • Configure your browser to use a generic HTTP proxy, and have the proxy log interesting traffic in either direction.
  • In the server, intercept incoming and outgoing traffic for logging. Server-side frameworks often have a common controller object which can be instrumented to capture information in either direction. In addition, interception facilities are often available, such as Java's Servlet Filters.

Traffic Sniffing is a kind of Logging function. As such, you'll probably want similar filtering functionality, e.g. to see only messages in one direction, matching certain text, or to a particular URL.


Tool Support

XMLHttpRequest Tracing and XMLHttpRequest Debugging

Julien Couvreur has written two invaluable Firefox tools: XMLHttpRequest Tracing unobtrusively logs traffic to the Javascript console, while XMLHttpRequest Debugging is a much more powerful, interactive, Popup tool that not only shows the messages, but lets you set filters and configure the display. Both are Greasemonkey scripts, so you'll need to install the Greasemonkey extension first.


Fiddler is a Windows proxy specifically designed for analysing and "fiddling" with browser-server traffic.


Adam Vandenberg has noted that his personal flangelib.js library contains an XMLHttpRequest wrapper that performs logging. While you're unlikely to use that library directly, it's a function the more popular XMLHttpRequest wrapper libraries may eventually implement. The main barrier right now is possibly the absence of a standard logging library (see Log).

Tool Illustration

Following is the output from the XMLHttpRequest Tracing script during the initial load sequence for the Ajax Patterns Reader. First, the request is logged: [736] intercepted open (GET , patternList.phtml , true , undefined , undefined) [736] intercepted send (null)

Then, the result, showing response code (200) and content: [736] intercepted load: 200 Ajax Stub|||Browser-Side Cache|||Browser-Side Templating|||Browser-Side XSLT||| ....

Related Patterns


Traffic Sniffing in the browser is a form of Logging.

Want to Know More?