September, 2009

DESCRIPCIÓN DEL PROBLEMA

Tenéis una aplicación ASP.NET que requiere certificados de cliente y en la que realizan peticiones HTTP de gran tamaño (por ejemplo un POST HTTP adjuntando ficheros). Cuando el tamaño de la petición (o el fichero adjunto) supera un determinado límite falla, y en los logs de IIS vemos el error HTTP 413 – Request entity too large. Si la aplicación cliente es .NET, la petición HTTP o llamada a web service fallará, y veremos el siguiente mensaje de error asociado:

The underlying connection was closed: An unexpected error occurred on a send.

O su variante en castellano:

Se ha terminado la conexión: Error inesperado de envío

RESOLUCIÓN

Ver el post Detalles sobre el error HTTP 413.

Happy hacking

- Daniel Mossberg

Hoy quería escribir sobre caso en el que trabajé hace unas semanas, no por la complejidad del problema, si no por mostrar un ejemplo de cómo abordar un problema y qué herramientas utilizar cuando no tienes ni idea de por dónde van los tiros. Los datos iniciales que tenía del problema era que el cliente tenía un portal de SharePoint en el que todas las páginas le daban errores HTTP 401 si habilitaba la autenticación de Windows integrada. Si configuraba autenticación básica o acceso anónimo los portales funcionaban correctamente.

Mi primera hipótesis fue que probablemente los errores se debían a un problema en la configuración de Kerberos, pero pronto descubrí que tenían configurada únicamente la autenticación por NTLM. Kerberos estaba deshabilitado en la configuración de IIS:

C:\Inetpub\AdminScripts>cscript adsutil.vbs get W3SVC/1/NTAuthenticationProviders

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

NTAuthenticationProviders       : (STRING) "NTLM"

Puesto que no tenía ni idea de cuál podría ser la causa de este comportamiento, le pedí los siguientes logs al cliente:

·         La metabase de IIS (en Windows Server 2003 se encuentra en la siguiente ruta: %WINDIR%\system32\inetsrv\metabase.xml).

·         Los logs de IIS.

·         Unas trazas de red capturadas mientras reproducían el error.

Examinando los logs de IIS veíamos los errores HTTP 401, pero no arrojaban luz sobre el origen del problema:

#Fields: date time s-sitename … sc-status sc-substatus sc-win32-status

2009-09-16 14:37:46 W3SVC1 … 401 2 2148074254

2009-09-16 14:37:46 W3SVC1 … 401 1 0

Yo esperaba encontrar alguna pista al menos a partir del estado win32, pero el estado 2148074254 (No credentials are available in the security package) en la primera petición es esperado (ver el siguiente post para más detalles), y en la segunda petición el resultado era 0 (The operation completed successfully). Y lo más extraño de todo, es que no se registraba una tercera y última petición para finalizar la secuencia de autenticación como sería lo normal (de nuevo, ver el post al que hacía referencia antes).

Analizando las trazas de red veíamos la secuencia de peticiones habitual durante el handshake NTLM, pero cuando el cliente hace la petición final autenticada (en el frame TCP 5004), en el siguiente frame TCP el cliente cierra la conexión TCP deliberadamente ([FIN, ACK]) y por tanto la respuesta del IIS nunca llega.