Extracting maximum value from the Flash Builder 4 Network Monitor
Content
Modified
22 March 2010
Requirements
Prerequisite knowledge
Some familiarity with building Flex applications is required.
User level
Intermediate
Required products
- Flash Builder (Download trial)
In Adobe Flash Builder 4, Flex developers have at their fingertips a built-in Network Monitor that allows the inspection of HTTP traffic between client side applications and the server. This is especially helpful for Flex applications that may not get the actual HTTP response data back in the case of HTTP errors like 500 or 404.
This article provides a detailed look at how Network Monitor works and how you can use it to inspect the HTTP traffic between your Flex application and the server.
Monitoring traffic between the client and server
There are currently two main ways to monitor HTTP data being sent back and forth: low level network sniffers and HTTP proxies.
The network sniffer Wireshark is a great tool for monitoring network traffic and troubleshooting communication problems at a low level, but it has two limitations. First, it cannot decrypt SSL traffic, and second, in Windows it cannot sniff traffic to localhost. Proxy-based tools such as Fiddler or Charles do not have these drawbacks. These tools, however, show requests from all applications and have no way of linking a request to the line of code that made it.
Network Monitor takes the proxy approach, but shows only the requests that your Flex application has made and can identify the line of code that made each request.
Overview of Network Monitor
By default (in the Flash perspective) there's a tab labeled Network Monitor in the bottom part of Flash Builder 4 along with the Problems, Data/Services, ASDoc, and Console tabs. When you click the Network Monitor tab, the Network Monitor view displays the requests your Flex application is sending and the corresponding responses the server is returning, including HTTP headers and body (see Figure 1).
If you double-click a request in the Network Monitor view, Flash Builder 4 will highlight the line in the source code that issued the request (see Figure 2).
When you run or debug your application, responses from the server can be viewed as a tree when the response is XML, JSON or AMF (see Figure 3).
In addition to the Tree View, you can also see the data in Raw View or Hex View by clicking the buttons in the upper part of the Network Monitor’s right pane. Power users may prefer to see the raw response in its entirety, and the Hex View is invaluable for inspecting binary response data from the server (see Figure 4).
Useful tips
Here are helpful tips for using the Network Monitor on your projects:
- You can disable or suspend Network monitor at any point by clicking the appropriate buttons on the top right of the Network Monitor tab.
- To identify which requests take the most (or least) time, click the elapsed time column to sort the requests by elapsed time.
- Click the save button to save all of the request and response data along with elapsed time, associated source code, and more to an XML file.
Interesting scenarios involving Network Monitor
Some situations where Network Monitor is invaluable:
POST into GET: If you make an HTTP POST call using HTTPService without passing any parameters to send(), the call will be converted into a GET. This can be especially troublesome if you are expecting only POST calls on the server-side. Network Monitor helps you troubleshoot whether an actual POST or GET call was made by showing the information in the “Operation” column.
Debugging erroneous HTTP responses: HTTPService’s “fault” event handler returns the status code, but not the actual body of the response. This makes debugging responses like the “Internal Server Error” (500) or “Page not found” (404) hard. Simulating the same call via the browser may be hard due to the size or nature of the data passed. Network Monitor can show you the actual response body from the server in the “Raw” view.
Viewing cookie information and other headers: Headers like “Cookie” are often automatically inserted by the browser. Also, the flash player restricts certain headers from being sent. Network Monitor lets you view the actual headers being sent and received so you can confirm the data that has been exchanged. For me, this has been particularly useful to verify if the “Set-Cookie” header from the server contained the correct cookie information.
Validating format of responses: A server may respond with data in binary form or even with partial XML data. Binary responses are common when AMF is used, and relevant when images or files are received from the server. “Hex” and “Raw” view makes validating the format of such responses easy because you can easily compare the response data and the data that HTTPService parsed out of it.
Cross-domain redirects: HTTP Status code 301 or 302 indicates a redirect to another URL. A server may redirect you to a URL in a different domain. In flash player, the call will fail with a security error (cross-domain requests have to be explicitly allowed with a crossdomain.xml file). Without Network Monitor, tracking down how the redirect happened when you were originally pointing to a different domain is hard.
How it works
When Network Monitor is activated it conditionally enables code in the Flex SDK that re-routes Flex RPC calls to an internal proxy. This proxy then makes the outward HTTP request. As a result, the proxy can report the actual HTTP request and response and is not bound by the security and transformation rules that Flash Player enforces on network requests.
This is important to understand because only the Flex RPC APIs will be re-routed to the proxy and reported in Network Monitor.
Note that the proxy does not intercept low-level Flash Player API calls. Also, data sent over the RTMP channel is recorded only at the SDK level. The request is not re-routed to a proxy in these cases and hence the Raw View and Hex View will not show the actual raw data, but only what Flash Player decoded.
Trying it out with a simple application
Follow these steps to try out Network Monitor using this simple application that uses an HTTPService to query the Latest Adobe News RSS feed:
- Create a new Flex Project in Adobe Flash Builder 4.
- Paste the following code into the main MXML file:
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="1024" minHeight="768"
creationComplete="service.send()">
<fx:Script>
<![CDATA[import mx.rpc.events.FaultEvent;
import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
protected function service_resultHandler(event:ResultEvent):void
{
Alert.show("Result is " + event.result.RDF.channel.description);
}
protected function service_faultHandler(event:FaultEvent):void
{
Alert.show("Fault: " + event.fault.faultString);
}
]]>
</fx:Script>
<fx:Declarations>
<mx:HTTPService id="service"
url="http://feeds.adobe.com/xml/rss.cfm?query=byMostRecent&languages=1"
result="service_resultHandler(event)"
fault="service_faultHandler(event)"
/>
</fx:Declarations>
</s:Application>
- Make sure Network Monitor is enabled by switching to the Network Monitor view and clicking the Enable Monitor button on the top right of the tab.
- Run the application to view the request and response in the Network Monitor view.
Where to go from here
Try the Network Monitor on your own Flex application to view the data being exchanged between the client and server right within the IDE. I think you’ll find the ability to jump to the line in code that made the URL request and the ability to view the response in tree, raw, or hex format are invaluable.
To learn more about the great new features in Adobe Flash Builder 4, read the article What’s new in Flash Builder 4 Beta.
This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.
