JQuery的阿贾克斯后的参数有时无法在IE浏览器发送 [英] JQuery Ajax post parameters sometimes not sent on IE

问题描述

我遇到的问题是，当我使用jQuery阿贾克斯后，以非常低的频率（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).

当我切换通话从类型后键入得到的问题消失了。

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

更新：通过缓存：假不能解决问题

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

推荐答案

我花了上周在自己的应用程序跟踪一个类似的问题（使用道场，不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).

互联网浏览器的确实的尝试重新发送请求时发生这种情况，，但的时候恰好是一个POST，它轧液它通过发送头（有内容 - 长度），但没有实际的数据。这是一个畸形的请求，并应经常导致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. 的修补程序默认情况下不激活。您可以使用注册表编辑器激活此修复程序创建一个非常奇怪的项：HKEY_LOCAL_MACHINE \ SOFTWARE \微软\的Internet Explorer \ MAIN \ FeatureControl \ FEATURE_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_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_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.

看来，你有，如果它没有添加错误处理程序在code和重新发布的要求自己。我期待到该解决方案为我的应用程序。我担心的是，我不知道如何判断我的错误是一次失败的尝试导致发送查询，或者从服务器返回的查询结果的一些错误（在这种情况下，我不要重新发送）。

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恢复通过适当重新发送POST上的另一个连接的时间100％。也许答案是，不使用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的阿贾克斯后的参数有时无法在IE浏览器发送的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！