Opened 15 years ago

Closed 15 years ago

#2357 closed defect (fixed)

XHR connections may leak in IE to fill per host connection limit even after page unload

Reported by: [email protected] Owned by: alex
Priority: high Milestone: 0.9
Component: IO Version: 0.4.1
Keywords: Cc:
Blocked By: Blocking:


When user exits a page, asynchronous XHR requests are not aborted. Normally you would expect the hostenv to handle these cases automatically but at least with IE (version 6, probably others too) this is not always the case. I have come to believe that there exists some states in the execution of an XHR in which page unloading causes an unaborted XHR to leak and count indefinitely as an open connection to a host.

I have reproduced this constantly by opening an SSH tunnel to forward a port to my web server, opened a page through that tunnel which fetches itself periodically using XHR and then brought the tunnel down for a while. After the page has tried to fetch itself twice without an abort or a success through the broken tunnel the IE's two connections per host limit is reached and if I then proceed to reload the page or load an another page, the connections are never cleared by IE and the browser can not connect the given host anymore due to the two connection limit, until the browser is restarted.

Since the "open connections" are never cleared from IE, it is also possible to fill the connection limit of IE one connection at a time using this method. Combined with bugs and which both make it easy to accidentally leave unaborted XHR connection open in IE, this can cause seemingly random host connection lockups when using pages that make consecutive XHRs to the server.

I am not quite sure what exactly are the XHR states which cause IE to leak the connections upon unload. I have been unable to reproduce this behaviour when fetching large files with XHR and unloading the page while the file is still being fetched. It seems that at least if the XHR reaches the stage where it is receiveing resource content (state 3?), it can correctly clear the connection. More testing would be needed wether the leakage occurs on states 1 and 2 or wether the leakage occurs only when the network connection is down (but this is not very easy).

Anyway as a fix, I seem to be unable to reproduce this problem anymore after I added an unload handler like this on the page:

dojo.addOnUnload( function() {
   for(var; x>=0; x--){
       try {
       } catch (e) {};
} );

This however requires that also bug 2352 is resolved since it causes XHR requests to be removed from the inFlight array without being aborted in IE.

As a reference, I'm using an unmodified "custom" build of dojo 0.4.1 and IE6 on Linux (using ies4linux) but we have received many reports of problems that sound like they are caused by this also when using dojo 0.3.1 and when the reporters are using IE versions 6 and 7 on Windows.

Change History (2)

comment:1 Changed 15 years ago by dylan

Milestone: 0.9

comment:2 Changed 15 years ago by alex

Resolution: fixed
Status: newclosed

(In [9950]) Prevent in-flight leakage on IE. fixes #2357

Note: See TracTickets for help on using tickets.