After some investigation, I have come across a bug in Internet Explorer that is causing intermittent failures for users running my application. This bug exists within the HTTP stack of IE and impacts all applications utilizing POST requests from this browser. The issue manifests as a request hanging for approximately 5 minutes before ultimately failing on the server's end. Subsequently, the browser application gives up on the post request after the server halts responding. Below, I will delve into further detail about this IE bug.
It appears that any application using XMLHttpRequest to send POST requests could face this problem if the timing of the request transmission is incorrect. To experiment with this behavior, I created a sample program that continually sends POSTs to the server at the exact moment when the server closes the connections. The interval for sending these POSTs aligns with the Keep-Alive header transmitted by the server.
When testing this setup from IE to a server featuring latency (e.g., not located on the same LAN), issues occur after only a few POST requests. During these incidents, IE freezes to such an extent that it necessitates forceful closure. The presence of a ticking clock signifies that the browser remains somewhat responsive.
To experience this firsthand, visit: . Please exercise caution and refrain from having important unsaved data in any ongoing IE sessions while trying this out, as it has the potential to crash IE.
Access the complete source code at: . You can execute this on any server equipped with php and configured for persistent connections.
My queries are:
What experiences have others had regarding this problem?
Are there known workarounds for addressing this issue apart from switching to another browser?
Does Microsoft offer more insights into this matter than what I found in the provided article (see below)?
The predicament lies in browsers and servers defaulting to utilize persistent connections as outlined in RFC 2616 section 8.1 (refer to ). While crucial for performance—particularly in AJAX applications—this feature should remain enabled. Nonetheless, a slight timing discrepancy may arise where the browser initiates a POST on a prior connection just as the server decides the connection is idle and opts to close it. Consequently, the browser reports an HTTP stack error due to utilizing a closed socket. As per RFC 2616 section 8.1.4, "clients, servers, and proxies MUST be able to recover from asynchronous close events. Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction."
Although Internet Explorer does resend the POST upon encountering this scenario, it mishandles the request by transmitting the POST headers (including the Content-Length) but omitting the actual data payload. This unconventional request triggers the server to wait indefinitely for the anticipated data before eventually failing the request with an error. Using a C program simulating an HTTP server closing the socket of an incoming POST request sans response, I validated this flaw consistently.
Microsoft seems to acknowledge this glitch in http://support.microsoft.com/kb/895954, noting its impact on IE versions 6 through 9. A hotfix was issued but comes with drawbacks:
Activating the hotfix requires adding a registry key named FEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954 via regedit. This task seems overly burdensome for end-users.
The hotfix does not rectify the broken POST mechanism; instead, if the socket closes as predicted by the RFC, it generates an immediate error without attempting to resend the POST. Even with the hotfix, the application fails, albeit at an earlier stage.
Presented below is a standalone php script illustrating this bug, aiming to send continuous POSTs to the server during those critical moments when the server severs connections.