A GUI tool for hand-crafting HTTP requests and examining responses to them
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.
HTTPeek is a single Python source file and it requires no configuration. You can put the file anywhere you like, point your Python interpeter 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
This is where you set request related options. This description obviously needs fleshing out...
Response analysis frame
This is where you can see (but not change!) the details of the received response. This description obviously needs fleshing out...
This little frame just lets you see what HTTPeek is doing right this instant.
The menus provide some really simple functionality like saving and loading requests or responses to text files.