Les journaux IIS affichent sc-win32-status = 64 mais uniquement via certains réseaux

J'ai une application ASP.NET exécutée sur un serveur client (W2k3, IIS6, .NET 2.0). FWIW, il s'agit d'une instance de test , elle n'a pas encore été déplacée en production . Il ne fonctionne donc pas sous SSL, l'équilibrage de charge, etc.

Lorsque j'accède à l'une des pages de leur serveur depuis notre bureau, la page est affichée une fois. L'inspection des journaux IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) affiche un GET pour cette page, puis j'appuie sur un bouton de la page et le fichier journal affiche un POST. Cela semble bien fonctionner jusqu'à présent.

Maintenant, lorsque je me connecte au réseau du client et accède à la page à partir de l'une de leurs machines locales, le fichier journal affiche un GET, puis j'appuie sur le bouton de la page et le journal affiche deux POST à ​​la même seconde. Le premier affiche le statut (sc-status, sc-substatus, sc-win32-status) 200 0 64, le second affiche 200 0 0.

Dans le fichier journal, les deux POST sont identiques. Fondamentalement, le journal ressemble à ceci (sauf que j'ai masqué certaines données):

#Fields: date heure s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs (User-Agent) sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - aaaa Mozilla / 4.0 + (compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 0
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - aaaa Mozilla / 4.0 + (compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 64
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - aaaa Mozilla / 4.0 + (compatible; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 0

Le problème est que la page est frappée deux fois. La base de données effectue une opération pour la première demande, puis la deuxième demande détecte qu'une opération en double est en cours et émet un message d'erreur. Les utilisateurs pensent que leur opération a échoué, mais elle a réussi.

La description d'erreur de sc-win32-status 64 est: "Le nom de réseau spécifié n'est plus disponible." Cela m'amène à croire, étant donné que les deux demandes POST affichent un état HTTP 200, que le serveur réussit à servir la demande, mais le client n'est jamais averti et soumet à nouveau la demande.

• Comment puis-je résoudre ce problème?

• Des idées sur ce qui pourrait être à l'origine de ce comportement sur leur réseau interne uniquement?

• Je dois mentionner que cela se produit sur deux sites clients distincts, mais ne se produit pas sur six de nos autres sites clients, ou dans nos bureaux, ou en se connectant à l'un de nos huit clients sur le Web.

• Qu'est-ce qui pourrait rendre cela reproductible 100% du temps sur leur réseau local mais 0% du temps ailleurs?

Mise à jour: J'ai trouvé qu'un très petit nombre des demandes POST dupliquées avaient un statut sc-win32 de 995 au lieu de 64 comme indiqué initialement. La description d'erreur de sc-win32-status = 995 est: "L'opération d'E / S a été abandonnée en raison d'une sortie de thread ou d'une demande d'application." Cela n'a aucun sens (étant donné que j'ai un accès complet au code). Je ne comprends toujours pas comment ou pourquoi ce problème se produit, mais le nouveau code d'erreur me porte à croire qu'il ne s'agit peut-être pas d'un problème de réseau après tout et j'étudie maintenant la possibilité d'un bogue de code aléatoire.

Voici ma compréhension du problème jusqu'à présent:

• sc-win32-status 64 signifie "Le nom de réseau spécifié n'est plus disponible."
• Une fois qu'IIS a envoyé la réponse finale au client, il attend généralement un message ACK du client.
• Parfois, les clients réinitialisent la connexion au lieu de renvoyer l'ACK final au serveur. Ce n'est pas une fermeture de connexion gracieuse, donc IIS enregistre le code "64".
• De nombreux clients réinitialisent la connexion lorsqu'ils en ont fini, pour libérer le socket au lieu de le laisser dans TIME_WAIT / CLOSE_WAIT.
• Les mandataires ont tendance à le faire plus que d'autres.

Mise à jour: J'ai trouvé des informations intéressantes ici et ici , donc j'ai essentiellement réécrit la page pour m'assurer qu'il n'y avait pas de mauvais balisage, etc. et ... le problème a maintenant disparu! Ce n'était qu'un coup de feu dans le noir, et je ne pouvais pas vraiment dire ce qui avait résolu le problème, car cela n'affectait certains de nos clients que dans des circonstances très spécifiques ...

J'ai rencontré ce même problème lorsque j'essayais de servir des fichiers binaires compressés à partir d'IIS6 via un serveur proxy. Je n'ai rencontré aucun problème lorsque j'allais directement sur le site Web.

J'ai trouvé que c'était la cause dans mon cas en exécutant Fiddler sur une machine cliente et en inspectant la réponse. Fiddler avertit que la réponse est codée et se plaint ensuite que le nombre magique sur le fichier gzip n'était pas correct.

J'ai désactivé la compression gzip pour les fichiers binaires dans mon code et le problème a cessé de se produire.

Je ne suis pas un expert en la matière, mais j'ai rencontré un problème similaire qui ne s'est produit que lors de l'utilisation d'une adresse IP plutôt que d'un nom d'hôte.

Peut-être que cela aide un peu ...

Tapis.