Compartir a través de

Solución de problemas de errores HTTP 400 en IIS

Se aplica a: Internet Information Services

Este artículo describe los pasos de solución de problemas para identificar la causa de varios errores HTTP 400 al usar IIS.

Información general

Después de que un cliente HTTP (como Microsoft Edge) envíe una solicitud HTTP a un servidor IIS, podría mostrar el siguiente tipo de mensaje de error:

HTTP 400: solicitud incorrecta

En este escenario, IIS rechaza la solicitud HTTP del cliente porque la solicitud no cumple las reglas de análisis HTTP del servidor, supera los límites de tiempo o produce un error en otras reglas a las que IIS o HTTP.sys requiere que se cumplan las solicitudes entrantes. IIS devuelve el HTTP 400 - Bad Request estado al cliente y, a continuación, finaliza la conexión TCP.

Herramientas

Métodos de solución de problemas

Al solucionar problemas de una condición HTTP 400, es importante recordar que el problema subyacente es que el cliente ha enviado una solicitud a IIS que interrumpe una o varias reglas que HTTP.sys está aplicando. Teniendo esto en cuenta, querrá ver lo que el cliente envía exactamente a IIS. Para ello, capture un seguimiento de red del cliente que envía la solicitud incorrecta. Puede analizar el seguimiento para ver los datos sin procesar que el cliente envía a IIS y los datos de respuesta sin procesar que IIS envía al cliente. También puede usar una herramienta de búfer HTTP denominada Fiddler, una excelente herramienta, ya que le permite ver los encabezados HTTP incluso si el cliente y el servidor se comunican a través de SSL.

El siguiente elemento de datos que usa es el archivo C:\Windows\System32\LogFiles\HTTPERR\httperr.log . En IIS, el componente HTTP.sys controla las solicitudes HTTP entrantes antes de pasarlas a IIS y es responsable de bloquear las solicitudes que no cumplen los requisitos de IIS. Cuando HTTP.sys bloquea la solicitud, registra información en su archivo httperr.log relativo a la solicitud incorrecta y por qué se bloqueó.

Nota:

Para obtener más información sobre el registro de errores de la API HTTP que proporciona HTTP.sys, consulte Registro de errores en la API HTTP.

Técnicamente es posible, aunque no es muy probable que un cliente reciba una respuesta HTTP 400, que no tiene una entrada de registro asociada en el archivo httperr.log . Podría ocurrir si un filtro o una extensión ISAPI, o un módulo HTTP en IIS, establece el estado 400, en cuyo caso podría examinar el registro de IIS para obtener más información. También puede ocurrir si una entidad entre el cliente y el servidor, como un servidor proxy u otro dispositivo de red, intercepta una respuesta de IIS e invalida con su propio estado 400 y/o "Solicitud incorrecta".

Nota:

En este artículo se describen principalmente los errores HTTP 400 comunes antes de llegar al sitio web. En algunos escenarios, el sitio web también podría devolver errores HTTP 400 a los clientes debido a la lógica de código personalizada o al entorno de ejecución (por ejemplo, ASP.NET). Si todavía no puede resolver los errores HTTP 400 después de realizar los pasos de las secciones siguientes, intente solucionar problemas mediante la característica Seguimiento de solicitudes con error en IIS. Si encuentra que el controlador de tiempo de ejecución correspondiente del sitio web establece los errores HTTP 400, como ASP.NET, es posible que tenga que inspeccionar los detalles de las solicitudes y respuestas, junto con la lógica de código relacionada del sitio web y la configuración en tiempo de ejecución, para comprender la causa de los errores HTTP 400.

Escenario de ejemplo

A continuación se muestra un ejemplo de un escenario HTTP 400, donde un cliente envía una solicitud incorrecta a IIS y el servidor devuelve un mensaje "HTTP 400 - Solicitud incorrecta".

Cuando el cliente envía su solicitud, el error del explorador que devuelve tiene el siguiente aspecto:

Solicitud incorrecta (campo de encabezado demasiado largo)

Captura de un seguimiento de red de la solicitud y la respuesta, verá las siguientes salidas:

PEDIR:

HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/1234567890123456789012345678901234567890/time.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept-Language =en-us
HTTP: UA-cpu =x86
HTTP: Accept-Encoding =gzip, deflate
HTTP: Host =iisserver
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 14 (0x000E)

RESPUESTA:

HTTP: Response to Client; HTTP/1.1; Status Code = 400 - Bad Request
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Bad Request
HTTP: Reason =Bad Request
HTTP: Content-Type =text/html
HTTP: Date =Wed, 14 Nov 2012 20:36:36 GMT
HTTP: Connection =close
HTTP: Content-Length =44
HTTP: Data: Number of data bytes remaining = 63 (0x003F)

Observe que los encabezados de respuesta no indican tanto como el mensaje de error en el explorador. Sin embargo, si examina los datos sin procesar en el cuerpo de la respuesta, verá más:

00000030                                           48 54               HT
00000040 54 50 2F 31 2E 31 20 34 30 30 20 42 61 64 20 52 TP/1.1.400.Bad.R
00000050 65 71 75 65 73 74 0D 0A 43 6F 6E 74 65 6E 74 2D equest..Content-
00000060 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type:.text/html.
00000070 0A 44 61 74 65 3A 20 57 65 64 2C 20 32 38 20 4A .Date:.Wed,.28.J
00000080 61 6E 20 32 30 30 39 20 32 30 3A 33 36 3A 33 36 an.2009.20:36:36
00000090 20 47 4D 54 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E .GMT..Connection
000000A0 3A 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 :.close..Content
000000B0 2D 4C 65 6E 67 74 68 3A 20 34 34 0D 0A 0D 0A 3C -Length:.44....<
000000C0 68 31 3E 42 61 64 20 52 65 71 75 65 73 74 20 28 h1>Bad.Request.(
000000D0 48 65 61 64 65 72 20 46 69 65 6C 64 20 54 6F 6F Header.Field.Too
000000E0 20 4C 6F 6E 67 29 3C 2F 68 31 3E 01 02 03 04 05 .Long).....
000000F0 05 06 0E 94 63 D6 68 37 1B 8C 16 FE 3F D5       ....c.h7....?.

Puede ver que el texto del mensaje de error que aparece en el explorador también se puede ver en los datos de respuesta sin procesar en el seguimiento de red.

El siguiente paso consiste en examinar el archivo httperr.log en el directorio C:\Windows\System32\LogFiles\HTTPERR de la entrada que corresponde a la solicitud incorrecta:

#Software: Microsoft HTTP API 1.0
#Version: 1.0
#Date: 2012-11-14 20:35:02
#Fields: date time cs-version cs-method cs-uri sc-status s-reason 
2012-11-14 20:36:36 HTTP/1.1 GET /1234567890/time.asp 400 FieldLength

En este escenario, el Reason campo del archivo httperr.log proporciona la información exacta que necesita para diagnosticar el problema. Verá que HTTP.sys registró FieldLength como la frase de motivo del error de esta solicitud. Una vez que sepa la frase de motivo, compruebe la tabla en Tipos de errores que la sección registros de LA API HTTP para obtener su descripción:

FieldLength: se superó un límite de longitud de campo.

Por lo tanto, en este momento sabe del mensaje de error del explorador y el registro de errores de la API HTTP que la solicitud contenía datos en uno de sus encabezados HTTP que superaban los límites de longitud permitidos. En este ejemplo, el HTTP: Uniform Resource Identifier header valor de es largo intencionadamente: /1234567890123456789012345678901234567890/time.asp.

La última fase de solución de problemas de este ejemplo es comprobar las claves del Registro de HTTP.sys y la configuración predeterminada de IIS.

Como sabe la frase de motivo y el error sugieren que una longitud de campo de encabezado supere los límites, puede restringir nuestra búsqueda en la tabla Claves del Registro como tal. El candidato principal es:

Clave del Registro Valor predeterminado Intervalo de valores válido Función de clave del Registro Código DE ADVERTENCIA
MaxFieldLength 16384 64 - 65534 (64k - 2) bytes Establece un límite superior para cada encabezado. Vea MaxRequestBytes. Este límite son aproximadamente 32 000 caracteres para una dirección URL. 1

Para reproducir este error en este ejemplo, la clave del MaxFieldLength Registro se estableció con un valor de 2. Dado que la dirección URL solicitada tenía un HTTP: Uniform Resource Identifier header campo con más de dos caracteres, la solicitud se bloqueó con la FieldLength frase de motivo.

Otro escenario común de HTTP 400 es uno en el que el usuario que realiza la solicitud HTTP es miembro de un gran número de grupos de Active Directory y el sitio web está configurado para la autenticación Kerberos de usuario. Cuando se produce este escenario, se mostrará un mensaje de error similar al siguiente al usuario:

Solicitud incorrecta (encabezado de solicitud demasiado largo)

En este escenario, el token de autenticación que se incluye como parte de la solicitud HTTP del cliente es demasiado grande y supera los límites de tamaño que http.sys está aplicando. Este problema se describe en detalle, junto con la solución, en HTTP 400 - Solicitud incorrecta (encabezado de solicitud demasiado larga) respuestas a solicitudes HTTP.

Referencias