S
Steve Kirkendall
I need a work-around for an IE limitation, regarding fetching HTTP
documents in the background. It takes a bit of explaining; please
be patient...
I'm working on an project that will run on an intranet. I need to
have pages be reloaded automatically when the data they reflect is
changed at the server. For Netscape/Mozilla/Firefox, I do this by
having the page use JavaScript to read a special "/update.html" URL
in the background. For this URL, the server doesn't return anything
until it detects a change in the data, at which point it sends a
meaningless response and closes the connection. The browser's
JavaScript code then reloads the main page, showing the new data.
It works great!
But there's this other browser, "Internet Explorer", which I must
also support. The "slow /update.html" strategy *seems* to work until
I exit & reload the main page multiple times, without any changes
being detected in the data. If I do that, then the browser gets stuck.
Apparently IE doesn't terminate backgrounded JavaScript when you exit
the page that started it. For my applicatation, this means IE tries
to accumulate extra backgrounded "/update.html" requests each time
you exit & reload the main page. Also, it seems that IE only allows
about 6 TCP connection in total, so once it's accumulated 6
"/update.html" requests, it can't read anything else.
I got the background "/update.html" strategy to work in IE, more or
less, by making it remember which thread is being used to serve the
slow "/update.html" request for each client, and then when a new thread
wants to do serve a new "/update.html" for the same client, it first
kills the old thread and closes the old connection. I consider this
a nasty hack, but it works.
Except that now I want to allow each client to perform two "/update.html"
requests in parallel -- one for the main window, and one for a pop-up
window. (The /update.html request accepts parameters describing what,
exactly, the client wants to wait for. The main window and pop-up window
will wait for different things.) I tried extending the same "kill the
old thread" hack to handle two connections, but it doesn't seem to be
working. I may yet get it to work, but before I waste a lot of time
on it, I thought I'd ask whether anybody else can suggest something
better.
To reitterate: I want to allow each client to have two windows that
immediately reload their pages when the server's data changes.
Is there some option that IE's JavaScript environment uses to indicate
whether backgrounded tasks should die when the page is unloaded?
Is there a way to kill them on a document unload event, or some
similar event?
Thanks in advance for any advice you can give.
documents in the background. It takes a bit of explaining; please
be patient...
I'm working on an project that will run on an intranet. I need to
have pages be reloaded automatically when the data they reflect is
changed at the server. For Netscape/Mozilla/Firefox, I do this by
having the page use JavaScript to read a special "/update.html" URL
in the background. For this URL, the server doesn't return anything
until it detects a change in the data, at which point it sends a
meaningless response and closes the connection. The browser's
JavaScript code then reloads the main page, showing the new data.
It works great!
But there's this other browser, "Internet Explorer", which I must
also support. The "slow /update.html" strategy *seems* to work until
I exit & reload the main page multiple times, without any changes
being detected in the data. If I do that, then the browser gets stuck.
Apparently IE doesn't terminate backgrounded JavaScript when you exit
the page that started it. For my applicatation, this means IE tries
to accumulate extra backgrounded "/update.html" requests each time
you exit & reload the main page. Also, it seems that IE only allows
about 6 TCP connection in total, so once it's accumulated 6
"/update.html" requests, it can't read anything else.
I got the background "/update.html" strategy to work in IE, more or
less, by making it remember which thread is being used to serve the
slow "/update.html" request for each client, and then when a new thread
wants to do serve a new "/update.html" for the same client, it first
kills the old thread and closes the old connection. I consider this
a nasty hack, but it works.
Except that now I want to allow each client to perform two "/update.html"
requests in parallel -- one for the main window, and one for a pop-up
window. (The /update.html request accepts parameters describing what,
exactly, the client wants to wait for. The main window and pop-up window
will wait for different things.) I tried extending the same "kill the
old thread" hack to handle two connections, but it doesn't seem to be
working. I may yet get it to work, but before I waste a lot of time
on it, I thought I'd ask whether anybody else can suggest something
better.
To reitterate: I want to allow each client to have two windows that
immediately reload their pages when the server's data changes.
Is there some option that IE's JavaScript environment uses to indicate
whether backgrounded tasks should die when the page is unloaded?
Is there a way to kill them on a document unload event, or some
similar event?
Thanks in advance for any advice you can give.