Ajax call backstage: Ajax calls with caution post, there are serious problems or bugs

This problem only exists if the client is an IE or IE kernel, but you can't control what browser the client uses, so it still poses a great performance problem for your application.
Let's first say the phenomenon:
Service side: We only use a static HTML page ok.html, content only return OK.
Then we write an AJAX called HTML on the client access:
<script>
function Send_request (method,url,param) {
Http_request = false;
if (window. XMLHttpRequest) {
Http_request = new XMLHttpRequest ();
else if (window. ActiveXObject) {
try {
Http_request = new ActiveXObject ("Msxml2.xmlhttp");
catch (e) {
try {
Http_request = new ActiveXObject ("Microsoft.XMLHTTP");
catch (e) {
}
}
}
if (!http_request) {
Return
}
Http_request.open (method, url,true);
Http_request.send (param);
}
function Get () {
var url = "Http://myhost/ok.html?name=axman&test=123";
for (Var i=0;i<1000;i++) {
Send_request ("Get", url,null);
}
}
Function post () {
var url = "Http://myhost/ok.html";
for (Var i=0;i<1000;i++) {
Send_request ("POST", url, ' name=axman&test=123 ');
}
}
</script>
<input type= ' button ' name= ' B1 ' value= ' get ' onclick= ' get () ' >
<input type= "button" Name= "B2" value= "POST" onclick= "post ()" >
The two ways of accessing and passing the parameters on this page are exactly the same, and when I press the Get button, the server receives 1000 access records.
[Admin@vm-platform access_log]$ cat apache_access.log.4 wc-l
1000
Then I counted the records with access times greater than 1ms:
[Admin@vm-platform access_log]$ cat apache_access.log.4 awk ' {if ($ > 1000) print $} '
The result is empty.
Now we'll press the Post button:
[Admin@vm-platform access_log]$ cat apache_access.log.4 wc-l
2000
When the service side displays 2000, the access is complete.

[Admin@vm-platform access_log]$ Cat apache_access.log.4 The result of awk ' {if ($ > 1000) Print $} ': 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 696078 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 696045 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 695776 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 695332 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 696500 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 696484 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 696215 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 696235 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 696182 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:55 +0800] "post/myhost/ok.html http/1.1" 694964 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:58 +0800] "post/myhost/ok.html http/1.1" 1274 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"- 10.16.14.82--[24/nov/2011:16:08:59 +0800] "post/myhost/ok.html http/1.1" 1019 "-" mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; trident/4.0) "--" a=-; b=-; c=-"-

Note that the time of the Apache%d record is from the first header field (read to the first newline carriage start) to the response Output (protocol layer, as long as it is written to the buff, not necessarily sent to the client). This unit of time is
In microseconds, take a look at the 10 records that are nearly 700ms and are thousand-fold of the get way.
Because this phenomenon to our two applications to bring performance problems, I began to analyze this reason, and later from the web search to the article said IE Kernel browser in Ajax call, the Post method to send two steps, the first time to send
Header field, the second time the body is sent. The middle has a lot of delay, and sometimes cause the body packet loss, we look at the packet from the network, there is really only sent header, only the server-side timeout returned error packets, no body data. The odds are about 1%.
In the case of Apache as a proxy, the proxy cannot send client requests to backend in a valid time, causing a large number of internal error outputs. If SS also can cause data timing chaos. After sending the \r\n\r\n The tail is not sent to complete, these phenomena are monitored from the network grab packet.
If you switch to Firefox, the same Ajax code implementation post is not a problem, the key is that you can not control the user does not use IE.
The solution given on the net did not work at all (perhaps IE6 can work, I use the IE8 did not IE6), the key is that as long as some of the browser occurs, the application will bring a lot of performance problems.
So try to use less Ajax post to submit your data, but sometimes the server only allows post submissions for security reasons, and you can dynamically construct form forms and use Ajax to invoke post as little as possible.

This article links http://www.cxybl.com/html/wyzz/JavaScript_Ajax/20121127/34459.html