📄 ch13.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 13 -- Proprietary Extensions to Severs </TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 13</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Proprietary Extensions to Severs </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="#ServerPush" >Server Push</A>
<LI><A HREF="#HTTpcookies" >HTTP Cookies</A>
<LI><A HREF="#OtherServerExtensions" >Other Server Extensions</A>
<UL>
<LI><A HREF="#WebServer400" >WebServer/400</A>
<LI><A HREF="#ApacheModules" >Apache Modules</A>
<LI><A HREF="#JigsawResources" >Jigsaw Resources</A>
<LI><A HREF="#NetscapeandMicrosoft" >Netscape and Microsoft</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
Behind every good CGI program is a good server, usually an HTTP
server. An HTTP server is a program that intermediates between
the end user (the browser) and the CGI program itself. It is the
server that actually spawns the CGI program, passing along information
from the browser, and it is the server that collects the output
of the CGI program and sends it back to the end user who requested
it.
<P>
At its most basic, that is all a Web server has to do: Be a sort
of halfway house for information between the client and the machine
storing the data. It didn't take long before people started to
realize that the more tricks a server had up its sleeve, the less
work they would have to do with external CGI programs. As a result,
server extensions were born.
<P>
Server extensions are added bits of functionality that are either
built straight into the server or dynamically added to the server
as needed. Either way, they are part of the server. This means
that when a client requests a function from a server, the server
extension is right there. Unlike CGI programs, a server extension
does not require an extra process to be run on the host machine.
<P>
A downside to server extensions is that they are largely proprietary,
meaning that a nifty add-on to the ncSA server might not be present
in the CERN server or vice versa. However, several server extensions
have proven useful enough to be added to many of the most popular
Web servers (which at the time of this writing means Apache, ncSA,
and Netscape).
<P>
I'll start by looking at the two server extensions that are currently
used the most: server push and cookies.
<H2><A NAME="ServerPush"><FONT SIZE=5 COLOR=#FF0000>Server Push</FONT></A>
</H2>
<P>
Server push was first envisioned as a method for displaying simple
animations over the Web. Unfortunately, it's not very good at
it. At the time server push was implemented, it was the only option,
but today Web animations are better served by Java or GIf89a extensions.
Other applications have been found for server push, and its cousin,
client pull, so it remains a useful extension supported by almost
all servers.
<P>
To understand server push, you must first look at how the Web
server handles data before it passes it on to the client. When
asked to retrieve a file from the host, the server first looks
at the extension of the file and based on that, assigns it a MIME
type. MIME (Multipurpose Internet Mail Extensions) types tell
the browser what type of file it is receiving. This is usually
put in the initial header of the document, which the end user
never sees. For example, if you were to Telnet to <TT><FONT FACE="Courier">www.yahoo.com</FONT></TT>
on port 80 (the HTTP port), and type <TT><FONT FACE="Courier">GET
/ HTTP/1.0</FONT></TT>, you would receive Yahoo's home page with
the following information attached to the beginning:
<BLOCKQUOTE>
<TT><FONT FACE="Courier">HTTP/1.0 200 OK<BR>
Last-Modified: Thu, 25 Jul 1996 21:45:35 GMT<BR>
Content-Type: text/html<BR>
Content-Length: 5490</FONT></TT>
</BLOCKQUOTE>
<P>
The first line tells the browser what version of the HTTP protocol
Yahoo's server is using; the OK indicates it found the requested
document. The second line gives the date the document was last
modified, and the last line gives the size of the document in
bytes. The third line, <TT><FONT FACE="Courier">Content-type:
text/html</FONT></TT>, tells the browser to expect an HTML document
and treat it accordingly. It is this content type header that
makes server push possible.
<P>
As intimated by the acronym, MIME was originally designed as a
set of protocols to enable electronic mail to contain full multimedia
enhancements. In fact, most modern mail clients do support MIME,
but its usefulness has grown beyond that. One of the necessities
of transferring multimedia mail is the capability to enclose several
different types of documents in one message. MIME does this through
a content type called multipart/mixed. A document of this type
has a string of characters given in the header known as the boundary.
This boundary can occur any number of times in the message, each
time preceded by <TT><FONT FACE="Courier">--</FONT></TT>. Each
section of document between boundaries is considered a separate
message with its own MIME type.
<P>
In 1995, some smart folks at Netscape, Inc., thought of a way
to put a twist on the multipart/mixed MIME type that would allow
animations to be displayed over the Web. A new MIME type was created:
multipart/x-mixed-replace. The x means that it's an extra type
that is not part of the official MIME specification. The replace
part is the key. This means that instead of one message with lots
of different types, a multipart/x-mixed-replace message is really
lots of separate messages all with the same type. As each message
is displayed, it replaces the one before it. When applied to a
MIME type such as image/gif, this multipart/x-mixed-replace causes
one GIF to be displayed and then replaced by another and so on.
Voilà! Instant "poor man's animation."
<P>
Because the key to server push lies in the header that appears
before the document is sent, you can't use server push within
a plain HTML document. You must use a CGI program to generate
the document and send each part along as needed.
<P>
One of the great advantages of server push is that as long the
browser remains on the page, the server can keep the connection
open as long as it wants. Suppose you want to keep users around
the world up-to-date on the local softball game. Using server
push, a connection is kept open between your server and each viewer,
and you could send an updated score whenever necessary.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
The advantage of a persistent connection can also be a disadvantage. Having a server keep the connection open keeps the server's process alive, which could cause added load to your system. This is usually not a problem, but if you get thousands of hits a
day, it does add up.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
For a simple example, you can go back to the original purpose
of server push and make a poor man's animation. I'll use Perl
for these examples, although this first one is simple enough for
Bourne Shell. I start by cycling through a series of GIFs (assumed
to be in the current directory and named <TT><FONT FACE="Courier">0.gif</FONT></TT>
through <TT><FONT FACE="Courier">9.gif</FONT></TT>):
<BLOCKQUOTE>
<TT><FONT FACE="Courier">#!/usr/local/bin/perl -Tw<BR>
<BR>
use strict; # The -Tw flags and "use strict" are always
useful for<BR>
# keeping CGIs safe.<BR>
<BR>
print <<EOP; # Print the HTTP header<BR>
Content-type: multipart/x-mixed-replace;boundary=I_Like_Snow<BR>
<BR>
EOP<BR>
for $i (0..9) {<BR>
print "--I_Like_Snow\n"; # Print
boundary to start new image.<BR>
print "Content-type: image/gif\n\n";
# Tell client that it's a GIF<BR>
open (GIF, "$i.gif"); #
<BR>
while (<GIF>) { print; } # Send
the GIF.<BR>
close GIF;
#<BR>
}<BR>
<BR>
print "--I_Like_Snow--\n"; # Tell client that you're
done.<BR>
</FONT></TT>
</BLOCKQUOTE>
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Tip</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
It might be necessary to read the documentation that came with your server before running these examples. Some servers have trouble with certain aspects of server push. Notably, ncSA httpd has been known to have fits if the HTTP header isn't exactly
right.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
Label this script as a CGI program (for example, <TT><FONT FACE="Courier">cycle.cgi</FONT></TT>)
and then insert the tag <TT><FONT FACE="Courier"><IMG SRC="cycle.cgi"></FONT></TT>
into any HTML file in the same directory, and suddenly you have
a full-blown animation accessible from the Web. As it stands,
this script pushes the GIFs to the client as fast as it can. Because
most people use 14.4Kbps modems or live far away from your server,
this rapid pushing guarantees that the end user receives the animations
as quickly as possible. This also means that people using a good
connection might receive the images too fast to display and could
skip images. You can avoid this by using sleep statements in strategic
parts of the script to pause between images. Using sleep statements
is also a good way to create slide-show-type animations. You could
cause each image to stay on the screen for however long is necessary
before the next image is called up.
<P>
As mentioned previously, you can also use server push to create
an HTML document that updates itself as needed. As long as the
client stays on the page, it receives the new information; as
soon as the client leaves the page, the connection is broken and
no more information is sent. For an example of this, consider
the script in Listing 13.1, which displays the users currently
logged into a UNIX machine and updates the display every time
someone logs in or out.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Listing 13.1 makes heavy use of the <TT><FONT FACE="Courier">system()</FONT></TT> function so it must be run from a UNIX machine with the necessary commands. You probably need to change it somewhat for your system to reflect the location and differences in
syntax of the commands.
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<HR>
<BLOCKQUOTE>
<B>Listing 13.1. Dynamically display current users.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">#!/usr/local/bin/perl -Tw<BR>
<BR>
print <<EOP; # Print the HTTP header<BR>
Content-type: multipart/x-mixed-replace;boundary=I_Like_Snow<BR>
<BR>
EOP<BR>
<BR>
LOOP:<BR>
while (1) { # Perform an endless loop.
We leave it up to the client<BR>
#
to break the connection.<BR>
open(WHO,
"w|"); # Run the 'w' command to list users.
<BR>
my @who
= <WHO>; # Collect the result in an array.<BR>
close WHO; #
Close the command.<BR>
<BR>
my $i; #
Dummy variable<BR>
foreach
$i (2..$#who) { # Start at the third line of output.<BR>
#
The first two are other information.<BR>
my
@fields = split(/ +/, $who[$i]); # Get the user name.<BR>
push(@users2,
$fields[0]); # Add it to list of<BR>
# current users.<BR>
}<BR>
foreach $user2 (@users2) {<BR>
# If any of the
current users were not present last<BR>
# time through,
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -