When developing a web application, it’s essential to be able to debug any problems at as low a level as possible. When experiencing problems with a form handler, for example, it’s common practise to echo out all the data in the POST to see if anything looks odd – if you’re not getting the data you’re expecting from the form, then there’s no point debugging all your code.

When dealing with issues involving cookies, character sets, error codes, other HTTP headers and such, this can often be difficult to debug with a standard browser. Most browsers go to great lengths to hide away the nasties of HTTP from the user, and as a developer this can make debugging difficult. You basically end up tracking a circumstance by a browser’s reaction to a circumstance, which is often far from ideal.

Whilst some browsers (primarily Firefox) have extensions available for displaying HTTP headers and the like, let us not forget the speed and convenience of the unix command-line tool curl. A quick call to curl -I http://allinthehead.com/ results in:

HTTP/1.1 200 OK
Date: Wed, 25 Aug 2004 15:37:30 GMT
Server: Apache
X-Powered-By: One fiercely courageous armadillo invoking, The blood, sweat and tears of the fine, fine TextDrive staff
Vary: Accept-Encoding
Served-By: TextDrive
Connection: close
Content-Type: text/html; charset=utf-8

Which quickly reveals the HTTP error code (200, all’s good), that my character set is set to UTF-8 as I’d intended, and so on. Drop the -I argument, and you’d get the full source of the page returned. Try curl --user-agent 'GoogleBot' http://allinthehead.com/ and see how the GoogleBot sees my site (the same as everyone else, but hey).

This is nothing revolutionary, of course, but it’s something I find useful on a regular basis, so I thought I’d share. If you run OS X you’d got curl right there from the terminal, and it seems to be pretty common on linux and unix machines generally. I use curl from Debian pretty frequently too.