📄 ch7.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 7 -- Sever-Side Inducles (SSI) and Gateways</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 7</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Sever-Side Inducles (SSI) and Gateways</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#WhatAreServerSideIncludesandWhat" >What Are Server-Side Includes, and What Are They Useful For?</A>
<LI><A HREF="#ComparisonofSSIandCGIs" >Comparison of SSI and CGIs</A>
<LI><A HREF="#WhichServersSupportSSI" >Which Servers Support SSI?</A>
<UL>
<LI><A HREF="#Cern" >Cern</A>
<LI><A HREF="#Apache" >Apache</A>
</UL>
<LI><A HREF="#AListofUsefulSSIDirectives" >A List of Useful SSI Directives</A>
<LI><A HREF="#SomeSSIExamples" >Some SSI Examples</A>
<UL>
<LI><A HREF="#Counter" >Counter</A>
<LI><A HREF="#RandomImageGenerator" >Random Image Generator</A>
</UL>
<LI><A HREF="#TheProtocoloftheWebHTTP" >The Protocol of the Web: HTTP</A>
<LI><A HREF="#GatewaysAccessingOtherProtocolsthro" >Gateways: Accessing Other Protocols through the Web</A>
<LI><A HREF="#ImprovingExistingGateways" >Improving Existing Gateways</A>
<LI><A HREF="#SomeGatewayExamples" >Some Gateway Examples</A>
<UL>
<LI><A HREF="#finger" >finger</A>
<LI><A HREF="#FormbyMail" >Form-by-Mail</A>
</UL>
<LI><A HREF="#UsingtheWebasaStandardInternetAcc" >Using the Web as a Standard Internet Access Interface</A>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
This chapter covers the use of <I>server-side includes</I> (commonly
known as <I>SSI</I>) and World Wide Web <I>gateways</I>, which
are special purpose programs that perform some actions and output
results in HTML. We discuss how to improve prewritten gateways
and how to develop custom gateways for your own use.
<P>
Both techniques enable Web developers to go beyond normal static
HTML pages. SSI is a simple mechanism of dynamically creating
Web pages in which the information changes every time the page
is requested.
<P>
A <I>gateway</I> is a program that gathers and converts information
from different sources so that it can be used by a person or another
program. A Web gateway is a program that converts information
so that a Web browser can display it. These special programs can
be written in virtually any computer language and can handle tasks
as simple as converting finger information or as complex as talking
to a mail server or handling database queries. One could imagine
many ways for servers and gateways to communicate, but the <I>Common
Gateway Interface (CGI)</I> arose as the standard mechanism for
information exchange between Web servers and other programs.
<P>
In fact, both techniques allow the Web to be a complete platform
for presenting information of different natures. It may be static
images, video,<I> </I> or text, but also information originating
from other Internet tools or services. Everything is integrated
in a more dynamic and interactive way! By using SSI and gateways,
the Web becomes the major platform for accessing the Internet.
The Web expansion figures prove it already! The following list
shows the number of estimated WWW hosts on the Internet (figures
provided by Network Wizards, <TT><FONT FACE="Courier"><A HREF="http://www.nw.com/">http://www.nw.com/</A></FONT></TT>):
<UL>
<LI><FONT COLOR=#000000>January 1995: 3016</FONT>
<LI><FONT COLOR=#000000>January 1996: 75743</FONT>
</UL>
<H2><A NAME="WhatAreServerSideIncludesandWhat"><FONT SIZE=5 COLOR=#FF0000>What
Are Server-Side Includes, and What Are They Useful For?</FONT></A>
</H2>
<P>
<I>Server-side includes (SSI)</I> define a special set of tags
(also called <I>directives</I>) that can be embedded in the HTML
source of documents and are preprocessed by the Web server before
they are sent to the client, the Web browser. Think of SSI as
special bits of programs (or, more correctly, the names of programs)
embedded in HTML pages. Instead of sending just the source of
the page, the Web server searches for these special tags, executes
the code it finds, replacing the tag with the output of the program,
and then finally sends the page to the Web browser. The SSI tags
are never sent to the browser and are always replaced by data
(in some cases, data may be empty).
<P>
The format of an SSI tag or directive is
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><!--#command argument="value"--></FONT></TT>
</BLOCKQUOTE>
<P>
where
<UL>
<LI><TT><FONT FACE="Courier"><!--</FONT></TT> and <TT><FONT FACE="Courier">--></FONT></TT>
delimit the start and end of the SSI tag
<LI><TT><FONT FACE="Courier">command</FONT></TT> is the action
to be performed (see list later in this section)
<LI><TT><FONT FACE="Courier">argument</FONT></TT> is the argument
passed to the action specified
</UL>
<P>
Each tag corresponds an action executed directly by the server
or by a program the server must call.
<P>
Notice that the SSI tag starts with <TT><FONT FACE="Courier"><!--</FONT></TT>
and ends with <TT><FONT FACE="Courier">--></FONT></TT>, as
do comments embedded in HTML pages. This design decision allows
for servers and clients to ignore the tag if SSI functionality
is not used. If the Web server allows SSI functionality, it parses
the document and replaces any SSI tag by the output of the corresponding
program, leaving other comments as they are.
<P>
See the list of possible SSI tags later in this chapter, in the
section "A List of Useful SSI Directives."
<P>
The difference between SSI and, for example, Java or JavaScript
is that the program code is executed on the server side instead
of the client side. There has been a lot of discussion on whether
strategy is better, but both have their own qualities and pitfalls.
The main advantages of this SSI approach follow:
<UL>
<LI><FONT COLOR=#000000>You don't have to worry about the client
computational power. From the browser's point of view, the received
page is a common and simple HTML page.</FONT>
<LI><FONT COLOR=#000000>You may use the tools available on your
server (such as databases, random image libraries, and so on)
and provide cross-platform, content-rich pages.</FONT>
</UL>
<P>
As you may have guessed, there are some disadvantages, too:
<UL>
<LI><FONT COLOR=#000000>You need to have a more powerful Web server
platform than the one you need without SSI. Special care should
be taken if you plan to have many hits on your pages because it
can quickly overload your server, especially if the programs executed
are CPU hungry and most of your pages are checked for SSI tags.</FONT>
<LI><FONT COLOR=#000000>If you have other users providing content
using your Web server, you may want to either disable SSI or find
a way to protect yourself from bad behavior programs that can
be a real security problem.</FONT>
</UL>
<P>
The bottom line is that you should use SSI when and where you
really need it. Lots of times, SSI is the most suited solution
for a given problem, but sometimes there may be a better way to
do things.
<P>
Well, this all seems fine, but what are server-side includes useful
for? Server-side functionality in general and server-side includes
in particular allow applications as simple as a visitor counter
or as complex as a database query to be displayed inside an HTML
page.
<P>
Although SSI allows the embedding of the output of lots of different
programs or actions in a page, the most commonly used programs
produce the following results:
<UL>
<LI><FONT COLOR=#000000>Visitor counter: Haven't you ever seen
something like "You are the 44811th visitor of this page"?</FONT>
<LI><FONT COLOR=#000000>Date or time: A very simple clock or calendar
can be built this way.</FONT>
<LI><FONT COLOR=#000000>Last modified: "This page was last
updated on 15 May 1996."</FONT>
<LI><FONT COLOR=#000000>Random image generator: This allows for
random advertisements on a Web page. Read the section "Some
SSI Examples" later in this chapter for an example of a random
image generator.</FONT>
<LI><FONT COLOR=#000000>Custom footer: The navigation buttons
on the bottom or top of a page are generally included from a separate
file by using an SSI directive</FONT>.
</UL>
<H2><A NAME="ComparisonofSSIandCGIs"><FONT SIZE=5 COLOR=#FF0000>Comparison
of SSI and CGIs</FONT></A></H2>
<P>
SSI applications are, in fact, special purpose programs that run
on the server side in order to produce a Web page (or part of
it, really) before it is sent to a browser. CGI is an interface
specification designed to allow Web servers and other programs
to interact. It defines what the program should expect as information
from the server and what and how it should send data to the Web
server.
<P>
SSI does not require (but can make use of) any external interface
and is generally easier to implement than CGI or other proprietary
solutions (by the use of a proprietary Application Programming
Interface (API), for example). For example, SSI programs do not
receive input through the stdin (standard input), as do CGI scripts
(when the <TT><FONT FACE="Courier">POST</FONT></TT> method is
used). Just think of SSI applications as programs that do not
need to worry about the context in which they are running and
that just need to output the correct results.
<P>
The common characteristic between SSI and CGIs is that both are
techniques for server-side execution, and most of the time the
computer language used to produce CGI and SSI programs is the
same. Remember Perl? Being a Perl addict, most of the SSI programs
I develop myself are done with this language. But, sometimes,
when speed of execution or server overload becomes an issue, we
should consider alternatives, preferably compiled languages (not
interpreted) such as C.
<P>
Also, when viewing a document source, you don't generally notice
SSI, but you notice CGI script calls. When the browser receives
the page, every SSI tag has been replaced by the corresponding
action output; however, CGI script calls stay as they are because
the script is still going to be executed, generally by pressing
a form submit button.
<H2><A NAME="WhichServersSupportSSI"><FONT SIZE=5 COLOR=#FF0000>Which
Servers Support SSI?</FONT></A></H2>
<P>
Most modern Web servers support SSI, but I will cover only two
of them: Apache and CERN.
<P>
The reason for this choice is that both servers are freely available
to everyone and are used in many Web server platforms around the
world.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Tip</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
You can find lots of statistics about Web servers' usage at <TT><FONT FACE="Courier"><A HREF="http://www.netcraft.com/survey/">http://www.netcraft.com/survey/</A></FONT></TT>
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
In fact, it was the ncSA HTTPD that first introduced the SSI feature.
This section covers the use of SSI on the Apache and CERN server,
but most of the principles apply to other servers, as well (at
least ncSA and Sioux, two near cousins of Apache). Apache is,
according to the latest figures, the most used Web server in the
world and was created as an evolution of ncSA. The CERN server
was created in the birthplace of the Web, the CERN (European Center
for Nuclear Physics Research) laboratory in Geneva, Switzerland.
<P>
The CERN server, one of the oldest around, now called W3 server,
does not support SSI. But there is a way around this, as with
everything in computer science, called <TT><FONT FACE="Courier">fakessi</FONT></TT>.
<TT><FONT FACE="Courier">fakessi</FONT></TT> is a special script
in Perl (we could imagine it in C or another language) that works
alongside the CERN server and provides the SSI functionality.
Although limited in features and more performance demanding, this
is a nice script that could help many people still using this
server.
<P>
Not only do you have to have a Web server that supports SSI, you
must also configure it accordingly. It is up to the Webmaster
to decide whether or not to support SSI, even if the server used
supports the feature. In particular, the Webmaster must decide
which documents are parsed and which ones are not. <I>Parsing</I>
is the action of searching through a file (HTML in this case)
for the SSI directives. Sure, you can configure your server to
parse every page sent, but this is not generally a good idea because
it overloads a server considerably. A common configuration is
to name the files that will be parsed with the .shtml extension
and tell the server to parse only these. Normal .html files will
not be parsed this way. The Apache server introduced a new trick
that consists of turning on the x bit for the file you want to
parse (make the file an executable by turning on the x bit with
the <TT><FONT FACE="Courier">chmod 700</FONT></TT> command on
UNIX platforms). This way, you can let all your normal files have
the .html extension and turn on the x bit for those you want to
parse for SSI directives. I personally prefer the second solution
because there is no need to worry about different file extensions
(and, consequently, new MIME types), but either solution is better
than letting the server parse all your .html files!
<H3><A NAME="Cern">Cern</A></H3>
<P>
The CERN server does not originally support the use of SSI. A
way around this is to use a program sitting alongside the server
that parses the pages itself but asks the server to send them
to the client. So, you must also tell the server to pass the files
to this program before sending them to the client.
<P>
There are several scripts available on the Internet to allow the
use of SSI with the CERN server, but one of the most used is called
<TT><FONT FACE="Courier">fakessi.pl</FONT></TT>, a Perl script
that you can find at <TT><FONT FACE="Courier"><A HREF="http://sw.cse.bris.ac.uk/WebTools/fakessi.html">http://sw.cse.bris.ac.uk/WebTools/fakessi.html</A>></FONT></TT>.
<P>
Here are the steps for installing <TT><FONT FACE="Courier">fakessi.pl</FONT></TT>:
<OL>
<LI>Make sure you have Perl (version 4 is sufficient) installed
on your system.
<LI>Download the script from the URL shown previously.
<LI>Put it on your <TT><FONT FACE="Courier">cgi-bin</FONT></TT>
directory and make it an executable. Edit it in order to enter
the Perl binary, <TT><FONT FACE="Courier">cgi-bin</FONT></TT>
directory, and document root path.
<LI>Edit your <TT><FONT FACE="Courier">httpd.conf</FONT></TT>
file and add the following directive: <TT><FONT FACE="Courier">Exec
/*.shtml /cgi-bin/fakessi.pl</FONT></TT>. Reload your server configuration
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -