Debugging W3C httpd

Suppose you think you have installed W3C httpd but it doesn't work. Here we assume you have used port 80. Please read the documentation carefully before sending mail to httpd.w3.org - we get a lot of mail and want to do development as well!

Use the Line Mode Browser as a test tool. Type

        www http://myhost.domain/

What happens?

Connection Refused

The browser tries to connect to the daemon but gets this status in the trace.

This means that nobody was listening on that port number. Check the port numbers match between server and client. Make sure you specify the port number explicitly in the document address for www.

If you are running the daemon standalone (as you should be), check that it is actually running by taking a list of processes, and that it is listening to the correct port (specified with -p port option), or try running it from the terminal with -v option as well. The trace for the server should say "socket, bind and listen all ok". If it does, and you still get "connection refused", then you must be talking to the wrong host (or, conceivably, different ethernet adapters on the same host).

If you are running with the inet daemon, then check both the services file (/etc/services) or database (yellow pages, netinfo) if your system uses it, and the /etc/inetd.conf file. Check the service name matches between these two (e.g. http).

Did you remember to kill -HUP the inetd when you changed the inetd.conf file?

Be aware that on some systems your local file /etc/services will not be consulted E.g. when ypbind is running on Suns, then you should type

        ypwhich -m services

and ask the administrator of the machine named to change its own /etc/services.

Try running the deamon from a shell window to see better what happens.

Cannot Connect To Information Server

The usual cause of this is that the server is not running, or it's running on a different port.

There is more information you can get. Use the "verbose" option on the LineMode browser to find out what went wrong:

        www -v http://myhost.domain:80/

What do you get? A load of trace messages. There are several cases.

The browser can't look up the name of the host. If it can, it will display "Parsed address as" message. If not, try fixing your name server or /etc/hosts file, or quoting the IP number of the host in decimal notation (like 128.141.77.45) instead.
The browser can get to the host but gets Connection refused status back.
Your browser gets an error number but prints "error message not translated". This is because when it was compiled on your platform it didn't know what form the error message table took. Try the same thing form a unix platform for example.
You get some network error like "network unreachable". Depending on whether the IP network is your responsibility or not, and your attitude to life, either fix it, try again in an hour's time, or complain to someone.

Unable To Access Document

Typical cause of this is that the configuration file is incorrect, or files are not readable by the user-id under which the server runs. When you are running the server as root, it will automatically switch it to nobody just before serving the document. This can be changed with the UserId configuration directive.

An Empty Document Is Displayed

The document sent back is empty, but there is no error message.

The inetd has started a process to run your server but it immediately failed. Possibilities include:

When running from inetd, the daemon may not be in the file specified, or may not be executable by the specified user (or, if a user id is not specified in your variety of inetd.conf, root).
For some reason server crashes when it's trying to serve the request. If you can, try to tract down when this happens, and send mail to httpd@w3.org. Try running the daemon from a terminal window to see what happens.
Script fails to produce any result, which may be due to the fact that there is no empty line after the header section output by the script, causing server to read the entire generated document as the header section.

Document Address Invalid Or Access Not Authorized...

...or some similar kind of error message. This means either:

You have been passed a bad document address. If you are following a link, check with the author of the document which contained the link.
The document has been moved. Check with the server administrator. You should be able to find out who runs the server by going to the welcome page (type "g /" with the line mode browser) and seeing a link to information about the maintainers.

If you are the server administrator, and you can't understand why the daemon refuses to deliver the file,

Check the configuration file (rule file, by default /etc/httpd.conf) if you have one. Think out way the document name will be mapped successively by each line, and what the result will be.
Run the daemon in debug mode from a terminal session to get trace information.

Bad Output

A document is displayed, but not the one you wanted.

These are some ideas:

Try running the server from the terminal.

Check the HTML source the daemon produces with

        www -source http://my.host.domain/

Try telnetting to httpd and simulating the client:

        > telnet my.host.domain 80
        Connected to my.host.domain on port 80
        Escape is ^[
        GET /document/name

httpd@w3.org, July 1995