Share via

Solución de problemas de errores HTTP 400 en IIS

  • Artículo

por Mike Laing

Herramientas usadas en este solucionador de problemas:

  • Monitor de red
  • Registro de errores HTTP

Este material se proporciona únicamente con fines informativos. Microsoft no ofrece garantía alguna, ya sea expresa o implícita,

Información general

Después de enviar una solicitud HTTP a un servidor IIS, un cliente HTTP (como Internet Explorer) puede mostrar el siguiente tipo de mensaje de error:

HTTP 400No se encuentra la página web.

Las causas más probables son:

  • Podría haber un error tipográfico en la dirección.
  • Si ha realizado clic en un vínculo, puede que no esté actualizado.

Lo que puede probar:

  • Vuelva a escribir la dirección.
  • Volver a la página anterior.
  • Vaya a Bing y busque la información que desee.

Si el cliente HTTP es Internet Explorer y la opción Mostrar mensajes de error HTTP descriptivos está desactivada, el error puede parecerse a lo siguiente:

Solicitud incorrecta

En estos escenarios, IIS ha rechazado la solicitud HTTP del cliente porque la solicitud no cumple las reglas de análisis HTTP del servidor, o ha superado los límites de tiempo, o ha superado algún otro tipo de regla que IIS o HTTP.sys requiera solicitudes entrantes para cumplir. IIS devuelve el estado HTTP 400 - Solicitud incorrecta al cliente y, a continuación, finaliza la conexión TCP.

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 exactamente lo que el cliente envía 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 para ver los datos de respuesta sin procesar que IIS devuelve al cliente. También puede usar una herramienta de búfer HTTP denominada Fiddler; esta es una excelente herramienta, ya que 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 desea usar es el C:\Windows\System32\LogFiles\HTTPERR\httperr.log archivo . A partir de IIS 6.0, el componente de HTTP.sys controla las solicitudes HTTP entrantes antes de pasarlas a IIS y es el componente responsable de bloquear las solicitudes que no cumplen los requisitos de IIS. Cuando HTTP.sys bloquea la solicitud, registrará 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 HTTP.sys proporciona, consulte el siguiente artículo:

Técnicamente es posible, aunque no es muy probable que un cliente reciba una respuesta HTTP 400 que no tenga una entrada de registro asociada en httperr.log. Esto podría ocurrir si un filtro o 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 podría 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".

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 respuesta, vemos la siguiente solicitud o respuesta sin procesar:

PETICIÓN:

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)

Observará que los encabezados de respuesta no nos indican tanto como el mensaje de error en el explorador. Sin embargo, si examinamos los datos sin procesar en el cuerpo de la respuesta, veremos 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 se muestra en el explorador también se puede ver en los datos de respuesta sin procesar en el seguimiento de red.

El siguiente paso es examinar el archivo httperr.log en el C:\Windows\System32\LogFiles\HTTPERR directorio 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 campo Motivo del archivo httperr.log nos proporciona la información exacta que necesitamos para diagnosticar el problema. Aquí vemos que HTTP.sys fieldLength registrado como la frase de motivo del error de esta solicitud. Una vez que sepamos la frase de motivo, podemos usar el artículo registro de errores en la API HTTP mencionado anteriormente para obtener su descripción:

FieldLength: A field length limit was exceeded.

Por lo tanto, en este momento sabemos desde el 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 superó los límites de longitud permitidos. Para este ejemplo, el encabezado HTTP: Identificador uniforme de recursos es largo de forma intencionada: /1234567890123456789012345678901234567890/time.asp.

La última fase de solución de problemas de este ejemplo es usar el siguiente artículo para ver las claves del Registro de HTTP.sys y la configuración predeterminada de IIS:

Dado que sabemos que la frase y el error de motivo sugieren que una longitud de campo de encabezado supere los límites, podemos restringir nuestra búsqueda en KB820129 como tal. El candidato principal aquí es:

MaxFieldLength: establece un límite superior para cada encabezado. Consulte MaxRequestBytes. Este límite se traduce en aproximadamente 32 000 caracteres para una dirección URL.

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

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 esto ocurre, 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 el siguiente artículo de Knowledge Base:

Otros recursos