Monitoring the HTTP Traffic in a JSF Redirect
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
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.