HTTP in the background in IE



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.
.



Relevant Pages

  • Re: [PHP] php sessions
    ... I open a web browser and login to my application. ... window and goto the web application, and it asks me to login. ... then it certainly seems relevant to the discussion, and that my one client ... > Then show us these requests and point out how they are different. ...
    (php.general)
  • COM Interop + Threading + Scalability
    ... The Client completely denies ... The Rules Processor is implemented in VB 6 and the ASP.NET ... multiple concurrent requests for the Rules Processor. ... creates and initializes an apartment when calling a COM ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Rem Desktop conflict with Interactive Logon Message
    ... > for users" window is not sent to the RD client. ... In the Group Policy window, which is focused on the Default Domain ... Security Settings, then to Local Policies, and select Security Options. ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: [CFT][PATCH] new scheduler policy
    ... "The X server uses selectto detect clients with pending input. ... executing requests from the client with the smallest file descriptor. ... Each client has a buffer which is used to read some data from the ...
    (Linux-Kernel)
  • Re: TCP packets : end of thre-way handshake and start of data-transmission - how to dete
    ... RFC 793 Section 3.4 (Establishing a connection) says in part: ... packet because it would be necessary to assume a window size. ... client has already indicated a non-empty window). ... Server sends SYN/ACK and data ...
    (comp.arch.embedded)