One of the best things about the World Wide Web is that you can use it to interact with potentially millions of users to obtain and provide different information. Due to the dynamic nature of this information, static HTML pages alone are not enough. There has to be a way to display dynamic information to those surfing your Web site based on what they need. CGI is a mechanism that enables you to do just that. CGI stands for Common Gateway Interface. After you have your Web site all set up and have created some Web pages, it's time to think about making your Web site dynamic by setting up CGI scripts on your Web server. By utilizing CGI, you can exploit the World Wide Web to its fullest potential because it allows you to interact with browsers of your Web site.
Feedback forms, e-mail forms, database query interfaces, database update mechanisms, Web page counters, and search engines are all applications of CGI. Thanks to the user-friendly development environment of Windows NT, by the end of this chapter you will be able to develop CGI scripts, experiment with them, and harness the power of interactive Web interfaces. This chapter first provides you with an introduction to CGI and explains how CGI works. Then you are shown practical applications of CGI and how CGI scripts can be utilized to enhance your Web site. Next, you are shown how to develop CGI programs. C and Perl are used to illustrate how CGI programs can be created to perform various tasks. At the end of this chapter, you will be able to utilize CGI to interact with your Web site browsers. The next chapter, "Advanced Windows NT CGI Applications," covers advanced CGI programming and builds on material covered in this chapter. Among other things, it demonstrates how databases on your Web server can be queried and updated by using a Web front end.
Before going any further, an introduction to CGI is in order. CGI is a standard for various programs at your Web site that you can use to interact with users surfing your site. Because CGI is a standard, it is not browser- or server-dependent and can be moved from one Web server to another while still retaining its full functionality.
Just like application programs, CGI programs can be written in almost any programming language that will let you either create an executable program or let you interpret it in real time with another program (as in the case of AWK and Perl). The following lists a few languages that you can utilize to create CGI applications under Windows NT:
Depending on your expertise, what's available, and the nature of your CGI projects, you will have to choose the best language to suit your needs. Customarily, CGI scripts are stored in the CGI-BIN directory of the Web server's document root directory. All files and pathnames of a Web site are relative to this directory.
Plain text HTML files retrieved by Web clients are static. The information contained in these files never changes unless you manually edit them to make changes. However, by utilizing CGI scripts, your Web pages can be created dynamically each time a client accesses them. To the client, it will look as if the page has been specially created for him or her based on the information needed. Obviously, this is a very powerful tool for interacting with Web surfers. You should utilize CGI to make your Web site interactive so that you can provide customized content and enable those browsing your Web site to interact with the information you provide.
Benefits of CGI are invaluable to any Web site. These benefits range from having a customized input form for feedback to allowing someone browsing your Web site to update and retrieve information from a database on your server. By setting up a customized e-mail feedback form, you can make sure you are provided with all the information you need. Furthermore, you can be sure that your e-mail feedback form will always work because it does not depend on how the e-mail capability of your client's Web browser is set up (in case it is not set up correctly for e-mail). In the "Setting Up a Feedback Form" section, you will be shown how to utilize CGI to set up an e-mail feedback page. Furthermore, if you want to set up a database that collects data from users browsing your Web site, you can use a CGI script to update information provided by these users to a database. With the aid of CGI, it is possible to update a database on your server without your direct human intervention. As you can see, the possibilities and applications of CGI are endless.
One of CGI's best features is its capability to let Web surfers interact with databases on your server. For example, you might have a Microsoft Access database on your server that needs to be updated with information provided by users surfing your Web site. You might also need to make parts of this database available to authenticated users for querying. Although you can use plain old e-mail to correspond with people, and manually perform database queries and updates, this is not very practical after you start getting more and more visitors. Eventually, you will end up spending the whole day answering and responding to e-mail. (Maybe you do this already, but just imagine how much worse it will be!) By setting up a simple form, you can perform updates to your database by utilizing a CGI script. Keep on reading, and soon you will find out how easy it is to use CGI to interact with people browsing your Web site.
Dynamic content that is output by CGI programs can be made portable
across other Web servers. For example, if in the output of a CGI
script, a hypertext link has to be created to the main homepage
of a Web server, you can use the CGI environment variable SERVER_NAME.
By using this CGI variable as opposed to hard coding the homepage
in the CGI program, the CGI script will be portable across various
Web servers.
Tip |
Whenever possible, you should make use of such CGI variables to make moving scripts from one Web server to another as effortless as possible. |
By utilizing CGI to make your Web site interactive, users visiting your Web site will be able to easily find the information they need. Because your Web site is easy to navigate, these users will visit it again and again for more information. CGI also enables you to customize what people see when browsing your Web site by providing dynamic content. Furthermore, you can use a CGI script to provide content that's customized for the Web browser being used to access the information.
Many organizations and individuals are using CGI for a variety of tasks, from having a simple counter on a Web page to counting the number of accesses to a CGI script managing an entire store front-end. This CGI script can allow users visiting a Web site to look at various merchandise being sold and even place orders. In addition to this, various Web sites offer search capabilities of the site to make finding information easier.
You can use CGI whenever you want to interact with those browsing your Web site, to get feedback from those browsing your Web site, or to provide dynamic content. The following lists a few applications of CGI that you can use to enhance the capabilities of your Web site:
This chapter and the following chapter demonstrate how to add most of these capabilities to your Web site. Before moving on to more advanced topics, it's time to cover the basics of CGI.
A CGI script is typically used to provide dynamic content to the client that called the CGI script. CGI scripts communicate with Web browsers, as shown in Figure 16.1. If the CGI script is an interactive script, typically a form with various input controls is sent to the Web client. After filling in the form, the user submits it to the Web server. The Web server then uses CGI to call the CGI script with data from the Web client. The CGI script processes the data, possibly accessing a database on the server, and sends a message to the client that made the request. If the CGI script is a noninteractive CGI script, the output of the script is sent directly to the client that called the CGI script with its URL.
Figure 16.1: Architecture of a typical Web server with CGI scripts.
When a CGI script is called, the Web server first examines the REQUEST_METHOD used to call the CGI script to determine how the Web client is sending data to the CGI script. This process is shown in Figure 16.2. If the REQUEST_METHOD used to call the CGI script is GET, any data supplied by the Web client for the CGI script is found immediately following the URL name of the CGI script. Therefore, this information will be stored in the environment variable QUERY_STRING. On the other hand, if the REQUEST_METHOD used was POST or PUT, the size of input for the CGI script is stored in CONTENT_LENGTH. CONTENT_LENGTH contains the size of data supplied to the CGI script in bytes. The CGI script can then read from standard input the number of bytes returned by CONTENT_LENGTH to find out data given to the CGI script. If you are confused about all these strange environmental variables, don't worry-they are all discussed in the "CGI Environment Variables" section.
Figure 16.2: How Web servers determine and handle the REQUEST_METHOD,which calls the CGI scripts.
Although a major use of CGI is to provide dynamic content to those
browsing your Web site, CGI programs do not always need to be
interactive. You can use noninteractive CGI scripts to provide
dynamic information that does not need user input to be created.
For example, in order to take advantage of various features offered
by Web browsers such as Netscape Navigator and Microsoft Internet
Explorer, it is relatively simple to write a CGI program to determine
the browser being used by a client and send a page specially designed
to take advantage of that browser's capabilities. In the "Using
CGI to Provide Customized Content" section, you will see
how easy it is to write a CGI script to provide customized content
based on the browser being used to access a page. In such an event,
the CGI script will not need to interact with the person browsing
the Web site. The CGI script can be executed transparently to
the user without any user intervention. For example, if the default
Web page of a Web server is welcome.html,
the main Web page of the Web server can be mapped to a CGI script
by creating a URL-CGI mapping, as shown in Figure 16.3. Such a
script can determine the browser being used by the client and
display a page with dynamic content optimized for the browser
being used by the client. Please refer to your Web server's documentation
for more information on creating
URL-CGI mappings.
Figure 16.3: You can map a Web page URL to a CGI script to provide dynamic content.
If a CGI script-such as the one described previously-does not make use of user input, what happens when a client accesses the page is very simple. First, the client connects to the Web server and requests a Web page. Because the document requested is linked to a CGI script, the Web server executes the CGI program that the page is linked to. Output of the CGI program is then sent to the client that requested the page. Afterward, the connection between the Web server and the Web client is closed. This interaction is shown in Figure 16.4.
Figure 16.4: You can use a nouninteractive CGI script to provide dynamic content.
One of the greatest aspects of CGI is its capability to interact with those browsing your Web site. You can ask a user to fill in a form and then submit the form. The CGI script can then validate the user's input, ask the user to complete any incomplete information, and process the user's input, as shown in Figure 16.5.
Figure 16.5: You can use an intertactive CGI script to provide dynamic content.
In the case of a CGI script interacting with a Web client to display dynamic content, first a Web page with various controls is sent to the Web browser. After the user fills in the form, the form is submitted to the Web server to be processed. Depending on the REQUEST_METHOD used to communicate with the CGI script, the CGI script obtains data sent from the client, processes the data, and displays its output to standard output. Everything written to standard output by the CGI script will be visible to the client that called the CGI script.
When setting up CGI scripts, there are a few things you should be concerned with. Each time you allow a CGI script to be executed by someone surfing your Web site, you are allowing someone to execute a program on your server. This can potentially lead to security breaches. Although this might sound a little perilous, it's not as bad as it sounds, provided that you follow a few guidelines. As long as it is utilized properly, CGI is very safe.
Another issue is the time it takes for a CGI script to fulfill
a client's request. If you will be providing the data to those
browsing your Web site in real time, you should ensure that, at
most, no one has to wait longer than about five to ten seconds.
If it's going to take longer to process a request, you should
obtain the e-mail address of the person requesting the information
and simply e-mail the information when the data is processed.
If it takes longer than about ten seconds to process a request,
a person waiting at the other end might think there is something
wrong and simply stop waiting.
Performance |
If you need to provide data in real time and CGI scripts take longer than about ten seconds to execute, it's a very good indication that you are outgrowing your server and need more processing power and/or RAM. This might also be an indication of a bottleneck, such as an inefficient database access driver or a poorly written CGI script. |
Due to the nature of HTTP, it's possible that two or more clients will call the same CGI script at the same time. If the CGI script locks various files or databases when it is processing data, this can cause problems, potentially causing loss of data. CGI scripts should be capable of handling such a situation without any problem. This can be done by making sure the CGI application does not lock databases or files that might potentially be accessed by another instance of the same application.
Although CGI is a very powerful tool for making information available to those browsing your Web site, you need to be aware of certain things. The first thing you should be concerned about is security. You should be particularly careful about CGI scripts that take input from a Web client and use that data (without checking) as a command line argument. An example of this would be using an e-mail address supplied by a Web client to call Blat, a command line e-mail program. When using such an e-mail address, make sure there is no possibility of it being interpreted as a command-line command. Your CGI scripts should always check for special control characters to avoid potential security breaches. If you have various sections of your Web site protected with a password, you might want to disable directory browsing of your Web server. By disabling directory browsing, you're preventing someone from "snooping around" your Web site by browsing various directories and their contents, unless that person knows the URL of a certain page or is transferred to a page from one of your own pages.
You should be cautious about who has access to your Web server's CGI directory. It's very dangerous to allow users who upload files to your Web site via FTP to have access to your CGI directory. It doesn't take much knowledge in programming to write a potentially malicious program, upload it to the CGI directory, and execute it with a Web browser. Therefore, you should control who has access to your CGI directory via FTP or any other method.
You should never set up CGI applications to distribute potentially harmful personal information unless the Web server is configured to encrypt the data before it is transmitted over the Internet. If you will be distributing financial information or credit card numbers, you should not use CGI unless you have configured your Web server to encrypt data before it is transmitted over the Internet. If you need to transmit sensitive data and your Web server does not encrypt data before transmitting, you should consider a medium such as PGP (Pretty Good Privacy) protected e-mail to transmit such data.
If you validate users who access parts of your Web site, you should never use the IP address returned by the Web server as the real IP address of the Web client. It's possible to trick the Web server into believing the client making the HTTP request is requesting the data from a site other than the site the Web client is connecting from. Even if you protect a certain area of your Web server with a password and a user ID, this data might be intercepted by a third party. Someone might be able to intercept a valid user ID and password when a legitimate user uses it to access your Web site. If the Web server being used supports data encryption, this won't be a problem; however, it will be a problem if you are not using any Web server-based encryption. In such a case, you should use an OTP (One Time Password) mechanism to validate users. An OTP authorizing mechanism works by making sure a password used once cannot be used again. Such a mechanism typically sends a "challenge string" to the client who wants to gain access. The client then uses a special program to find out the correct "response string" for the "challenge string" supplied by the server. This is done by typing the user's secret password and the challenge string and obtaining a response string generated by this special program. The response string is then sent to the server. The server validates the user and remembers the response string so that it can't be used again. The next time the user wants to gain access, the server will send a different challenge string to the client that can be decoded only with the user's secret password. Because the user's secret password never travels across the Internet, this is a safe way of authorizing users. However, unless an encryption technology is used, the content being accessed by a client might still be intercepted by a clever person with too much free time. For more information on such an OTP mechanism, you might want to visit
http://www.yahoo.com/Computers_and_Internet/Security_and_Encryption/S_KEY/
Each time the Web server executes a CGI script, it creates a number of environment variables to pass information to the CGI script. These variables inform the CGI script how the script is being invoked as well as provide information about the server and the Web browser being used by the client. Depending on how the CGI script is invoked, some environment variables may not be available in some cases.
Environment variables supplied to CGI scripts are always all uppercase. When they are being accessed by a C Program or Perl script, or whichever language you are using, be sure to use all uppercase letters.
This section discusses the environment variables available to CGI scripts. By accessing these variables, CGI scripts can obtain certain information, such as the browser used to invoke the script. After the following discussion about environment variables, you learn how to access these variables from a Perl script, as well as a C program via CGI.
Some Web servers can be configured to authenticate users. If the server has authenticated a user, the authentication type used to validate the user is stored in the AUTH_TYPE variable. The authentication type is determined by examining the Authorization Header the Web server might receive with an HTTP request.
Sometimes CGI scripts are invoked with additional information. This information is typically input for the CGI program. The length of this additional information is specified by the number of bytes taken up by the additional information in this variable. If a CGI script is called with the PUT or POST method, CONTENT_LENGTH is used to determine the length of the input.
MIME content types are used to label various types of objects (HTML files, Microsoft Word files, GIF files, etc.). The MIME content-type for data being submitted to a CGI script is stored in CONTENT_TYPE. For example, if data is submitted to a CGI script using the GET method, this variable will contain the value application/x-www-form-urlencoded. This is because responses to the form are encoded according to URL specifications.
The CGI specification revision number is stored in the GATEWAY_INTERFACE environment variable. The format of this variable is CGI/revision. By examining this variable, a CGI script can determine the version of CGI that the Web server is using.
Various Web clients can handle different MIME types. These MIME types are described in the HTTP_ACCEPT variable. MIME types accepted by the Web client calling the CGI script will be a list separated by commas. This list takes the format type/subtype, type/subtype. For example, if the Web client supports the two image formats GIF and JPEG, the HTTP_ACCEPT list will contain the two items image/gif, image/jpeg.
By looking at this value, the Web browser used by the client can be determined. For example, if Netscape 2.0 beta 4 is being used by the client, the HTTP_USER_AGENT variable will contain the value Mozilla/2.0b4 (WinNT; I). The general format of this variable is software/version library/version.
The PATH_INFO variable is usually used to pass various options to a CGI program. These options follow the script's URL. Clients may access CGI scripts with additional information after the URL of the CGI script. PATH_INFO will always contain the string that was used to call the CGI script after the name of the CGI script. For example, PATH_INFO will have the value These/Are/The/Arguments if the CGI script FunWithNT.EXE is called with the following URL:
http://your_server.your_domain/cgi-bin/FunWithNT.EXE/These/Are/The/Arguments
In the event the CGI script needs to know the absolute path name of itself, the CGI script can obtain this information from PATH_TRANSLATED. For example, if the CGI script being invoked is HelloNTWorld.EXE, all CGI scripts are stored in H:\www\http\ns-home\root\cgi-bin, and the CGI script is accessed with the URL http://your_server.your_domain/root/cgi-bin/HelloNTWorld.EXE, PATH_TRANSLATED will contain the value H:\www\http\ns-home\root\cgi-bin\HelloNTWorld.EXE. If the CGI program needs to save or access any temporary files in its home directory, it can use PATH_TRANSLATED to determine its absolute location by examining this CGI variable.
You may have noticed that when you submit some forms, there is a string of characters after a question mark, followed by the URL name of the script being called. This string of characters is referred to as the query string and contains everything after the question mark. When a CGI script is called with the GET method, QUERY_STRING typically contains variables and their values as entered by the person who filled in the form. QUERY_STRING is sometimes used by various search engines to examine the input when a form is submitted for a keyword search. For example, if a CGI application is executed using the URL, http://www.server.com/cgi-bin/application.exe?WindowsNT=Fun, QUERY_STRING will contain the string "WindowsNT=Fun."
The IP address of the client that called the CGI program is stored in the REMOTE_ADDR environment variable. Due to security reasons, the value of this variable should never be used for user authentication purposes. It's not very hard to trick your Web server into believing a client is connecting to your Web server from a different IP address.
If the Web server can do a DNS lookup of the client's IP address and finds the alias of the IP address, the REMOTE_HOST variable will contain the alias name of the client's IP address. Some Web servers allow DNS lookups to be turned on or off. If you will be using this variable to find the IP address alias of clients, be sure the DNS lookup option is turned on. The Web server can find the IP address aliases of most clients, but it might not be capable of getting the aliases of some clients. In such an event, the REMOTE_HOST variable will not be assigned the client's DNS alias value; it will just contain the client's IP address. This value should never be used for user authentication purposes.
If the Web server being used supports RFC 931 identification, this variable will contain the user name retrieved from the server. Unfortunately, this value cannot be trusted when transmitting sensitive data. Typically, a Web server obtains this value by contacting the client that initiated the HTTP request and speaking with the client's authentication server. Visit http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view?number=931 for additional information about RFC 931 and the Authentication Server Protocol.
Some Web servers support user authentication. If a user is authenticated, the CGI script can find out the username of the person browsing the Web site by looking at the value of the REMOTE_USER environment variable. The REMOTE_USER CGI variable is available only if the user has been authenticated using an authentication mechanism.
A client can call a CGI script in a number of ways. The method used by the client to call the CGI script is in the REQUEST_METHOD variable. This variable can have a value like HEAD, POST, GET, or PUT. CGI scripts use the value of this variable to find where to obtain data passed to the CGI script.
All files on a Web server are usually referenced relative to its document root directory. SCRIPT_NAME contains the virtual path name of the script called relative to the document root directory. For example, if the document root directory is c:\www\http\ns-home\root, all CGI scripts are stored in c:\www\http\ns-home\root\cgi-bin\ and the CGI script HelloNTWorld.EXE is called, the SCRIPT_NAME variable will contain the value \cgi-bin\HelloWorld.EXE. The advantage of this variable is that it allows the CGI script to refer to itself. This is handy if somewhere in the output, the script's URL needs to be made into a hypertext link.
The domain name of the Web server that invoked the CGI script is stored in this variable. This domain name can either be an IP address or DNS alias.
Typically, Web servers listen to HTTP requests on port 80. However, a Web server can listen to any port that's not in use by another application. A CGI program can find out the port the Web server is serving HTTP requests by looking at the value of the SERVER_PORT environment variable. When displaying self-referencing hypertext links at runtime by examining the contents of SERVER_NAME, be sure to append the port number of the Web server (typically port 80) by concatenating it with the value of SERVER_PORT.
Web servers speak the HyperText Transport Protocol (HTTP). The version of HTTP the Web server is using can be determined by examining the SERVER_PROTOCOL environment variable. The SERVER_PROTOCOL variable contains the name and revision data of the protocol being used. This information is in the format protocol/revision. For example, if the server speaks HTTP 1.0, this variable will have the value HTTP/1.0.
The name of the Web server that invoked the CGI script is stored in the SERVER_SOFTWARE environment variable. This environment variable is in the format name/version. If a CGI script is designed to make use of various special capabilities of a Web server, the CGI script can determine the Web server being used by examining this variable before those special capabilities are used.
This section introduces you to Perl and how you can set up CGI Perl scripts on Windows NT Web servers. The Internet contains many CGI Perl scripts written by various people. By utilizing these scripts and customizing them to suit your needs, you can easily improve a Web site. A comprehensive tutorial of Perl is beyond the scope of this book, so this chapter discusses only the basics of writing CGI Perl scripts.
Perl stands for Practical Extraction and Report Language. With the growth of the World Wide Web, Perl is being used increasingly to write CGI programs. Most of the best features of C, sed, awk, and sh are incorporated in Perl. This allows Perl scripts to be developed in the least amount of time possible by avoiding reinventing the wheel for fundamental tasks such as string manipulation. The expression syntax of Perl corresponds quite closely to the expression syntax of C programs. This makes Perl an easy language to learn for those who are already familiar with C. One of the best things about Perl is its portability. Perl is an interpreted language that is available for a number of hardware platforms including PCs, Macs, and various flavors of UNIX. Unlike most languages, and utilities, Perl does not impose limits on the size of data. As long as you have enough system resources, Perl will happily read the contents of an entire file into a string. Thanks to various optimizing algorithms built into Perl, scripts written in Perl are robust and fast.
Before proceeding any further, you need to obtain Perl for Windows
NT and install Perl on your Web server. Perl for Windows NT is
provided free of charge on the Internet. You can obtain it from
http://info.hip.com/ntperl/.
After obtaining Perl for NT, create a directory for Perl and copy
the Perl distribution file to this directory. Then uncompress
the distribution file. When uncompressing the distribution file,
be sure to use the option to use stored directory names in the
archive. If this option is not used, all files will be extracted
to the Perl directory you created, and you'll find yourself in
a mess! After the archive is uncompressed, run install.bat to
install Perl on your server. Then you need to copy Perl.EXE
to the root CGI directory of your Web server, which enables your
Web server to execute Perl CGI scripts.
Note |
When uncompressing the ZIP file, be sure to use a 32-bit unzipping program that supports long filenames. Otherwise, the distribution files may not be properly installed. WinZip is a fine file uncompressing program that supports long filenames and a variety of file compression formats. You can obtain WinZip from http://www.winzip.com/WinZip/download.html |
After installing Perl, you need to reboot your server for the installation directory paths to become effective. Failure to do this will cause Perl to greet you with an Unable to locate DLL message. (Yes, I was naíve and tried it!) If you don't feel like rebooting your server, there is another alternative (and I found a way around the problem!). You can simply copy all files in the Perl\bin directory to the CGI directory of your Web server. However, this is not recommended in a production Web server. Doing this opens several security holes.
Before creating CGI applications, it is recommended that you check your Web server settings and find out the name of its CGI directory. The remainder of this chapter assumes this directory to be CGI-BIN.
After you're comfortable with CGI and using CGI Perl scripts, for more information about Perl and sample CGI Perl scripts, you might want to give the following URLs a click:
Yahoo-Computers and Internet:Internet:World Wide Web:Programming:Perl Scripts
http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/
Programming/Perl_Scripts/
Yahoo-Computers and Internet:Languages:Perl
http://www.yahoo.com/Computers_and_Internet/Languages/Perl/
To keep up-to-date with the latest news on Perl for Windows NT, you might also want to consider joining the following mailing lists:
Perl-Win32-Perl discussion list
To subscribe, send e-mail to:
majordomo@mail.hip.com
Include the following in the message body:
subscribe Perl-Win32
Perl-Win32_announce-Perl announcements
To subscribe, send e-mail to:
majordomo@mail.hip.com
Include the following in the message body:
subscribe Perl-Win32_announce
The Perl discussion list is a relatively high-volume mailing list. However, this list is read by many Windows NT Perl programmers and will answer any questions you might have when starting out with Perl.
Because you're reading this book, chances are that you have at least heard of C and possibly know how to program in C. Therefore, an introduction to the C programming language will not be provided. For more information, please refer to one of the many fine books that have been written about programming in C.
C is a general purpose language with very few restrictions imposed on the programmer. It is also a portable language that can be moved from one computer to another as long as only standard POSIX/ANSI C function calls are used. There are many CGI programs written in C on the Internet that you can use to enhance the capabilities of your Web site. For more information on C CGI programs, please look up
http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/Programming/
By using various Windows API calls from C programs, you can further exploit the capabilities of C and Windows NT. Although a command line C compiler for Windows NT can be obtained from ftp://ftp.cygnus.com/pub/sac/gnu-win32/, it is recommended that you invest in a C compiler with a GUI development environment such as Microsoft Visual C++ or Borland C++.
All CGI scripts have one thing in common: the first two lines displayed by all CGI programs that display text output are the same. The first line displayed by all CGI programs that display text is Content-type: text/html. This line of text is always followed by two blank lines. Typically, ASCII character 10 is used twice, immediately after this line of text to create the blank lines.
For example, the first line of output for all CGI C programs with text output is
printf("Content-type: text/html%c%c",10,10) ;
The first line of output for all CGI Perl scripts with text output is
print "Content-type: text/html\n\n";
A small note about programming in CGI is in order before moving into writing CGI programs. Sooner or later, when you write your own programs or try out examples, you'll get error messages generated by your Web server when you call the CGI script. Although things might get somewhat frustrating for you, don't give up! Most likely, the error message you receive from your Web server is due to a small oversight on your behalf. After a while, if you're still not getting anywhere with debugging your CGI script, it's time for you to start printing everything you can think of to standard output. Perhaps a variable you thought contained a value contains nothing but a NULL string. Perhaps an environmental variable you thought would be available to your script is not available. It's also possible that you left out the most important thing of all: the first line of all CGI scripts, as mentioned in the preceding section.
Rather than trying to debug CGI scripts by executing them on your Web server, you can execute them from the command prompt as well. It is possible to execute CGI programs by running them from the command prompt to find out what really happens. In order to do this, you need to manually set various CGI environment variables to make the CGI program believe that it's really being invoked by a Web server. Environmental variables can be defined by using the SET command, with the following syntax:
SET VARIABLE_NAME=VARIABLE_VALUE
For example, you can create a batch file with the following variable declarations to test CGI programs when running them from the command prompt. Please note that you may need to change the value of QUERY_STRING if your CGI script makes use of arguments.
SET SERVER_SOFTWARE=Netscape-Communications/1.12 ;SET SERVER_NAME=your.host.name ;SET GATEWAY_INTERFACE=CGI/1.1 ;SET SERVER_PROTOCOL=HTTP/1.0 ;SET SERVER_PORT=80 ;SET REQUEST_METHOD=GET ;SET SCRIPT_NAME =/cgi-bin/ScriptName.exe ;SET QUERY_STRING=ArgumentsToCGIScript ;SET REMOTE_HOST =000.000.000.000 ;SET REMOTE_ADDR =000.000.000.000 ;SET CONTENT_TYPE=application/x-www-form-urlencoded ;SET HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* ;SET HTTP_USER_AGENT=Mozilla/2.0b4 (WinNT; I)
It's customary for the first program written in a new language or programming interface to display the string Hello World! Although this is a very simple application of CGI, it will teach you the basics of CGI scripts as well as how CGI scripts are called by Web browsers. The Hello World! script is demonstrated in Perl as well as C to make you more familiar with both languages and syntaxes of calling Perl and CGI scripts.
The Hello World! CGI script will simply display the current day, time, arguments passed in, and the browser being used by the client to access the CGI script. And of course, the string Hello World! will also be displayed!
The script that displays Hello World! and the additional information is very simple to write in Perl. The code for this Perl script is listed next. The output of the Perl script appears in Figure 16.6.
Figure 16.6: Output of Hello World! CGI Perl script.
Security |
Do not place PERL.EXE in your CGI directory. A user with malicious intent can potentially use PERL.EXE to execute commands on your NT Server. Rather than place PERL.EXE in your CGI directory, create a CGI extension mapping and place PERL.EXE in a directory that's not accessible via your Web server. Refer to your Web server documentation for information about creating CGI extension mappings. |
# Sanjaya Hettihewa, http://wonderland.dial.umd.edu/ # December 31, 1995 # "Hello World" CGI Script in Perl # Display content type being outputted by CGI script print "Content-type: text/html\n\n"; # Label title of contents being outputted print "<TITLE>Perl CGI Script Demonstration</TITLE>\n"; # Display text print "<H1>Hello World!</H1>\n"; print "<H3>Welcome to the fun filled world of<BR>\n"; print "Windows NT CGI programming with Perl!</H3><BR><BR>\n"; print "The Web browser you are using is:"; # Display value of the environmental variable HTTP_USER_AGENT print $ENV{"HTTP_USER_AGENT"} , "<BR>\n" ; print "Arguments passed in: "; # Display value of the environmental variable QUERY_STRING print $ENV{"QUERY_STRING"} , "<BR>\n" ; # Obtain date and time from the system ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime(time); # display time print "\nThe current time is: "; print $hour, ":", $min, ":", $sec , "<BR>\n"; # display date print "\nThe current date is: "; print $mon + 1 , "/", $mday , "/", $year, "<BR>\n";
Pay particular attention to how the Perl CGI script is invoked. In the case of this example, the URL used to invoke the CGI script is
http://wonderland.dial.umd.edu/cgi-bin/perl.exe?PERLScripts/HelloWorld/ HelloWorld.pl+Argument
When calling a Perl script on a Windows NT Web server, the general syntax of the URL is
http://A/B?C+D
where
A is the host name of the Web server; in this example, it is wonderland.dial.umd.edu.
B is the relative path to PERL.EXE; in this example, it is cgi-bin/perl.exe.
C is the location of the Perl script. This path is relative to the location of PERL.EXE.
D contains any arguments passed into the Perl script. These arguments can be obtained by examining the contents of the CGI environment variable QUERY_STRING.
As you can see from the preceding example, when Perl scripts are called with arguments, the length of URLs can become quite long. You can avoid this by creating aliases for Perl scripts on your Web server. (Please consult your Web server's documentation for more information on creating aliases for URLs.) For example, if an alias called Hello was created for
http://wonderland.dial.umd.edu/cgi-bin/perl.exe?PERLScripts/HelloWorld/HelloWorld.pl
the URL to call the preceding Perl CGI script will be reduced to
http://wonderland.dial.umd.edu/Hello+Argument
Whenever you have complex URLs for CGI scripts, create an alias for the CGI script. By hiding gory details such as long and complicated URL paths, your Web site will actually look "friendlier" to someone browsing your Web site. It will also save you time whenever you refer to such CGI scripts from one of your Web pages because you will have to do less typing. If you're still not convinced, it's much easier to remember
http://wonderland.dial.umd.edu/Hello+Argument
as opposed to
http://wonderland.dial.umd.edu/cgi- bin/perl.exe?PERLScripts/HelloWorld/HelloWorld.pl+Argument
The following code lists the C program that displays the same information as the preceding Perl example. The output of the C script appears in Figure 16.7.
Figure 16.7: Output of Hello World! CGI C script.
/* Sanjaya Hettihewa, http://wonderland.dial.umd.edu/ * December 31, 1995 * "Hello World" CGI Script in C */ /* Libraries containing special functions used in program */ #include <stdio.h> #include <stdlib.h> #include <time.h> main ( ) { /* Obtain current time */ time_t currentTime ; struct tm *timeObject ; char stringTime[128] ; currentTime = time ((time_t *) NULL ) ; timeObject = localtime (¤tTime) ; /* Display content type being outputted by CGI script */ printf ("Content-type: text/html\n\n"); /* Displaying simple text output */ printf ("<TITLE>C CGI Script Demonstration</TITLE>\n"); printf ("<H1>Hello World!</H1>\n"); printf ("<H3>Welcome to the fun filled world of<BR>\n"); printf ("Windows NT CGI programming with C!</H3><BR><BR>\n"); /* Display value of the environmental variable HTTP_USER_AGENT */ printf ("The Web browser you are using is: "); if ( getenv ( "HTTP_USER_AGENT" ) != NULL ) printf ( "%s%s" , getenv ( "HTTP_USER_AGENT" ) ,"<BR>\n") ; /* Display value of the environmental variable QUERY_STRING */ printf ("Arguments passed in: "); if ( getenv ( "QUERY_STRING" ) != NULL ) printf ( "%s%s", getenv ( "QUERY_STRING" ) ,"<BR>\n") ; /* Display date and time using strftime() to format the date */ strftime ( stringTime, 128, "%H:%M:%S", timeObject ) ; printf ("\nThe current time is: %s<BR>\n", stringTime ); strftime ( stringTime, 128, "%m/%d/%y", timeObject ) ; printf ("\nThe current date is: %s\n", stringTime ); return ( 0 ) ; }
CGI C programs are accessed differently than Perl CGI scripts. C Programs can be directly executed by the Web server. However, Perl scripts have to be interpreted using the Perl interpreter. After compiling the C program into an executable program, it should be placed either in the CGI directory of your Web server or in a directory that's a child of the CGI directory. In this example, the executable program was placed in the cgi-bin directory, and the URL used to invoke the CGI script is
http://wonderland.dial.umd.edu/cgi-bin/hello.exe?Argument
When a CGI program on a Windows NT Web server is called, the general syntax of the URL is
http://A/B?C
where
A is the host name of the Web server. In this example, it is wonderland.dial.umd.edu.
B is the relative path to the executable program from the Web server's document root directory. In this example, it is cgi-bin/hello.exe.
C contains any arguments passed into the C program. You can obtain these arguments by examining the contents of the CGI environment variable QUERY_STRING.
A thorough introduction to various programming languages and how you can utilize them to develop CGI applications is beyond the scope of this book. Therefore, most CGI applications developed in this chapter are developed by using the C programming language. However, to give you a feel for how various programming languages can be used to write CGI applications, you are shown how various environmental variables can be accessed by using Perl and C.
The following C program displays all CGI variables that have been set by the Web server. Note that all environmental variables may not be defined depending on how the script is called. The following CGI program will display all CGI variables that have been defined by the Web server before invoking the CGI script:
/* C Program to display CGI environment variable values defined by the Web server before the CGI program is invoked */ #include <stdio.h> #include <stdlib.h> #define NUM_ENVIRONMENT_VARIABLES 19 main ( ) { /* Define the data structure that stores all the CGI variable names */ char* environmentVariables[] = { "SERVER_SOFTWARE", "SERVER_NAME", "GATEWAY_INTERFACE", "SERVER_PROTOCOL", "SERVER_PORT", "REQUEST_METHOD", "PATH_INFO", "PATH_TRANSLATED", "SCRIPT_NAME", "QUERY_STRING", "REMOTE_HOST", "REMOTE_ADDR", "AUTH_TYPE", "REMOTE_USER", "REMOTE_IDENT", "CONTENT_TYPE", "CONTENT_LENGTH", "HTTP_ACCEPT", "HTTP_USER_AGENT" } ; int count ; printf("Content-type: text/html%c%c",10,10) ; printf("%s%s" , "<PRE>\n", "<TITLE>CGI Environmental Variables Demonstration</TITLE>\n") ; /* Loop through all CGI variables that were defined earlier */ for (count = 0; count < NUM_ENVIRONMENT_VARIABLES; count++) /* Check if a certain CGI variable has been defined by the Web server and print its value if the CGI variable has been defined */ if ( getenv ( environmentVariables[count] ) != NULL ) printf ( "%17s = %s\n" , environmentVariables[count] , getenv ( environmentVariables[count] ) ) ; printf("</PRE>\n") ; return ( 0 ) ; }
The output of the preceding CGI script appears in Figure 16.8. As you can see from the URL, the URL of the CGI script is followed by additional arguments to the CGI script. Notice how the Web server has passed the arguments following the URL to the CGI script by using an environment variable.
Similarly, CGI scripts can be accessed very easily from a Perl script. The CGI Perl script that displays values of various CGI variables follows:
# Print the first line of all CGI scripts print "Content-type: text/html\n\n"; print "<TITLE>PERL CGI Variable Demonstration</TITLE>\n"; printf( "<PRE>\n" ); foreach $EnvVar ( SERVER_SOFTWARE, SERVER_NAME, GATEWAY_INTERFACE, SERVER_PROTOCOL, SERVER_PORT, REQUEST_METHOD, PATH_INFO, PATH_TRANSLATED, SCRIPT_NAME, QUERY_STRING, REMOTE_HOST, REMOTE_ADDR, AUTH_TYPE, REMOTE_USER, REMOTE_IDENT, CONTENT_TYPE, CONTENT_LENGTH, HTTP_ACCEPT, HTTP_USER_AGENT ) # Loop through all environment variables and display the values of all CGI variables that have been defined by the Web server. { if ( $ENV{"$EnvVar"} ) { printf( "%17s = %s\n", $EnvVar, $ENV{"$EnvVar"} ); } } printf( "</PRE>\n" ); exit( 0 );
The output of the preceding Perl script appears in Figure 16.9. Note again how the Perl script is being called. The URL of the Perl script is made up of the URL of PERL.EXE and the location of the Perl script with respect to the location of PERL.EXE.
Figure 16.9: Output of CGI script written in Perl to display CGI variables.
With the expansion of the World Wide Web, more and more Web browsers are being invented. Although there are many Web browsers available for Windows NT, their capabilities differ greatly. Although at the time this book was written, Netscape roughly accounted for about 70 percent of all Web browsers being used. In all likelihood, with the release of Internet Explorer 3.0, this will change when Microsoft's Internet Explorer becomes more widely used. If the appearance of your Web site is very important to you, you might want to consider setting up a CGI script to provide a customized Web page, depending on the browser being used. Clearly, this is not practical for a very large Web site. However, by setting up a very simple CGI script as shown next, you can find out which Web browser is being used by the user browsing your Web site. If the browser being used is Netscape Navigator or Microsoft's Internet Explorer, you can provide a richly formatted Web page with various HTML enhancements, or otherwise provide a basic page with the same content.
Most Web pages that make use of special HTML tags (such as Netscape enhancements to HTML) look very attractive when viewed with a browser that supports the special HTML tags used. However, these pages tend to look less attractive when viewed with browsers that do not support the enhancements. The percentage of people with Web browsers that do not support various enhancements to HTML can be as much as 40 percent. For these Web browsers, it's possible to set up a CGI script that will display the same content that's formatted by using standard HTML. Such a CGI script can display customized content, as shown in Figure 16.10, based on the CGI variable HTTP_USER_AGENT.
Figure 16.10: Using a CGI program to provide customized content based on the Web browser being used.
The CGI script in the following code listing is very simple. It
first determines the Web server being used by looking at the environment
variable HTTP_USER_AGENT.
Depending on the value of this variable, a page with Netscape
enhancements to HTML can be displayed if the browser being used
is Netscape. On the other hand, a page that contains only standard
HTML 2.0 can be displayed if the browser used by a Web surfer
is not Netscape. By modifying the script, you can always add more
customized pages for other browsers. Such a script can be used
for important pages like the main home page of your organization.
By utilizing CGI to provide dynamic content, you will give a good
impression to someone browsing the contents of your Web site.
You can ensure that a user with an advanced Web browser will see
richly formatted Web pages. It is not feasible to support more
than two custom Web pages. Both Internet Explorer and Netscape
Navigator interpret HTML tags more or less the same way. You might
want to create one page with Netscape and Internet Explorer extensions
and another that uses only standard HTML 2.0.
Performance |
Please note that the following program is not optimized for speed of processing but for ease of reading. Because it is written to demonstrate how a CGI program can be written to provide customized content, it focuses on teaching CGI fundamentals and not on optimizing the code. You can make it more efficient by reading chunks of the file at a time rather than reading and outputting the file character by character. |
/* (C) 1995 Sanjaya Hettihewa http://wonderland.dial.umd.edu/ * January 1, 1996 * Program to output a customized Web page based on Web browser being used. */ /* Special function libraries being used by this program */ #include <stdio.h> #include <stdlib.h> #include <string.h> /* Please note the use of double quotes. This is because a single quote is used to quote the next character */ /* If you provide content specialy formatted for a different browser, please change the following */ #define SPECIAL_BROWSER_SUB_STRING "Mozilla" /* Please change the following to the full path name of the HTML file that's specially formatted */ #define SPECIAL_BROWSER_PAGE "H:\\www\\https\\ns-home\\root\\documents\\WSDGNT\\special.htm" /* Please change the following to the full path name of the HTML file that's formatted using standard HTML */ #define OTHER_BROWSER_PAGE "H:\\www\\https\\ns-home\\root\\documents\\WSDGNT\\regular.htm" /* Please change the following to the e-mail address of your Web site administrator */ #define WEBMASTER "mailto:Webmaster@wonderland.dial.umd.edu" static int DisplayPage ( char *pageName ) ; main ( ) { /* The "First Line" of all CGI scripts... */ printf("Content-type: text/html%c%c",10,10) ; /* Find out what Web browser is being used */ if ( getenv ( "HTTP_USER_AGENT" ) == NULL ) { printf("FATAL ERROR: HTTP_USER_AGENT CGI variable undefined!\n") ; return ( 0 ) ; } /* Display appropriate page based on browser being used by client */ if (strstr (getenv ("HTTP_USER_AGENT" ), SPECIAL_BROWSER_SUB_STRING)!=NULL) DisplayPage ( SPECIAL_BROWSER_PAGE ) ; else DisplayPage ( OTHER_BROWSER_PAGE ) ; return ( 0 ) ; } /* Contents of file passed into this function will be displayed to standard output. The Web server will transmit what's displayed to standard output by this CGI script to the client that called the CGI script */ int DisplayPage ( char *pageName ) { FILE *inFile ; char character ; /* Check to ensure a valid file name is given */ if ((inFile = fopen(pageName, "r")) == NULL) { printf ( "FATAL ERROR: Content file can't be opened! %s<BR>", pageName); printf ( "Please contact the <A HREF=%s>Webmaster.</A><BR>", WEBMASTER ); return ( 0 ) ; } /* Displaying contents of file to standard output Please note that this can be done more efficiently by reading chunks of the file at a time */ fscanf ( inFile , "%c" , &character ) ; while ( !feof(inFile) ) { printf ( "%c" , character ) ; fscanf ( inFile , "%c" , &character ) ; } fclose(inFile); return ( 1 ) ; }
Because the purpose of this program is to provide customized content based on the browser being used to browse your Web site, you need to create two separate Web pages. The first Web page is sent to any non-Netscape browser, assuming it does not parse various HTML-enhanced tags as does Netscape. This Web page can be very simple. For the purpose of this demonstration, assume that you need to display a number of options inside a table. Because browsers that do not support the <TABLE> tag might interpret this tag differently, you will have no control over what your Web site will look like when viewed with a different browser. To remedy this situation, you can use the preceding CGI program. For Web browsers that do not support enhanced HTML tags, you can create a non-table version of the same page using only standard HTML. By doing this, the appearance of your Web site can be controlled no matter what browser is being used to access your Web pages.
The following is the standard HTML Web page designed for non-Netscape browsers. In case you're interested in knowing where this Web page is referenced in the CGI program, this file will be saved at
H:\\www\\https\\ns-home\\root\\documents\\WSDGNT\\regular.htm
The location of the preceding file is defined in the C program so that its contents can be displayed for non-Netscape browsers. In the C program, the location of the preceding file is defined in OTHER_BROWSER_PAGE.
<TITLE>Standard HTML page</TITLE> <BODY> Welcome to the standard HTML page for technically challenged Web browsers. <P> Option One<BR> Option Two<BR> Option Three<BR> </BODY>
The following is the Netscape-enhanced HTML Web page that is specially designed for those browsing your Web site with Netscape. The following HTML code displays the same three options that are displayed by the standard HTML page. However, the options are displayed inside a table with some additional Netscape enhancements. Because the C program needs to know the location of this file for the purpose of this example, the following page is located at
H:\\www\\https\\ns-home\\root\\documents\\WSDGNT\\special.htm
In the C program, the full path name of the preceding file is stored in SPECIAL_BROWSER_PAGE. The contents of this file are displayed by the CGI program whenever Netscape Navigator is used. You will need to change this variable depending on where you store the Netscape-enhanced Web page.
<TITLE>Netscape Enhanced page</TITLE> <BODY> <CENTER> <TABLE BORDER=15 CELLPADDING=10 CELLSPACING=10 > <TR> <TD > Welcome to the <FONT SIZE=4>Ne</FONT><FONT SIZE=5>ts</FONT><FONT SIZE=6>ca</FONT><FONT SIZE=7>pe</FONT> <FONT SIZE=6>En</FONT><FONT SIZE=5>ha</FONT><FONT SIZE=4>nc</FONT><FONT SIZE=3>ed </FONT> Web page! </TD> <TD >Option One<BR></TD > <TD >Option Two<BR></TD > <TD >Option Three<BR></TD > </TR> </TABLE> </CENTER> </BODY>
After compiling the preceding program and placing it in your Web server's CGI directory, depending on the browser being used to call the CGI script, the appropriate page will be displayed. When compiling the C program, please be sure to change SPECIAL_BROWSER_PAGE, OTHER_BROWSER_PAGE, and WEBMASTER. The output of the CGI program to provide customized content appears in Figures 16.11 and 16.12. For the purpose of this example, the two Web browsers Netscape and Mosaic were used. Note how the enhanced HTML page is displayed when accessing the script with Netscape, and the standard HTML page is displayed when accessing the script with Mosaic.
Figure 16.11: Output of a CGI program when it is invoked by using Netscape.
Figure 16.12: Output of a CGI program when invoked with a non-Netscape browser such as Mosaic.
One of the best things about CGI is that it lets you interact with people browsing your Web site. What better way is there to interact with them than ask for their feedback? By using a Windows NT command line mail utility called Blat and another CGI program that can be used to e-mail the contents of a form, you can set up a feedback form at your Web site in just a few minutes. Please refer to Chapter 26, "Setting Up Mail Server," to learn how to set up Blat on your system.
After setting up Blat, you need to create a feedback form. This feedback form will be used by users who want to e-mail their feedback to you. Before setting up the form, you need to download the program that will process the contents of the form after it's submitted. The program you need to download is wwwmail.exe, and you can download it from
http://www.esf.c-strasbourg.fr/misc/amsoft.exe?www
After downloading wwwmail.exe, you need to copy it to the CGI directory of your Web server. Then you need to create a page that displays after the user submits his or her feedback. This page can then thank the user for the feedback and allow the user to choose another link to follow.
Now all that's left to do is to create a feedback form and a response page that will display after the form is submitted. Refer to the following code listing for a simple feedback page. You can utilize a similar page to set up a feedback form at your Web site. There are a few values that you need to change to customize the feedback form, depending on how your Web site is organized. These values are
name="mailto" value="user_ID@your.site" name="WWWMail-Page" value="<Full Path of page to display after submitting the form"> action="<your CGI Directory>/wwwmail.exe/cgi-bin/feedback.hfo">
Tip |
In order to provide the user with a set of predefined selections, you can have a pull-down list using the <SELECT/OPTION> tag, as shown in the following listing. |
<HTML> <HEAD> <title>Feedback Form Demonstration</title> </HEAD> <BODY> <FORM method=POST action="/cgi-bin/wwwmail.exe/cgi-bin/feedback.hfo"> <INPUT TYPE=hidden name="mailto" value="Webmaster@wonderland.dial.umd.edu"> <INPUT TYPE=hidden name="WWWMail-Page" value="H:\www\netscape_commerce\ns-home\root\documents\feedback\ThanksForFeedback.html"> <PRE> <b>Subject:</b> <SELECT name="subject"> <OPTION> I have some Feedback <OPTION> I have a comment... <OPTION> I have a suggestion... <OPTION> I need assistance with... <OPTION> Other </SELECT> <B>Your E-mail address please:</B> <INPUT name="sender" SIZE=30> <b>Your name Please:</b> <INPUT name="name" SIZE=30 > <b>Your phone # (If you wish)</b> <INPUT name="phoneno" SIZE=20 > <b>Would you like a reply from me?</b> <SELECT name="Reply"> <OPTION> If you wish <OPTION> Yes, please <OPTION> No thanks </SELECT> <b>Is this message urgent?</b> <SELECT name="Urgency"> <OPTION> Not particularly <OPTION> Yes, very urgent <OPTION> Not at all </SELECT> <b>Please type your message and press the submit button:</b> <TEXTAREA name="comments" cols=65 rows=3> </TEXTAREA> <input type=submit value="Please click here to send message"> </FORM> </PRE> </BODY> </HTML>
After setting up a form similar to the one in the preceding listing, you will have a feedback form that looks like the form shown in Figure 16.13.
Figure 16.13: A generic feedback form.
Now you need to create a page like the one shown in Figure 16.14. After the feedback form is submitted, this page will be displayed by the CGI script to thank the user for the feedback. The location of this page is defined in the variable WWWMail-Page of the HTML form. After the form is filled in and submitted, the page defined in WWWMail-Page should let the user know that you received the feedback and will get in touch with the user soon. It will also be helpful if you can let users know how soon you will be able to get in touch with them. Also, this page should provide a hypertext link to another page at your Web site so the user can continue to browse your Web site with ease.
One of the best things about the World Wide Web is how you can use it to distribute information to millions of people. CGI allows you to interact with this large audience of people. This chapter was an introduction to using CGI to enhance the capabilities of your Web site as well as how to write CGI scripts in Perl and C. Various aspects of setting up CGI scripts, such as security, were also covered in this chapter so that the CGI scripts you develop and set up will not be a threat to the security of your Web server. Various practical applications of CGI were illustrated along with the source code so that you can modify examples presented to enhance your Web site.
In order to become more familiar with the topics covered in this chapter, you need to spend some time with either C or Perl. After writing some CGI programs and experimenting with the effects of making changes to them, you will discover how CGI scripts work as well as gain more experience in debugging and developing CGI scripts. Afterward, you will be able to create various CGI applets to perform many specialized tasks. As you gain more experience, CGI programs you once thought to be very complicated will be easy for you. By utilizing CGI and unleashing its potential to make the contents of your Web site easier to navigate, you will have an outstanding Web site with many repeat visitors.
With the knowledge gained by reading this chapter, you're now ready to move on to the more advanced applications of CGI in the next chapter. Chapter 17, "Advanced Windows NT CGI Applications," shows you how to retrieve data from feedback forms and process them. It also covers a number of tools that you can use to create forms and dynamic Web pages.