~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is there any way in HTTP for a Server to automatically update a page
without requiring the user of the client to click on anything?
An example use of this would be if a Client requests a stock price
page and keeps the page displayed. Now suppose the stock price
changes. Is there a way within HTTP for the Server to update the page
automatically without requiring the user to click on the reload option?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The basic answer so far is that the Expires Object Header field (see section
7.7 of the HTTP/1.0 document) could potentially be used for this purpose,
but that any client which supports the Expires header field would probably
only update the page when the user clicked on the "forward" or "back" button
on a browser.
If a client did continually request a page as its expiration time arrived
(perhaps every few seconds), this could handle the case where the
client should get continuous updates. But there are cases where a page
is valid only once -- they expire immediately and the client shouldn't
get them again. The example cited in this context by Mark J. Cox
(M.J.Cox@bradford.ac.uk) was "a page which tells you that the
phone link to our remote telescope has been established -- this document
expires immediately but I don't want the document to reload forever".
Mark's position therefore, was that if a client did automatically refresh
a page without user intervention, "then there is a need for a second header:
one that tells the client that the document will expire at some given time -
but don't bother getting it again."
Christian Mogensen (<mogens@CS.Stanford.EDU) suggested that "another
way to do this would be to provide a stock-ticker application that
is initialized by the web client when it receives application/x-stock-ticker
data. The browser forks off the special viewer which opens a separate
communication channel to the server."
Finally, the support for automatic refresh could not really be completely
Server-driven. As Mark J. Cox points out "since HTTP follows a single
Request/Responce paradigm it can not be made a function of the Server
(actually it could, but it would also require client modifications and
would be far more complex)."
Are there any additional thoughts on this question?
Bill Allocca
allocca@openmarket.com