Résolution des erreurs HTTP 400 dans IIS
S’applique à : Internet Information Services
Cet article décrit les étapes de résolution des problèmes permettant d’identifier la cause de diverses erreurs HTTP 400 lors de l’utilisation d’IIS.
Aperçu
Une fois qu’un client HTTP (tel que Microsoft Edge) envoie une requête HTTP à un serveur IIS, il peut afficher le type de message d’erreur suivant :
HTTP 400 - Requête incorrecte
Dans ce scénario, IIS rejette la requête HTTP du client, car la requête ne répond pas aux règles d’analyse HTTP du serveur, dépasse les limites de temps ou échoue à certaines autres règles auxquelles IIS ou HTTP.sys exige que les requêtes entrantes adhèrent. IIS renvoie l’état HTTP 400 - Bad Request au client, puis met fin à la connexion TCP.
Outils
- Moniteur réseau
- Journalisation des erreurs HTTP
Résolution des problèmes des méthodes
Lors de la résolution des problèmes d’une condition HTTP 400, il est important de se rappeler que le problème sous-jacent est que le client a envoyé une demande à IIS qui interrompt une ou plusieurs règles qui HTTP.sys s’appliquent. Dans cet esprit, vous souhaiterez voir ce que le client envoie exactement à IIS. Pour ce faire, capturez une trace réseau du client envoyant la demande incorrecte. Vous pouvez analyser la trace pour voir les données brutes envoyées par le client à IIS et afficher les données de réponse brute que IIS renvoie au client. Vous pouvez également utiliser un outil de reniffer 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 . Dans IIS, le composant HTTP.sys gère les requêtes HTTP entrantes avant qu’elles ne soient transmises à IIS et est 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 pourquoi elle a été bloquée.
Note
Pour plus d’informations sur la journalisation des erreurs d’API HTTP fournies par HTTP.sys, consultez Journalisation des erreurs dans l’API HTTP.
Il est techniquement possible, bien qu’il ne soit pas très probable qu’un client reçoive une réponse HTTP 400, qui n’a pas d’entrée de journal associée dans le fichier httperr.log . Cela peut se produire si un filtre ou une extension ISAPI, ou un module HTTP dans IIS, définit l’état 400, auquel cas vous pouvez examiner 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 son propre état et/ou erreur 400 « Demande incorrecte ».
Note
Cet article traite principalement des erreurs HTTP 400 courantes avant d’atteindre votre site web. Dans certains scénarios, votre site web peut également renvoyer des erreurs HTTP 400 aux clients en raison d’une logique de code personnalisée ou d’une configuration d’exécution (par exemple, ASP.NET). Si vous ne pouvez toujours pas résoudre les erreurs HTTP 400 après avoir effectué les étapes décrites dans les sections suivantes, essayez de résoudre les problèmes à l’aide de la fonctionnalité de suivi des demandes ayant échoué dans IIS. Si vous trouvez que les erreurs HTTP 400 sont réellement définies par le gestionnaire d’exécution correspondant de votre site web, par exemple ASP.NET, vous devrez peut-être inspecter les détails des requêtes et réponses, ainsi que la logique de code et la configuration du runtime associées de votre site web, pour comprendre la cause des erreurs HTTP 400.
Exemple de scénario
Voici un exemple de scénario HTTP 400, où un client envoie une requête incorrecte à IIS et que le serveur renvoie un message « HTTP 400 - Requête incorrecte ».
Lorsque le client envoie sa requête, l’erreur du navigateur qu’il retourne ressemble à ceci :
Demande incorrecte (champ d’en-tête trop long)
Capture d’une trace réseau de la demande et de la réponse, les sorties suivantes s’affichent :
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)
REPONSE:
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 indiquent 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 dans la trace réseau.
L’étape suivante consiste à examiner le fichier httperr.log dans le répertoire C :\Windows\System32\LogFiles\HTTPERR pour 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 enregistré FieldLength en tant que raison de l’échec de cette demande. Une fois que vous connaissez l’expression de raison, vérifiez la table dans types d’erreurs que la section journaux de l’API HTTP pour obtenir sa description :
FieldLength : une limite de longueur de champ a été dépassée.
Ainsi, à ce stade, vous savez à partir du message d’erreur du navigateur et de la journalisation des erreurs d’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, la HTTP: Uniform Resource Identifier header valeur est très longue : /1234567890123456789012345678901234567890/time.asp.
La dernière étape de résolution de cet exemple consiste à vérifier les clés de Registre HTTP.sys et les paramètres par défaut pour IIS
Étant donné que vous connaissez l’expression de raison et l’erreur suggèrent une longueur de champ d’en-tête dépassant les limites, vous pouvez affiner notre recherche dans la table Clés de Registre, par exemple. Le premier candidat ici est :
| Clé de registre | Valeur par défaut | Plage de valeurs valide | Fonction de clé de Registre | CODE WARNING |
|---|---|---|---|---|
MaxFieldLength |
16384 | 64 - 65534 (64k - 2) octets | Définit une limite supérieure pour chaque en-tête. Consultez l’article MaxRequestBytes. 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 avait un HTTP: Uniform Resource Identifier header champ avec plus de deux caractères, la requête a été bloquée avec l’expression FieldLength de raison.
Un autre scénario HTTP 400 courant est celui où l’utilisateur effectuant la requête HTTP est membre d’un grand nombre de groupes Active Directory, et le site web est configuré pour l’authentification Kerberos de l’utilisateur. Lorsque ce scénario se produit, un message d’erreur similaire à celui suivant s’affiche à l’utilisateur :
Demande incorrecte (en-tête de requête trop long)
Dans ce scénario, le jeton d’authentification inclus dans la requête HTTP du client est trop grand 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.