📄 ch11.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 11 -- The CGI and Networks</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT SIZE=6 COLOR=#FF0000>Chapter 11</FONT></H1>
<H1><FONT SIZE=6 COLOR=#FF0000>The CGI and Networks</FONT></H1>
<HR>
<P>
<CENTER><B><FONT SIZE=5><A NAME="CONTENTS">CONTENTS</A></FONT></B></CENTER>
<UL>
<LI><A HREF="#MoreCGISpecifics">
More CGI Specifics</A>
<UL>
<LI><A HREF="#MIME">
MIME</A>
<LI><A HREF="#OtherCGIRealizations">
Other CGI Realizations</A>
</UL>
<LI><A HREF="#ServerSideIncludes">
Server-Side Includes</A>
<UL>
<LI><A HREF="#SSISyntax">
SSI Syntax</A>
<LI><A HREF="#SSICommands">
SSI Commands</A>
</UL>
<LI><A HREF="#HowCGIWorks">
How CGI Works</A>
<UL>
<LI><A HREF="#ADemonstration">
A Demonstration</A>
<LI><A HREF="#FormsandCGI">
Forms and CGI</A>
<LI><A HREF="#NonParsedHeaders">
Non-Parsed Headers</A>
</UL>
<LI><A HREF="#CGISummary">
CGI Summary</A>
</UL>
</UL>
<HR>
<P>
At this point, knowing what you know about CGI, you can begin
to lay out what is important when deciding to work in a programming
environment. The first consideration is whether the programming
language you use allows you to read it, enhance it, and maintain
it. Match your language to your needs. Some languages are more
powerful, but take more time and RAM to do their processing. Keep
storage concerns in mind. Every language has memory needs. There
has to be sufficient disk space to store the language software
itself, as well as room for the language to create temporary files
"on the fly" that it may need to operate properly.
<P>
How fast can clients access each particular feature on your server,
whether it is your Web pages or your FTP archive? When determining
your access response time standard, the five-second rule is a
good rule to follow. If it takes more than five seconds for the
client to load whatever it has requested from your server, you
are taking too long. The one big exception to the five-second
rule is a search engine response-which may take longer.
<P>
The aptitude the language has for text manipulation is also important.
Finally, figure out whether the language can "talk"
easily with the various applications that will be accessing the
Web server. The ability to "talk" means that the language
you use should easily mesh with the applications you use on your
server when it uses them. The best way to decide how well a language
will "talk" with your applications is to determine which
applications you will be using with the language-perhaps a database
program-and then examine the potential CGI language based on the
needs of your list of applications.
<P>
CGI scripts work best with well-organized data. There should be
an overall method that you use to decide where each piece of data
goes and to guide your file storage. Are you storing data by type
or by category? Or are you storing data by kind of access or ease
of display? This method can then be easily applied to your CGI
scripts, to integrate them into your system's present organizational
structure.
<P>
Make sure you know where everything is going before you get going.
Establish a directory for final scripts, then don't clutter up
that directory with test scripts. Create a way to check which
version of your script is current, and where your test scripts
are located, such as keeping test scripts in a directory labeled
"TEST_SCRIPTS." Then rename and move a script to its
proper directory, perhaps a script library folder, once it is
ready for use.
<P>
Following accepted programming practices is very important. Document
your code. Use separate directories for production and testing.
Keep up-to-date maintenance logs with each new bug recorded in
sufficient detail to be useful later.
<P>
Getting a handle on HTTP is essential for success with your CGI
scripts. Keep up with any changes through any number of USENET
newsgroups. Know the client/server cycle. Whether it is using
CGI or not, the client/server dynamic should be well understood
by anyone running an HTTP service. You should also have an understanding
of how data is passed using <STDIN> and environmental variables,
including the primary methods for doing this-that is, GET and
POST in the HTML form format.
<H2><A NAME="MoreCGISpecifics"><FONT SIZE=5 COLOR=#FF0000>
More CGI Specifics</FONT></A></H2>
<P>
There are several protocols and specifications used by the CGI,
like HTTP, FTP, and e-mail. MIME specifications are very important
when using the CGI with a Web server. There are several languages
that can be used with these CGI specifics, such as C/C++, REXX,
Python, and of course, Perl.
<P>
Understanding their role is important in understanding where your
Perl scripts will fit in without difficulty. Another important
consideration is whether protocols or specifications need adapting,
such as with MIME headers, which must be included at the beginning
of any Perl script returning data from your server to a client.
<H3><A NAME="MIME">
MIME</A></H3>
<P>
For CGI to run smoothly on your server, it has to know what kind
of data is coming in so it can figure out what to do with it.
Using MIME specifications, your server tells the client what kind
of file it is returning to fulfill its request, so the client
knows what to do with that file. Some of the different file types
handled with MIME specifications are HTML, JPEG, GIF, MOV, and
so forth. A full list of MIME header file types can be found in
Appendix B.
<P>
If a client's request comes in, and it contains a METHOD=GET (or
POST) argument, then some kind of data will be written to standard
output, which is then sent by the server to the client. The initial
print statement must be output in a kind of form string. Its format
would resemble
<BLOCKQUOTE>
<PRE>
Content-type type/subtype <line feed> <line feed>
</PRE>
</BLOCKQUOTE>
<P>
and when this appears in Perl, it will look like this:
<BLOCKQUOTE>
<PRE>
print "Content-type: text/html \n\n";
</PRE>
</BLOCKQUOTE>
<P>
where \n is Perl's line feed escape.
<P>
Adhering to MIME specifications lets the client know that it is
receiving a text file to be treated like HTML. Note that there
are two line feed escape commands given. The first makes the initial
line feed to go to line 2 of the output. The second produces a
completely blank line. For a CGI script to run successfully, the
second line of its output must be blank.
<P>
An example of a simple HTML document sent to satisfy a client's
request might look something like Figure 11.1, where a simple
greeting is sent back to the user. It is accomplished with the
following script:
<P>
<A HREF="f11-1.gif" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/f11-1.gif"><B>Figure 11.1 :</B> <I>A simple CGI greeting using Perl</I>.</A>
<BLOCKQUOTE>
<PRE>
#!/usr/bin/perl
#kingsley.pl
print "Content-type: text/html \n\n";
print "<HTML> \n";
print "<HEAD><TITLE>Hey Now!</TITLE></HEAD> \n";
print "<BODY>Hey Now!</BODY></HTML> \n";
exit;
</PRE>
</BLOCKQUOTE>
<H3><A NAME="OtherCGIRealizations">
Other CGI Realizations</A></H3>
<P>
Now, a quick look at other commonly used CGI languages is in order.
These are the other CGI languages that you may have heard of-or
even encountered-in written scripts. Among them are C, C++, REXX,
and Python. Some quick definitions will help you to understand
better what is being discussed when you come across references
to these other CGI languages, and even how they compare with Perl.
To do this, a quick review of Perl as a CGI language is helpful
here.
<H4>Perl</H4>
<P>
The first reason for using Perl as a CGI language is due entirely
to its popularity. There are so many people using it that the
number of Perl libraries is huge, and these libraries are growing
every day. Ready-to-use Perl routines are often included in many
Web server packages. Often, new Internet applications include
Perl gateway routines free of charge.
<P>
There are also numerous support areas; the most important of these
are the newsgroups, comp.lang.perl.misc and comp.lang.perl.announce,
where Perl creator, Larry Wall, has been know to hold court, as
well as many of the other key players in Perl's development and
evolution, such as Tom Christiansen and Randal Schwartz.
<P>
Finally, Perl routines can be viewed as mix and match modules.
Often a Perl script can be used in a new configuration with an
intent that was never meant for the original script. These smaller
scripts can reside quietly in the library waiting to be used for
many other tasks, thus making Perl even more efficient.
<P>
Perl behaves as an interpreted language, which means that it interacts
with the operating system in a more complicated way than a compiled
language like C. This creates a longer processing time than a
compiled language. The trade-off for this loss in speed with Perl
is the ease with which its code can be written and understood.
<H4>C/C++ </H4>
<P>
C is one of the most widely accepted languages in the scripting
world. Even though it is a very difficult language to learn, it
is very powerful. Its difficulties and power both derive from
the same reason-it is a low-level language. Although this makes
C seem positively archaic in its peculiarities, it works very
close to an operating system when it is parsing and processing
code, making it very fast, even when used to create large applications.
<P>
C works directly with the operating system itself, instead of
the processes which often act as an intermediary between a language
and an operating system. This can be seen best when C is run against
interpreted scripts like Korn, Bourne, and Perl, especially when
used in large database programs. The interpreted languages must
operate out of a shell, whereas C does not. This can be very advantageous
to a Web site designer, who does not want to expose his or her
system's operating shell to the outside world.
<P>
Another benefit of C is that it has extensive libraries of procedures,
lots of readily available sample code, debuggers, and support
groups. As the primary language for UNIX development, C is also
secure as far as having a future, as well. Learning C is never
a waste of time.
<P>
Another factor that makes C attractive is that it adds an extra
level of security to a Web server. Because it is compiled, there
is no need to have the source code on your server. The C language
works by being compiled into machine language. It is this machine
language executable that sits on your server, not the original
C script. Any of the three people who are smart enough to figure
out how to modify machine code are not likely to waste their time
trying; they're too busy trying to invent a new organism, or artificial
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -