Résolution des erreurs HTTP 400 dans IIS

  • Article

S’applique à : Internet Information Services

Cet article décrit les étapes de résolution des problèmes pour identifier la cause de diverses erreurs HTTP 400 lors de l’utilisation d’IIS.

Vue d’ensemble

Après avoir envoyé une requête HTTP à un serveur IIS, un client HTTP (tel qu’Internet Explorer) peut afficher le type de message d’erreur suivant :

HTTP 400La page web est introuvable.

Causes les plus probables :

  • Il peut y avoir une erreur de saisie dans l’adresse.
  • Si vous avez cliqué sur un lien, il est peut-être obsolète.

Ce que vous pouvez essayer :

  • Retapez l’adresse.
  • Retour à la page précédente.
  • Accédez à Bing et recherchez les informations souhaitées.

Si le client HTTP est Explorer Internet et que l’option Afficher les messages d’erreur HTTP conviviaux est désactivée, l’erreur peut ressembler à ceci :

Demande incorrecte (Bad Request)

Dans ces scénarios, IIS a rejeté la requête HTTP du client, car la requête ne répondait pas aux règles d’analyse HTTP du serveur, ou elle a dépassé les limites de temps ou a échoué à une autre règle à laquelle IIS ou HTTP.sys exigent que les requêtes entrantes respectent. IIS renvoie le status « HTTP 400 - Requête incorrecte » au client, puis met fin à la connexion TCP.

Outils

Méthodes de résolution des problèmes

Lors de la résolution d’une condition HTTP 400, il est important de se rappeler que le problème sous-jacent est que le client a envoyé une requête à IIS qui enfreint une ou plusieurs règles que HTTP.sys applique. Dans cette optique, vous souhaiterez voir ce que le client envoie exactement à IIS. Pour ce faire, capturez une trace réseau du client envoyant la requête incorrecte. Vous pouvez analyser la trace pour voir les données brutes que le client envoie à IIS et pour voir les données de réponse brutes qu’IIS renvoie au client. Vous pouvez également utiliser un outil de renifleur HTTP appelé Fiddler, un excellent outil, car il vous permet de voir les en-têtes HTTP même si le client et le serveur communiquent via SSL.

L’élément de données suivant que vous utilisez est le fichier C :\Windows\System32\LogFiles\HTTPERR\httperr.log . À compter d’IIS 6.0, le composant HTTP.sys gère les requêtes HTTP entrantes avant qu’elles ne soient transmises à IIS, et est le composant responsable du blocage des requêtes qui ne répondent pas aux exigences IIS. Lorsque HTTP.sys bloque la demande, il enregistre des informations dans son fichier httperr.log concernant la demande incorrecte et la raison pour laquelle elle a été bloquée.

NOTE: Pour plus d’informations sur la journalisation des erreurs de l’API HTTP que HTTP.sys fournit, consultez Journalisation des erreurs dans l’API HTTP.

Il est techniquement possible, bien que peu probable, qu’un client reçoive une réponse HTTP 400, qui n’a pas d’entrée de journal associée dans le httperr.log. Cela peut se produire si un filtre ou une extension ISAPI ou un module HTTP dans IIS définit la status 400, auquel cas vous pouvez consulter le journal IIS pour plus d’informations. Cela peut également se produire si une entité entre le client et le serveur, telle qu’un serveur proxy ou un autre périphérique réseau, intercepte une réponse d’IIS et la remplace par sa propre erreur 400 status et/ou « Demande incorrecte ».

Exemple de scénario

Voici un exemple de scénario HTTP 400, où un client envoie une requête incorrecte à IIS et le serveur renvoie un message « HTTP 400 - Requête incorrecte ».

Lorsque le client envoie sa demande, l’erreur de navigateur qu’il obtient ressemble à ceci :

Requête incorrecte (champ d’en-tête trop long)

En capturant une trace réseau de la requête et de la réponse, vous voyez les sorties suivantes :

DEMANDE:

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)

RÉPONSE:

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)

Vous remarquez que les en-têtes de réponse ne disent pas autant que le message d’erreur dans le navigateur. Toutefois, si vous examinez les données brutes dans le corps de la réponse, vous voyez plus :

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....?.

Vous pouvez voir que le texte du message d’erreur affiché dans le navigateur est également visible dans les données de réponse brutes de la trace réseau.

L’étape suivante consiste à examiner le fichier httperr.log dans le répertoire C :\Windows\System32\LogFiles\HTTPERR pour trouver l’entrée qui correspond à la requête incorrecte :

#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

Dans ce scénario, le Reason champ du fichier httperr.log fournit les informations exactes dont vous avez besoin pour diagnostiquer le problème. Vous voyez que HTTP.sys journalisé FieldLength comme expression de raison de l’échec de cette demande. Une fois que vous connaissez l’expression de raison, case activée la table dans La section Types d’erreurs que l’API HTTP journalise pour obtenir sa description :

FieldLength : une limite de longueur de champ a été dépassée.

À ce stade, vous savez par le message d’erreur du navigateur et la journalisation des erreurs de l’API HTTP que la requête contenait des données dans l’un de ses en-têtes HTTP qui ont dépassé les limites de longueur autorisées. Pour cet exemple, le HTTP: Uniform Resource Identifier header est volontairement long : /1234567890123456789012345678901234567890/time.asp.

La dernière étape de la résolution des problèmes de cet exemple consiste à case activée les clés de Registre HTTP.sys et les paramètres par défaut pour IIS

Étant donné que vous savez que l’expression de motif et l’erreur suggèrent qu’une longueur de champ d’en-tête dépasse les limites, vous pouvez affiner notre recherche dans la table Clés de Registre en tant que telle. Le candidat principal ici est :

Clé du Registre Valeur par défaut Plage de valeurs valide Fonction de clé de Registre Code d’AVERTISSEMENT
MaxFieldLength 16384 64 - 65534 (64 Ko - 2) octets Définit une limite supérieure pour chaque en-tête. Voir MaxRequestBytes (en anglais). Cette limite se traduit par environ 32 000 caractères pour une URL. 1

Pour reproduire cette erreur pour cet exemple, la MaxFieldLength clé de Registre a été définie avec la valeur 2. Étant donné que l’URL demandée comportait un HTTP: Uniform Resource Identifier header champ contenant plus de deux caractères, la requête a été bloquée avec l’expression FieldLength de motif.

Un autre scénario HTTP 400 courant est celui où l’utilisateur qui effectue la requête HTTP est membre d’un grand nombre de groupes Active Directory et où le site web est configuré pour l’authentification Kerberos de l’utilisateur. Dans ce cas, un message d’erreur semblable au suivant s’affiche à l’utilisateur :

Requête incorrecte (en-tête de requête trop long)

Dans ce scénario, le jeton d’authentification inclus dans le cadre de la requête HTTP du client est trop volumineux et dépasse les limites de taille que http.sys applique. Ce problème est abordé en détail, ainsi que la solution, dans http 400 - Requête incorrecte (en-tête de requête trop long) réponses aux requêtes HTTP.

References