HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

where String is a string of ASCII characters used as the separator between the different parts of the message. This string of characters must consist only of letters (a–z, A–Z) and numbers (0–9), and it must not appear anywhere within the message parts being sent. This ensures that the software receiving the data will not detect the string within a part of the message and prematurely end the message part. The general format for this MIME message type is shown in Figure 11.1.

Note how the boundary between different parts of the multipart message are denoted by the string SpecialAsciiString preceded by two dashes, that is:

--SpecialAsciiString

The end of the message is denoted by the same string but with two additional trailing dashes:

--SpecialAsciiString--

In practice, you can leave out this termination string and send an unending sequence of messages. A user can end this sequence by selecting the browser’s “Stop” button, or by explicitly selecting an alternate URL.

Figure 11.1 Structure of a multipart/x-mixed-replace MIME message. Here, SpecialAsciiString represents the string of ASCII characters used as the the separator between message parts, and type/subtype is the data type of the data being sent. Comments are in italics.

Content-type: multipart/x-mixed-replace;boundary=SpecialAsciiString
                         [blank line, containing a CRLF pair    ]
--SpecialAsciiString     [marker denoting boundary between parts]
Content-type: type/subtype
   [blank line, containing a CRLF pair ]
.... content of first chunk ....
.... and more content ....
--SpecialAsciiString
Content-type: type/subtype
   [blank line, containing a CRLF pair ]
.... content of second chunk ....
.... and more content ....
--SpecialAsciiString
Content-type: type/subtype
   [blank line, containing a CRLF pair ]
.... content of third chunk ....
.... and more content ....
--SpecialAsciiString
.
.
. [and so on... any number of parts can be present...]
.
--SpecialAsciiString--   [The end of the multipart message ]

The following two gateway program examples illustrate how server-push works.

Example 25: A Simple “Server-Push” Shell Script

This simple shell script, listed in Figure 11.2, repeatedly returns a document listing the “top” process running on the computer.

This first thing to note is that this is a non-parsed header script—this is usually necessary with server-push, as many servers buffer the data returned from a gateway program, and only forward data when the buffer is full or when the gateway program stops running. Here, however, we want each part of our multipart message to be immediately delivered to the client. We ensure this by using a non-parsed header script, which bypasses the server buffering and dumps data directly down the port to the client.

As a result, lines 2 through 6 return all the required HTTP response headers, namely, the status header (response 200, implying success), the date (the format instructions provide a date in the correct format), the server type (obtained from the environment variable), and the MIME version, followed by the content-type declaration for the type multipart/x-mixed-replace. In this example, the multipart boundary string is a11pRf5fgFd1dr. Note that there are no space characters in this content-type header. Ordinarily, you can have spaces before and after the semicolons separating the type/subtype from the associated parameters, but this is incorrectly processed by some servers (in particular, early versions of the NCSA HTTP server), so it is safest to remove all unnecessary whitespace. Finally, line 7 returns a blank line, which indicates the end of server directives and the start of the data being returned to the client.

Figure 11.2 The Bourne shell script nph-top-list.sh, which returns a list of the top 10 processes running on the computer every 10 seconds. Line numbers are in italics.

1  #!/bin/sh
2  echo “HTTP/1.0  200 OK”                # [ Server 
3  date -u ‘+Date: %A, %d-%b-%y %T GMT‘   #   Response   4  echo Server: $SERVER_SOFTWARE          #   Headers ]
5  echo MIME-Version: 1.0
6  echo “Content-type: multipart/x-mixed-replace;boundary=a1lpRf5fgFd1dr”
7 echo “”
8  echo “--a1lpRf5fgFd1dr”      # [initial boundary for first part]
9       while true
10      do
11      echo “Content-type: text/html”
12      echo “”
13      echo “>>”
14      echo “> Top Running Processes >>>”
15      echo “> Top Running Processes at time: >”
16      date                    # [prints the current time and date]
17      echo “>>”
18      echo “>”
19      /usr/local/bin/top -d1  # [Print out “top” running processes]
20      echo “>>>”
21      echo echo “--a1lpRf5fgFd1dr”
22      sleep 10
23  done

Line 8 prints the first boundary marker—this indicates the start of the first part of the message. The script then executes a loop, starting from line 10, which is executed every 10 seconds (see the sleep 10 command at the bottom of the loop). The loop returns a content-type header (here text/html) followed by a blank line—the mandatory blank line marks the end of the headers and the beginning of the data. This is followed by the HTML document which includes, inside a PRE, the output from the program top. The last thing returned is the boundary marker “--a1lpRf5fgFd1dr ” that tells the client that the message is complete and that it can stop waiting for more data. It also tells the client to keep the connection to the server open, in anticipation of the next part of the message.

This program will in principle run forever, sending information every 10 seconds. A user can interrupt this by simply pressing the “Stop” button, or by selecting another URL. The server should detect the broken connection and issue a kill signal to the gateway program. Unfortunately, this does not work on some servers, so it is a good idea to have gateway programs check for a broken connection and gracefully quit if this has occurred. Shell languages, such as the Bourne shell used in this example, are notoriously bad at this—they often “forget” to die—so you should write server-push scripts in languages such as perl or C, which properly terminate when the connection breaks. The script in Figure 11.2, for example, does not always terminate when the client breaks the connection—this has, on occasion, left a dozen of these scripts happily running on our server, long after the browser that started them has broken the connection to the server.

Example 26: A C Program for “Pushing” Images

The example C program nph-doit-2, shown in Figure 11.3, uses server-push to send a sequence of GIF images. Assume that this CGI program is located in the server’s cgi-bin/ directory. Then, to insert an animated image in an HTML document, you would write the following HTML markup:

<IMG SRC=“/cgi-bin/nph-doit2”>