Section 13.2. Client-Pull Documents
Client-pull documents are relatively easy to prepare. All you need to do is embed a <meta> tag in the header of your HTML or XHTML document. The special tag tells the client browser to display the current document for a specified period of time and then load and display an entirely new one, just as if the user had selected the new document from a hyperlink. (Note that currently there is no way to change just a portion of a document dynamically using client-pull.) [<meta>]
13.2.1 Uniquely Refreshing
Client-pull dynamic documents work with Netscape and Internet Explorer because the browsers respond to a special HTTP header field called Refresh.
You may recall from previous discussions that whenever an HTTP server sends a document to the client browser, it precedes the document's data with one or more header fields. One header field, for instance, contains a description of the document's content type, used by the browser to decide how to display the document's contents. For example, the server precedes HTML documents with the header "Content-type: text/html," whose meaning should be fairly obvious.
As we discussed in Chapter 6, you can add your own special fields to an HTML document's HTTP header by inserting a <meta> tag into its <head>. [<meta>]
The HTTP Refresh field implements client-pull dynamic HTML documents, enabled by the <meta> tag format:
<meta http-equiv="Refresh" content="field value">
The tag's http-equiv attribute tells the HTTP server to include the Refresh field, with a value specified by the content attribute (if any, carefully enclosed in quotation marks), in the string of headers it sends to the client browser just before it sends the rest of the document's content. The browser recognizes the Refresh header as the mark of a dynamic HTML document and responds accordingly, as we discuss in the next section.
13.2.2 The Refresh Header Contents
The value of the content attribute in the special Refresh <meta> tag determines when and how the browser updates the current document. Set it to an integer, and the browser delays that many seconds before automatically loading another document. You may set the content field value to 0, meaning no delay at all. In that case, the browser loads the next document immediately after it finishes rendering the current one, which allows you to achieve some very crude animation effects. [Section 6.8.1]
13.2.2.1 Refreshing the same document
If the Refresh field's content value is just the number of seconds, the browser reloads that same document over and over again, delaying the specified time between each cycle, until the user goes to another document or shuts down the browser.
For example, the browser reloads the following client-pull document every 15 seconds:
<html> <head> <meta http-equiv="Refresh" content="15"> <title>Kumquat Market Prices</title> </head> <body> <h3> Kumquat Market Prices</h3> Kumquats are currently trading at $1.96 per pound. </body> </html>
The financial wizards among you may have noticed that, with some special software tricks on the server side, you can update the price of kumquats in the document so that it acts like a ticker-tape machine, with the latest kumquat commodity price updated every 15 seconds.
13.2.2.2 Refreshing with a different document
Rather than reloading the same document repeatedly, you can tell the browser to load a different document dynamically. You do so by adding that document's URL after the delay time and an intervening semicolon in the <meta> tag's content attribute. For example:
<meta http-equiv="Refresh" content="15; URL=http://www.kumquat.com/next.html">
would cause the browser to retrieve the next.html document from the www.kumquat.com web server after having displayed the current document for 15 seconds.
13.2.2.3 Cycling between documents
Keep in mind that the effects of the Refresh <meta> tag apply only to the document in which it appears. Hence, to cycle between several documents, you must include a Refresh <meta> tag in each one. The content value for each document in the cycle must contain an absolute URL that points to the next document, with the last document pointing back to the first one to complete the cycle.
For example, the following are the <meta> tags for the headers of each in a three-HTML-document cycle.
The document first.html contains:
<meta http-equiv="Refresh" content="30; URL=second.html">
The document second.html contains:
<meta http-equiv="Refresh" content="30; URL=third.html">
And the third.html document has in its <head> (besides other crazy ideas):
<meta http-equiv="Refresh" content="30; URL=first.html">
If it is left alone, the browser endlessly loops between the three documents at 30-second intervals.
Cycling documents make excellent attractors, catching the attention of passers-by to a web-driven kiosk, for example. Users may then navigate through the wider collection of kiosk documents by clicking hyperlinks in one of the kiosk's attractor pages and subsequent ones.[2]
[2] This brings up a good point: the user may override the Refresh dynamic action at any time (for instance, by clicking a hyperlink before the client-pull time-out expires). The browser always ignores the Refresh action in lieu of user interaction.
To return to the cycling set of attractors, each document in the rest of the collection should have its own Refresh field that eventually points back to the attractor. You should specify a fairly long delay period for the nonattractor pages ? 120 to 300 seconds or more ? so that the kiosk doesn't automatically reset while a user is reading the current document. However, the delay period should be short enough so that the kiosk resets to the attractor mode in a reasonable period of time after the user finishes.
13.2.3 Pulling Non-HTML Content
Netscape's and Internet Explorer's client-pull feature is not restricted to HTML documents, although it is certainly easiest to create dynamic documents with HTML. With a bit of server-side programming, you can add a Refresh field to the HTTP header of any sort of document, from audio files to images to video clips.
For example, create a real-time video feed by adding a Refresh header field in each of a sequence of images grabbed and digitized from a camera. Include a delay of 0 with the URL that points to the next image, so that as quickly as the browser displays one image, it retrieves the next. Assuming that the network keeps up, the result is a crude (really crude) TV.
Since the browser clears the window before presenting each subsequent image, the resulting flicker and flash make it almost impossible to present a coherent sequence of images. This technique is more effective when presenting a series of images designed to be viewed as a slide show, where the user expects some sort of display activity between each of the images.
Perhaps a better use of the client-pull feature is with long-playing multimedia documents, which Netscape and Internet Explorer use special helper applications to display. On a multitasking computer, such as one running Unix or Windows 98, the browser downloads one document, while a helper application plays another. Combine the client-pull capabilities with that multitasking to improve multimedia document performance. Rather than waiting for a single, large document like a movie or audio file to download before playing, break it into smaller segments, each automatically downloaded by the previous segment via the Refresh header. The browser plays the first segment while downloading the second, then third, then fourth, and so on.
13.2.4 Combining Refresh with Other HTTP Header Fields
You can have your client-pull dynamic documents perform some neat tricks by combining the effects of the Refresh field with other HTTP header fields. One combination that is particularly useful is Refresh with a Redirect field.
The Redirect field lets the server tell the browser to retrieve the requested document elsewhere at the field's accompanying URL value. The client browser automatically redirects its request to the new URL and gets the document from the new location, usually without telling the user. We retrieve redirected documents all the time and may never notice.
The most common cause for redirection is when someone moves an HTML document collection to a new directory or to a new server. As a courtesy, the webmaster programs the original host server to send an HTTP header field containing the Redirect field and new URL (without a document body) to any and all browsers that request the document from the original location. That way, the new document location is transparent to users, and they won't have to reset their browser bookmarks.
But sometimes you want the users to reset their bookmarks to the new location, because the old one won't be redirecting browsers forever (perhaps because it's being taken out of service). One way to notify users of the new location is to have the redirection URL point to some HTML document other than the home page of the new collection that contains a message about the new location. Once noted, users then take a "Continue" hyperlink to the new home page location and set their bookmarks accordingly.
By combining the Redirect and Refresh fields, you can make that notification screen automatically move to the new home page. If the browser receives an HTTP header with both fields, it honors both; it immediately fetches the redirected URL and displays it, and it sets the refresh timer and replacement URL, if specified. When the time expires, the browser automatically retrieves the next URL ? your new home page location.
13.2.4.1 A random URL generator
Another application for the combination of Redirect and Refresh HTTP header fields is a perpetual, random URL generator. You'll need some programming skills to create a server-side application that selects a random URL from a prepared list and outputs a Redirect field that references that URL along with a Refresh field that reinvokes the random-URL application after some delay.
When Netscape or Internet Explorer receives the complete header, it immediately loads and displays the randomly selected document specified in the Redirect field's URL. After the delay specified in the Refresh field, the browser reruns the random-URL generator on the server (as specified in the refresh URL), and the cycle starts over. The result is an endless cycle of random URLs displayed at regular intervals.
13.2.5 Performance Considerations
Client-pull documents consume extra network resources, especially when the refresh delay is small, since each refresh may involve a 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.
