📄 ch13.htm
字号:
"$_ Whatzit: ${$_} \@ \$$whatzit{$_} ea. = \$$subtotal<br>";
<BR>
<BR>
#
Add them all up for the total.<BR>
$total += $subtotal;<BR>
}<BR>
}<BR>
# Say bye bye!<BR>
print <<EOP;<BR>
<hr><BR>
Your total is \$$total<BR>
<hr><BR>
Have a nice day!<BR>
</body></html><BR>
EOP<BR>
die;<BR>
}<BR>
<BR>
<BR>
# If the user isn't checking out, we send them a new cookie and
resend<BR>
# the form so they can choose more Whatzitses to buy.<BR>
print <<EOP;<BR>
Content-type: text/html<BR>
Set-cookie: $id=$cstring; expires=$date; path=/~me/; domain=my.isp.com
<BR>
<BR>
<HTML><HEAD><TITLE>The Whatzit Emporium!</title></head><BODY>
<BR>
<H1 ALIGN=CENTER>The Whatzit Emporium</h1><BR>
<p>We hope you are enjoying your visit. If you have any
questions please<BR>
feel free to ask one of our helpful associates.<BR>
<BR>
<p>To add a Whatzit to your cart, simply click on the 'Pick
Me!' button<BR>
next to it. When you are ready to leave, simply click on the 'Check
Out!'<BR>
button on the bottom of the screen.<BR>
<BR>
<p><BR>
<UL><BR>
EOP<BR>
<BR>
# As we print out the form, we tell the user how many Whatzitses
they have<BR>
# in their cart.<BR>
foreach (keys %whatzit) {<BR>
print <<EOP;<BR>
<LI><INPUT TYPE="SUBMIT" NAME="$_"
VALUE=" Pick Me! "> $_ Whatzit<BR>
\$$whatzit{$_}<BR>
EOP<BR>
if (${$_}) {<BR>
print "<BR>(
You currently have ${$_} $_ Whatzitses\n";<BR>
}<BR>
}<BR>
<BR>
# Give the user the option to check out.<BR>
print <<EOP;<BR>
<hr><BR>
<INPUT TYPE=SUBMIT NAME="Checkout" VALUE=" Check
Out! "><BR>
</form></body></html><BR>
EOP</TT>
</BLOCKQUOTE>
<HR>
<P>
The preceding example is about as simple as it gets for shopping
carts. All the items are on one page. There is no mechanism for
removing items from the cart or for buying multiple items at once.
These topics are covered more in <A HREF="ch23.htm" >Chapter 23</A>,
"Shopping Carts." The point here is showing what can
be done with cookies. The only data you passed through the HTML
form is the most recent addition to the cart. Yet, through using
cookies, you were able to remember every single past addition
the user had ever made. If the user were to turn off his computer
and come back an hour later, the data would still be there. You
chose to make the cookie expire after three hours, but that is
completely arbitrary. However, in the interest of good manners,
you should set your cookies to expire as soon as they are not
needed, so they won't clutter up the user's hard drive.
<P>
Cookies have many other uses as well. In lieu of image-based counters,
some sites have begun keeping track of hits by sending each visitor
a cookie. Keeping track of this data, however, requires a modification
to the server, or each page must be CGI generated to receive the
cookie information.
<H2><A NAME="OtherServerExtensions"><FONT SIZE=5 COLOR=#FF0000>Other
Server Extensions</FONT></A></H2>
<P>
Although cookies and server push get the most press, many other
extensions are written for servers. Most are proprietary to one
server or another, and some require the browser to have special
capabilities as well, but all are useful, one way or another,
in extending the capabilities of ordinary CGI.
<H3><A NAME="WebServer400">WebServer/400</A></H3>
<P>
An extreme example of what can be done with a Web server is the
WebServer/400 from I/Net (<TT><FONT FACE="Courier">http://www.inetmi.com/products/webserv/webinfo.htm</FONT></TT>).
This is a server that runs only IBM AS/400 mainframes and uses
them to unique advantage. The AS/400 is usually run through TN/3270
terminals with no graphics capabilities. This means that the interface
to any AS/400 program is easily reproducible on the Web. WebServer/400
allows this, in a sense making <BR>
every program on the mainframe a CGI program. Input fields in
the program are translated to HTML forms and the data is passed
through the program to create new forms with the results. The
entire machine can be run from a Web browser.
<H3><A NAME="ApacheModules">Apache Modules</A></H3>
<P>
The Apache server is a freely available Web server for UNIX that
has swiftly become the most widely used server on the Web. At
last count, 34 percent of all Web sites were using Apache as a
server. The most recent versions of Apache have introduced a feature
called modules that should make server extensions much more common
in the future. Modules are server extension that are loaded into
the server while it's running and used as they are needed. This
takes up less memory than keeping them in the server all the time,
and it is faster than calling an external CGI program. Apache
itself comes with several modules, and many more are available
in the public domain. I'll discuss the ones that bear a direct
relationship with CGI programming in the following sections.
<H4>XSSI</H4>
<P>
XSSI (Extended Server-Side Includes) was developed by Howard Fear
as an enhanced version of the server-side includes provided by
Apache HTTPD. A server-side include is part of the HTML document
that is parsed before being sent to the client. XSSI provides
several capabilities previously only accessible through CGIs,
such as simple if-then-else flow control and access to all environment
variables set by the client. Using XSSI, a page could detect which
type of browser is calling it and display HTML accordingly. More
information on XSSI is available at <TT><FONT FACE="Courier"><A HREF="ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html">ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html</A></FONT></TT>.
<H4>mod_rewrite</H4>
<P>
<TT><FONT FACE="Courier">mod_rewrite</FONT></TT> is a module that
intercepts the URL sent from the client and rewrites it based
on a set of regular expressions. This is similar to the concept
of URL aliases provided by most servers but takes it one step
further. The incoming URL can be mapped to any other URL on the
host machine. <TT><FONT FACE="Courier">mod_rewrite</FONT></TT>
was written by Ralf S. Engelschall and is available at <TT><FONT FACE="Courier"><A HREF="http://www.engelschall.com/sw/mod_rewrite/">http://www.engelschall.com/sw/mod_rewrite/</A></FONT></TT>.
<H4><TT><FONT SIZE=4 FACE="Courier">mod_perl</FONT></TT></H4>
<P>
<TT><FONT FACE="Courier">mod_perl</FONT></TT>, written by Doug
MacEachern, is a fully functional Perl interpreter linked dynamically
to Apache, which cuts downs on the startup cost of launching Perl
for each CGI request. <TT><FONT FACE="Courier">mod_perl</FONT></TT>
allows you to write your own server extensions in Perl and dynamically
link them to Apache. You can find information on <TT><FONT FACE="Courier">mod_perl</FONT></TT>
at <TT><FONT FACE="Courier"><A HREF="http://www.osf.org/~dougm/apache/">http://www.osf.org/~dougm/apache/</A></FONT></TT>.
<H4><TT><FONT SIZE=4 FACE="Courier">CGI_SUGid</FONT></TT> and
<TT><FONT SIZE=4 FACE="Courier">suCGI</FONT></TT></H4>
<P>
One of the biggest hurdles in programming CGI is that all CGI
programs are run as the user of the Web server (usually user "nobody").
Without this, security would be hard to maintain, but it also
means that CGI programs can only write to directories that are
world writeable. This makes interfacing with flat-file databases
rather difficult. If the database is world writeable, any user
on the host machine can change or delete the database at any time.
If it's not, the CGI program can't modify it.
<P>
<TT><FONT FACE="Courier">CGI_SUGid</FONT></TT> and <TT><FONT FACE="Courier">suCGI</FONT></TT>
are attempts to remedy this. These modules are installed in Apache
as a replacement for the default CGI handler (<TT><FONT FACE="Courier">mod_cgi</FONT></TT>).
When a CGI program is called, it checks the owner of the program
and executes the CGI as that owner. This way, CGI programs owned
by you are run as you, allowing them write access to your directories
while preserving security for the machine as a whole. <TT><FONT FACE="Courier">CGI_SUGid</FONT></TT>
was written by Philippe Vanhaesendonck and is available at <TT><FONT FACE="Courier"><A HREF="http://linux3.cc.kuleuven.ac.be/~seklos/mod_cgi_sugid.c">http://linux3.cc.kuleuven.ac.be/~seklos/mod_cgi_sugid.c</A></FONT></TT>.
<TT><FONT FACE="Courier">suCGI</FONT></TT> is by Jason A. Dour
and is available at <TT><FONT FACE="Courier"><A HREF="http://www.louisville.edu/~jadour01/mothersoft/apache/">http://www.louisville.edu/~jadour01/mothersoft/apache/</A></FONT></TT>.
<H4>WebCounter</H4>
<P>
Web counters are a hot commodity right now; everybody wants one.
This popularity is despite the fact that they are horribly unreliable
and that the odometer motif was cute for about one second. The
WebCounter module is an attempt to rectify the "horribly
unreliable" part. Having the server itself keep a count of
how many times each page is hit is much more efficient than CGI
programs that count hits to graphics (which, of course, ignore
hits from text browsers or browsers with images turned off). WebCounter
was written by Brian Kolaci and is available from <TT><FONT FACE="Courier"><A HREF="ftp://ftp.galaxy.net/pub/bk/webcounter.tar.gz">ftp://ftp.galaxy.net/pub/bk/webcounter.tar.gz</A></FONT></TT>.
<H4>NeoWebScript</H4>
<P>
NeoWebScript is similar in concept to XSSI in that it allows basic
scripting to be done within the HTML file itself. It takes a different
approach, however. Instead of embedding the scripting commands
in SSI-style includes, NeoWebScript commands are separated from
the HTML by comment tags but otherwise resemble full scripts (as
in JavaScript). NeoWebScript's language is based on Safe TCL,
which in turn is based on TCL. With the recent announcement that
Sun Microsystems is going to push TCL (and its graphical extension,
Tk) as a companion to Java and the planned support of TCL/Tk in
most major browsers (including Netscape), a server-side TCL interpreter
provides a very useful complement to client-side implementations.
More information on NeoWebScript is available at <TT><FONT FACE="Courier"><A HREF="ftp://ftp.neosoft.com/pub/tcl/neowebscript/">ftp://ftp.neosoft.com/pub/tcl/neowebscript/</A></FONT></TT>.
<P>
These are just some of the modules that extend the capabilities
of the Apache server. An extremely useful list of modules for
Apache is maintained by Zyzzyva Enterprises at <TT><FONT FACE="Courier"><A HREF="http://www.zyzzyva.com/server/module_registry">http://www.zyzzyva.com/server/module_registry</A></FONT></TT>.
<H3><A NAME="JigsawResources">Jigsaw Resources</A></H3>
<P>
Jigsaw is a new HTTP server created by the World Wide Web Consortium
(W3C). W3C consists of the people who create the Web, as well
as many other entities, and its purpose is to promote the Web
by creating official standards for HTTP and HTML and by writing
cutting-edge software to push the frontiers of the Web.
<P>
The main difference between Jigsaw and all other Web servers in
existence is that Jigsaw is written in Java. The W3C saw Java
as an advantage in terms of portability and extensibility. Java
support is available for all major platforms. Jigsaw has an extension
capability similar to Apache except that the extensions are called
resources rather than modules. Because Java bytecode need only
be compiled once to run on any Java interpreter, Java resources
can easily be added and removed from the server just by telling
Jigsaw the location of the resource class.
<P>
Jigsaw is still under development and has some lingering bugs,
but it looks promising. Unfortunately, no third-party Java resources
have been announced at the time of this writing, but due to Java's
popularity, they should be appearing soon. You can find more information
about Jigsaw at <TT><FONT FACE="Courier"><A HREF="http://www.w3.org/pub/WWW/Jigsaw/">http://www.w3.org/pub/WWW/Jigsaw/</A></FONT></TT>.
<H3><A NAME="NetscapeandMicrosoft">Netscape and Microsoft</A>
</H3>
<P>
The two commercial giants of the Internet, Microsoft and Netscape,
also have their own Web servers. These servers come with their
own proprietary extension APIs, which are covered elsewhere in
this book. (Netscape Server API is covered in <A HREF="ch26.htm" >Chapter 26</A>,
"NSAPI," and Microsoft's Internet Server API is covered
in <A HREF="ch25.htm" >Chapter 25</A>, "ISAPI.")
<H2><A NAME="Summary"><FONT SIZE=5 COLOR=#FF0000>Summary</FONT></A>
</H2>
<P>
The concept of creating extensions to HTTP servers adds whole
new worlds to the capabilities of CGI programming. Open standard
extensions such as server push and cookies allow all servers and
browsers to expand. Server push provides rudimentary animation
abilities and slide-slow features to allow dynamic, near real-time
HTML pages. Cookies allow the end users to store information sent
to them by servers. This information allows servers to keep track
of users' progress and keep state information alive during the
users' visits to the site (and even long after they have left).
<P>
Some extensions, such as the everything-can-be-a-CGI feature of
the WebServer/400, are narrowly specific. Others, such as the
Apache and Jigsaw servers' capability to allow users to add their
own extensions, have the most general appeal.
<P>
As browsers grow more powerful and flashy, the reports of the
imminent death of CGI become more frequent. By adding new functionality
and extending the power of the server side of the equation, CGI
takes on new life and gains even more power to provide true interactivity
on the Web.
<P>
<HR WIDTH="100%"></P>
<CENTER><P><A HREF="ch12.htm"><IMG SRC="pc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="#CONTENTS"><IMG SRC="cc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="index.htm"><IMG SRC="hb.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="ch14.htm"><IMG
SRC="nc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A></P></CENTER>
<P>
<HR WIDTH="100%"></P>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -