Make Your NT Workstation a HTTP Server
Introduction
The Internet has become such a hot item that there is software available for users of many different types of computers (DOS-based, Windows- based, Macintosh, etc.) can log on and "surf" the 'net. Since the Internet began primarily as a UNIX-based network, anyone looking to provide a service to other users on the 'net had to set up their own UNIX system. Windows NT already has one Internet "back-end" capability, namely the FTP (File Transfer Program) Service, and as NT's popularity increases, we're seeing other services from the UNIX world being developed for NT. One of these is HTTPS, the HyperText Transfer Program Server. HTTPS is a program that allows a NT system to become a server site on the World Wide Web (WWW), which is a group of Internet sites that makes their resources available through a series of hypertext documents.
What are HTTP and the World Wide Web?
The idea behind the
World Wide Web (WWW) is simple: provide a graphical interface to the
Internet that relies on "hypertext" documents to help the user
maneuver from one online resource to another. Hypertext is what is
used to implement Windows Help documents. Topics, sentences and
phrases of interest to the user are highlighted or are in a
secondary color in a hypertext document. If the user wants more
information, she points to the highlighted phrase and clicks with
her mouse. The user "jumps" to the relavent part of that document,
or possibly to another document. Graphics, even sound can be
included in these files, and accessed by clicking on the appropriate
part of the screen.
These hypertext documents are available from systems all over the
world. What enables a user in one location to get hypertext files
from another is HTTP, the HyperText Transfer Program. As with FTP,
you run a program on your system that links you with a "server"
system at another location. The local "browser" program makes a
request from the remote "server" program, and the server returns the
requested file(s), if the request is a valid one.
The World Wide Web is an international, online collection of
hypertext files. These files are accessed via a network of HTTPS
servers on the Internet. Let's say there is a group of Internet
users who want to put together a bunch of information about their
favorite science-fiction TV show. One person has a listing of the
show's episodes, another keeps biography files of the stars, a third
has a collection of graphics files from the show, and yet another
keeps up with all of the gossip about the show's future. If all of
these folks have access to WWW server sites, they can make hypertext
documents that include all of this information. If you want to read
some or all of this stuff, you connect with a WWW "browser" program
to a "home page," which is a hypertext document that includes
references to all of the documents available. That "home page"
document can contain references to other documents on multiple
servers on the Internet. When you "jump" from page to page, you're
not worried about moving from system to system -- the HTTP programs
take care of that for you.
Clients and Servers
The World Wide Web is a
client/server system. The user's browser software is the client.
Documents and files you want to retrieve are on servers. When you
want to retrieve information on a topic, you tell the client
software to connect to a server. The client attaches to the server,
requests and transfers the document, then theconnection is broken.
The document is read locally, as is the viewing of any graphics
files transferred.
There are several client "browser" programs for the WWW. The most
common (and most popular is Mosaic. Mosaic is available for
UNIX-based X-Window systems, Macintoshes, Windows and Windows NT. An
alternative to Mosaic for 16-bit Windows users is Cello, and
dos-based users can get Lynx and use it to browse the Web. There
have been some rudimentary HTTP servers available for Windows, but a
full-function HTTP server requires a UNIX system and HTTPD, the
"daemon" version for UNIX, or HTTPS running on a Windows NT system.
Installing HTTPS for Windows NT
The first step in installing HTTPS for NT is to figure out what documents you want to make available and develop them. It doesn't make much sense to set up a transfer server if you have nothing to transfer! After you have developed the overall plan for the server, here are the steps for getting the system operational:
Obtaining the Software
Obtaining software related to the Internet can sometimes be a Catch-22-- you need to be on the Internet to get ths software, but you can't get on the Internet until you have the software installed. With a more sophisticated application like a HTTP server, you should have a connection to the Internet already or you wouldn't be considering implenting a server. HTTPS is a product of the European Microsoft Windows Academic Centre (EMWAC), located at the University of Edinburgh in Edinburgh, Scotland, U.K. HTTPS is available from EMWAC as well as several other locations (see sidebar). HTTPS is distributed for both Intel and DEC Alpha systems, so be sure that you get the file that is right for your system. Remember, NT runs on other machine types besides Intel!
Installing on the Hard Drive
The HTTPS software will
usually come as a compressed ZIP file. You'll need PKUNZIP 2.4x or
higher to unpack the archive. Users familiar with downloading
software from the Internet or services like CompuServe should
already be familiar with PKZIP/PKUNZIP. Unpack the archive into your
\WINNT\SYSTEM32 directory (if you've upgraded your existing windows
3.x to NT, the dirctory will most likely be \WINDOWS\SYSTEM32.
At this point, it would be a good idea to take a time out and
print out the HTTPS manual. There are two files included in the
distribution archive: HTTPS.DOC, which is the manual in Microsoft
Word format, and HTTPS.PS, which is the file in PostScript format.
You'll definitely want the manual as a reference tool if you're
going to do some of the more sophisticated hypertext functions, such
as online maps, etc.
Installing HTTPS in the Services List
The final installation
step is to install HTTPS in to the services table. This also
registers the program with the Event Logger. To do this, open up a
Command Prompt window, switch to the directory where you unpacked
HTTPS (\WINNT\SYSTEM32 was the suggested location), and run HTTPS
from the command prompt. Type in the following:
https -version
to see which version of the program you're using. At this
writing, the current version of HTTPS is 0.7. Next, type:
https -ipaddress
to display the IP address of your machine. Then type:
https -remove
to remove any older versions of HTTPS that may be in your
services table. Finally, type:
https -install
which will install this version of HTTPS into the services table.
HTTPS is now installed. To confirm that the installation actually
worked, go to the Services icon in Control Panel, double-click, and
see if HTTP Server is in the list of services installed. (More on
using the Services applet later.)
Configuring the HTTP Server Applet
The HTTP Server Applet is a fairly straightforward dialog box. There are five functions whose configuration is controlled from the applet dialog.
Data Directory
The Data Directory is
the root directory that the user will see and reference when
accessing your system with a browser program such as Mosaic. URL
(Universal Resource Locater) references are relative to the
directory specified as your data directory. For example, if you
specify the data directory as C:\HTTPS\DATA, a user looking for the
following URL:
http://yourserver.yourdomain.com/yourstuf/yourfile.htm
Would find that file in the directory C:\HTTPS\DATA\YOURSTUF. The
machine and domain identifiers are set when you configure TCP/IP.
Regular Systems
Your data directory tree can be on any type of partition used by
NT (FAT, HPFS, NTFS). The data directory tree must be accessible by
the user ID normally used to run HTTPS. This is usually the SYSTEM
user. This means that the average 'net surfer can retrieve any file
in the data directory tree, so make sure that you don't put any
files you don't want leaving your system in that tree. If you do
need to limit access to some of the files in the data directory
tree, you'll have to change the permissions of those specific files
in File Manager to deny access to the SYSTEM user id.
File Servers
If you want to locate your data directory tree on a file server
rather than the local NT machine, you've got some special
considerations. On a local machine, the data directory tree is
designated by using a standard drive letter/directory name
combination. Most sites configure HTTPS to start up automatically
when NT is loaded. There are no drive mappings to file servers in
place until after a user logs in, which is after HTTPS is started.
This means that a reference to a server directory has to be made in
UNC form. For example, if your data directory tree is \HTTPS\DATA on
the file server WEBSERVER, you would have to assign a sharename for
that directory on the server for that directory. If you call that
sharename WEBSTUFF, the UNC you would enter in the HTTPS dialog box
would be:
\\WEBSERVER\WEBSTUFF
The Internet user still makes his requests the same way, since
the sharename specifies the root of the directory tree.
TCP/IP Port
HTTPS needs to know where to "listen" for incoming file requests. You must put in the value of a valid port into the TCP/IP Port box. The default here is 80, which is a valid port if the only TCP/IP services you're running are HTTPS and FTP. If you've installed other TCP/IP servers (such as a Gopher or WAIS service) on the same machine you'll be running HTTPS, you will have to find an open port to use here.
File Extension/MIME Type Mapping
HTTPS uses the MIME type/subtype format to classify the various files it uses. This classification scheme allows the user of a browser program like Mosaic call up different applications to view requested files. For example, if HTTPS sees a file with the extension GIF, it knows that this is an image file in CompuServe GIF format, and that information is passed back to the browser program so it can call up the user's GIF viewer program. You should normally leave these settings the as the defaults, and add new ones as they become part of the MIME type set. Should you need to change a setting, click on the setting you want to work withto highlight it and choose the Change Mapping button. This will bring up an edit dialog which will enable you to make your changes.
Transaction Logging
The HTTPS transaction log allows you to track requests to your server. This is useful to determine which documents on your server are popular, etc. When this check box is enabled, HTTPS writes a file named HTTPS.LOG to your \WINNT (or \WINDOWS) directory. The file contains the IP address of the client, the command it issued, and the URL requested. An operator of a commercial WWW server could use the log file to show a track record to potential customers to get them to buy space on the server.
Directory Browsing
When the "Permit
Directory Browsing" check box is enabled, clients using your server
will be allowed to request a URL that is just a directory, such as:
http://yourserver.yourdomain.com/yourstuf
where yourstuf is a directory. The user will then get a list of
files and subdirectories under the yourstuf directory from which to
choose. If you just have one file in that directory, you can copy
that file to the name DEFAULT.HTM, and that file will be sent out in
response to the request. When Directory Browsing is disabled, an
error message is returned to the client informing that the feature
is not enabled.
Operation
After you've configured the HTTPS Applet, click the OK button in that applet. It's then time to start the HTTPS server for operation. Checking TCP/IP Installation (see sidebar also) Before starting HTTPS, it's a good idea to double-check the TCP/IP installation on the machine. The best way to do this is to use a TCP/IP client application such as TELNET or PING to connect with another system. Try a machine in your LAN, then a system out on the net. If you can connect to outside systems, then have someone on another machine PING your system. If you have the FTP service installed, have someone else transfer a file from your machine to theirs. If both of these are successful, you can proceed with the HTTPS startup knowing that your machine is connecting to the outside world.
Starting the HTTP Service from the Services Applet
Now that everything is
configured and you're satisfied that your machine is communicating
with the rest of the network, it's time to start up the HTTP
Service. Double-click the Services icon in the Control Panel to
bring up the list of available services. Scroll to the line for
HTTPS, highlight it, and click the Start button.
The Pause button is used to temporarily stop a service. If you
pause operation of HTTPS, the following will happen:
Setting the Auto-start Function
If you're going to be
operating a full-time HTTPS server on the Internet, you'll want to
set up HTTPS so that it starts up automatically every time you load
Windows NT. This will ensure that the system will come back up
properly in the event of a power failure, system reset, or someone
kicking the plug out of the wall.
To set the auto-start active, choose HTTPS from the list of
services and click the Startup button. This changes the status from
Start to Startup.
Connecting to HTTPS with Mosaic
The final operating test
of your HTTP server is to go to a system connected to the 'net, run
Mosaic, and request a URL from your server. If you receive the URL
from the server, you're in business. If you run into a problem,
check the obvious things such as spelling and syntax errors under
Mosaic. If you're satisfied that you're typing things in correctly,
double-check the address you're using for the server and make sure
that your NT machine's TCP/IP is configured with the same address.
Try the numeric IP address instead of the name of the system. If you
continue to be unable to connect to the HTTP server, try to connect
to another system on the net.
When all of these things continue to fail, it's time to go back
into the installation and setup of the server and re-trace your
steps. Stop the service, double-check all of the configuration
options, then re-start the service. The key issue here is to
determine whether or not the problem is related to TCP/IP or the
server setup.
Once everything is going OK and you can request simple HTML
documents from the server, you can then add Web documents with a bit
more sophistication to your system. HTTPS implements the HTTP 1.0
protocol, as well as to conforming to the Common Gateway Interface
(CGI) 1.1 standard. Hypertext documents which contain CGI scripts
are essentially WWW "programs." For example, you can develop and
implement hypertext documents which contain forms that enable the
client user to send you back information on whatever topic you
choose. HTTPS also supports "clickable images," where a document can
contain a bitmap file that is displayed on the client system, and
different options are executed depending where on the image the user
clicks. As the system manager, you don't have any work to do to
implement these features. The server supports them, so it's a matter
of writing the HTML documents that contain the codes to make use of
them.
The Bottom Line...
A HTTPS system will essentially run itself once installed. The only ongoing maintenance item is to clear the transaction log on a regular basis so it doesn't reach an unmanageable size. Other than that, it's up to those folks who will be placing HTML documents on the server to design and write those documents. HTTPS is still distributed as a beta- test product, so there is always the possibility of undocumented errors popping up from time to time. Upgrades will also be forthcoming, as EMWAC continues to refine the program. HTTPS is a great way for those of us familiar with Windows to get onto the Web without having to go through the hassle of gathering and compiling all of the necessary C source code to perform these functions on a UNIX system.
Availability of HTTPS
The primary means of distributing HTTPS is via the Internet. The program is usually distributed as a ZIP archive, keeping it to a minimal size for transmission. One of the problems with programs that are distributed via the 'net is that those making the program available tend to forget about potential users who may not have a full Internet connection available to them at the moment. Here are several possible locations from where you can obtain HTTPS.
On the Internet
HTTPS is available on
the Internet at ftp.ncsa.uiuc.edu. Mosaic users can get to this site
by connecting to ftp://emwac.ed.ac.uk/. The
directory is pub/https. Make sure you download the correct file
(Alpha or I386) for your system.
HTTPS is also available via e-mail through the Minas Tirith mail
server. Send a message to:
With the following in the body: GET https.zip
This is the I386 file. The Alpha version is not available from
Minas Tirith.
VIA CompuServe
The file HTTPS.ZIP (I386 version) is available in LIB 10 of the Internet Forum on Compuserve.
TCP/IP Installation
Since TCP/IP has to be
up and running before HTTPS can function, it's important that you
have a clear picture of how TCP/IP works under NT. The Transmission
Control Protocol/Internet Protocol suite was developed by the
Department of Defense as a means to network government computers
with those of contractors and researchers. Like many creations of
government agencies, TCP/IP has become the de facto networking
standard for most UNIX systems, and is the backbone protocol of the
Internet.
While many users may still think of Windows NT as merely an
expanded version of Windows, the addition of TCP/IP gives NT the
ability to connect to the outside world in a variety of ways. If
you've already set up your NT workstation to link to other NT or
Windows for Workgroups systems, adding TCP/IP is a relatively
painless procedure.
Checking the Hardware
The first step in TCP/IP installation is to make sure that your hardware is ready to make the connection. You'll need to make sure that your NT system can link with your existing TCP/IP network. Usually this means making sure you have an ethernet adapter and the cable from the network running to your system. The TCP/IP protocol for Windows NT does not support SLIP (Serial Line Internet Protocol) at this time; The "Daytona" release is expected to have this. This means that you cannot access the Internet directly via a modem with NT. For an application such as an FTP or HTTP server, this is not usually a problem, since these server really need more bandwidth than what a 14.4kbps modem can provide anyway.
Local TCP/IP or Internet?
The second step is to
decide who is going to be able to access your HTTP server. If your
server is to be public-access, you'll need to get a connection to
the Internet through a commercial provider. This normally involves
the addition of communications equipment such as a router,
multiplexor, etc. Your NT system will hook to the router via
ethernet.
If you plan to use HTTPS for distribution of in-house
information, all you need to do is link to your internal TCP/IP
network. Depending on the size and architecture of your site's LAN,
traffic to and from your server may be routed through one or more
gateways or routers, but the technical aspects of this flow is not
terribly important to you. If you know the necessary IP addresses to
input into NT's configuration dialogs, you're in good shape.
Configuring a Network Adapter for TCP/IP
Your existing network adapter can usually be configured to add TCP/IP capability. Say you have a NE2000 ethernet card installed in your system to use the NetBIOS and NetBEUI protocol, the normal settings for a standard NT/Windows for Workgroups network. Adding TCP/IP involves loading the Networks applet in the Control Panel. When you do this, a dialog will pop up listing all of the network software and adapters currently installed. Choose the Add Software button here, and then choose TCP/IP Protocol from the list of possiblities. The setup program will then pull the necessary files from your NT distribution CD-ROM. You'll then be asked to input your IP address, gateway address, etc., to properly link your system to the Internet (more on addresses in a minute). You'll then have to shutdown the system and re-start so that TCP/IP can be loaded and bound to the network adapter properly.
Network Addresses
Every system on the
Internet has a unique address as well as name. The address usually
has four parts, in the form 255.255.255.255. If your site or company
is already linked to the Internet, check with your network
administrator and have him assign your system an IP address in your
company's domain. If you're just getting started, your Internet
provider will work with you on getting an address and registering
it.
If your system will be using TCP/IP in a LAN environment (not
hooked to the Internet), you can make up your own IP addresses, so
long as you are consistent across all of your platforms. The only
catch to making up your own addresses is that you'll have to go to
each system on your LAN and change these addresses to legal Internet
ones if you ever decide to link to the 'net.
The quickest test of your TCP/IP configuration is to use Telnet to try to log into another system. If you have a local UNIX host on your LAN, to login via Telnet. Since Telnet is a TCP/IP client, if it connects with the host, you're working OK with TCP/IP. You can test your Internet capability by loading Mosaic and trying to connect to a Web server URL. If you connect, TCP/IP is installed just fine!
. Edward J. Branley is an independent consultant, freelance writer, and Microsoft Certified Professional in New Orleans, LA. He is also SysOp of Minas Tirith BBS, which is the home of the New Orleans Internet Mailing List, as well as the WebMaster of Virtually New Orleans , the premiere city guide to New Orleans on the Web. He can be reached at Yatcom Communications, +1.504.455.5087, via e-mail at elendil@yatcom.com, or on CompuServe at 71237,2227.