神马文学网An Exploration of Dynamic Documents
来源：百度文库 编辑：神马文学网 时间：2024/04/29 07:37:03
INTRODUCTION
This document explores the "server push" and "client pull" dynamicdocument capabilities of Netscape Navigator 1.1 (Windows, Mac, andUnix versions). Please send comments topushpull@netscape.com.Also, if you are using either server push or client pull in areal-world application, please drop us a note atpushpull@netscape.comand let us know -- thanks!
Examples are given at the end, along with an important note onimplementing server push CGI programs as shell scripts.
THEGREATIDEA
The general idea is that browsers have always been driven by userinput. You click on a link or an icon or an image and some data comesto you. As soon as people saw they could do that, they wanted to givea server the ability to push new data down to the browser. (Anobvious example is a stock trader who wants to see new quote dataevery 5 minutes.) Up until now, that hasn‘t been possible.
Netscape Navigator 1.1 gives content creators and serveradministrators two new open standards-based mechanisms for making thiswork. The mechanisms are similar in nature and effect, butcomplementary. They are:
Server push -- the server sends down a chunk of data; the browser display the data but leaves the connection open; whenever the server wants it sends more data and the browser displays it, leaving the connection open; at some later time the server sends down yet more data and the browser displays it; etc.
Client pull -- the server sends down a chunk of data, including a directive (in the HTTP response or the document header) that says "reload this data in 5 seconds", or "go load this other URL in 10 seconds". After the specified amount of time has elapsed, the client does what it was told -- either reloading the current data or getting new data.
In server push, a HTTP connection is held open for an indefiniteperiod of time (until the server knows it is done sending data to theclient and sends a terminator, or until the client interrupts theconnection). In client pull, HTTP connections are never held open;rather, the client is told when to open a new connection, and whatdata to fetch when it does so.
In server push, the magic is accomplished by using a variant of theMIME message format "multipart/mixed", which lets a single message (orHTTP response) contain many data items. In client pull, the magic isaccomplished by an HTTP response header (or equivalent HTML tag) thattells the client what to do after some specified time delay.
We‘ll explore client pull first...
CLIENTPULL
A simple use of client pull is to cause a document to be automaticallyreloaded on a regular basis. For example, name the following document"doc1.html" and try loading it in Netscape Navigator 1.1:
This is Document ONE!
Here‘s some text.
You will notice that the document reloads itself once a second.
What‘s happening? Simply put, we‘re using the META tag(a standard HTML 3.0 tag, for simulating HTTP response headers in HTMLdocuments) to tell the browser that it should pretend that the HTTPresponse when "doc1.html" was loaded included the following header:
Refresh: 1
That HTTP header, in turn, tells the browser to go reload (refresh)this document after 1 second has elapsed. If we wanted to wait 12seconds instead, we could have used this HTML directive:
...which is equivalent to this HTTP response header:
Refresh: 12
Note: You should make sure the META tag is used insidethe HEAD of your HTML document. That means it must appear before anytext or images that would be displayed as part of your document.So that‘s pretty cool.
A couple things to notice:
In this example, a new "Refresh" directive (via either the META tag or the Refresh HTTP response header) is given as a part of every retrieval. This is an important point. Each individual "Refresh" directive is one-shot and non-repeating. The directive doesn‘t say "go get this page every 6 seconds from now until infinity"; it says "go get this page in 6 seconds".
If you want continuous reloading, you have to give the directive on each retrieval. If you only want the document reloaded once, only give the directive on the first retrieval.
Once given the directive, the browser will do the specified retrieval after the specified amount of time. The only way to cause it not to happen is to not have an open window that contains the document.
This also means that if you set up an "infinite reload" situation (as the example above does), the only way you can interrupt the infinite reloading is by pressing the "Back" button or otherwise going to a different URL in the current window (or, equivalently, by closing the current window).
So another thing you obviously want to do, in addition to causing thecurrent document to reload, is to cause another document to bereloaded in n seconds in place of the current document. Thisis easy. The HTTP response header will look like this:
Refresh: 12; URL=http://foo.bar/blatz.html
The corresponding META tag would be:
Important note: make sure the URL you give is fully qualified(e.g. http://whatever/whatever). That is, don‘t use a relativeURL.
Here are two example documents, "doc2.html" and "doc3.html", each ofwhich causes the other to load (so if you load one of them, yourbrowser will flip back and forth between them indefinitely). Here‘s"doc2.html":
This is Document TWO!
Here‘s some other text.This is Document THREE!
Here‘s yet more text.
(You should tweak the URLs to match your local system. Remember, theymust be fully specified.)
Now load one of the documents; the browser will load the other in 1second, then the first in another second, then the second again inanother second, and so on forever.
How do you make it stop? The easiest way is to either close thewindow, or put a link in the document(s) that points to somewhereelse. Remember, any retrieval of any document can cause the wholeprocess to stop at any point in time if a fresh directive isn‘t issued-- the process only continues as long as each new document causes itto continue. Thus, the content creator has total control.
Neat trick: the interval can be 0 seconds! This will cause thebrowser to load the new data as soon as it possibly can (after thecurrent data is fully displayed).Another neat trick: the data that is retrieved can be of anytype: an image, an audio clip, whatever. One fun thing to envision is0-second continuous updating of a live image (e.g. a camera feed), ora series of still images. Poor man‘s animation, kind of. We‘reconsidering mounting a camouflaged IndyCam on the prow of Jim Clark‘sboat and feeding live images to the world using this mechanism.Yet another neat trick: a "Refresh" header can be returned aspart of any HTTP response, including a redirection. So a single HTTPresponse can say "go get this URL now, and then go get this other URLin 10 seconds".
This means you can have a continuous random URL generator! Have anormal random URL generator (such asURouLette)that returns as part of its redirection response a "Refresh" directivethat causes the browser to go get another random URL from the randomURL generator in 18 seconds.
SERVERPUSH
Server push is the other dynamic document mechanism, complementingclient pull.
In contrast to client pull, server push takes advantage of aconnection that‘s held open over multiple responses, so the server cansend down more data any time it wants. The obvious major advantage isthat the server has total control over when and how often new data issent down. Also, this method can be more efficient, since new HTTPconnections don‘t have to be opened all the time. The downside isthat the open connection consumes a resource on the server side whileit‘s open (only when the server knows it wants this to happen,though). Also, server push has two other advantages: one is that aserver push is easily interruptible (you can just hit "Stop" andinterrupt the connection), and the other advantage we‘ll talk about alittle later.
First, a short review: the MIME message format is used by HTTP toencapsulate data returned from a server in response to a request.Typically, an HTTP response consists of only a single piece of data.However, MIME has a standard facility for representing many pieces ofdata in a single message (or HTTP response). This facility uses astandard MIME type called "multipart/mixed"; a multipart/mixed messagelooks something like:
Content-type: multipart/mixed;boundary=ThisRandomString--ThisRandomStringContent-type: text/plainData for the first object.--ThisRandomStringContent-type: text/plainData for the second and last object.--ThisRandomString--
The above message contains two data blocks, both of type "text/plain".The final two dashes after the last occurrence of "ThisRandomString"indicate that the message is over; there is no more data.
For server push we use a variant of "multipart/mixed" called"multipart/x-mixed-replace". The "x-" indicates this type isexperimental. The "replace" indicates that each new data block willcause the previous data block to be replaced -- that is, new data willbe displayed instead of (not in addition to) old data.
So here‘s an example of "multipart/x-mixed-replace" in action:
Content-type: multipart/x-mixed-replace;boundary=ThisRandomString--ThisRandomStringContent-type: text/plainData for the first object.--ThisRandomStringContent-type: text/plainData for the second and last object.--ThisRandomString--
The key to the use of this technique is that the server does not pushthe whole "multipart/x-mixed-replace" message down all at once butrather sends down each successive data block whenever it seesfit. The HTTP connection stays open all the time, and the serverpushes down new data blocks as rapidly or as infrequently as it wants,and in between data blocks the browser simply sits and waits for moredata in the current window. The user can even go off and do otherthings in other windows; when the server has more data to send, itjust pushes another data block down the pipe, and the appropriatewindow updates itself.
So here‘s exactly what happens:
Following in the tradition of the standard "multipart/mixed", "multipart/x-mixed-replace" messages are composed using a unique boundary line that separates each data object. Each data object has its own headers, allowing for an object-specific content type and other information to be specified.
The specific behavior of "multipart/x-mixed-replace" is that each new data object replaces the previous data object. The browser gets rid of the first data object and instead displays the second data object.
A "multipart/x-mixed-replace" message doesn‘t have to end! That is, the server can just keep the connection open forever and send down as many new data objects as it wants. The process will then terminate if the user is no longer displaying that data stream in a browser window or if the browser severs the connection (e.g. the user presses the "Stop" button). We expect this will be the typical way people will use server push.
The previous document will be cleared and the browser will begin displaying the next document when the "Content-type" header is found, or at the end of the headers otherwise, for a new data block.
The current data block (document) is considered finished when the next message boundary is found.
Together, the above two items mean that the server should push down the pipe: a set of headers (most likely including "Content-type"), the data itself, and a separator (message boundary). When the browser sees the separator, it knows to sit still and wait indefinitely for the next data block to arrive.
Putting it all together, here‘s a Unix shell script that will causethe browser to display a new listing of processes running on a serverevery 5 seconds:
#!/bin/shecho "HTTP/1.0 200"echo "Content-type: multipart/x-mixed-replace;boundary=---ThisRandomString---"echo ""echo "---ThisRandomString---"while truedoecho "Content-type: text/html"echo ""echo "
Processes on this machine updated every 5 seconds
"echo "time: "dateecho ""echo "