javascript JQuery Ajax post 参数有时不会在 IE 上发送
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6941898/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
JQuery Ajax post parameters sometimes not sent on IE
提问by Jasper Rosenberg
The problem I am having is that when I use jquery ajax post, with very low frequency (< 2%), the post parameters never make it to the server. I do see the post request in the access log. It seems to happen only on IE (I've observed it on 7, 8, and 9 in the logs).
我遇到的问题是，当我使用 jquery ajax post 时，频率非常低（< 2%），post 参数永远不会到达服务器。我确实在访问日志中看到了发布请求。它似乎只发生在 IE 上（我在日志中的 7、8 和 9 上观察到了它）。
When I switch the call from type "post" to type "get" the issue goes away.
当我将呼叫从“post”类型切换到“get”类型时，问题就消失了。
Has anyone else ever seen this odd behavior on IE? Thanks!
有没有其他人在 IE 上见过这种奇怪的行为？谢谢！
I have seen this for various ajax calls, but here is a typical one:
我已经在各种 ajax 调用中看到了这一点，但这是一个典型的调用：
var data= {
"guess" : "m1",
"eas" : "hello world"
};
$.ajax({
url: "http://myco.com/ajaxcall.action",
data: data,
type : 'post',
dataType: 'json',
success: function(data) {},
error: function() {}
});
Update: passing "cache: false" does not fix the issue.
更新：传递“缓存：假”并不能解决问题。
回答by Tony Abo
I have spent the last week tracking down a similar problem in my own application (uses Dojo, not JQuery). From your description and frequency of occurrence, I would say it's the same issue.
上周我一直在跟踪我自己的应用程序中的类似问题（使用 Dojo，而不是 JQuery）。根据您的描述和发生频率，我会说这是同一个问题。
When HTTP persistent connections are used between browser and server (the default behavior), an HTTP connection can be closed down by the server at any time. This creates a very small timing hole when the browser starts to send a new request at the same time the server closes the connection. Most browsers will use a different connection or open a new connection and resend the request. This is the behavior suggested in RFC 2616 section 8.1.4:
当浏览器和服务器之间使用 HTTP 持久连接时（默认行为），服务器可以随时关闭 HTTP 连接。这会在浏览器开始发送新请求的同时服务器关闭连接时创建一个非常小的计时漏洞。大多数浏览器将使用不同的连接或打开新连接并重新发送请求。这是 RFC 2616 第 8.1.4 节中建议的行为：
A client, server, or proxy MAY close the transport connection at any time. For example, a client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress.
客户端、服务器或代理可以随时关闭传输连接。例如，客户端可能在服务器决定关闭“空闲”连接的同时开始发送新请求。从服务器的角度来看，连接是在空闲时关闭的，但从客户端的角度来看，请求正在进行中。
This means that 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 so long as the request sequence is idempotent (see section 9.1.2).
这意味着客户端、服务器和代理必须能够从异步关闭事件中恢复。只要请求序列是幂等的，客户端软件应该重新打开传输连接并重新传输中止的请求序列，而无需用户交互（参见第 9.1.2 节）。
Internet explorer doestry to resend the request when this happens, butwhen it happens to be a POST, it mangles it up by sending the headers (with Content-Length) but no actual data. That is a malformed request and should always lead to an HTTP error (usually after some timeout waiting for the data that never comes).
发生这种情况时，Internet Explorer确实会尝试重新发送请求，但是当它恰好是 POST 时，它会通过发送标头（带有 Content-Length）而不是实际数据来破坏它。这是一个格式错误的请求，应该总是导致 HTTP 错误（通常在等待永远不会到来的数据超时之后）。
This bug is documented by Microsoft as KB 895954 (see http://support.microsoft.com/kb/895954). Microsoft first recognized this bug in IE 6. They provided a hotfix, and appear to have shipped the hotfix with every version of IE since then including IE 9. There are two problems with the fix:
Microsoft 将此错误记录为 KB 895954（请参阅http://support.microsoft.com/kb/895954）。微软首先在 IE 6 中发现了这个错误。他们提供了一个修补程序，并且从那时起，包括 IE 9 在内的每个版本的 IE 似乎都提供了这个修补程序。这个修复程序有两个问题：
The hotfix is not activated by default. You have to create a really weird key using regedit to activate the fix: HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954.
The fix doesn't really fix the problem. The "fixed" behavior is that when the connection is closed when trying to send a request, it does not even try to resend it. It simply passes the error along to the javascript application.
默认情况下不激活此修补程序。您必须使用 regedit 创建一个非常奇怪的密钥来激活修复程序：HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954。
修复并不能真正解决问题。“固定”行为是当尝试发送请求时连接关闭时，它甚至不会尝试重新发送它。它只是将错误传递给 javascript 应用程序。
It appears that you have to add error handlers in your code and re-post the request yourself if it fails. I am looking into this solution for my application. My concern is that I'm not sure how to tell if the error I get is caused by a failed attempt to send the query, or some error sent back from the server as a result of the query (in which case I don't want to resend it).
看来您必须在代码中添加错误处理程序，并在失败时自己重新发布请求。我正在为我的应用程序寻找这个解决方案。我担心的是，我不确定如何判断我得到的错误是由尝试发送查询失败引起的，还是由于查询而从服务器发回的某些错误（在这种情况下我不知道）想重发）。
I wrote a C program to simulate a web server and explicitly close a connection to see how the browser handles it. I have found that IE reproduces the errant behavior 100% of the time, while Firefox, Safari and Chrome recover by properly resending the POST on another connection 100% of the time. Perhaps the answer is, "don't use IE."
我编写了一个 C 程序来模拟 Web 服务器并显式关闭连接以查看浏览器如何处理它。我发现 IE 可以 100% 的时间重现错误行为，而 Firefox、Safari 和 Chrome 可以通过在另一个连接上 100% 的时间正确重新发送 POST 来恢复。也许答案是“不要使用 IE”。
回答by Stuart
As a direct answer to your question: Yes we have just come across this issue and could not find a reasonable explanation. It only affects IE and with a very low frequency - took a long while to get to the conclusion that it is a sporadic jQuery Ajax in IE bug. We had to 'fix' the issue by returning a fail from the server under this condition and re-posting the data after a 1 second delay!
作为对您问题的直接回答：是的，我们刚刚遇到这个问题，找不到合理的解释。它只影响 IE 并且频率非常低 - 花了很长时间才得出结论，它是 IE 中一个零星的 jQuery Ajax 错误。在这种情况下，我们必须通过从服务器返回失败并在 1 秒延迟后重新发布数据来“修复”问题！
Hacky as hell but seemed to be the only way.
像地狱一样的哈克，但似乎是唯一的方法。
There was definitely no clash with DOM elements etc. and no logical reason for this to happen, the page can be updated many times by the user successfully with intermittent fails.
肯定没有与 DOM 元素等发生冲突，也没有发生这种情况的合乎逻辑的原因，用户可以多次成功更新页面，但间歇性失败。
Must be a bug.
应该是bug。
回答by Erik Márf?ldi
I think you have to prevent caching in Internet Explorer. Try to set option cache to false.
我认为您必须防止在 Internet Explorer 中缓存。尝试将选项缓存设置为 false。
Example:
例子：
$.ajax({
url: "http://myco.com/ajaxcall.action",
data: data,
type : 'post',
dataType: 'json',
success: function(data) {},
error: function() {},
cache: false
});
回答by atiruz
The params sent to the PHP are received from IE in GET:
发送到 PHP 的参数是从 IE 中接收的GET：
$.ajax ({
url: "path/to/ajax.php"
,method: "POST"
,data: {
var1: "value1"
,var2: true
,varX: 123123
}
,cache: false
,success: function (data) {
alert (data);
}
});
Then on PHP you should use REQUEST instead of POST:
然后在 PHP 上你应该使用 REQUEST 而不是 POST：
$var1 = $_REQUEST ["var1"]; // value1
$var2 = $_REQUEST ["var2"]; // true
$var3 = $_REQUEST ["var3"]; // 123123
This example could use it for compatibility with IE7
这个例子可以用它来兼容 IE7
