WEBDEBUG: MANUAL

_/Introduction\_ _/Manual\_ _/FAQ\_ _/Enhancements\_ _/License\_ _/Download\_


Current WebDebug version: 1.2

Installation

  • First, install a version of Python for your system. You can find the right version at the official Python site. WebDebug has been developed and tested with Python version 2.1.2 but should work with all 2.0+ versions too
  • Second, download WebDebug and decompress it in a directory of your choice
Running WebDebug

WebDebug is easy to run, just execute python webdebug.py at a command prompt.
By default WebDebug will listen for HTTP requests from your browser on port 2001, if you give it another port as argument, WebDebug will use that instead:
python webdebug.py -port [port]
Here are all the available command-line parameters:
webdebug.py [-port <port>] [-nokeepalive] [-singlethreaded]

  • -port <port> tells WebDebug which port to listen on
  • -nokeepalive disables Keep-Alive
  • -singlethreaded forces WebDebug in single-threaded mode and automatically disable Keep-Alive as well. This may be useful for test purposes or when you run WebDebug on a Python configuration that doesn't support the threading module
Browser Configuration

All you need to do is set your browser's HTTP proxy server to point to the WebDebug server. If you are using the standard WebDebug settings, you can set your proxy server host to localhost and the port to 2001. If you already use a proxy server to access the web then, sorry, WebDebug won't work for you.

Surfing

Nothing new here, just surf away. Every request the browser makes shows up in the window WebDebug was run from. This way you can verify that things are working as expected.

Viewing HTTP messages

To access WebDebug's menu, just make the following request from a browser:
http://webdebug_host:webdebug_port/WEBDEBUG/
if you have used the default value and are running WebDebug on your local machine, you will typically hit:
http://localhost:2001/WEBDEBUG/
The /WEBDEBUG/ portion of the URL tells WebDebug that the URL is a command for it instead of a standard browser request.

You will then see the WebDebug menu containing the following options:

  • Show Message List: the message list keeps track of all request/response pairs that WebDebug processes. This command tells WebDebug to display them
  • Clear Message List: removes all request/response pairs from the message list
  • Load Message List: loads a message list from file. This replaces the existing message list
  • Save Message List: saves the current message list to file
  • Save stats in Tab-delimited format: saves HTTP request and response statistics concerning the current message list to file in tab-delimited format (also displays them on the browser)
Notes: all loads and saves are relative to the directory you started WebDebug from. Also, the format WebDebug uses should be completely cross-platform. You can save a message list on Windows NT and send it to a friend using WebDebug on Solaris. Version 1.1 file format is not backwards compatible with version 1.0, see below for more details.

The Message List

When you display the contents of the message list, the following information is displayed:

  • Request and associated response contents: for differentiation purposes, all rows received from a browser or a server are either completely greyed out or have their first column greyed out
  • Additional information is also returned, some of which depends of the exact nature of the request or response:
    • Size of message: including headers, body, etc.
    • Message received: time at which the request was received from the browser (i.e. the moment at which the first byte of the request is received) or at which the response was received from the server (i.e. the time at which the last byte of the response is received by WebDebug from the server)
    • Browser/Server IP address & port: pretty obvious
    • Throughput: for responses only, throughput is based on the time taken to receive the response
    • Parameters: if a request has parameters in the URL and/or in the body of a message (as with a POST), the name-value pairs are URL decoded and presented here
    • Image: if a response contains an image, it will be displayed
    • Display HTML instructions: if a response contains HTML, this link will display it in another browser window
    • Display HTTP response: returns the response to a new browser window
    • Decoded authorization: if the request includes a username/password authorization it is decoded here
  • Requests and their corresponding responses are displayed in the order the pair was added to the message list
  • Also displayed are the total number of requests, responses, their total size, etc. and a table containing statistics of each content-type contained in the message list
  • WebDebug also tracks the number of sockets opened by the browser. This is useful to check how much "socket re-use" Keep-Alive is achieving

Enhancements/Changes since version 1.15

  • Fixed new syntax in connect() socket call
Enhancements/Changes since version 1.1
  • Now display list of all requests at the start of the Message List
  • Fixed bug where WebDebug would eat multiple HTTP headers with the same name (e.g. if a webserver returns multiple Set-Cookie headers)
  • Minor enhancements and bug fixes
Enhancements/Changes since version 1.0
  • Supports Keep-Alive
  • Save request/response statistics in tab-delimited format, suitable for importing into spreadsheets
  • Single-threaded mode available
  • More accurate timing of when requests and responses are received
  • Additional statistics now gathered: response throughput, number of individual sockets used (useful when using Keep-Alive), etc.
  • Added sorting capabilities: by time requests received, responses received, and grouped by client socket used
  • Misc. bug fixes
  • Note: version 1.0 file format is no longer supported. If you need to read message lists saved in version 1.0, keep it around. Future versions should be backwards compatible with version 1.1. Apologies for any inconvenience caused!

Paul Clip.