Question

178

Why does Internet Explorer not send HTTP post body on Ajax call after failure?

rated 0 times [ 179] [ 1] / answers: 1 / hits: 48008 / 14 Years ago, tue, january 25, 2011, 12:00:00

We are able to reliably recreate the following scenario:

Create a small HTML page that makes AJAX requests to a server (using HTTP POST)

Disconnect from the network and reconnect

Monitor the packets that IE generates after the failure

After a failed network connection, IE makes the next AJAX request but only sends the HTTP header (not the body) when doing the HTTP post. This causes all sorts of problems on the server as it is only a partial request. Google this issue with Bing and you'll find lots of people complaining about random server errors using AJAX or unexplained AJAX failures.

We know that IE (unlike most other browsers) always sends an HTTP POST as TWO TCP/IP packets. The header and body is sent separately. In the case directly after a failure, IE only sends the header. IE never sends the payload and the server eventually responds with a Timeout.

So my question is - why does it behave this way? It seems wrong based on the HTTP spec and other browsers don't behave this way. Is it simply a bug? Surely this creates havoc in any serious AJAX based Web application.

Reference information:

There is a similar problem, triggered by HTTP keep-alive timeouts that are shorter than 1 minute and is documented here:

http://us.generation-nt.com/xmlhttprequest-post-sometimes-fails-when-server-using-keep-aliv-help-188813541.html

http://support.microsoft.com/default.aspx?kbid=831167

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

nestorjarettg

Add To Favorites

Follow

Total Points: 451

Total Questions: 108

Total Answers: 108

Location: Rwanda

Member since Thu, Feb 10, 2022

2 Years ago

nestorjarettg questions

1 Discord Bot Not Playing Audio discord.js v13

Sat, Sep 25, 21, 00:00, 3 Years ago

1 Access and modify react context from jest test with react testing library

Wed, Sep 9, 20, 00:00, 4 Years ago

1 Uncaught ReferenceError: _ is not defined at < anonymous>:1:1 (Not jQuery)

Sun, Feb 16, 20, 00:00, 4 Years ago

1 403 Access Error returned from Browser possibly caused by AWS

Wed, Jan 29, 20, 00:00, 4 Years ago

1 Uncaught TypeError: Class extends value #< Object> is not a constructor or null

Mon, Jan 13, 20, 00:00, 4 Years ago

View All

answered 14 Years ago gideonb · Accepted Answer

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.