In the introduction to this book I told you about my early experience alongside my dad as he "surfed" the radio waves as an amateur radio enthusiast. Some nights we just listened to the coded conversations as other hams communicated with each
other over the airwaves using Morse code. Other nights, my father participated by joining an existing conversation or by "calling" a friend at a prearranged time.
As you browse the Web with Internet Explorer or watch the threads of a chat using NetMeeting, your experience is similar. I was participating as a "lurker"—listening in on someone else's electronic conversation without entering in
myself.
My experience was even further removed by the fact that I didn't know the language. My dad was an active participant. He understood the language, had all the right tools, and was skilled at their use.
I've come a long way from those days with my dad. I still can't send Morse code, but I have learned a new language, and I have the right tools. As you've read through this book, you've come a long way too. You've learned just about everything you need
to participate in this phenomenon called the Internet. There is one more piece in the process, however, that hasn't been discussed thoroughly. That piece is the Web server. If you really want the whole online experience, you've got to run your own Web
server. When you set up a server, you cross over from being a Web browser to becoming a webmaster! And now that you've learned the language, and you have all the right tools, nothing's stopping you from setting up your own Web site.
This chapter offers a close-up look at the FrontPage Personal Web Server. In the course of learning about the server, you will also use the complete FrontPage package to redesign the Sams.net Web pages on the Net. The beauty of the Personal Web Server
is best demonstrated, so I recommend that you take the time to complete the FrontPage tutorial outlined in the Help for FrontPage. This tutorial goes a long way toward illustrating exactly how the server operates and the way FrontPage uses the concept of
a
web to assist in managing the whole Web site as individual manageable structures.
The FrontPage Personal Web Server is a very capable Web server that can easily handle the traffic you might get from an intranet web site or even a moderately used Internet site. It is a 32-bit application, which among other things means that on Window
NT or Windows 95 it runs in its own address space and its processes are preemptively multitasked with other applications you might have running. It's not going to crash when or if another application crashes. Because its code is derived from NCSA HTTPD
source code, it is a well-designed server, uniquely suited to the Windows 95 or Windows NT environment. If you purchased FrontPage only for the Personal Web Server, you would get your money's worth. You can extend your server using FrontPage WebBots or
standard CGI scripts written in C or C++. The access log files are in the NCSA format, which has become the standard for server log files, so you will find a number of standard tools available on the Internet for log file analysis. And, of course, you
already have a fully integrated Web publishing system with the rest of the FrontPage package.
NOTE
At the time of this writing, Microsoft has announced intentions to replace the existing Personal Web Server in FrontPage with the new Peer Web Services that will be part of the next release of Windows 95 and Windows NT. Some configuration might therefore be different when this is done.
To give you a good understanding of the Personal Web Server's operation, the next sections cover these main areas:
A fairly detailed discussion of the installation of the Personal Web Server is presented in Chapter 27, "Using FrontPage Editor," so there isn't much to add as far as the basic installation is concerned. The Personal Web Server is
automatically installed as part of the Typical setup, as shown in Figure 29.1. You can also use the Custom option to install only certain pieces of the product, such as just the client applications, or the Personal Web Server or server extensions. As you
can also see in this figure, the default location for FrontPage is the C:\Program Files\Microsoft FrontPage folder. You can easily change this location as needed using the Browse button. It is a very simple installation, 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. 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. It will not operate with 16-bit TCP/IP stacks. If you do not know whether or not 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, though very simple in scope, gives the most important information you need to set up your Web server, as you can see in Figure 29.2. If you use the TCP/IP stack supplied with either Windows 95 or Windows NT you will be able
to use the Personal Web server directly in either a network or dial-up configuration.
Figure 29.2. FrontPage TCP/IP Test application details the TCP/IP information for your computer.
The information that this application captures is the same information that will be used by the installation program when you install FrontPage. This information is stored in the configuration files for your server, and you can change it manually if
needed by editing those files, as explained 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 box. The Test application discovered that my PC is running a
32-bit TCP/IP stack, with a host name of jawapc.remote.ingr.com, at IP address 129.135.35.105. The information shown here is what you would use for a URL to your site, as well as the information that the Personal Web Server will use as its identity. When
you tell people to connect to your site, the correct URL from the preceding information would be
http://jawapc.remote.ingr.com/
or
http:// 129.135.35.105/
TIP
If you publish your URL for others to see, please always reference the URL as shown and always include the trailing slash (/) character. Without the slash, the URL 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 fixup to fix the URL with an assumed path equal to the root of the server. This fixup is a potential cause for performance problems as the server has to execute this fixup on every URL received in this manner.
The reason that you can use either the host name or the IP address for your server is that the host name is actually just a convenient way to reference the server for human readability. What really occurs when you enter a host name in a URL is that 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 we would all have to remember numbers like 199.177.202.10 or 198.105.232.30 instead
of
names like www.mcp.com or www.microsoft.com, which actually are the host names of those same IP addresses.
NOTE
You might have noticed the designation localhost in the TCP/IP test dialog box. The name localhost and the IP address 127.0.0.1 are reserved names for the local machine. You normally should be able to open Web pages on your local machine using a URL of http://localhost/ or http://127.0.0.1/ instead of your fully qualified domain name.
When you have this information, it is quite simple to install the Personal Web Server and begin to build the content using FrontPage. Though you won't be asked during installation to input the information, FrontPage will use the information to
configure
the Personal Web Server. You might have noticed in the introduction to this chapter that the Personal Web Server can be installed separately from the client software. As shown in Figure 29.3, if you choose the Custom installation from the opening dialog
box, you are given the option to install only the portions of the program that you need to install. You could, for example, install the client software on your main PC and the Personal Web Server and server extensions on another PC that would be dedicated
for Web traffic. You'll also notice that if you install only these components, you'll need only 965KB of space—a very minimal impact on your system.
During installation of the Personal Web Server, you will be asked to provide an administrative name and password, as shown in Figure 29.4. You will be asked to enter this information before the FrontPage Explorer can open a web for editing. This is
part
of the built-in authentication that FrontPage enforces so that only authorized administrators or authors can change the content of your web. If you later add individual authors, they will be shown a similar dialog box before authoring access is allowed.
The Personal Web Server fully supports HTTP basic authentication, and it is a version of this mechanism that is used to allow access for authoring as well as to add access restrictions to sections of your web.
After the server is installed, you will need to start the Personal Web Server before you use 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 will probably want to have the server start automatically by adding a shortcut to the server in the Startup folder. Then as long as you are logged in to the computer, your server will be running and people can assess your
content. If you are running Windows NT 4.0 or you have Windows 95 set to provide separate profiles for each user, your Web server will run only when the user who installed the server is logged in. If this is not the behavior you wanted, you could edit the
registry in Windows 95 to add the Personal Web Server executable vhttpd32.exe to the Run key in the registry; or if in Windows NT, you could 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 will run no matter who is currently logged on to the PC. You could also log in as the administrator account when you create the Startup folder shortcut so that the shortcut will be seen by all users.
CAUTION
If you choose to edit the registry in Windows 95, the key you need to edit is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
You 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.
When you have made the appropriate changes, the next time you reboot your PC, the Personal Web Server will automatically start up so anyone can connect to your server.
In most installations there is no need to change the configuration of your server. If you have installed the server properly and you are able to browse the contents using Internet Explorer, the server is running. But sometimes you might need to change
the server from its default operation. For example, you might need to change your server's configuration if you need to run the server on a different port. You might have to add a new MIME type to serve a new data type, or you might need to add access
restrictions to a portion of your web.
All of these changes are performed in FrontPage by directly editing the server configuration files. If you accept the installation defaults, the server's configuration and access information is located in the C:\FrontPage Webs\Server\conf folder. The
four main configuration files are called http.cnf, srm.cnf, mime.typ, and access.cnf. If you are familiar with the UNIX NCSA servers, you will recognize three of those names as similar to the configuration files for those servers that are named with the
extension .conf. The contents of these files are very similar as well, and Microsoft even points you to http://hoohoo.ncsa.uiuc.edu/ for more details on the configuration. Another file examined in this chapter is
the mime.typ file, which details the MIME types that the server recognizes.
The following sections look at each of these files in turn to see what settings might commonly need changing.
The httpd.cnf file is the main configuration file for your Personal Web Server. This file contains the location of the server root—the location of the vhttpd32.exe server executable. This is where you will find the port number on which the server
listens for HTTP requests. Listing 29.1 shows a portion of this file.
Listing 29.1. Partial listing of the httpd.cnf file.
# ServerRoot: The directory the server's config, error, and log files # are kept in. This should be specified on the startup command line. # # Format: ServerRoot <path> # ServerRoot e:/frontpage\ webs/server/ # Port: The port the standalone listens to. 80 is the network standard. # Port 80
There is usually no reason that would require you to change any of these settings. But if, for example, you manually moved the server files from the E: drive to another drive, you could change the ServerRoot directive to the new location to enable the
server to run and find its other files. The other configuration files use the ServerRoot as the default starting location for their files, so when you change this one directive you do not need to change the other files. Another common reason to change
this
file is if you want to run the server on a different port than the default Port 80. You might already have another Web server installed on Port 80, and you just want to install the Personal Web Server for testing purposes. You could change the port
directive line to read something like the following, which would cause the server to listen to Port 8080 instead of Port 80:
Port 8080
TIP
You might have encountered a location on the Web with a URL like http://www.someplace.com:8080/.
This means that the server is running on Port 8080, a common alternative to Port 80. Also note that without the :8080 portion of the URL, a client browser will fail to connect to the server.
After you make any changes to this or the other configuration files, you will need to stop and restart the Personal Web Server for the changes to take effect. And it is always a good idea to make a copy of these files before you make any changes.
FrontPage already ships an original unedited version of these files named with an .org extension, as in httpd.org, but you still should make sure that you have a backup copy of these files for safety's sake.
The Server Resource file contains settings that control the document layout for your server and the file and folder names that a client will be allowed to see. It is this file that defines the location of your DocumentRoot—the location for the
content of your Web. As you can see in Listing 29.2, this file also determines the default directory index file, the file that the server will attempt to load when a URL ends without a filename as in http://www.where.com/.
Listing 29.2. Partial listing of the srm.cnf file.
# DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # aliases may be used to point to other locations. # DocumentRoot e:/frontpage\ webs/content # DirectoryIndex: Name of the file to use as a pre-written HTML # directory index. This document, if present, will be opened when the # server receives a request containing a URL for the directory, instead # of generating a directory index. # DirectoryIndex index.htm # AccessFileName: The name of the file to look for in each directory # for access control information. This file should have a name which is # blocked from appearing in server-generated indexes! # AccessFileName #haccess.ctl
As shown in Listing 29.2, the DocumentRoot for this server is at e:\frontpage webs\content, but notice also that instead of normal backslash (\) path delimiters you would expect in Windows NT or Windows 95, the srm.cnf file uses the UNIX forward slash
(/) character. This reveals the UNIX roots of the Personal Web Server and is the way paths are delimited throughout all of the configuration files. As with the httpd.cnf file, there will not normally be a reason to change the settings in this file. But,
for example, if you already were using the popular EMWAC HTTPS Web server for NT whose default directory index filename is default.htm, you could change the DirectoryIndex line so that you could easily use your existing files without having to rename
them.
NOTE
The European Microsoft Windows Academic Consortium (EMWAC) created the first popular HTTP server for Windows NT, which is still an easy server to use and configure. Dr. Chris Adie, the author of this server, is also responsible for many of the other tools that are available from the EMWAC server at
http://emwac.ed.ac.uk/
Microsoft eventually shipped this same server as part of the Windows NT Resource Kit, and it was also the base for the commercial Purveyor Web Server from Process Software.
Another section of the srm.cnf file that might interest you is shown in Listing 29.3.
Listing 29.3. Another section of the srm.cnf file.
# AUTOMATIC DIRECTORY INDEXING # ============================ # The server generates a directory index if there is no file in the # directory whose name matches DirectoryIndex. # FancyIndexing: Whether you want fancy directory indexing or standard # FancyIndexing off # IconsAreLinks: Whether the icons in a fancy index are links as # well as the file names. IconsAreLinks off # AddIcon tells the server which icon to show for different files or filename # extensions. In preparation for the upcoming Chicago version, you should # include explicit 3-character truncations for 4-character endings. Don't # rely on the DOS underpinnings to silently truncate for you. AddIcon /icons/text.gif .html .htm .txt .ini AddIcon /icons/image.gif .gif .jpg .jpe .jpeg .xbm .tiff [ic:ccc].tif .pic .pict .bmp AddIcon /icons/sound.gif .au .wav .snd AddIcon /icons/movie.gif .mpg .mpe .mpeg AddIcon /icons/binary.gif .bin .exe .bat .dll AddIcon /icons/back.gif .. AddIcon /icons/menu.gif ^^DIRECTORY^^ AddIcon /icons/dblank.gif ^^BLANKICON^^ # DefaultIcon is which icon to show for files which do not have an icon # explicitly set. DefaultIcon /icons/unknown.gif
If you are familiar with directory indexing, you might be able to figure out what the settings in this section are used for. Most Web servers have the capability to show you a file directory when a default document is not found. This has become a
common
alternative to an FTP server. If FancyIndexing is turned off and you access a folder that doesn't have a default document, the server will generate a display like that shown in Figure 29.5. If you turned FancyIndexing on, you would see a display similar
to
that in Figure 29.6. Another change you can make is to enable IconsAreLinks so that the icons that are shown in these server-generated listings (see Figure 29.7) are links to the files as well as the filenames.
You could also create custom icons to use in place of the default icons to represent the types of files you have in these directories. These icons are specified using an AddIcon directive, as in
AddIcon /icons/text.gif .html .htm .txt .ini
Note that you specify an icon to represent a specific file extension, and that you can have a single icon represent multiple file types. If you are going to make extensive use of this feature and plan on creating multiple icons for different file
types,
you should use the delivered icons as samples so that your icons are the same size. This makes for a uniform display.
A Web server is essentially a file pump. It simply sends a file to the client when requested. This file can be any type of file—the server doesn't care. The file is dutifully sent when requested. Without the existence of MIME types, a Web server
and client would have a hard time deciding the content of files. MIME types define the content of files so that the Web server and client can communicate consistently. Listing 29.4 is a partial listing of the mime.typ file that ships with FrontPage. If
you
need to add a content type to your web, you would add a line to this file.
Listing 29.4. Partial listing of the mime.typ file.
text/html html htm text/plain txt application/octet-stream bin exe application/oda oda application/pdf pdf application/postscript ai eps ps audio/basic au snd audio/x-aiff aif aiff aifc audio/wav wav image/gif gif image/ief ief image/jpeg jpeg jpg jpe image/tiff tiff tif application/zip zip # Microsoft types application/msword doc dot application/ms-access mdb application/ms-excel xls application/ms-powerpoint ppt application/ms-project mpp application/ms-publisher pub application/ms-schedule scd
This example shows several common file types that you will likely be familiar with. MIME types are listed as type/sub-type, with the most common types encountered being text, application, and audio. When the server is requested a specific URL,
it
parses the URL. If the request resolves to one of the typed files, the server sends a Content header to the client defining the data that will follow, then the content is sent to the client, which already knows what data to expect.
Remember that undefined MIME types should not be arbitrarily assigned. The MIME RFC1521 specifically requires that undefined types be preceded with an x- to signify the type. So if you have an application called myapp that creates MYF files that are
currently undefined, you would need to use a MIME type similar to application/x-myfile myf to specify that the content type is not currently accepted as a standard MIME type.
TIP
For more information on MIME types, check out the Hypertext version of RFC1521 at
http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html
The Personal Web Server can be configured to support by directory access control. It uses the same model as the NCSA server, and therefore uses password files formatted in the same manner as UNIX password files. If you have a UNIX server with an
existing list of users that you want to use, these files can be copied to the directory specified in the access.cnf file and used as is. Authentication can be applied using individual users and group passwords to further increase the ease of use of access
restrictions. The Explorer also uses this format when you add access restrictions to a web. The next section looks at the access.cnf file for the basic construction of access authentication.
The access.cnf file controls who can access all the files on the server. You can use the contents of this file to restrict access to individual directories on your server. You can restrict access based on host name or IP addresses so that only clients
from certain locations can access your content. The settings in this file should usually only be changed if you wish to institute server-wide access restrictions. If you want to restrict access to individual directories, you can use #htaccess.ctl files,
which you might have noticed in Listing 29.2. The content of these files is similar to the format used in the access.cnf file and allows a very fine granularity to the authentication that the Personal Web Server supports. Listing 29.5 shows the format of
the access.cnf file.
Listing 29.5. Partial listing of the access.cnf file.
# The following access configuration establishes unrestricted access # to the server's document tree. There is no default access config, so # _something_ must be present and correct for the server to operate. # This should be changed to whatever you set ServerRoot to. <Directory e:/frontpage\ webs/server> Options Indexes </Directory> ## This should be changed to whatever you set DocumentRoot to. #<Directory e:/frontpage\ webs/content/> ## This may also be "None", "All", or "Indexes" #Options Indexes ## This controls which options the #HACCESS.CTL files in directories can ## override. Can also be "None", or any combination of "Options", "FileInfo", ## "AuthConfig", and "Limit" #AllowOverride All ## Controls who can get stuff from this server. #<Limit GET> #order allow,deny #allow from all #</Limit> #</Directory> # You may place any other directories you wish to have access # information for after this one.
To understand the format of this file, you need to understand the original NCSA HTTPD server that it is based on. The structure is based on concepts originally developed for a UNIX environment. The file is a simple sequential list of access directives.
Because the file is sequentially read when the server starts, the order of the directives is important. If you only want to deny unrestricted access to a single folder on your server, it is best to add that directive at the end of the access.cnf file
rather than at the beginning. If you changed the <Directory...> section in Listing 29.5 to read as the following, you would lock out all accesses to your server:
<Directory e:/frontpage\ webs/server> <Limit GET> deny from all </Limit> </Directory>
If you are going to require access authentication on your server, you need to think it through before you implement it. There are generally three ways of thinking when it comes to access restrictions for a site. One is the wide open allow-all approach.
Any and all accesses are allowed. A second approach is what was just illustrated, with a significant change. The change would be to limit access to everybody except certain people. Instead of totally closing the site, you can open it to certain
host
names using a format such as
<Directory e:/frontpage\ webs/server> <Limit GET> order deny, allow deny from all allow from *.ingr.com </Limit> </Directory>
Remember that the file is read sequentially. The preceding code tells the server to deny everybody first, then allow those from any host name that has the string .ingr.com in it. This will result in everyone except those from ingr.com domain being
denied access to the server. If the directives in the order deny, allow line were reversed to read order allow, deny instead, the file would be processed in such a manner that the deny from all would be the last directive, and again, no access would be
allowed.
The third way that access restrictions are usually used is kind of a hybrid approach. You start with a wide-open server and add access restrictions on a single directory basis using #HACCESS.CTL files. If you are not careful, this scheme can become
very
hard to keep track of. You might intend to restrict access to a specific subfolder and place the #HACCESS.CTL file in the wrong location and therefore lock out a section of the server that you weren't intending to. The default #HACCESS.CTL file is shown
in
Listing 29.6.
Listing 29.6. Listing of the default #HACCESS.CTL file.
# -FrontPage- IndexIgnore #haccess.ctl */.??* *~ *# */HEADER* */README* */_vti* <Limit GET> order deny,allow deny from all allow from all </Limit> <Limit POST PUT> order deny,allow deny from all </Limit> AuthName default_realm AuthUserFile e:/frontpage\ webs/content/_vti_pvt/service.pwd AuthGroupFile e:/frontpage\ webs/content/_vti_pvt/service.grp
The #HACCESS.CTL file is a very powerful tool. As you can see from this listing, you can put any directives in this file to modify the standard settings of the server. Because configuration files are read sequentially, settings in this file will be
loaded when an attempt is made to get a file from the folder that this file resides in.
You can place a copy of this file in any folder to restrict access on a folder and subfolder level. I mentioned that you could also use this file to add or change MIME types on-the-fly in a given folder. If you want to serve self-extracting archive
files from a certain folder, you might need to change the MIME type from the usual application/octet-stream to something like application/x-sfx-archive so that the Internet Explorer would offer a dialog box to open or save a file of this unknown type. To
change a MIME type on-the-fly like this you would need to place an #HACCESS.CTL file in the folder where you wished to change the defaults with the single line:
AddType application/x-sfx-archive exe
Then any time a client clicks on a link in this folder with an .exe file extension, the server will send the file with a content type of application/x-sfx-archive.
In addition to the application of access restrictions by IP address and host name, you can also assign access based on password. FrontPage fully supports the access authentication methods of any of the servers that server extensions are available for.
Communication between the FrontPage Explorer and the server is fully encrypted to provide secure access. The FrontPage Explorer is used to add username/password combinations. Even though the Explorer is the tool used to add or edit passwords, the
passwords
themselves are stored in standard text files in the \frontpage webs\content\_vti_pvt\ folder. You can change the location of these files if needed, as long as you change the lines in the #HACCESS.CTL file to reflect their new location. In Listing 29.6,
the
lines in the file that determine the location of the password files are these last three lines:
AuthName default_realm AuthUserFile e:/frontpage\ webs/content/_vti_pvt/service.pwd AuthGroupFile e:/frontpage\ webs/content/_vti_pvt/service.grp
These three lines specify the location of the AuthUserFile, the AuthGroupFile, and the realm that is used to determine the scope of the access. When you add administrators, authors, or even end usernames and passwords, these are the files that the
information is written to. Notice the format of the service.pwd file:
# -FrontPage- admin:ocwbT22w1i.ew CoolDude:cr81ntYWRi7Bo
You'll notice that there are only two passwords defined in this file. The format of these files is logon_name:password and the password section is encrypted. You cannot create these password files manually. But, using the FrontPage Explorer, you can
add
username:password combinations as easily as you add administrator accounts and authoring access. Select Tools | Permissions to access the Web Permissions dialog box in FrontPage Explorer shown in Figure 29.8. This dialog box enables you to manage all the
authentication on your web. Note that there is a separate page for each area of FrontPage access management: Administrators, Authors, and End Users. The Administrators tab is used to add additional administrative users to a web, the Authors tab is used to
grant authoring access to a web, and the End Users tab is used to grant individual users access to areas of the server. Figure 29.8 shows the End Users tab with the user CoolDude added.
Figure 29.8. Select Tools | Permissions to access the Web Permissions dialog box.
When you restrict access based on authentication to a section of your web and a user attempts to access this section, an Authentication dialog box similar to Figure 29.10 will prompt for a valid name and password.
As you can see from this quick tour of FrontPage's Personal Web Server, it is a versatile server capable of supporting most needs of the average user. It is ideal for an intranet server and reasonable on an Internet site with moderate traffic. The
server isn't designed to handle the traffic of an active site like www.microsoft.com; that is a job better handled by Microsoft's Internet Information Server.
The server extensions are really the glue that makes FrontPage work so well; they also enable FrontPage to operate with most of the popular servers whether running under Windows or UNIX. The next section takes a closer look at this important piece of
the package.
As mentioned in Chapter 26, the FrontPage Server Extensions manage the communication between your Web server and the Editor and Explorer. Without the server extensions, FrontPage is nothing more than a well-designed HTML editor. The tasks that the
server extensions enable include administrative and authoring support, and WebBot processing—which FrontPage calls SmartHTMl. I present each of these in some detail before concluding the discussion of the Personal Web Server.
The server extensions' primary task is to manage access to the Web server in a secure manner for the FrontPage client. The actual mechanism is identical to a standard CGI process. When the client needs to access a file on the server, the request is
sent
via HTTP to the server using a POST process with the information formatted in standard name=value pairs. This data is passed by the Web server to the CGI program specific in the POST process, which acts upon the request and sends the appropriate
information back to the client via the Web server. The executable that handles administrative requests is the file named admin.exe, which is normally located in the \FrontPage Webs\Content\_vti_bin\_vti_adm folder. When you attempt to open a web in
FrontPage Explorer, the Web server is sent a URL similar to
http://www.myserver.com/_vti_bin/_vti_adm/admin.exe
using the POST method, with appropriate transaction information passed via STDIN. ADMIN.EXE processes the information and sends the results to the server to be sent back to the client—in this case the FrontPage Explorer. It is important to note
that all transactions between the extensions and the FrontPage client are encrypted as an added level of security.
Web authoring works in a similar manner with FrontPage. The executable that is used for authoring transactions is named author.exe and will normally be located in the \FrontPage Webs\Content\_vti_bin\_vti_aut folder. When a person initiates an
authoring
session, the Explorer sends a URL to the web server similar to:
http://www.myserver.com/_vti_bin/_vti_aut/author.exe
using the POST method, with appropriate information passed via STDIN. AUTHOR.EXE processes the information and checks whether this client has access to the information that is being requested. If the user hasn't already been authenticated, the client
will be required to enter an authorized username:password combination in the Authentication dialog box. Subsequent requests from the same authenticated author in this session will not require additional validation unless the author attempts to access a
portion of the web for which authoring permissions are different.
The final piece of the server extensions is performed by the shtml.exe executable, which is usually located in the \FrontPage Webs\Content\_vti_bin\ folder. This file is the SmartHTML executable, which handles all WebBot processing. When a file is sent
from the Explorer, the shtml.exe program checks the file for the existence of WebBots. If a file contains a WebBot, shtml.exe processes the WebBot in place, generates the resulting HTML file, and then creates the generated contents in the appropriate
location, but saves the original file in a _vti_shm folder located in the same folder as the generated file. Because the actual contents of the file that a client is able to retrieve has already been processed, there is no back-end process to produce the
information. So, if you used a TimeStamp Bot in one of your pages, the SmartHTML will be generated when the file is saved to the Web by the shtml.exe executable.
This concludes the tour of the FrontPage Personal Web Server. You will find it to be a robust and useful server for all but the most demanding installations. It is developed from the industry standard NCSA HTTPD server, with similar characteristics. It
is easy to manage the server, and most of all easy to publish your content when using the Personal Web Server. You've seen the main features of the server and you have all the information you need to use this server fully. You should have a good grasp of
the administration of the server as well as the operation under the hood. With this information behind you, you are ready to turn to the last portion of this tour of FrontPage: using the tools to create a web.
In the remainder of this section you will be taken on a hands-on tour as you actually use the product to build a web. To fully illustrate the use of the tools, you are going to be redesigning the Sams.net WWW home page on the Internet. Using the
FrontPage Editor and Explorer, I am going to show you how to exploit these tools to either create an original site from scratch or re-create a site like you are going to do. You will be able to browse the files directly from the CD using the File | Open
menu selection in Internet Explorer. If you have a Web site managed with FrontPage, you could even use the Import Web tool to copy the contents of the IEWEB directory from the CD that accompanies this book to your existing web and have the files available
as you read the book.
Before you begin to create a Web site, you need to spend a little time thinking about the purpose of the site, the type of information that will be presented, the general layout of the site, and of course the actual way the data would be best
presented.
Sometimes a storyboard is a good tool to use to arrive at a good working format. Animators use storyboards to tell the story on paper before they start drawing the first character. It is a good general suggestion that unless you already have a good idea
where to start, you start with a pen and paper and sketch out the details of the site you intend to create. Sometimes the information that you are going to be presenting is itself a good guide to the layout of the site and the formatting of the HTML pages
as well.
Microsoft calls this step the "Define and Design" step of the process. It is the most important step in designing the site, and is usually the most overlooked step. Your storyboard can be a simple sketch, or it can be composed using printouts
of images you expect to use. The idea is to lay out the site mentally before you create a single HTML file. Decide how the information you want to present can be best represented graphically. Use the storyboard to help you decide how different schemes can
help the visitors of your site navigate through the site. The storyboard can be an indispensable design tool.
If you are designing a corporate site like the Sams.net home page, you will be attempting to capture the nature of the corporation in a manner that is both appealing and informative. Identifying your target audience is a primary goal as well, because
the information you have to share will be designed to best reach those users. In the case of Sams.net, the site is currently designed to maximize access to the all the books that are available and to do so in an inviting manner. The interface is designed
to make it easy to navigate the site to the exact information that the user is interested in pursuing. Redesigning a site requires that you understand the original goals, and enhance rather than inhibit those goals. I'll briefly sketch the parameters of
the task in a fashion that illustrates the issues. Some of the questions that you need to ask as you approach a similar task are
These questions and others like them should get you started thinking about the intent of the Web site you are creating. It is the intent of the site that dictates the contents and the layout of information, as well as the best mechanism for presenting
the information.
NOTE
The redesign of the Sams.net site in this book is for the purpose of illustration only; the changes you see here will not be reflected online. A site like Sams.net could well be managed using FrontPage, but the depth of the site precludes a total redesign based on the whims of this author. You've probably noticed that a popular site can change dramatically over time. Some of this is evolution, some of it is just simple marketing—keeping it interesting to encourage visitors to return.
First, take a look at the Sams.net site so that you can begin to get a feel for how best to approach the redesign. To do this, you can either use the Internet Explorer or access it directly using the FrontPage Editor. Figure 29.11 shows the Sams.net
home page in Internet Explorer 3.0, and Figure 29.12 shows the same page in the FrontPage Editor. Seeing how both the pages appear will help you see decide how to best present the data.
Figure 29.11. Sams.net home page in Internet Explorer 3.0.
Figure 29.12. Sams.net home page in FrontPage Editor.
TIP
To browse a site from within the FrontPage Editor, use the File | Open menu selection to enable you to enter a URL to retrieve using the Open Location dialog box.
As you can see from these two figures, presentation of the Sams.net the site is tied by its background to space, denoting its link with cyberspace. This device is used to evoke all the associations that one may make with the idea of space, exploration,
and technology. Because Sams.net is primarily concerned with Internet technologies, the space age theme might have been the best choice for their pages. Apparently, the site designers have already answered the number one question about what is the purpose
of the site and decided to use the space metaphor to express that purpose. But for the purposes of this illustration, some of the design elements are a little too strong and don't allow us to illustrate the advanced techniques available in FrontPage, so
your purpose is a little different. What happens, for example, if you remove the background space image and look at different choices for that image? Figure 29.13 shows the home page with the background image removed.
Figure 29.13. Sams.net home page in FrontPage Editor with space background image removed.
The image associated with the page was created with a transparent background, but the main image used as an image map really requires a background or the images need to be changed, as you can see. One of the first things you will add to your
storyboard,
therefore, is that you need to break up the navigation buttons so that the background can be changed more easily without the obvious problems seen in Figure 29.13.
TIP
When you design a site, you should provide text links for all the selections so that users with slower speed connections can still get to all of the information on the site. These users often browse with graphics disabled to speed up transfers, so the fancy backgrounds and images won't be seen by these users.
The selections that are available on the home page need to be preserved as these pages represent the main organizational areas for the site. So you have another item to add to your storyboard—the layout of the site according to these areas. These
areas are
You might not need to preserve every one of these areas in the exact manner or with the same emphasis, so with these elements on your storyboard, you can prioritize how you want to present the information to emphasize the real message of Sams.net.
NOTE
For this example, the predominantly black background of the Sams.net home page are not preserved so that the illustrations in the book will be easier to read.
One thing that you might want to do to enhance your site is to change the navigation method for the system. Using a table layout with Internet Explorer 2.0 would help to make this change. Or you could design the page for Internet Explorer 3.0 and use
frames to make navigation even better. Additionally, you probably want to enhance the site with new Internet Explorer extensions that enable you to be more creative with the presentation of the information. Now that you have some ideas for your redesign,
you can get back to FrontPage editor and see how to use the tool to best achieve these goals.
As you've seen, the editing features of FrontPage provide all the tools required for publishing in the HTML environment. Two features of HTML that have been implemented especially well are support of tables and frames. These two important advancements
are particularly hard to implement in practice because of the relatively complicated nature of the tags used. Frames are harder to implement primarily because they require the use of separate files for each of the documents in each separate frame of the
source file. Because some of you readers might still be using Internet Explorer 2.0, I concentrate on the use of tables to enhance the Sams.net site for the remainder of this chapter.
NOTE
For a detailed discussion on the use of tables in HTML, look at Chapter 22, "HTML 3.0 and Internet Explorer Extensions." For details on frames see Chapter 23, "Tables, Frames and Style Sheets."
A typical word processing usage of tables is to display data, such as data from a spreadsheet, in a tabular format. The information is displayed in regularly spaced rows and columns with uniform borders and individual cell formatting. This is one use
of
tables for HTML, but it is probably not the primary use. Because HTML does not give you exact control of page layout, tables are more often than not being used for better control of the layout of an entire page. Tables are usually implemented to so that
images can reside on one side of a page while text flows well around the image or is spaced evenly in a central portion of the page. Tables provide a good formatting mechanism when visual layout is important. How can you use tables to enhance the Sams.net
home page?
To begin the transformation, use the FrontPage Explorer to create a new Normal Web. If you remember from the last chapter, this creates a web with a single blank page. You will use this page to begin your transformation. When you first open the new
page
in the FrontPage Editor, you will have a blank untitled page, so the first thing you need to do is set up the page properties using the Page Properties dialog box, which is accessible using the File | Page Properties menu selection as shown in Figure
29.14.
Figure 29.14. Setting the Page Properties for your new Sams.net home page in the FrontPage Editor.
You'll notice that I have added a Title to the page, and also chosen a white background color. All the other settings have been left as is for now. When you click OK to return to your editing session, you will need to begin your table. By using the
storyboard, I have decided that three selections need to be available from every page in the web: the Welcome or Home Page, the Books page, and the How to Read Us selection. These areas will probably the most used, so it makes sense to place these
selections at the bottom of every screen. You can do this by using a simple text menu, but you have graphics, so you will use graphic bullets for these selections. You need to make sure that these bullets are laid out uniformly across the bottom of the
page; you can use a simple one-row/three-column table to accomplish this arrangement. Figure 29.15 shows the addition of such a table to the otherwise blank page.
Figure 29.15. The addition of a simple one-by-three table begins the layout for the new page.
Notice that the table fills only a portion of the screen. You want the navigation buttons that will be in this table to stand out and to be centered in the page to help draw attention to the selections. The borders of the cells are set to a pixel size
of one so that they will be easy to see as you design the page. When you complete the page, you will revisit each table and disable the table borders so that only the layout that the tables give us will be apparent. When you add buttons to the table
cells,
you get a better idea what the page will look like (see Figure 29.16).
Figure 29.16. The addition of navigation buttons to the table improves the appearance of the page.
You want to use these same three selections on every page, so you need to save this file for later use by using the File | Save As. . . menu selection. Then you can easily use the Insert | File. . . menu selection later to insert this file's contents
into another file.
You need to create the table for the rest of your page now. Using the same Table/Create Table. . . dialog box as before, this time you will create the main table that will hold the bulk of the content for your page. Because you have placed the home
page, books, and contacts on separate buttons accessible from the bottom of the page, you are left with a decision as to what buttons should be available as navigation buttons. You are only left with four selections, but you might want to include the
all-important Books selection in that main navigation area as well. That leaves us with five navigation selections you need to use. With a title area at the top of the page, this means that you will have at least a two row by five column table. You also
want the top row to span both columns, as this will create a nicely centered effect for the title page. You already have the image for the Sams.net logo, so you are going to add that to your page and then add another table to your page for your three
navigation buttons. Figure 29.17 shows what the page looks like in the FrontPage Editor after these additions. Figure 29.18 shows the new page in the Internet Explorer 3.0.
Figure 29.18. Your page looks a little different in the Internet Explorer.
You immediately notice a difference when you load the file in Internet Explorer. Because you haven't placed anything in the cells of the right side of your table, Internet Explorer believes that they are empty cells and doesn't display them at all.
After you have some information in these cells, Internet Explorer will display them properly.
What you really want to do is have a single large section on the right side of your page, so that the navigational buttons are on the left side with appropriate text on the right side. This is easily accomplished in the FrontPage Editor by using the
Cell Properties dialog box shown in Figure 29.19. You want this cell to span all five rows so that you have a single large cell on the right side, so select the Number of Rows Spanned text box and enter 5. When you click on the OK button, FrontPage makes
the change, as you can see in Figure 29.20.
Figure 29.20. You now have achieved the general layout you want to use for your pages.
You'll probably notice that I've added a few more buttons and a text heading under the main title. You could change this heading to a marquee later, but for now it is quite sufficient for your purposes. All you have to do now is add some appropriate
text to the right side of your table, and you will have a working home page. Another thing you might want to do is change the Sams.net button on the home page to point to Macmillan's home page instead. There's no good reason to link to a page you're
already on. So after another visit to your image factory, you have a page that looks like Figure 29.21 in the Editor and even better in Internet Explorer, as seen in Figure 29.22.
Figure 29.21. With the addition of some introductory text, your table begins to take shape.
Figure 29.22. The finished home page for Sams.net with its new look.
With this file created, the rest of your web is fairly easy to create. You can save your new page as a template and then it will be accessible from the File | New Page menu selection to use as a template for each of the other pages in your web (see
Figure 29.23). Because you are creating secondary pages, these will all need the Sams.net button at the bottom instead of the Macmillan button, so you will need to change those images for each of your successive pages. I won't step through every change on
every one of the other pages you create, but I will show you a couple of the secondary pages so that you can see the layout carried through the site.
When you add the headings for each page, you begin to see a coherent look and feel, as shown in Figures 29.24 and 29.25.
Figure 29.25. Another page using the same template shows the consistent look.
These pages were created using the original file as a template and simply changing the images and link information for each of the images as needed. This preserves the look of the site and gives the visitor to the site standard navigation throughout.
When someone visits this site it will be immediately clear what information is available and how to navigate to the area of interest. Any number of pages could have been created using this same template, and the resulting site would maintain a coherent
look and feel.
You've completed your transformation of the Sams.net pages; at least the top level! Using the tools in FrontPage, you can easily create a set of pages like these with only a modicum of effort—certainly less effort than if you had to code these
tables by hand.
This concludes this section on Microsoft FrontPage. You've learned about the various pieces of FrontPage and the basic role each piece plays in this comprehensive Web publishing tool. If you decide you'd like to really dig in and learn more about
FrontPage, look for the book FrontPage Unleashed at the same bookstore where you purchased this book.
In the next section of the book you learn some of the methods you can use to add dynamic content to your Web using CGI, VBScript, and JavaScript. You learn how to use these languages to add more than just static data to your site and give a richer
experience to your visitors. They'll come back more often if your site is inviting and these tools will help you get them back!
