HTML The Definitive Guide (139 page)

14.2.5 Performance Considerations

Client-pull documents consume extra network resources, especially when the refresh delay is small, since each refresh involves a completely new connection to a server. It may take a browser several seconds to contact the server and begin retrieving the document. As a result, rapid updates generally are not feasible, especially over slow network connections.

Use client-pull dynamic documents for low-frequency updates of entire documents, or for cycling among documents without user intervention.

14.1 An Overview of

14.3 Server -Push Documents

Dynamic Documents

Chapter 14

Dynamic Documents

14.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, not special HTML embedded tags, 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.

14.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-media, 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; the 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 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 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've got 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.

14.3.2 Multipart Mixed-Replace Media Type
Server-push dynamic document authors may also use an experimental variant of the MIME multipart mixed-media content known as
multipart 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.

14.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, perhaps even animation.

Note in particular 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.

14.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) expire 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.

14.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 also 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. You will need to 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 backwards and howl at the moon on certain days.

14.3.4.1 Server-push example application for NCSA and Apache httpd
The NCSA and Apache
httpd
servers run on most Unix systems. Administrators usually configure the server to run server-side applications stored in a directory named
cgi-bin
.

The following is a simple Unix shell script that illustrates how to send a multipart document to a Netscape client via NCSA or Apache
httpd
:[4]

[4] 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 #