Re: HTTP in the background in IE
- From: "Norman L. DeForest" <af380@xxxxxxxxxxxxxx>
- Date: Sun, 22 Jan 2006 02:26:29 -0400
On Thu, 19 Jan 2006, Steve Kirkendall wrote:
> 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.
I have an idea (which I can't test as I don't have control of any
server and also refuse to use IE for anything but Windows updates and
testing my own pages) but I have no idea whether it would work.
If a page is redirected with reply code 307, can IE detect the new page
name and can JavaScript get the temporary name?
If so, perhaps you could:
1. Have the JavaScript test for IE and request "/updateIE.html"
instead of "/update.html" when IE is detected (and do so
periodically).
2. Have the server act the same as it does now for a request
for "/update.html".
3. Have the server *temporarily* redirect "/updateIE.html requests
(using reply code 307) to "foo.html" or "bar.html" depending of
whether an update is available. "foo.html" could be a tiny file,
<html><body><p> </p></body></html>
that simply flags by its file name that no information is available
and "bar.html" could be a similar file that flags that information
*is* available.
4. Have the IE JavaScript test for the file name of the returned page
and act accordingly depending on whether it's "foo.html" or "bar.html".
Since the files would actually be fetched, no unsatisfied requests would
be left pending.
For two windows, use two different sets of filenames.
Creating two tiny unobtrusive windows to "display" the request results
is left as an exercise. Or try fetching two 1x1 GIFs and redirect
"/update.gif" to "foo.gif" or "bar.gif" depending on the results
and see if IE can detect the redirected image file names.
<discworld>
"Hey, it's a million-to-one chance so it might work."
</discworld>
--
Norman De Forest http://www.chebucto.ns.ca/~af380/Profile.html
af380@xxxxxxxxxxxxxx [=||=] (At the Sign of the Flashing Cursor)
"Oh how I miss the days when it was easier to catch gonorhea than a
computer virus." -- Big Will in alt.comp.virus, March 9, 2005
.
- References:
- HTTP in the background in IE
- From: Steve Kirkendall
- HTTP in the background in IE
- Prev by Date: Re: Images don't load when using JavaScript in SRC= attribute for FireFox
- Next by Date: How to ignore the signed bit?
- Previous by thread: Re: HTTP in the background in IE
- Next by thread: Attach event/function to links within span tag
- Index(es):
Relevant Pages
|
