With both AJAX and non-AJAX the browser sends HTTP requests and receives HTTP responses from the web server. Deference between an AJAX request and a non-AJAX request is that, AJAX requests: work in the background seamlessly, and. don't make the pages to reload every time a response is received.
When you make an AJAX request, your browser sends an HTTP request to a given address. The server on the other end of the request responds, and returns the data to your browser. This is the same thing that happens when you navigate to a new web page.
There does not seem to be a clear answer to this question, so I will provide my empirical data as a substitute and provide some ways to work around it. Maybe some MS insider will one day shed some light on this...
If HTTP Keep-Alive is disabled on the server, this issue goes away. In other words, your HTTP 1.1 server will respond to every Ajax request with a Connection: Close
line in the response. This keeps IE happy but causes every Ajax request to open a new connection. This can have a significant performance impact, especially on high latency networks.
The issue is triggered easily if Ajax requests are made in rapid succession. For example, we make Ajax requests every 100ms and then the network status changes, the error is easy to reproduce. Although most applications probably do not make such requests, you might well have a couple of server calls happening right after each other which could lead to this problem. Less chatty keeps IE happy.
It happens even without NTLM authentication.
It happens when your HTTP keep-alive timeout on the server is shorter than the default (which defaults to 60 seconds on Windows). Details provided in link in question.
It does not happen with Chrome or Firefox. FF sends one packet so seems to avoid this issue altogether.
It happens in IE 6, 7, 8. Could not reproduce with IE 9 beta.
The microsoft KB article titled When you use Microsoft Internet Explorer or another program to perform a re-POST operation, only the header data is posted seems to fix this problem.
The article provides a hotfix. For later browsers such as IE8 it says the hotfix is already included but needs to be enabled through the registry settings on the client PC.
I had a similar problem where some older versions of IE would send back only the Header and not the body of a POST. My problem turned out to be related to IE and NTLM. Since you didn't mention NTLM, this probably does not help, but just in case:
http://support.microsoft.com/kb/251404
This is a longshot, but IE (and even Firefox) sometimes "remembers" the connection it uses for an HTTP request. Notes/examples:
In Firefox, if I change the proxy settings and hit SHIFT-RELOAD on a page, it still uses the old proxy. However, if I kill the old proxy ("killall squid"), it starts using the new proxy.
When you disconnect/reconnect, do you receive a new IP address or anything similar? Can you somehow monitor the old IP address to see if IE is sending data to that now-dead address?
My guess is that IE is sending the data, just down the wrong path. It might be smart enough to not cache network connections for "POST" packets, but might not be smart enough to do that for POST payloads.
This probably doesn't affect most AJAX apps, since people rarely disconnect and re-connect to their networks?
Are you using NTLM authentication?
When using NTLM authentication, IE doesn't send post-data. It sends header info, expects an unauthorized response send authorization, and after the 're-authentication' sends the post.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With