13.3 Server -Push Documents
Server-push dynamic documents are
driven from the server side. The client/server connection remains
open after an initial transfer of data, and the server periodically
sends new data to the client, updating the
document's display. Server-push is made possible by
some special programming on the server side and is enabled by the
multipart/mixed-media type feature of Multipurpose Internet Mail
Extensions (MIME), the computer industry's standard
for multimedia document transmission over the Internet.
Server-push documents currently are not supported by Internet
Explorer.
13.3.1 The Multipart/Mixed Media Type
As we mentioned earlier in this
chapter, in the discussion of client-pull dynamic documents, the HTTP
server sends a two-part transmission to the client browser: a header
describing the document, followed by the document itself. The
document's MIME type is part of the HTTP header
field. Normally, the server includes "Content-Type:
text/html" in an HTML document's
header before sending its actual contents. By changing that content
type to "multipart/mixed," you can
send an HTML document or several documents in several pieces, rather
than in a single chunk. Only Netscape, though, understands and
responds to the multipart header field; other browsers either ignore
additional parts or refuse the document altogether.
The general
form of the MIME multipart/mixed-media
Content-Type header looks like this:
Content-type: multipart/mixed;boundary="SomeRandomString"
This HTTP header component tells the Netscape client to expect the
document to follow in several parts and to look for
SomeRandomString, which separates the parts. That
boundary string should be unique and should not appear anywhere in
any of the individual parts. The content of the server-to-client
transmission looks like this:
--SomeRandomString
Content-type: text/plain
Data for the first part
--SomeRandomString
Content-type: text/plain
Data for the second part
--SomeRandomString--
The above example has two document parts, both plain text. The server
sends each part, preceded by our SomeRandomString
document-boundary delimiter (which, in turn, is preceded by two
dashes), followed by the Content-Type field and
then the data for each part. The last transmission from server to
client is a single reference to the boundary string, followed by two
more dashes indicating that this was the last part of the document.
Upon receipt of each part, the Netscape browser automatically adds
the incoming data to the current document display.
You have to write a special HTTP server application to enable this
type of server-push dynamic document one that creates the
special HTTP MIME multipart/mixed header and sends the various
documents separated by the boundary delimiter.
13.3.2 The Multipart/X-Mixed-Replace Media Type
Server-push dynamic document authors
may use an experimental variant of the MIME multipart/mixed media
type known as multipart/x-mixed-replace media.
The difference between this special content type and its predecessor
is that, rather than simply adding content to the current display,
the "replace" version has each
subsequent part replace the preceding one.
The format of the mixed-replace HTTP header is very similar to its
multipart/mixed counterpart; the only difference is in the
Content-Type:
multipart/x-mixed-replace;boundary=SomeRandomString
All other rules regarding the format of the multipart content are the
same, including the boundary string used to separate the parts and
the individual Content-Type fields for each part
of the content.
13.3.3 Exploiting Multipart Documents
It is easy to see how you can use the two special MIME multipart
content types to create server-push dynamic documents. By delaying
the time between parts, you might create an automatically scrolling
message in the Netscape browser window. Or by replacing portions of
the document through the x-mixed-replace MIME type, you might include
a dynamic billboard in your document, or perhaps even animation.
Note that server-push multipart documents need not apply only to HTML
or other plain-text documents. Images, too, are a MIME-encoded
content type, so you can have the HTTP server transmit several images
in sequence as parts of a multipart transmission. Since you may also
have each new image replace the previous one, the result is crude
animation. Done correctly, over a network of sufficient bandwidth,
the effect can be quite satisfying.
13.3.3.1 Efficiency considerations
Server-push documents keep a
connection open between the client and server for the duration of the
dynamic document's activity. For some servers, this
may consume extra network resources and may also require that several
processes remain active, servicing the open connection. Make sure the
server-push process (and, hence, the client/server connection)
expires upon completion or after some idle period. Otherwise, someone
will inadvertently camp on an endlessly cycling server-push document
and choke off other users' access to the server.
Before choosing to implement server-push documents, make sure that
your server can support the added processing and networking load.
Keep in mind that many simultaneous server-push documents may be
active, multiplying the impact on the server and seriously affecting
overall server performance.
13.3.4 Creating a Server-Push Document
Create a special application that
runs with the HTTP server to enable server-push dynamic documents.
The application must create the special MIME
Content-Type header field that notifies the
Netscape browser that the following document comes in several
parts added to or replacing a portion of the current document.
The application must create the appropriate boundary delimiter and
send the Content-Type header and data for each
part, perhaps also delaying transmission of each part by some period
of time. Consult your server's documentation to
learn how to create a server-side application that can be invoked by
accessing a specific URL on the server. With some servers, this may
be as simple as placing the application in a certain directory on the
server. With others, you may have to bend over backward and howl at
the moon on certain days.
13.3.4.1 Server-push example application for NCSA and Apache httpd
The NCSA and Apache httpd servers run on most
Unix and Linux systems. Administrators usually configure the servers
to run server-side applications stored in a directory named
cgi-bin.
The following is a simple shell script that illustrates how to send a
multipart document to a Netscape client via NCSA or Apache
httpd:[3]
[3] It is an idiosyncrasy of
NCSA httpd that no spaces are allowed in the
Content-Type field that precedes your multipart
document. Some authors like to place a space after the semicolon and
before the boundary keyword. Don't do this with NCSA
httpd; run the whole Content-Type
together without spaces to get the server to recognize the
correct multipart content type.
#!/bin/sh
#
# Let the client know we are sending a multipart document
# with a boundary string of "NEXT"
#
echo "HTTP/1.0 200"
echo "Content-type: multipart/x-mixed-replace;boundary=NEXT"
echo "
echo "--NEXT"
while true
do
#
# Send the next part, followed by a boundary string
# Then sleep five seconds before repeating
#
echo "Content-type: text/html"
echo "
echo "<html>"
echo "<head>"
echo "<title>Processes On This Server</title>"
echo "</head>"
echo "<body>"
echo "<h3> Processes On This Server</h3>"
echo "Date:"
date
echo "<p>"
echo "<pre>"
ps -el
echo "</pre>"
echo "</body>"
echo "</html>"
echo "--NEXT"
sleep 5
done
In a nutshell, this example script updates a list of the processes
running on the server machine every five seconds. The update
continues until the browser breaks the connection by moving on to
another document.
We offer this shell script example to illustrate the basic logic
behind any server-push document generator. In reality, you should try
to create your server-side applications using a more conventional
programming language, such as Perl or C. These applications will run
more efficiently and can better detect when the client has severed
the connection to the server.