Warum sendet Internet Explorer nach einem Fehler keinen HTTP-Post-Body beim Ajax-Aufruf?

Wir können das folgende Szenario zuverlässig neu erstellen:

1. Erstellen Sie eine kleine HTML-Seite, die AJAX-Anforderungen an einen Server sendet (mithilfe von HTTP POST).
2. Trennen Sie die Verbindung zum Netzwerk und stellen Sie die Verbindung wieder her
3. Überwachen Sie die Pakete, die der IE nach dem Fehler generiert

Nach einer fehlgeschlagenen Netzwerkverbindung stellt der IE die nächste AJAX-Anforderung, sendet jedoch nur den HTTP-Header (nicht den Body), wenn der HTTP-Beitrag ausgeführt wird. Dies verursacht alle möglichen Probleme auf dem Server, da es sich nur um eine Teilanforderung handelt. Google dieses Problem mit Bing und Sie werden viele Leute finden, die sich über "zufällige Serverfehler" mit AJAX oder ungeklärte AJAX-Fehler beschweren.

Wir wissen, dass der IE (im Gegensatz zu den meisten anderen Browsern) einen HTTP-POST immer als ZWEI TCP / IP-Pakete sendet. Der Header und der Body werden separat gesendet. Im Fall direkt nach einem Fehler sendet der IE nur den Header . IE sendet niemals die Nutzdaten und der Server antwortet schließlich mit einem Timeout.

Meine Frage ist also - warum verhält es sich so? Aufgrund der HTTP-Spezifikation scheint dies falsch zu sein, und andere Browser verhalten sich nicht so. Ist es einfach ein Fehler? Dies führt sicherlich zu Chaos in jeder ernsthaften AJAX-basierten Webanwendung.

Referenzinformationen:

Es gibt ein ähnliches Problem, das durch HTTP-Keep-Alive-Timeouts ausgelöst wird, die kürzer als 1 Minute sind und hier dokumentiert sind:

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

Es scheint keine klare Antwort auf diese Frage zu geben, daher werde ich meine empirischen Daten als Ersatz bereitstellen und einige Möglichkeiten zur Umgehung dieser Probleme bereitstellen. Vielleicht wird eines Tages ein MS-Insider etwas Licht ins Dunkel bringen ...

1. Wenn HTTP Keep-Alive auf dem Server deaktiviert ist , wird dieses Problem behoben. Mit anderen Worten, Ihr HTTP 1.1-Server antwortet auf jede Ajax-Anfrage mit einer Connection: CloseZeile in der Antwort. Dies macht den IE glücklich, führt jedoch dazu, dass bei jeder Ajax-Anforderung eine neue Verbindung hergestellt wird. Dies kann erhebliche Auswirkungen auf die Leistung haben, insbesondere in Netzwerken mit hoher Latenz.

2. Das Problem wird leicht ausgelöst, wenn Ajax-Anfragen schnell hintereinander gestellt werden. Zum Beispiel stellen wir alle 100 ms Ajax-Anfragen und dann ändert sich der Netzwerkstatus. Der Fehler ist leicht zu reproduzieren. Obwohl die meisten Anwendungen solche Anfragen wahrscheinlich nicht stellen, werden möglicherweise einige Serveraufrufe direkt nacheinander ausgeführt, was zu diesem Problem führen kann. Weniger gesprächig macht IE glücklich.

3. Dies geschieht auch ohne NTLM-Authentifizierung.

4. Dies tritt auf, wenn Ihr HTTP-Keep-Alive-Timeout auf dem Server kürzer als der Standard ist (unter Windows standardmäßig 60 Sekunden). Details finden Sie im betreffenden Link.

5. Dies ist bei Chrome oder Firefox nicht der Fall. FF sendet ein Paket und scheint dieses Problem insgesamt zu vermeiden.

6. Es passiert in IE 6, 7, 8. Konnte nicht mit IE 9 Beta reproduzieren.

Der Microsoft KB-Artikel mit dem Titel Wenn Sie Microsoft Internet Explorer oder ein anderes Programm verwenden, um einen erneuten POST-Vorgang auszuführen, scheint dieses Problem nur durch die veröffentlichten Header-Daten behoben zu werden.

Der Artikel enthält einen Hotfix. Für spätere Browser wie IE8 heißt es, dass der Hotfix bereits enthalten ist, aber über die Registrierungseinstellungen auf dem Client-PC aktiviert werden muss .

Ich hatte ein ähnliches Problem, bei dem einige ältere Versionen des IE nur den Header und nicht den Text eines POST zurücksendeten. Es stellte sich heraus, dass mein Problem mit IE und NTLM zusammenhängt. Da Sie NTLM nicht erwähnt haben, hilft dies wahrscheinlich nicht, aber nur für den Fall:

http://support.microsoft.com/kb/251404

Dies ist ein Longshot, aber der IE (und sogar Firefox) "erinnert" sich manchmal an die Verbindung, die er für eine HTTP-Anforderung verwendet. Anmerkungen / Beispiele:

• Wenn ich in Firefox die Proxy-Einstellungen ändere und auf einer Seite UMSCHALT-RELOAD drücke, wird weiterhin der alte Proxy verwendet. Wenn ich jedoch den alten Proxy ("killall squid") töte, wird der neue Proxy verwendet.

• Erhalten Sie beim Trennen / erneuten Verbinden eine neue IP-Adresse oder ähnliches? Können Sie die alte IP-Adresse irgendwie überwachen, um festzustellen, ob der IE Daten an diese jetzt tote Adresse sendet?

• Ich vermute, dass der IE die Daten auf dem falschen Weg sendet. Es ist möglicherweise intelligent genug, Netzwerkverbindungen nicht für "POST" -Pakete zwischenzuspeichern, aber möglicherweise nicht intelligent genug, um dies für POST-Nutzdaten zu tun.

• Dies betrifft wahrscheinlich nicht die meisten AJAX-Apps, da Benutzer selten die Verbindung zu ihren Netzwerken trennen und erneut herstellen.

Verwenden Sie die NTLM-Authentifizierung?

Bei Verwendung der NTLM-Authentifizierung sendet der IE keine Postdaten. Es sendet Header-Informationen, erwartet eine nicht autorisierte Antwort-Sendeberechtigung und sendet nach der erneuten Authentifizierung den Beitrag.

Ich hatte heute ein ähnliches Problem bei der Verwendung von $ .ajax und konnte es beheben, indem ich async auf false setzte.

$.ajax({
  async: false, 
  url: '[post action url]',
  data: $form.serialize(),
  type: 'POST',
  success: successCallback
});