Skip to main content

Monitoring the HTTP Traffic in a JSF Redirect

Posted by cayhorstmann on October 20, 2009 at 10:20 AM PDT

I wanted to trace exactly what happens when a JSF page uses a redirect. Here are my experiences with the HTTP and TCP/IP monitors in NetBeans and Eclipse, and why I ended up using Wireshark instead.

Consider the usual JSF flow. The client makes a GET request for the first page. That's a special case, but from then on everything follows a pattern. The server renders a page containing an HTML form that is to be posted back to the same URL. The client makes a POST, the server navigates to a new page and renders it. The problem is that the browser requested the new page with the old URL, and so the browser bar URL is always one step behind.


You can fix that with a redirect. If you use JSF 2.0 “EZ navigation”, you produce outcome strings like this.

if (...) return "success?faces-redirect=true"
else return "failure?faces-redirect=true"

So, what exactly happens now? That's where HTTP monitoring comes in.

In Netbeans, you activate HTTP monitoring by checking “Enable HTTP monitor” in the GlassFish server properties.

You can then see the traffic in the HTTP Server Monitor tab. For example, here you can see the initial GET, the POST to /faces/index.xhtml, and the GET to /success.xhtml.

Unfortunately, NetBeans doesn't show you what the server returns to the client, so you don't see why that second GET request was made.

The Netbeans HTTP monitor modifies the domain1/config/default-web.xml file, adding a filter to every web application. That filter is left in place after Netbeans exits. If you run the application from inside Eclipse, the filter will throw an exception. The remedy is to turn monitoring off before exiting Netbeans.

Eclipse uses a different approach. It can monitor arbitrary TCP/IP traffic. With Glassfish, right-click on the server in the Servers tab and select Monitoring > Properties. Then click on Add and select port 8080. Select Start to actually start monitoring. Then you need to point your browser to localhost:8081/contextRoot/faces/index.xhtml. Eclipse routes the packets from port 8081 to port 8080, which gives it a chance to monitor them.

As you can see here, Eclipse shows what the server sends back to the client.

Well, almost. What you don't see are the HTTP headers, so you don't see how the browser knows where to go. (The browser doesn't parse the HTML that you see in the screen capture—that's for people who turned off automatic redirect in their browser.)

To really see what is going on, I used Wireshark. It captures all TCP/IP traffic, doesn't install any filters in your app server, and doesn't make you change port numbers. It decodes HTTP, showing you the entire response:

As you can see, the server sets the Location header to the redirect location.

Executive summary: The HTTP and TCP/IP monitors that are built into the IDEs are useful for routine traffic monitoring, but for hardcore sniffing, Wireshark is hard to beat.

cayhorstmann-monitor-netbeans.png39.61 KB
Related Topics >>


Is there a way to view the data using NetBean's HTTP Server Moni

I was just looking at NetBean's HTTP Server Monitor. So, there's no way to view the data itself? I never understood what the use of the HTTP Server Monitor was if it only shows the request attributes and query parameters and that's it. Am I missing something? It would be great if you could see the actual POST data and the response data. Otherwise, it seems pretty useless.

Eclipse TCP/IP Monitor

The TCP/IP Monitor in Eclipse has an option to display the headers as well. Click on the little down arrow on the right of the tab, and select the menu item 'Show Headers'.

Also consider intercepting proxies

Wireshark has limitations, especially on the Windows platform, where it cannot capture traffic on the loopback (localhost) interface. It can also not monitor encrypted (SSL) traffic. An alternative which most people can use is an intercepting proxy, such as WebScarab (disclaimer, I am the author), Burp Proxy, Paros, Achilles, etc. All of these allow intercepting of SSL-encrypted traffic, by presenting a fake certificate and pretending to be the target server. The intercepting proxy can then show the exact traffic, including headers, precisely as sent by the browser and as sent by the server. The other useful part of this is that the intercepting proxies are (obviously) independent of the IDE and the browser used, and the only changes required are updating of your browser's upstream proxy settings to point to the intercepting proxy,


Any reason for this lack of support on Windows? I would assume that the OS support is also there.

Actually, it seems like I am

Actually, it seems like I am a couple of years out of date. It certainly used to be the case that WinDump (tcpdump clone) was not able to monitor the loopback interface, but it seems that changed around 2007: The reason as I understood it was that the loopback interface "driver" in Windows was not fully compliant with the networking stack in some way.

Thanks for your note.

Thanks for your note. Monitoring localhost is definitely required for early stages of development. I didn't know Wireshark falls flat on Windows. Another reason to keep up those Linux skills :-) And that's a great tip about SSL debugging.

The Grinder

I've found The Grinder pretty useful in the past for debugging web service calls. Basically, you just configure it as an HTTP proxy in your browser and everything goes through it and it dumps to the console. It's 100% pure Java. I've found it more reliable than something like FireBug.

Intercepting is useful, too

One of the great things about using an *intercepting* proxy is that you can modify the requests and/or responses in flight. So, if you want to see how your app behaves when someone sends malicious input that you are checking for using JS in the browser, simply submit legitimate input using the browser front-end, intercept it in the proxy, and modify it to your heart's content. This is the sort of tool that the hackers are using to explore your apps. It's really a good idea to use it yourself to make sure that you understand what you are up against.