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.