JQuery Ajax post 参数有时不会在 IE 上发送 [英] JQuery Ajax post parameters sometimes not sent on IE

问题描述

我遇到的问题是，当我使用 jquery ajax post 时，频率非常低(<2%)，post 参数永远不会到达服务器.我确实在访问日志中看到了发布请求.它似乎只发生在 IE 上(我在日志中的 7、8 和 9 上观察到了它).

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).

当我将呼叫从post"类型切换到get"类型时，问题就消失了.

When I switch the call from type "post" to type "get" the issue goes away.

有没有其他人在 IE 上见过这种奇怪的行为?谢谢！

Has anyone else ever seen this odd behavior on IE? Thanks!

我已经在各种 ajax 调用中看到过这种情况，但这是一个典型的调用:

I have seen this for various ajax calls, but here is a typical one:

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() {}
});

更新:传递cache: false"并不能解决问题.

Update: passing "cache: false" does not fix the issue.

推荐答案

上周我一直在追踪我自己的应用程序(使用 Dojo，而不是 JQuery)中的类似问题.从你的描述和发生频率来看，我认为这是同一个问题.

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.

当浏览器和服务器之间使用 HTTP 持久连接时(默认行为)，服务器可以随时关闭 HTTP 连接.这会在浏览器开始发送新请求的同时服务器关闭连接时创建一个非常小的计时漏洞.大多数浏览器将使用不同的连接或打开新连接并重新发送请求.这是 RFC 2616 第 8.1.4 节中建议的行为:

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:

客户端、服务器或代理可以在任何时候关闭传输连接时间.例如，客户端可能已经开始发送新请求同时服务器决定关闭空闲"联系.从服务器的角度来看，连接正在在空闲时关闭，但从客户的角度来看，请求正在进行中.

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.

这意味着客户端、服务器和代理必须能够恢复来自异步关闭事件.客户端软件应该重新打开传输连接并重新传输中止的请求序列只要请求序列是幂等的(见 9.1.2 节).

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).

Internet Explorer 确实尝试在发生这种情况时重新发送请求，但是当它恰好是 POST 时，它会通过发送标头(带有 Content-长度)但没有实际数据.这是一个格式错误的请求，应该总是导致 HTTP 错误(通常在等待永远不会到来的数据一段时间后).

Internet explorer does try to resend the request when this happens, but when 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).

Microsoft 将此错误记录为 KB 895954(请参阅 http://support.microsoft.com/kb/895954).微软首先在 IE 6 中发现了这个错误.他们提供了一个修补程序，并且从那时起，包括 IE 9 在内的每个版本的 IE 似乎都提供了这个修补程序.这个修复程序有两个问题:

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:

1. 默认情况下不激活修补程序.您必须使用 regedit 创建一个非常奇怪的密钥才能激活修复程序:HKEY_LOCAL_MACHINESoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954.

1. The hotfix is not activated by default. You have to create a really weird key using regedit to activate the fix: HKEY_LOCAL_MACHINESoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954.

修复并没有真正解决问题.固定"行为是当尝试发送请求时连接关闭时，它甚至不会尝试重新发送它.它只是将错误传递给 javascript 应用程序.

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.

看来您必须在代码中添加错误处理程序，并在失败时自己重新发布请求.我正在为我的应用程序寻找这个解决方案.我担心的是，我不确定如何判断我得到的错误是由尝试发送查询失败引起的，还是由于查询而从服务器发回的某些错误(在这种情况下我不知道)想重发).

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).

我编写了一个 C 程序来模拟 Web 服务器并显式关闭连接以查看浏览器如何处理它.我发现 IE 可以 100% 的时间重现错误行为，而 Firefox、Safari 和 Chrome 可以通过在另一个连接上 100% 的时间正确重新发送 POST 来恢复.也许答案是不要使用 IE."

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."

这篇关于JQuery Ajax post 参数有时不会在 IE 上发送的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！