Pourquoi Internet Explorer pas envoie-t-il corps post HTTP sur appel Ajax après l’échec ?

Question

Nous sommes en mesure fiable de recréer le scénario suivant:

1. Créer une petite page HTML qui fait une requête AJAX vers un serveur (à l'aide de HTTP POST)
2. Débranchez-le du réseau et de le reconnecter
3. Surveiller les paquets que IE génère, après l'échec

Après un échec de connexion réseau, c'est à dire, la prochaine requête AJAX, mais seulement envoie l' en-tête HTTP (pas le corps) lors de la post HTTP. Cela provoque toutes sortes de problèmes sur le serveur en tant qu'il est seulement une partie de la demande. Google cette question avec Bing et vous trouverez beaucoup de gens se plaignent "aléatoire des erreurs de serveur" à l'aide d'AJAX ou inexpliquée AJAX échecs.

Nous savons que IE (contrairement à la plupart des autres navigateurs) envoie toujours un HTTP POST comme DEUX paquets TCP/IP. L'en-tête et le corps est envoyé séparément. Dans le cas directement après un échec, c'est à dire uniquement envoie l'en-tête.

Donc ma question est, pourquoi faut-il se comporter de cette façon? Il semble erroné basé sur la spécification HTTP et les autres navigateurs ne se comportent pas de cette façon. Est-ce simplement un bug? Certes, cela crée des ravages dans toute graves AJAX basé sur le Web application.

Des informations de référence.

Il y a un problème similaire, déclenchée par HTTP keep-alive délais d'attente qui sont plus courtes que 1 minute et est documenté ici:

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

Voici l'avant et l'après l'échec des captures de paquets:

Remarquez comment l'en-Tête HTTP et de la Charge utile est envoyé http://img827.imageshack.us/i/beforee.png/

Après un échec, notez que l'en-Tête est envoyé. IE ne jamais envoie la charge utile et le serveur finalement répond avec un Délai d'attente. http://img203.imageshack.us/i/retryt.png/

Answer 1

Il ne semble pas être une réponse claire à cette question, donc je vais donner mes données empiriques comme un substitut et de fournir des moyens de le contourner. Peut-être que certains états membres ont initié un jour faire la lumière sur cette...

1. Si HTTP Keep-Alive est désactivé sur le serveur, ce problème disparaît. En d'autres termes, votre serveur HTTP 1.1 permettra de répondre à chaque requête Ajax avec un Connection: Close ligne dans la réponse. Cela permet de maintenir IE heureux, mais provoque chaque requête Ajax pour ouvrir une nouvelle connexion. Cela peut avoir un impact significatif sur les performances, en particulier sur les réseaux à forte latence.

2. La question est déclenchée facilement si les requêtes Ajax sont prises en succession rapide. Par exemple, nous faisons des requêtes Ajax chaque 100ms et puis l'état du réseau change, l'erreur est facile à reproduire. Bien que la plupart des applications sans doute ne pas faire de telles demandes, vous pourriez bien avoir un couple d'appels vers le serveur passe les uns après les autres ce qui pourrait conduire à ce problème. Moins bavard garde IE heureux.

3. Il arrive même sans l'authentification NTLM.

4. Cela se produit lorsque votre HTTP keep-alive délai d'attente sur le serveur est plus courte que la valeur par défaut (qui par défaut est de 60 secondes sur Windows). Les renseignements fournis dans le lien en question.

5. Il n'arrive pas avec Chrome ou Firefox. FF envoie un paquet semble éviter ce problème tout à fait.

6. Il arrive dans IE 6, 7, 8. Ne pouvaient pas se reproduire avec IE 9 beta.

Answer 2

L’article de KB microsoft intitulé lorsque vous utilisez Microsoft Internet Explorer ou un autre programme pour effectuer une opération de re-poster, seules les données d’en-tête sont affichées semble corriger ce problème.

L’article fournit un correctif. Pour les navigateurs plus tard comme IE8, il indique le correctif est déjà inclus, mais doit être activé dans les paramètres du Registre sur l’ordinateur client.

Answer 3

J'ai eu un problème similaire où certaines anciennes versions d'IE ne renvoient que l'en-tête et non le corps d'un POST. Mon problème s'est avéré être lié à IE et NTLM. Comme vous n'avez pas mentionné NTLM, cela n'aide probablement pas, mais juste au cas où:

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

Answer 4

C'est un longshot, mais IE (et même Firefox) parfois "se souvient" de l' la connexion qu'il utilise pour une requête HTTP. Des Notes et des exemples:

• Dans Firefox, si je change les paramètres de proxy et appuyez sur MAJ-RECHARGER sur une page, on utilise encore l'ancien proxy. Cependant, si je tue le vieux proxy ("killall calmar"), il commence à utiliser le proxy nouveau.

• Lorsque vous se déconnecter/reconnecter, recevez-vous une nouvelle adresse IP ou quelque chose de semblable? Pouvez-vous en quelque sorte le moniteur de l'ancienne adresse IP pour voir si IE est l'envoi de données pour que, maintenant morts adresse?

• Ma conjecture est que IE est d'envoyer les données, juste en bas de la mauvaise chemin d'accès. Il pourrait être assez intelligent pour ne pas mettre en cache les connexions réseau pour "POST" paquets, mais pourrait ne pas être assez intelligents pour le faire pour le POST les charges utiles.

• C'est probablement ce qui n'affecte pas la plupart des applications AJAX, puisque les gens rarement de le déconnecter et de se re-connecter à leurs réseaux?

Answer 5

Utilisez-vous l'authentification NTLM?

Lors de l'utilisation de l'authentification NTLM, IE n'envoie pas de post-données. Il envoie des informations d'en-tête, attend une autorisation d'envoi de réponse non autorisée, et après l'envoi de la nouvelle authentification.