|
|
 |
 |
To access the contents, click the chapter and section titles.
Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98
|
 | You don’t have to understand all this now. This is just a taste of the rest of this chapter, which contains more details. If you want to learn more about the intricacies of Perl, specifically, you might want to get a full book on the subject, such as Perl 5 by Example, Perl 5 How-To, Perl 5 Interactive Course, Teach Yourself Perl 5 for Windows NT in 21 Days, or Special Edition Using Perl 5, all published by Macmillan imprints. Of course, the classic Programming Perl, by the creator of Perl, Larry Wall, and two other Perl luminaries, Tom Christiansen and Randal L. Schwartz, is now in its second edition, published by O’Reilly and Associates. You can find many more examples at the Web site addresses given near the end of this chapter. A good place to start is Matt’s Script Archives at http://www.worldwidemart.com/scripts/. You’ll find popular scripts with explanations and directions.
|
|
After looking at a few CGI programs, you’re ready to learn more about how they access information from the browser. Before the server launches the script, it prepares a number of environment variables representing the current state of the server that is asking for the information. The environment variables given to a script are exactly like normal environment variables, except that you can’t set them from the command line. They’re created on-the-fly and last only until that particular script is finished. Each script gets its own unique set of variables. In fact, a busy server often has many scripts executing at once, each with its own environment.
You’ll learn about the specific environment variables later in the “Designing CGI Applications” section. For now, it’s enough to know that they’re present and contain important information that the script can retrieve.
Also, depending on how the server invokes the script, the server may pass information another way, too: Although each server handles things a little differently, and although Windows servers often have other methods available, the CGI specification calls for the server to use the script’s STDIN (standard input) to pass information to the script.
Standard Input and Output
STDIN and STDOUT are mnemonics for standard input and standard output, two predefined stream/file handles. Each prcess inherits these two handles already open. Command-line programs that write to the screen usually do so by writing to STDOUT. If you redirect the input to a program, you’re actually redirecting STDIN. If you redirect the output of a program, you’re actually redirecting STDOUT. This mechanism enables pipes to work. If you do a directory listing and pipe the output to a sort program, you’re redirecting the STDOUT of the directory program (DIR or LS) to the STDIN of the sort program.
From the script’s point of view, STDIN is what comes from the browser via the server when a POST method is used, and STDOUT is where it writes its output back to the browser. Beyond that, the script doesn’t need to worry about what’s being redirected where. This standard works well in the text-based UNIX environment, where all processes have access to STDIN and STDOUT. In the Windows environments, however, STDIN and STDOUT are available only to nongraphical (console-mode) programs. To complicate matters further, Windows NT creates a different sort of STDIN and STDOUT for 32-bit programs than it does for 16-bit programs. Because most Web servers are 32-bit services under Windows NT, this means that CGI scripts have to be 32-bit console-mode programs. That leaves popular languages such as Visual Basic 1.0––3.0 and Delphi 1.0 out in the cold. One older Windows NT Web server, the freeware HTTPS from EMWAC, can talk only to CGI programs this way. Fortunately, several ways around this problem exist.
Some Windows NT servers, notably Bob Denny’s WebSite, use a proprietary technique using .ini files to communicate with CGI programs. This technique, which is an old but widely used standard, is called CGI-WIN. A server supporting CGI-WIN writes its output to an .ini file instead of STDOUT. Any program can then open the file, read it, and process the data. Unfortunately, using any proprietary solution such as this one means your scripts will work only on that particular server.
For servers that don’t support CGI-WIN, you can use a wrapper program. Wrappers do what their name implies: they wrap around the CGI program like a coat, protecting it from the unforgiving Web environment. Typically, these programs read STDIN for you and write the output to a pipe or file. Then they launch your program, which reads from the file. Your program writes its output to another file and terminates. The wrapper picks up your output from the file and sends it back to the server via STDOUT, deletes the temporary files, and terminates itself. From the server’s point of view, the wrapper was the CGI program.
The script picks up the environment variables and reads STDIN as appropriate. It then does whatever it was designed to do and writes its output to STDOUT.
The MIME codes that the server sends to the browser let the browser know what kind of file is about to come across the network. Because this information always precedes the file itself, it’s usually called a header. The server can’t send a header for information generated on-the-fly by a script because the script could send audio, graphics, plain text, HTML, or any one of hundreds of other types. Therefore, the script is responsible for sending the header. So in addition to its own output, whatever that may be, the script must supply the header information. Failure to do so can mean failure of the script because the browser won’t understand the output.
|
