Les journaux IIS montrent sc-win32-status=64 mais uniquement à travers certains réseaux

J’ai une application ASP.NET fonctionnant sur un serveur client (W2k3, IIS6, .NET 2.0). Pour information, c’est une instance de test, elle n’a pas encore été mise en production. Elle ne fonctionne donc pas sous SSL, équilibrage de charge, etc.

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

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

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

#Fields: date time 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 x.x.x.x GET /File.aspx - 80 - y.y.y.y 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 x.x.x.x POST /File.aspx - 80 - y.y.y.y 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 x.x.x.x POST /File.aspx - 80 - y.y.y.y 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 appelée deux fois. La base de données effectue une opération pour la première requête, puis la seconde requête détecte qu’une opération en double est en cours et renvoie un message d’erreur. Les utilisateurs pensent que leur opération a échoué, mais elle a en fait réussi.

La description de l’erreur sc-win32-status 64 est : « Le nom réseau spécifié n’est plus disponible. » Cela m’amène à croire, étant donné que les deux requêtes POST montrent un statut HTTP de 200, que le serveur réussit à servir la requête, mais que le client n’est jamais notifié et resoumet la requête.

Comment puis-je dépanner cela ?

Des idées sur ce qui pourrait causer ce comportement uniquement sur leur réseau interne ?

Je devrais mentionner que cela se produit sur deux sites clients distincts, mais ne se produit pas sur six de nos autres sites clients, ni dans notre bureau, ni en se connectant à l’un de nos huit clients via le web.

Qu’est-ce qui pourrait rendre cela reproductible à 100% sur leur réseau local mais à 0% partout ailleurs ?

Mise à jour : J’ai trouvé un très petit nombre de requêtes POST dupliquées avec un sc-win32-status de 995 au lieu du 64 initialement signalé. La description de l’erreur sc-win32-status=995 est : « L’opération d’E/S a été abandonnée en raison de la fin d’un 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 ni pourquoi ce problème se produit, mais le nouveau code d’erreur m’amène à croire qu’il ne s’agit peut-être pas d’un problème réseau après tout et j’enquête maintenant sur 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 réseau spécifié n’est plus disponible. »

  • Après 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 d’envoyer 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 terminé avec elle, pour libérer le socket au lieu de le laisser en TIME_WAIT/CLOSE_WAIT.

  • Les proxys ont tendance à faire cela plus que les autres.

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