Next: Dynamic Documents Up: Server Configuration and Previous: GN command line

Testing the server

Server software is generally robust and is usually quite easy to get going. Various techniques may be used to test the Web server once it has been installed and configured, but it would be impossible to present an exhaustive test plan which covered all possible implementations, since individual details will inevitably vary a great deal. What follows is really intended as a collection of hints and tips, to be applied selectively where appropriate to a particular Web implementation.

It may seem painfully obvious, but planning a logical test sequence will make the process of testing much less chaotic.

In order to test the server you will need to have created some sample Web documents within a directory hierarchy. You can use existing hypertext documentation for one of the Web servers, if you have nothing else available.

Put a welcome or index document at the top level of the hierarchy, start the server, and try to retrieve the document using a browser on the same system. By specifying localhost as the system name you can often test out network applications without access to a network. Ensure you include the port number that the server is using if this not the standard port (port 80). If this is successful then you have established that the server is at least responding to local requests and can go on to test further features. You may need to be privileged to start a server that uses a port number less than 1024. However, when testing a new server it is often as well to run it on a non-standard, non-reserved port, especially if there is an existing server already serving documents from that machine. If you bring a new server up on port 80, other people may find it and start using it before you are ready.

If the server does not respond to a local request, check that the server program was in fact started, and if so is still running. The server should be writing messages to log files. Check that these have been created where you specified and examine their contents. The CERN and NCSA servers write a message to the error log when they have successfully initialized themselves (although called an error log, this actually functions more as a status log).

If you are using the CERN server you can start it so that it reads requests from the terminal by omitting a port directive. You can then emulate the client yourself and type in an HTTP request, of the form:

    GET url HTTP/1.0

followed by a blank line. The simplest URL consists of just a slash (/), which specifies the server's home page, or you can use the path of another document relative to the top-level directory. The server should respond by printing a set of headers, followed by the document contents, to the terminal. If you omit the string HTTP/1.0, the server will assume that HTTP version 0.9 is being used. HTTP version 0.9 does not require a blank line following the request, and the response does not include header lines. Specifying a URL that does not exist should cause a document containing an error message to be generated and printed. Specifying the -v, or -vv, command line option also activates the printing of verbose, or very verbose, trace messages, which detail the actions that the server is taking. This option can also be specified when the server is listening on a real port.

Once it has been established that local retrievals are functioning you could test remote access by using a browser on another machine. Ensure that the path between the two systems does not pass through a gateway that will filter out the HTTP packets.

If local retrievals work but remote retrievals fail, check that other network applications are functioning. The ping program can be used to test that the remote system responds to IP requests. The TELNET program can be used to interact directly with the remote server. The telnet command on UNIX takes the following parameters:

    telnet host [port-number]

The port number is an optional parameter and defaults to port 23, the TELNET login port, but you can specify another port to connect to a different service. Once connected the server will wait for an HTTP request, and then send a response and close the connection.

If an empty document is returned when accessing the server from a remote system, this may be a sign that the server is crashing while processing the request. If the server is being started by the Internet services daemon, this behaviour will be repeatable.

Once it has been established that basic document retrieval is working, other server functions should be tested. These include: mapping of virtual URLs (aliases) to physical pathnames, invocation of CGI scripts, caching and proxy access.

Spinning the Web by Andrew Ford
© 1995 International Thomson Publishing
© 2002 Andrew Ford and Ford & Mason Ltd
Note: this HTML document was generated in December 1994 directly from the LaTeX source files using LaTeX2HTML. It was formatted into our standard page layout using the Template Toolkit. The document is mainly of historical interest as obviously many of the sites mentioned have long since disappeared.