Los registros de IIS muestran sc-win32-status = 64 pero solo a través de algunas redes

Tengo una aplicación ASP.NET que se ejecuta en un servidor cliente (W2k3, IIS6, .NET 2.0). FWIW, esta es una instancia de prueba , aún no se ha movido a producción . Por lo tanto, no se ejecuta bajo SSL, equilibrio de carga, etc.

Cuando accedo a una de las páginas de su servidor desde nuestra oficina, la página se ve afectada una vez. Inspeccionar los registros de IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) muestra un GET para esa página, luego presiono un botón en la página y el archivo de registro muestra una POST. Esto parece estar funcionando bien hasta ahora.

Ahora, cuando me conecto remotamente a la red del cliente y accedo a la página desde una de sus máquinas locales, el archivo de registro muestra un GET, luego presiono el botón en la página y el registro muestra dos POST en el mismo segundo. El primero muestra el estado (sc-status, sc-substatus, sc-win32-status) 200 0 64, el segundo muestra 200 0 0.

En el archivo de registro, ambos POST son idénticos. Básicamente, el registro se ve así (excepto que enmascaré algunos de los datos):

#Campos: fecha hora 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

El problema es que la página está siendo golpeada dos veces. La base de datos realiza una operación para la primera solicitud, luego la segunda solicitud detecta que se está realizando una operación duplicada y arroja un mensaje de error. Los usuarios piensan que su operación falló, pero en realidad tuvo éxito.

La descripción del error de sc-win32-status 64 es: "El nombre de red especificado ya no está disponible". Esto me lleva a creer, dado que ambas solicitudes POST muestran un estado HTTP de 200, que el servidor tiene éxito en atender la solicitud, pero el cliente nunca es notificado y vuelve a enviar la solicitud.

• ¿Cómo puedo solucionar esto?

• ¿Alguna idea de qué podría estar causando este comportamiento solo en su red interna?

• Debo mencionar que esto está sucediendo en dos sitios de clientes separados, pero no sucede en seis de nuestros otros sitios de clientes, o en nuestra oficina, o conectando a cualquiera de nuestros ocho clientes a través de la web.

• ¿Qué podría hacer que esto sea reproducible el 100% del tiempo en su red local pero el 0% del tiempo en cualquier otro lugar?

Actualización: Encontré que un número muy pequeño de solicitudes POST duplicadas tenía un estado sc-win32-995 en lugar de 64, como se informó originalmente. La descripción del error de sc-win32-status = 995 es: "La operación de E / S se ha cancelado debido a una salida de subproceso o una solicitud de aplicación". Esto no tiene ningún sentido (teniendo en cuenta que tengo acceso completo al código). Todavía no entiendo cómo o por qué está ocurriendo este problema, pero el nuevo código de error me lleva a creer que puede no ser un problema de red después de todo y ahora estoy investigando la posibilidad de un error de código aleatorio.

Esta es mi comprensión del problema hasta ahora:

• sc-win32-status 64 significa "El nombre de red especificado ya no está disponible".
• Después de que IIS ha enviado la respuesta final al cliente, generalmente espera un mensaje ACK del cliente.
• A veces, los clientes restablecerán la conexión en lugar de enviar el ACK final al servidor. Esto no es un cierre de conexión elegante, por lo que IIS registra el código "64".
• Muchos clientes restablecerán la conexión cuando hayan terminado, para liberar el socket en lugar de dejarlo en TIME_WAIT / CLOSE_WAIT.
• Los representantes tienden a hacer esto más que otros.

Actualización: encontré información interesante aquí y aquí , así que básicamente reescribí la página para asegurarme de que no hubiera ningún marcado incorrecto, etc. y ... ¡el problema ya no está! Fue solo un disparo en la oscuridad, y definitivamente no podía decir qué fue lo que solucionó el problema, ya que solo estaba afectando a algunos de nuestros clientes en algunas circunstancias muy específicas ...

Experimenté este mismo problema al intentar servir archivos binarios comprimidos desde IIS6 a través de un servidor proxy. No estaba experimentando ningún problema al ir al sitio web directamente.

Descubrí que esta era la causa en mi caso al ejecutar Fiddler en una máquina cliente e inspeccionar la respuesta. Fiddler advierte que la respuesta está codificada y luego se queja de que el número mágico en el archivo gzip no era correcto.

Desactivé la compresión gzip para archivos binarios en mi código y el problema dejó de ocurrir.

No soy un experto en esto, pero me encontré con un problema similar que solo sucedió al usar una dirección IP en lugar de un nombre de host.

Quizás eso ayude un poco ...

Estera.