Make Your NT Workstation a HTTP Server
by Edward J. Branley
(c) 1995. all rights reserved
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:
- HTTP transactions in progress will be allowed to complete.
- The first five HTTP connections will be queued up until you hit the Resume button. When you resume, those requests will be processed.
- Connections received after the first five will be rejected until HTTPS is resumed.
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:
mail-server@mintir.new-orleans.la.us
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.
Testing and Operation
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!
About the Author..
. 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.
