HTTPeek is a tool for sending hand-crafted HTTP requests to web servers and examining (``peeking into'') the details of their response. It is designed to assist web server developers in testing the features of their servers which cannot easily be tested using an ordinary browser. Read the detailed description for more information. HTTPeek is written in Python and has a GUI built using the Tkinter toolset.
- Detailed description
- Complete instructions
HTTPeek depends only upon Python. It was developed and tested on NetBSD and OpenBSD and is fully expected to work on any POSIX system. It should work equally well on Windows, but this has not been tested. If you successfully run HTTPeek on Windows, I'd love to hear about it.
HTTPeek is distributed under a standard 3-clause BSD license. It's as free as software gets.
Download the latest version of HTTPeek, HTTPeek 0.1, which was released on August 11 2007.
I wrote HTTPeek in order to test some features of my Python web server Comanche. Some parts of a web server - like handling standard GET requests or automatic directory indexing - are easy to test with a stock standard browser like Firefox. Some things are not quite as easy: most browsers will not show you the header a web server sends along with a website (links does, however, which has made it handy for Comanche testing). Some things are right out of the question: you can't ask Firefox to set a specific ``If-Range'' value in its request header, and Firefox will automatically follow a redirect without showing you the message it received. The need for a custom tool is clear and HTTPeek is intended to fill that role.
With HTTPeek, you can hand-craft every aspect of a standards compliant HTTP request. You can select the HTTP version to use, from HTTP/0.9, HTTP/1.0, or HTTP/1.1. You can select the HTTP method to use, from HEAD, GET, or POST. You can set an arbitrary number of (field,value) pairs in the request header - HTTPeek will automatically set some for you. You can include an entity in your request.
Once you've crafted your request, you can throw it at a webserver and get a response. HTTPeek will show you every aspect of the response. You can see the HTTP version the response complies with, the response status code and the descriptive string identifying that code. You can see all of the header fields in the response, and the complete response entity.
You can save both your crafted requests and received responses as plain text files in the same format they are sent over the network. If you've saved a request earlier, you can load that file if you want to send the exact same request out again.
Here's a screenshot of HTTPeek 0.1 running on NetBSD 3.0. It will look (cosmetically) different on Windows and Mac OS.
HTTPeek is a single Python source file and it requires no configuration. You can put the file anywhere you like, point your Python interpreter at it and go. HTTPeek's GUI is designed to be clear and intuitive, and anybody who understands the HTTP protocol should have no trouble in figuring things out (anybody who doesn't understand the protocol probably won't find any value in HTTPeek anyway).
The HTTPeek window is divided into four components: a network frame (top), a request construction frame (left), a response analysis frame (right) and a status/log frame (bottom). The features of each component are discussed here briefly. Also discussed are the file I/O options available through the menu bar at the top of the window.
The network frame contains 3 widgets allowing you to set the following network-related options:
- The hostname or dotted-quad IPV4 address of the host to send the request to.
- The port number which HTTPeek should attempt to connect to the above configur ed host on. The default is 80, which is the standard for HTTP traffic.
- The timeout duration (in seconds) for which HTTPeek will wait without having received any communication from a host before giving up.
The frame also contains 2 buttons, labeled "Send Request" and "Cancel". These buttons are self explanatory: the first sends the currently crafted request to the indicated host and waits for a response, the second aborts this process at whatever point it is currently at.
Request construction frame
Response analysis frame
Anything relating to the crafting of HTTP/0.9 requests and reading of HTTP/0.9 responses is currently liable to go wrong either subtly or horribly. These bugs are not deep or serious and will disappear in the next release.
Bug reports and suggestion for improvement of HTTPeek are very welcome: just email them to me. Full credit will be given on this page for bug reports, fixes, etc. Feel free to email me even just to let me know you think HTTPeek is neat, too.