June 12, 1996
The WebSite troubleshooting tips page is divided into two
main sections: a section of specific problems and solutions, and
a section of guidelines for diagnosing and solving problems on
The problems and solutions have been collected from
O'Reilly Technical Support and reflect questions users have had
with previous versions of WebSite.
The guidelines section describes the troubleshooting tools that
come with WebSite (such as the various logs and tracing
options), and suggests typical places to look for the causes of
This page also includes information regarding other
resources for getting help with WebSite.
Many of the problems you may encounter while installing and
starting your server are networking related. The specific
problems can be myriad, from a mistyped IP address to a wrongly
configured TCP/IP setup. These problems are beyond the scope of
this book and should be addressed to your network administrator
or your Internet service provider. If you suspect the problem is
with your TCP/IP configuration, see the documentation for your
operating and network systems.
Problems and Solutions
The following specific problems and questions have been encountered
by WebSite users. The answers are from O'Reilly's Technical Support staff.
My server starts and immediately exits. What now?
Look in the file server.log, normally in the logs
subdirectory under WebSite, to see any internal errors logged by the
server. The messages there can provide a clue. You must have TCP/IP
installed and active on your system. If you are using a dial-up
connection only, it must be dialed-in and active before the server will
I don't yet have an internet host name for my computer, but I
want to test it on the same computer as the server. What do I use
for a URL?
The URL http://localhost/ will contact your
local server and return your home page.
I let WebSite Setup install my server as an
application. How can I change it to run as a service?
Open the server's property sheet and select one of the service
options as the run mode. Stop the server. If you are on NT, you
must start it using the NT services control panel. You cannot
hand-start WebSite if it is set to run as an NT service. On Windows 95,
you can re-start the server using the Start menu now; the next time you
reboot your system, WebSite will start immediately and run without
anyone logged in.
I'm on an intranet with no Internet names. What do I use for
my host name in the Identities section of Server Admin?
Use the IP address (for example, 188.8.131.52). Do not use
the NetBIOS or Windows Network computer name. Windows domains and
names are not the same as internet/TCP-IP domains and names. If
you use an IP address, people can use it in their URLs to get to your
server, for example, http://184.108.40.206/.
No one else can see my server. Where do I look?
First, check to see that your server is running. Then try to access
it locally using the above URL. If both of these work then the server is
OK and the problem is networking related. Go to another computer on your
network and ping your server computer. If you don't know what
ping is, consult the Windows NT or Windows 95 TCP/IP networking
documentation or contact your local network administrator.
The file server.log is huge! What can I do?
Check the Logging tab in the WebSite property sheet and disable all
tracing options. Tracing is useful for diagnosing problems with CGI
programs and the server itself. Normally you should run the server with
all tracing disabled. Once you have disabled tracing, stop the server,
delete the server.log file and restart the server.
My Netscape users have problems loading inline images.
Sometimes they get broken icons. Is WebSite buggy?
Of course not! If you have "hold connections open for re-use" enabled
in Server Admin (General Page), try turning it off.
As of April, 1996, some browsers have quirks in their support of
keep-alive, which cause this behavior if the option is enabled.
Users get broken images if they don't put a
trailing slash on some URLs. What's wrong?
Check the Identity tab on the WebSite property sheet and see that the
host name is correct. You would have caught this if you had run through
the self-test and demonstration after you
When using the NT command scheduler (AT or WinAT),
logcycle.exe doesn't cycle the server logs.
Logcycle.exe is a desktop application. To successfully
schedule log cycling, it must be able to communicate with AT and
To ensure proper communication, set up the following services:
Scheduler service (must be running for AT to work): allow
service to interact with desktop (control panel, services,
scheduler, startup button)
WebSite as a service: allow service to interact with desktop
(control panel, services, webserver, startup button)
WebSite as a desktop application: no special requirements
AT: command line needs to have the argument /interactive
WinAT (GUI AT interface from resource kit): interact with
Note that any time you run WinAT and edit an entry, verify that
/interactive is turned on. A bug in WinAT causes /interactive to
be turned off when entries are edited.
When running WebSite as a service (under NT), the icon doesn't show.
To run as a service, WebSite must be run under a system
account. Do not run WebSite as a service under a nonprivileged
user account. Windows NT 3.51 security will not give an
unprivileged process access to the desktop. The simplest solution
is to run WebSite under the system account as it was installed.
How can I add more than five IP addresses to a Windows NT system? The Advanced
Networking option of the Control Panel limits me to five IP addresses.
Having more than five IP addresses per Network Interface Card (NIC)
is not supported by Microsoft. However, it is possible to add more
IP addresses through the Registry.
Mistakes with the Registry Editor (regedit) can be fatal to your system!
To add more IP addresses, follow these steps:
With the Registry editor, look under HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services and locate the entry, or entries, for
your Ethernet card. If you have more than one entry, you must
determine which is the primary one. For example, a 3Com Etherlink
III card probably has two keys, Elnk3 and Elnk31. Open each key and
look in the Linkage sub-key to see which one points to the other.
For the 3Com card, the Linkage sub-key Elnk3 points to Elnk31 as
the primary key.
Open the primary key for your Ethernet card and locate the Tcpip key under the
Parameters key. The hierarchical path should look something like this:
Under the Tcpip key, locate the named value IPAddress. This value is of type
REG_MULTI_SZ (multi-string). Each of the component strings represents one of
the IP addresses on which the NIC will answer. If you have entered five IP
addresses using the Control Panel, those five IP addresses are listed.
Double-click the IPAddress value, and the multi-string editor dialog appears
showing all the IP addresses you have already assigned.
Add additional IP addresses by appending them to the list, each one
on a separate line. We recommend that you have no more than 16 IP
addresses total. If you add too many, TCP will not start.
Don't forget to add an appropriate subnet mask for each entry.
Reboot the system. If TCP doesn't start, remove some of the addresses and try
You are now ready to set up multiple virtual servers (one for each
IP address), using the Identity wizard on the Identity page of Server Admin.
I have a server that uses only CGI programs (no static documents),
and I would like to allow users to self-register. How can I get the
username and password information from the authentication dialog?
First rename your CGI program so the name starts with a $. This
naming convention causes the server to pass the username and
password through the CGI interface. The CGI-BAS that ships with
WebSite (V1.7) includes the CGI_AuthPass and CGI_AuthUser variables.
To get the browser to display the username and password dialog (if
the request doesn't contain a username), have your CGI program
respond something like this:
Send "HTTP/1.0 401 Not Authorized"
Send "WWW-Authenticate: Basic Realm=""My Cool App""")
This response causes the browser to display the username/password
dialog. The user fills it in, presses OK, and the browser repeats
the previous request with the username and password included. Your
CGI application will get both username and password if you start
its name with a $ in the variables CGI_AuthUser and CGI_AuthPass.
Note that this example is for CGI programs written in Visual Basic.
If you aren't using Visual Basic, the process is still the same,
except you need to know the key names for username and password
that are used in the INI file. For more information on this, see
the Windows CGI
If you are using the Standard or DOS CGI interfaces, the
environment variable names are AUTH_USER and AUTH_PASSWORD.
My CGI execution is slow and my disk seems to be beaten to death.
Nothing will improve this situation better than adding more RAM. On
Windows NT, 16MB is not enough to run NT, WebSite, and do
database CGI. In fact, the RAM requirements for WebSite are 32
MB minimum for Windows NT and 16 MB minimum for Windows 95.
Note that those figures are the minimums. If you have a heavy load
and run complex CGI programs, or if you are running a mix of
database CGI and local work on the same system, you should consider
64MB or 128MB. WebSite users universally attest to dramatically
improved performance when they increase their RAM.
When I set up virtual servers, all my CGI programs stop working.
Make sure your CGI directories are properly mapped for each new
server. Each virtual server must have a URL prefix. Add that prefix
to the mapping for each CGI. For example:
/prefix/cgi-win/ C:\path\to\Win CGI directory
If you use the Identity wizard to set up your virtual servers, the
document and CGI mapping is done automatically for you. See the
Identity page in Server Admin and the instructions in Chapter 10,
Virtual Servers and WebSite.
I have WebSite running under Windows 95 and I want to
administer it remotely. Why am I having problems?
First, you cannot remotely administer the WebSite server
running under Windows 95 from a computer running Windows NT.
Administering the server from another Windows 95 system requires
the following conditions:
The remote computer (the one running WebSite) must be on a
network (in the same domain) as a Windows NT system with a user
list. The NT system enables user-level security for Windows 95
Enable remote Registry administration on the remote Windows 95
computer by installing the Remote Registry service, and by
selecting User-Level (rather than Share-Level) security.
Note also, in order to administer remotely, you must be logged into
the local computer as a user who has administrator privileges on
the remote computer (as defined by the user list on the NT system).
I'm having problems with a CGI program that I wrote. Any tips for
- See the white paper on
Debugging CGI Programs in the Tech Center at WebSite Central.
My CGI programs work okay except that images in the resulting
documents are broken.
CGI programs create virtual documents, which have no location in
file space. Thus, any relative URLs (for images or links) don't
work because relative URLs are relative to the current document
(see the next question for more on mapping). Note the following examples:
This reference is bad because the URL path is completely relative.
The server will not be able to locate this document.
This reference is better because the leading slash makes the URL
path absolute to the document root of the server.
This is the best reference because the URL is complete, and it
leaves no ambiguity for the image's location.
Some of my links work fine and others don't. I suspect my problem
may be mapping. Can you give me some pointers?
First, read Chapter 9, Mapping,
carefully and work through the examples. Apply the principles
covered in that chapter to your own situation.
In a nutshell, here are some general principles on relative URLs
that generally cause the most problems in creating document links
in your HTML files:
Q: Relative URLs are relative to what?
A: To the current document.
Q: What is the current document?
A: The URL displayed by the browser when a document is loaded.
Q: Why is a URL with a leading slash different?
A: A leading slash denotes the current server's document root.
Thus, the URL /index.html equals http://current_server/index.html
Q: Are there any URL forms that I should avoid?
A: Yes, avoid URLs beginning in ../. These URLs can easily cause grief.
When I install WebSite under Windows 95 or try to run the
server self-test under Windows 95, it fails.
You may have insufficient DOS environment space. Try adding the
line CommandEnvSize=8192 to the [NonWindowsApp] section of
The following guidelines will help you diagnose and solve problems
you may encounter while using WebSite. Please work through
these before calling technical support.
Reboot the system to ensure that the effects of any unstable or
faulty software are removed from memory.
- Make sure you have completed and used the WebSite
Installation Requirements checklist (Chapter 2, Before You Start)
- Make sure you have tested the server according to the
procedures outlined in Chapter 3, Installing WebSite.
- Run the WebSite server self-test
to verify that your server is set up correctly.
(See Chapter 3.)
- Complete specific examples in the server self-test for areas in
which you are having problems. For example, if an image map you are
creating won't work correctly, but the one in the server self-test
does, compare the source code in the self-test with the code you
created and find your error.
- Browse WebSite from the local computer and from a different
computer. If browsing locally works, but remotely doesn't, you have
a network problem. Contact your network administrator.
- Test your network connection with another tool or application,
such as ping or telnet. For example, if you ping localhost, the
true name it resolves to should be the same name used in Server
Admin (Identity page) and in your TCP/IP configuration (computer
name and host/domain name).
- Stop the server and check the error log.
(See Chapter 13, Logging.)
- Stop the server and check the server log.
(See Chapter 13.)
- Enable various tracing options for the server log, and recreate
the problems you are having. Then stop the server and check the
tracing data in the server log.
(See Chapter 13.)
- Check the WebSite abort log (located in the WebSite
directory) for fatal internal server errors. When the server won't
start, the abort log may show you why.
- Check the Application Event Log (from the Windows NT Event
Viewer) for information and warnings about problems with the application.
- Check the diagnostics information provided for HTML files in
WebView for possible HTML tagging errors. (See Chapter 4, Managing Your
Web Using WebView.)
- Look closely at the error messages sent from the server to the
browser. For example, in the Not Found return, the server reports
both the URL and the physical file pathname for the URL
target, information invaluable in diagnosing mapping problems. Not
all browsers save error messages. If yours doesn't, we recommend
that you try another browser or enable Dump Sent Data tracing,
which shows what the server sent to the browser.
(See Chapter 13.)
- Double-check your mapping. Make sure that CGI mappings do not
conflict with document mappings. Remember that CGI directories
cannot exist within document directories.
(See Chapter 9.)
- Your Web browser's View Source option often points out useful
information. Perhaps an HTML tag is missing or incomplete.
(See Chapter 5, HTML Tutorial and Quick Reference.)
- If you are doing CGI work, enable CGI tracing in Logging and use the
DEBUG_MODE CGI variable to enable debugging/tracing features of your CGI
program. (See Chapter 16, Developing Applications with Windows CGI.)
WebSite Central, the
web site maintained for WebSite users by
the technical support staff at O'Reilly & Associates, provides
product information, answers to frequently asked questions (FAQs),
troubleshooting help, advice for particular implementations of
WebSite, ideas for new uses of WebSite, sample HTML files,
helpful utility programs, and opportunities to interact with other
You can tap the resources at WebSite Central with your browser, and
find out how others have dealt with similar problems. In addition,
the Frequently Asked Questions (FAQs) and Infrequently Asked
Questions (IAQs) published on WebSite Central, may provide just the
answer you need. You will also find pointers to other resources on
the Web, such as specifi- cations, helpful application tools, and
resources for products bundled with WebSite.
Contacting Technical Support
If you've thoroughly tried all the other resources to solve your
problem and you still need assistance, O'Reilly & Associates
provides technical support for WebSite as listed below:
On a per-incident basis. For per-incident tech support,
call O'Reilly Technical Support at 1-707-829-0515.
Have your credit card ready.
On an annual basis with a technical support contract. Contracts are
available for a variety of needs and software package combinations.
To learn more about annual support contracts, contact O'Reilly &
Associates Customer Service at 800-998-9938 or send email to
Copyright © 1994-96 O'Reilly & Associates, Inc.
All Rights Reserved.
O'Reilly Software Online, WebSite Central, WebSite, and
WebSite Professional are trademarks of O'Reilly & Associates, Inc.
All other names are the trademarks of their respective companies.