Mike Holman

contact | twitter | rss

tcpflow

10th October, 2011

I’ve recently been evaluating WebAppKit, an open source framework for creating web applications in Objective-C. My application front end was written using another open source framework and for some reason my AJAX POST requests from the UI to the RESTful API on the server were not being logged, and no HTTP response was generated.

This proved somewhat tricky to debug – was the problem in the server implementation, my code or the Javascript framework? I used a RESTful web service testing tool called RESTClient for FireFox to send some POST requests to the server manually and everything worked as expected. This was going to require some lower level debugging – time to break out the command line. I installed tcpflow, an open source TCP packet inspector which for some reason I’d never installed on this laptop. Using this tool it’s trivial to monitor the data being sent via TCP to and from the computer

In this case, my WebAppKit server was running locally. The command to monitor only those TCP packets sent via the loopback interface (and only to the port I was running the server on) was: sudo tcpflow -c -i lo0 port 12345. Within a short while I’d narrowed down the problem to a lacking implementation in the POST body-parsing code in WebAppKit. The server code expects the HTTP Content-Type header to be set to application/x-www-form-urlencoded, the default setting for HTML form data. If the header is set to anything else, the request body is skipped. An issue has been filed on the GitHub repository – now to write up a patch on my fork!