Inspecting and Hacking HTTP

24 Aug 2008

There are numerous reasons you might want to inspect HTTP when debugging a problem. If you've ever tried to debug problems with sessions, cookies, or redirects, I'm sure you can appreciate how hard it is without taking a close look at what's going on behind the scenes.

There are numerous tools to help you inspect HTTP. If you're a Firefox user, you can use LiveHTTPHeaders or HttpFox. (Please feel free to suggest others.) If you use Safari, you can enable the debug menu:

  1. $ defaults write com.apple.Safari IncludeDebugMenu 1

This gives you access to the Web Inspector, which displays HTTP headers under Network. Unfortunately, it seems to be limited to the headers, omitting everything else. (Safari users, are there better options?)

If you're using Safari 3, replace IncludeDebugMenu with IncludeDevelopMenu. You'll know it's enabled when you see the Develop menu.

Sometimes it's useful to make a slight modification to the request and try it again to see if it fixes the problem. Many HTTP tools let you do this, and tamperdata for Firefox is particularly useful.

Despite having numerous tools available, I still find myself using telnet pretty regularly, partly because I want to minimize the risk that the tool I'm using is giving me false information, whether it's due to a bug in the tool or simply an error in my interpretation or use of it.

If you've never used telnet to send requests to a web server, you might be surprised by how easy it is:

  1. $ telnet google.com 80

Once connected, you can enter a simple GET request to try it out:

  1. GET / HTTP/1.1
  2. Host: google.com

Because Google prefers the superfluous www subdomain, you'll get a 301 response. If you want to follow the redirect like a browser would, simply change the Host header in your request, and you should get a 200 response that includes the content.

When debugging a secure URL, telnet won't help you. Luckily, openssl provides similar simplicity:

  1. openssl s_client -connect google.com:443

You might prefer -quiet if you don't find the s_client output useful.

You can use the same GET request as before to try it out, or you can copy a real request your browser sends by using one of the HTTP inspectors like LiveHTTPHeaders.

Do you have any related tips for budding web developers?