by John Jung and William Robert Stanek
FrontPage in itself is an impressive WYSIWYG HTML editor. However, Microsoft has also thrown in a Windows NT/95-based Web server, called the Personal Web Server, with the FrontPage package. You might be wondering what to do with this server. This
chapter explains why you might need a Web server and how to use the one included with FrontPage.
Is it really important to have a Web server along with an HTML editor? Absolutely. The Personal Web Server brings with it many different uses for everybody, from an individual creating his own Web page to an organization looking to create a presence on
the Net. The bundling of a full-fledged Web server makes FrontPage the front-runner as an end-all Web package.
Although an individual might not really need a Web server, there are times when having one is useful. One such instance is when you're designing and maintaining large Web pages. This situation typically occurs in large organizations where each internal
group has its own Web space. In this situation, groups typically have to design their Web pages without direct access to the Web server, so the Webmaster of each group has to maintain the content of the group's Web page. What this all adds up to is a lot
of bookkeeping on the part of each group's Webmaster.
Another use an individual might have for a Web server is in creating CGI scripts. Most advanced HTML elements, such as forms and image maps, depend on CGI scripts to work. Directory location, server type, and other technical information are often
needed in CGI script creation. Traditionally, creating these scripts required the Web author to get this information from the Webmaster. If there were some miscommunication between you and the Webmaster, your CGI script would probably fail. Consequently,
such scripts were created through trial and error. Also, tracking down buggy parts of CGI scripts could be problematic because you might need to look at system files.
By including a Web server with FrontPage, both these problems are easily resolved. Complicated Web sites are easier for the Webmaster to manage because she can easily check links when changes are made. If she adds, moves, or removes Web pages, she can
easily try the latest links on the Personal Web Server. Also, you can now test and debug CGI scripts without putting them on the actual Web server. Rather than guessing how a particular script might behave, you can test it. All these capabilities make the
Personal Web Server an invaluable tool for Web authors. Web pages and CGI scripts can now be correct the first time they're pushed out to the actual Web server.
Although there are some good reasons why you would find a Web server useful, there are also reasons why it's not useful. For one thing, if you're designing very simple Web pages, you really don't need a Web server. You don't need a Web server to see
how the <H1> tag looks or how your tables come out. You can correctly view and test these and other simple aspects of Web pages with a Web browser.
Another reason you might not want a Web server is because you're low on disk space. The typical Web server uses 6 to 10 megabytes of disk space for the server software alone. The content of the Web server takes up additional disk space. Although having
a Web server might be useful, you have to ask yourself if it's a luxury you can afford. Is it worth 10 megabytes of disk space just to verify your CGI scripts?
Organizations might need a Web server because they're looking to establish a Web presence. A Web presence can be a benefit for any size of company or organization. For companies that already have an Internet domain, a Web presence can provide great
customer support. Along with providing sales material, they can distribute information for customers. Such information might include frequently asked technical support questions, bug reports, or software updates.
Although a Web server might be beneficial for many businesses, it's certainly not right for all businesses. If you're running a corner drug store, does it really make sense to have a Web server? Probably not. Although it might be interesting to run a
server from the store, you would probably do better letting someone else host your Web presence. Having someone host your Web presence dramatically reduces the cost of doing business on the Web.
You've decided that you could use a Web server. Why should you use the Personal Web Server that comes with FrontPage? (Just because it's included doesn't mean that you should necessarily use it.) One reason to use the Personal Web Server is that it's
extremely flexible. It can talk to other Web servers if server extensions have been installed. This flexibility makes it possible for an organization to use the Personal Web Server as its main Web server. From there, the organization can access other Web
servers for different needs. For example, if you're running a Web site that allows people to purchase things over the Net, you can run the catalog of items on a Personal Web Server and access a commerce Web server when needed.
Another reason that you should use the Personal Web Server is because FrontPage is an integrated package. Any changes made on any Web page are instantly available. This integration allows for a faster and easier method of updating information for
different departments. Most traditional Web servers, especially corporate ones, have a staging area. Web pages are created and modified in the staging area before they are published to the outside world. With the Personal Web Server and FrontPage working
together, this area is no longer needed.
The Personal Web Server is easy to install. You can use most of the default options, and at the end of the process, you have a fully functional Web server.
The Personal Web Server is automatically installed as part of the Typical installation of FrontPage. You can also use the Custom option to install only certain pieces of the product, such as just the client applications, the Personal Web Server, or
server extensions. By default, FrontPage is installed to the C:\Program File\Microsoft FrontPage folder and the Personal Web Server is installed to C:\FrontPage Webs. You can easily change this location as needed using the
Browse button. The installation is very simple, and if the defaults are sufficient for your purposes, there is no reason to change them.
The Personal Web Server operates like most other HTTP servers. Generally, the server communicates over port 80 and requires TCP/IP as a transport for the HTTP information. The server application is a WIN32 application, so a requirement for operation is
a 32-bit TCP/IP stack. The Personal Web Server does not operate with 16-bit TCP/IP stacks. If you do not know whether you have the necessary 32-bit TCP/IP stack, FrontPage ships with a TCP/IP Test application that you can run to test whether the Personal
Web Server will run on your system. This application, although very simple in scope, provides the most important information you need to set up your Web server, as you can see in Figure 36.1.
Figure 36.1. The FrontPage TCP/IP Test application details the TCP/IP information for your computer.
To run the TCP/IP Test tool, execute the TcpTest.exe program located in the bin directory under the FrontPage installation. Alternately, you can select About the FrontPage Explorer from the
FrontPage Explorer's Help menu and then click the button labeled Network Test.
NOTE
The Personal Web Server installed on your system may run on port 80 or on port 8080. Port 8080 is an alternate port used only when you have another server installed on your system that is using port 80.
The information that this application captures is the same information that is used by the installation program when you install FrontPage. This information is stored in the configuration files for your server and can be changed manually if needed by
editing those files, as you'll see later in the chapter. If your TCP/IP stack is configured correctly, FrontPage should discover the information similar to what you see in this dialog. The information that is returned by the TCP/IP Test application is what
you use for an URL to your site. The Personal Web Server uses this same information as its identity.
TIP
If you publish your Web pages for others to see, always refer to the host name as TCP/IP Test application lists it, and always include the trailing slash (/) character. Without the slash, the URL path to your server is not complete; it is missing the path portion of the URL. When a server receives a URL without path information, it has to issue a server fix to correct the URL with an assumed path equal to the root of the server. This fix is a potential cause for performance problems because the server has to execute this fix on every URL received in this manner. Following this advice, you reference the URL path to your home page as http://www.tvp.com/ rather than http://www.tvp.com.
You can use either the host name or the IP address for your server because the host name is actually just a convenient way to reference the server for human readability. When you enter a host name in an URL, the request is sent to a Domain Name Server
(DNS) to translate the host name to an IP address. Then, the request is routed to the appropriate network address. Without the DNS, you would have to remember numbers such as 199.177.202.10 or 198.105.232.30 instead of names such as www.mcp.com or www.microsoft.com, which are the host names of those same IP addresses.
NOTE
The host name localhost and TCP/IP address 127.0.0.1 are reserved names. This host name and IP address refer to the local machine. You should be able to open Web pages on your local machine using an URL of http://localhost/ or http://127.0.0.1/ instead of your fully qualified domain name.
After you have this information, it is quite simple to install the Personal Web Server and begin to build the content using FrontPage. Although you won't be asked during installation to input the test information, FrontPage uses the test information to
configure the Personal Web Server. When installing FrontPage, if you chose the Custom installation from the opening dialog, you have the option to only install the portions of the program that you need to install. You could, for instance, install the
client software on your main PC and the Personal Web Server and server extensions on another PC that is dedicated to Web traffic.
During installation of the Personal Web Server, you are asked to provide an administrative name and password. You are asked to enter this information before the FrontPage Explorer can open a Web for editing. FrontPage enforces this built-in
authentication so that only authorized administrators or authors can change the content of your Web. If you later add individual authors, they are shown a similar dialog before authoring access is allowed.
Generally, the Personal Web Server is configured to run automatically at startup. However, you might need to start the Personal Web Server before using it the first time using the shortcut for the Personal Web Server from the Start/Programs/Microsoft FrontPage folder. After you have verified that the server is running as you want it to, you probably want to have the server start automatically.
You can set the server to do this by double-clicking the server icon on the taskbar. This icon depicts a PC with a globe behind it. Double-clicking the server icon opens the Personal Web Server Properties dialog box shown in Figure 36.2.
Figure 36.2. Setting server properties is done with the Personal Web Server Properties dialog box.
Click the Startup tab. As you can see in Figure 36.3, you can manipulate the state of the server and its startup options. To have the server run automatically at startup, select the checkbox labeled Run the Web Server Automatically at Startup. To
ensure you can easily manipulate server properties, you should also select the checkbox labeled Show the Web Server Icon on the Taskbar. Now, as long as you are logged in to the computer, your server will be running and people can access your content.
Figure 36.3. You can configure the server to start automatically using the Startup tab.
The Personal Web Server fully supports basic authentication and Windows NT challenge/response authentication. The authentication mechanisms are used to allow access for authoring as well as to add access restrictions to sections of your web.
If you are running Windows NT 4.0 or you have Windows 95 set to provide separate profiles for each user, your Web server only runs when the user who installed the server is logged in. If this is not the behavior you want, edit the Registry in Windows
95 to add the Personal Web Server executable vhttpd32.exe to the Run key in the Registry. In Windows NT, you can use the servany.exe file from the Resource Kit to run
the server as an NT service. When run as a service, the Personal Web Server runs no matter who is currently logged in to the PC. You could also log in as the administrator account when you create the Startup folder shortcut so that the shortcut is seen by
all users.
CAUTION
If you choose to edit the Registry in Windows 95, the key you need to edit is the following:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunYou need to add a string value to this key using the information in the other values as examples. Using the Registry Editor incorrectly can cause serious system-wide problems that might require you to reinstall Windows 95 to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.
After you make the appropriate changes, the Personal Web Server automatically starts so anyone can connect to your server the next time you reboot your PC.
The Personal Web Server supports both HTTP and FTP services. When you install the Personal Web Server, the only service running is HTTP. Using configuration settings of the Personal Web Server Properties dialog box, it is possible to configure the
server to run both HTTP and FTP, to run only FTP, to run only HTTP, or to run neither service. You can also use this dialog box to configure how these servers are started. Generally, the HTTP and FTP services are either started automatically or manually.
With the Personal Web Server acting as your FTP server, you gain the ability to locally support FTP file transfers to and from your computer's FTP directories. Just as you can restrict access to the Personal Web Server, you can also restrict access to
your FTP server. Access can be restricted by user name and computer IP addresses. To run the FTP service, you need to open the Personal Web Server Properties dialog box and click the Services tab.
As you can see from Figure 36.4, the Services tab is used to start, stop, and set properties for the HTTP and FTP services. In the Services area, click the entry for the FTP service. You can use the buttons labeled Start, Stop, and Properties. Clicking
the Start button changes the status of a Stopped service to Running. Similarly, clicking the Stop button changes the status of a Running service to Stopped. Because you want to start the FTP service, click the Start button.
Figure 36.4. Configuring HTTP and FTP services is handled with the Services tab.
With the FTP service selected, click the Properties button. You can set startup and directory options for the server using the FTP Properties dialog box shown in Figure 36.5. If you want the FTP service to start automatically when the Personal Web
Server starts, select the checkbox labeled Automatic.
Figure 36.5. Setting FTP service options is easy with this dialog box.
The FTP Home Root Settings area of the FTP Properties dialog box provides information about the Internet address of the FTP server and the server's home root directory. The Internet Address is the address you or other users use to access the server.
The home root directory is the directory accessed when you log into the server. Large sites probably want to immediately create additional folders in this directory to store files by category or type.
By default, the FTP server home root is C:\WebShare\ftproot. To change the home root directory, click the Change FTP Home Root button. This launches the Internet Services Administrator, which is a web-based application for
controlling your FTP and HTTP services. You'll read all about the Internet Services Administrator in Chapter 37, "Personal Web Server Administration." When you change the home root, users no longer have access to the old home root directory.
HTTP is the key to accessing the Web and HTML pages. Without the HTTP service, no one can access your Web pages, which is why the HTTP service is set to run automatically when the Personal Web Server starts. As with FTP, you can restrict access to HTTP
by user name and computer IP addresses.
To change the state of the HTTP service or change the home root directory, you need to open the Personal Web Server Properties dialog box and click the Services tab. In the Services area, click the entry for the HTTP service. After you make a
selection, you can use the buttons labeled Start, Stop, and Properties. Click the Start button to change the status of a Stopped HTTP service to Running. Click the Stop button to change the status of a Running HTTP service to Stopped. Click the Properties
button to set startup and directory options for the HTTP service.
As you can see from Figure 36.6, the Properties dialog box for the HTTP service is similar to the Properties dialog box for the FTP service. Using the radio buttons labeled Automatic and Manual, you can redefine how the HTTP services starts. Using the
Change Home Root button, you can define a new location for Web pages. An addition to this dialog box is the Change Home Page button.
Figure 36.6. Configuring the HTTP service is handled with this dialog box.
By default, your home page is set to index.htm. This means that anyone accessing your Web site using the URL path to your server, such as http://www.yourserver.com/, is served a document with
the filename index.htm. You can change this to one of several widely used defaults, such as default.htm, default.html, or index.html. You
can change the home page to any specific page of your liking.
NOTE
Clicking the Change Home Root button or the Change Home Page button launches the Internet Services Administrator. This web-based application for controlling your FTP and HTTP services is discussed in Chapter 37, "Personal Web Server Administration."
The Personal Web Server that comes with FrontPage is pretty straightforward. You administer the server using the FrontPage Explorer and the Internet Services Administrator. Using the FrontPage Explorer, you set general settings and permissions for the
Personal Web Server. Using the Internet Services Administrator, you can remotely administer HTTP and FTP services as well as local user accounts.
The Personal Web Server is, as its name implies, a server for individuals. That's not to say that it's limited or doesn't have a lot of features. Quite the contraryit has all the standard features you'd expect from a typical shareware Web server.
The only difference is that it doesn't implement many of the additional features you find in more expensive commercial servers. For example, it doesn't provide a news server. However, the Personal Web Server is more than adequate for most needs.
As mentioned before, the Personal Web Server supports a number of advanced Web server features. It supports such things as automation with WebBots, database connectivity, and discussion groups. You'll also find full support for CGI, which is useful for
processing forms. It also provides built-in support for image maps in FrontPage, Netscape, NCSA, and CERN formats. Client-side image maps in the form of Netscape or Microsoft extensions to HTML are also supported. The Personal Web Server provides built-in
support for O'Reilly's Web site. This support means that if you're already running a Web server with that software, FrontPage has no problems with it.
Because you're running the Personal Web Server, you're probably your organization's Webmaster. As the Webmaster, the most useful tool FrontPage provides is the Internet Services Administrator, which you use to manage your HTTP and FTP services. To work
with the Internet Services Administrator, you need to access the Personal Web Server Properties dialog box by double-clicking the Web server icon on the taskbar and then click the Administration tab. You launch the Internet Services Administrator by
clicking the button labeled Administration (see Figure 36.7.) Web server administration is covered in depth in Chapter 37, "Personal Web Server Administration."
Figure 36.7. You can access the Internet Services Administrator using the Administration tab of the Personal Web Server Properties window.
Although the Internet Services Administrator program gives you a great deal of control, part of a Webmaster's function still lies within the FrontPage Explorer. In this program, you can easily create, copy, and delete webs from any FrontPage Web server
for which you are the Webmaster. You can also specify who is, and isn't, a Webmaster for each particular web. Similarly, you can control who can, and can't, create pages for each web. Finally, the FrontPage Explorer gives the Webmaster the ability to
specify whether a certain web is publicly accessible. By default, every web is publicly viewable, but this situation might not always be desirable.
FrontPage extensions allow Windows 95, Windows NT, and UNIX Web servers to directly interface with a FrontPage server. To fully utilize the extensions, you must have a Personal Web Server running somewhere on your network. This machine is accessed by
the other Web servers when the extension is triggered.
Extensions are simply separate programs that run on the remote Web server. These programs, which are available for a large number of UNIX platforms, enhance existing Web servers. After you install the extensions, you can access FrontPage webs. This
kind of access gives you the best of both worlds. You can have a Personal Web Server running on a Windows NT machine to perform the regular Web server functions. In addition, you can have a commercial Web server that takes care of secure transmissions.
If an extension you need is not on the CD you used to install FrontPage, you can get FrontPage extensions by pointing your Web browser to http://www.microsoft.com/frontpage/freestuff/agreement.htm. Fill out the form on the corresponding download page. Select the platform you want the extension for and choose the file
format. Depending on the platform you have, the extension can use to 9MB of disk space.
Extensions are very easy and straightforward to install, especially if you already have a Web server installed. Simply uncompress, if necessary, and untar the file you downloaded. Next, modify the configuration files of the existing Web server to point
to the extensions. Finally, restart your Web server, and you can access FrontPage webs.
The FrontPage extensions come with their own barebones Web server administration program (see Figure 36.8). This program allows you to easily shut down and restart the entire Web server that the extensions are installed on. After the extensions are
installed, FrontPage can talk to that Web server.
Figure 36.8. The FrontPage server extensions give you a simple interface for maintaining the server.
A very useful, although somewhat limited, feature of the Personal Web Server is the support of multihoming. Traditionally, multihoming isn't available on all Web server software. Consequently, adding it to some UNIX Web servers requires you to
recompile the server itself. Making a computer multihoming-capable also requires some work.
Most individuals have no need to use the multihoming capability. Even though multihoming is a useful feature, it's still not necessary for everyone. This feature is mainly useful for companies and Internet service providers (ISPs). Even though you
might never need to use multihoming, it's a useful tool to have if you need it.
Multihoming is the capability for one computer on one domain name to pretend to be another domain name. One computer can then appear to be many different computers. Suppose you're the Webmaster for the company mycom.com.
The company spawns off a subsidiary that makes a different product and has the domain name mycom2.com.
Now, traditionally, to provide an Web presence for both companies, you need two computers: one computer to be the Web server for mycom.com and another computer to be the Web server for mycom2.com. Multihoming enables you to use one computer as the Web server for mycom.com and mycom2.com. At the same time, both Web sites look different from each other.
Probably the best example of multihoming in progress is with Web Presence Providers (WPPs). WPPs typically offer the service of domain hosting, which means that the WPP makes its multihome-capable Web server act as your server. You don't need to
dedicate any computing power to handle Web access. The WPP's computers take care of everything for you.
There are two different methods of multihoming. Each has its advantages and disadvantages. Fortunately, FrontPage supports both methods of multihoming.
The first method is to run multiple Web servers on one machine. The computer running the many Web servers is already configured to be different domain names. Each Web server is configured to listen for a different domain name so that when a particular
domain name is accessed, only that Web server is working. This method of multihoming has the advantage that each Web server can run independently of each other. If you need to change the content of one web, you don't have to take down everything else. You
also have the ability to run one type of server for one customer and another type for another customer. If one customer needs secure data transmissions, you can start a commerce server for him only. The obvious downside to this setup is that you can use
valuable system resources running multiple instances of the same program. Consequently, you need a fairly powerful and well-loaded computer for this task. Buying the extra necessary hardware could cost you a significant amount of money.
Another method of multihoming is to have one Web server running one set of configuration. The configuration tells the Web server to listen to different domain names and retrieve the appropriate content. The more people who access all the multihomed
domains, the greater the impact on the Web server. The clear advantage with this method of multihoming is that you're only running one process. Although the process might be running a lot and taking up lots of resources, it's not taking up as much as
having many servers running at once. Another advantage of this method is that when you upgrade the software, you only upgrade one program. The problem with this approach to multihoming is that if you do upgrade the software, everybody's affected. Another
problem is that you'll have a harder time running specific Web servers for specific customers.
Currently, multihoming is most widely supported on UNIX machines. This isn't because the UNIX Web server software is necessarily superior; it's because UNIX is capable of listening to multiple domain names. If a UNIX system receives data intended for
two different domains, it routes the data correctly. To get a UNIX machine to listen to multiple domains, you have to initialize the network devices to listen to the domains. For example, using a Solaris machine as the root, you have to type something
similar to the following:
ifconfig le0:1 www.mycom1.com up ifconfig le0:2 www.mycom2.com up
This code enables your computer to respond to incoming traffic directed for www.mycom1.com and www.mycom2.com. Once your computer is looking for multiple domains, you have to get the Web server
to do the same. This is often a simple matter of modifying a configuration file; for NCSA-based servers, this configuration file is the httpd.conf file. Most Web servers pretend to be a particular host by using the
specifications of ServerName and BindAddress in the httpd.conf file. To make a Web server be the server for www.mycom1.com, you have to add
the following code to this file:
ServerName www.mycom1.com BindAddress www.mycom1.com
Once you have your Web server configured for multihoming, you want to hook it into FrontPage. This is easily accomplished by installing the FrontPage server extension. Download the appropriate extension for your Web server, and install it on that
machine. After you've done that, a file called we####.cnf is placed in the /usr/local/frontpage directory. The #### refers to the port number that the Web server for
that domain is listening to. You must rename the we####.cnf file to hostname:port.cnf. The
hostname refers to the name of that domain's Web server, and port is the number that the server is installed on.
After you have the Web server and the FrontPage extensions up and running, you have to deal with some other issues. First and foremost is that the FrontPage server extensions are basically CGI scripts that run under the server itself. Consequently, the
Web server's CGI scripts must be run as the same user as the HTTP server itself. Probably the best way to implement this is to have the HTTP server and CGI scripts run as the FrontPage user account. This gives your UNIX system the most security and gives
FrontPage the most flexibility.
You can also configure the FrontPage server extensions themselves by modifying the configuration files. Because each multihomed server has its own configuration file in /usr/local/frontpage, you can configure each system
independently. Table 36.1 gives you a complete list of the parameters, what they do, and the acceptable values.
Parameter | Function | Values |
NoExecutableCgiUploads | Prevents files uploaded to the cgi-bin directory from being executable files. | 0 = Files have the execute permission set; 1 = Files don't have the execute permission set. |
NoSaveResultsTo AbsoluteFile | Prevents Discussion, Registration, and Save Results WebBots from writing to an absolute file. | 0 = Can write to absolute file; 1 = Can only write to relative file. |
NoSaveResultsPipeTo | Prevents Discussion, Registration, and Save Results WebBots from sending output to any other program. | 0 = Can send output to another program; 1 = Can't send output to another program. |
NoSaveResultsToLogDir | Stops the Discussion, Registration, and Save Results WebBots from writing to the vti_log directory. | 0 = Allows writing to _vti_log; 1 = Doesn't allow writing to vti_log. |
PreserveTagCase | Keeps the existing case (upper or lower) of HTML tags. | 0 = Does not preserve the case; 1 = Preserves the case. |
ReformatHtml | Allows FrontPage to reformat Web pages that contain WebBots. | 0 = Disables reformatting; 1 = Enables reformatting. |
SaveResultsPipeToAllows | Restricts which programs the Discussion, Registration, and Save Results WebBots send output to. | A list of space-separated programs. |
TextMemory | Indicates how many megabytes text indexing allocates for internal indexing. | Any numeric value. |
UpperCaseTags | Converts all HTML tags to uppercase characters. | 0 = Does not convert characters; 1 = Converts all characters. |
This chapter explained the advantages and disadvantages of having a Web server. Although it gives individuals the ability to write cleaner, and better, advanced Web pages, that might not be enough of a reason to install a server. Although companies
could benefit from having an integrated HTML editor and Web server, they might not need one.
If you think a Web server would be useful to you, you should seriously consider using the Personal Web Server. This Web server, which comes with FrontPage, is straightforward and versatile. It can talk to other Web servers that have FrontPage
extensions installed on them. Also, the Personal Web Server comes with the capability to multihome different domains. Although individuals might not have a need for this capability, companies and some Internet-based companies find it invaluable.