Journalisation des erreurs dans les API HTTP
Cet article décrit les fonctionnalités de journalisation des erreurs des INTERFACES de programmation d’applications (API) HTTP (HyperText Transfer Protocol).
Version d’origine du produit : Windows Server 2008 R2, Windows Server 2008, Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1
Numéro de la base de connaissances d’origine : 820729
Résumé
Certaines erreurs qui se produisent dans une application BASÉE sur HTTP sont gérées automatiquement par l’API HTTP au lieu d’être transmises à une application à des fins de gestion. Ce comportement se produit parce que la fréquence de ces erreurs peut inonder un journal des événements ou un gestionnaire d’application.
Les rubriques suivantes décrivent les différents aspects de la journalisation des erreurs de l’API HTTP.
Configurer la journalisation des erreurs de l’API HTTP
Les paramètres du Registre contrôlent les erreurs de journaux de l’API HTTP, la taille maximale autorisée des fichiers journaux et l’emplacement des fichiers journaux.Format des journaux des erreurs de l’API HTTP
L’API HTTP crée des fichiers journaux qui suivent les conventions de fichier journal W3C (World Wide Web Consortium). Vous pouvez utiliser des outils standard pour analyser ces fichiers journaux. Toutefois, contrairement aux fichiers journaux W3C, les fichiers journaux de l’API HTTP ne contiennent pas les noms des colonnes.Types d’erreurs journalises par l’API HTTP
L’API HTTP enregistre de nombreuses erreurs courantes.
Les méthodes suivantes décrivent la résolution de la journalisation des erreurs de l’API HTTP.
Configurer la journalisation des erreurs de l’API HTTP
Trois valeurs de Registre sous une clé HTTP \Parameters contrôlent la journalisation des erreurs de l’API HTTP. Ces clés se trouvent au niveau de la clé de Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
.
Remarque
L’emplacement et la forme des valeurs de configuration peuvent changer dans les versions ultérieures du système d’exploitation Windows.
Vous devez disposer d’informations d’identification administrateur/système local pour modifier les valeurs du Registre et pour afficher ou modifier les fichiers journaux et le dossier qui les contient.
Les informations de configuration dans les valeurs de Registre sont lues au démarrage du pilote d’API HTTP. Par conséquent, si vous modifiez les paramètres, vous devez arrêter, puis redémarrer le pilote pour lire les nouvelles valeurs. Pour ce faire, tapez les commandes de console suivantes :
net stop http
net start http
La convention de nommage suivante est utilisée pour nommer les fichiers journaux :
httperr + numéro de séquence + .log
Exemple : httperr4.log
Les fichiers journaux sont cycle lorsqu’ils atteignent la taille maximale spécifiée par la valeur de Registre ErrorLogFileTruncateSize. Cette valeur ne peut pas être inférieure à 1 mégaoctet (Mo).
Si la configuration de la journalisation des erreurs n’est pas valide ou si un type d’échec se produit pendant que l’API HTTP écrit dans les fichiers journaux, l’API HTTP utilise la journalisation des événements pour informer les administrateurs que la journalisation des erreurs ne se produit pas.
Le tableau suivant décrit les valeurs de configuration du Registre.
Valeur de Registre | Description |
---|---|
EnableErrorLogging | DWORD que vous pouvez définir sur TRUE pour activer la journalisation des erreurs ou sur FALSE pour la désactiver. La valeur par défaut est TRUE. |
ErrorLogFileTruncateSize | DWORD qui spécifie la taille maximale d’un fichier journal des erreurs, en octets. La valeur par défaut est 1 Mo (0x100000). La valeur spécifiée ne peut pas être inférieure à la valeur par défaut. |
ErrorLoggingDir | Chaîne qui spécifie le dossier dans lequel l’API HTTP place ses fichiers de journalisation. L’API HTTP crée un sous-dossier HTTPERR dans le dossier spécifié, puis stocke les fichiers journaux dans le sous-dossier. Ce sous-dossier et les fichiers journaux reçoivent les mêmes paramètres d’autorisation. Les comptes administrateur et système local disposent d’un accès complet. Les autres utilisateurs n’y ont pas accès. L’exemple suivant est le dossier par défaut lorsque le dossier n’est pas spécifié dans le Registre : %SystemRoot%\System32\LogFiles La valeur de chaîne ErrorLoggingDir doit être un chemin d’accès local complet. Toutefois, il peut contenir %SystemRoot% . Un lecteur réseau ou un partage réseau ne peut pas être utilisé. |
Format des journaux des erreurs de l’API HTTP
En règle générale, les fichiers journaux des erreurs de l’API HTTP ont le même format que les journaux d’erreurs W3C, sauf que les fichiers journaux des erreurs de l’API HTTP ne contiennent pas d’en-têtes de colonne. Chaque ligne d’un journal des erreurs de l’API HTTP enregistre une erreur. Les champs apparaissent dans un ordre spécifique. Un seul espace (0x0020) sépare chaque champ du champ précédent. Dans chaque champ, les signes plus (0x002B) remplacent les espaces, les tabulations et les caractères de contrôle non imprimables.
Le tableau suivant identifie les champs et l’ordre des champs dans un enregistrement de journal des erreurs.
Field | Description |
---|---|
Date | Le champ Date suit le format W3C. Ce champ est basé sur le temps universel coordonné (UTC). Le champ Date contient toujours 10 caractères au format AAAA-MM-JJ. Par exemple, le 1er mai 2003 est exprimé sous la forme 2003-05-01. |
Time | Le champ Heure suit le format W3C. Ce champ est basé sur UTC. Le champ d’heure est toujours de huit caractères sous la forme MM :HH :SS. Par exemple, 17 :30 PM (UTC) est exprimé sous la forme 17 :30 :00. |
Adresse IP (Internet Protocol) du client | Adresse IP du client affecté. La valeur de ce champ peut être une adresse IPv4 ou une adresse IPv6. Si l’adresse IP du client est une adresse IPv6, le champ ScopeId est également inclus dans l’adresse. |
Client Port | Numéro de port du client affecté. |
Adresse IP du serveur | Adresse IP du serveur affecté. La valeur de ce champ peut être une adresse IPv4 ou une adresse IPv6. Si l’adresse IP du serveur est une adresse IPv6, le champ ScopeId est également inclus dans l’adresse. |
Port serveur | Numéro de port du serveur affecté. |
Version du protocole | Version du protocole utilisé. Si la connexion n’a pas été suffisamment analysée pour déterminer la version du protocole, un trait d’union (0x002D) est utilisé comme espace réservé pour le champ vide. Si le numéro de version principale ou le numéro de version mineure analysé est supérieur ou égal à 10, la version est enregistrée au format HTTP/?.?. |
Verbe | Le verbe indique que la dernière requête analysée passe. Les verbes inconnus sont inclus, mais tout verbe de plus de 255 octets est tronqué à cette longueur. Si aucun verbe n’est disponible, un trait d’union (0x002D) est utilisé comme espace réservé pour le champ vide. |
CookedURL + Query | L’URL et toute requête qui lui est associée sont enregistrées sous la forme d’un champ séparé par un point d’interrogation (0x3F). Ce champ est tronqué à sa limite de longueur de 4 096 octets. Si cette URL a été analysée (« cuite »), elle est journalisée avec la conversion de la page de codes locale et est traitée comme un champ Unicode. Si cette URL n’a pas été analysée (« cuite ») au moment de la journalisation, elle est copiée exactement, sans aucune conversion Unicode. Si l’API HTTP ne peut pas analyser cette URL, un trait d’union (0x002D) est utilisé comme espace réservé pour le champ vide. |
État du protocole | Le protocole status ne peut pas être supérieur à 999. Si le protocole status de la réponse à une requête est disponible, il est enregistré dans ce champ. Si le protocole status n’est pas disponible, un trait d’union (0x002D) est utilisé comme espace réservé pour le champ vide. |
SiteId | Non utilisé dans cette version de l’API HTTP. Un trait d’union d’espace réservé (0x002D) apparaît toujours dans ce champ. |
Expression de raison | Ce champ contient une chaîne qui identifie le type d’erreur en cours de journal. Ce champ n’est jamais vide. |
Nom de la file d’attente | Il s’agit du nom de la file d’attente des demandes. |
Les exemples de lignes suivants proviennent d’un journal des erreurs de l’API HTTP :
2002-07-05 18:45:09 172.31.77.6 2094 172.31.77.6 80 HTTP/1.1 GET /qos/1kbfile.txt 503 - ConnLimit
2002-07-05 19:51:59 127.0.0.1 2780 127.0.0.1 80 HTTP/1.1 GET /ThisIsMyUrl.htm 400 - Hostname
2002-07-05 19:53:00 127.0.0.1 2894 127.0.0.1 80 HTTP/2.0 GET / 505 - Version_N/S
2002-07-05 20:06:01 172.31.77.6 64388 127.0.0.1 80 - - - - - Timer_MinBytesPerSecond
Types d’erreurs journalises par l’API HTTP
L’API HTTP enregistre les réponses d’erreur aux clients, les délais d’attente de connexion, les demandes orphelines et les connexions supprimées qui sont gérées de manière incorrecte.
La liste suivante identifie les types d’erreurs que l’API HTTP journalise :
Réponses aux clients
L’API HTTP envoie une réponse d’erreur à un client, par exemple une erreur 400 provoquée par une erreur d’analyse dans la dernière requête reçue. Une fois que l’API HTTP a envoyé la réponse d’erreur, elle ferme la connexion.Délais d’attente de connexion
L’API HTTP expire une connexion. Si une demande est en attente lorsque la connexion expire, elle est utilisée pour fournir plus d’informations sur la connexion dans le journal des erreurs.Demandes orphelines
Un processus en mode utilisateur s’arrête de façon inattendue alors qu’il y a toujours des demandes en file d’attente qui sont routées vers ce processus. L’API HTTP enregistre les demandes orphelines dans le journal des erreurs. Les types d’erreur spécifiques sont nommés par des chaînes d’expression de raison qui apparaissent toujours comme le dernier champ de chaque ligne d’erreur. Le tableau suivant identifie les expressions de raison de l’API HTTP.
Expression de raison | Description |
---|---|
AppOffline | Une erreur de service non disponible s’est produite (erreur HTTP 503). Le service n’est pas disponible, car des erreurs d’application ont provoqué la mise hors connexion de l’application. |
AppPoolTimer | Une erreur de service non disponible s’est produite (erreur HTTP 503). Le service n’est pas disponible, car le processus du pool d’applications est trop occupé pour gérer la requête. |
AppShutdown | Une erreur de service non disponible s’est produite (erreur HTTP 503). Le service n’est pas disponible, car l’application s’arrête automatiquement en réponse à la stratégie d’administrateur. |
BadRequest | Une erreur d’analyse s’est produite lors du traitement d’une requête. |
Client_Reset | La connexion entre le client et le serveur a été fermée avant que la demande puisse être affectée à un processus de travail. La cause la plus courante de ce comportement est que le client ferme prématurément sa connexion au serveur. |
Connection_Abandoned_By_AppPool | Un processus de travail du pool d’applications a arrêté de façon inattendue ou orphelin une demande en attente en fermant son handle. |
Connection_Abandoned_By_ReqQueue | Un processus de travail du pool d’applications a arrêté de façon inattendue ou orphelin une demande en attente en fermant son handle. Spécifique à Windows Vista et versions ultérieures et à Windows Server 2008 et versions ultérieures. |
Connection_Dropped | La connexion entre le client et le serveur a été fermée avant que le serveur puisse envoyer son paquet de réponse final. La cause la plus courante de ce comportement est que le client ferme prématurément sa connexion au serveur. |
Connection_Dropped_List_Full | La liste des connexions supprimées entre les clients et le serveur est complète. Spécifique à Windows Vista et versions ultérieures et à Windows Server 2008 et versions ultérieures. |
ConnLimit | Une erreur de service non disponible s’est produite (erreur HTTP 503). Le service n’est pas disponible, car la limite de connexion au niveau du site a été atteinte ou dépassée. |
Connections_Refused | La mémoire NonPagedPool du noyau est tombée en dessous de 20 Mo et http.sys a cessé de recevoir de nouvelles connexions |
Désactivé | Une erreur de service non disponible s’est produite (erreur HTTP 503). Le service n’est pas disponible, car un administrateur a mis l’application hors connexion. |
EntityTooLarge | Une entité a dépassé la taille maximale autorisée. |
FieldLength | Une limite de longueur de champ a été dépassée. |
Interdit (Forbidden) | Un élément ou une séquence interdit a été rencontré lors de l’analyse. |
En-tête | Une erreur d’analyse s’est produite dans un en-tête. |
Nom d'hôte | Une erreur d’analyse s’est produite lors du traitement d’un nom d’hôte. |
Interne | Une erreur de serveur interne s’est produite (erreur HTTP 500). |
Invalid_CR/LF | Un retour de chariot ou un flux de ligne illégal s’est produit. |
LengthRequired | Une valeur de longueur requise était manquante. |
S/O | Une erreur de service non disponible s’est produite (erreur HTTP 503). Le service n’est pas disponible car une erreur interne (telle qu’un échec d’allocation de mémoire ou un conflit de liste de réservations d’URL) s’est produite. |
N/I | Une erreur non implémentée s’est produite (erreur HTTP 501) ou une erreur de service non disponible s’est produite (erreur HTTP 503) en raison d’un encodage de transfert inconnu. |
Nombre | Une erreur d’analyse s’est produite lors du traitement d’un nombre. |
Condition préalable | Il manquait une condition préalable requise. |
QueueFull | Une erreur de service non disponible s’est produite (erreur HTTP 503). Le service n’est pas disponible, car la file d’attente des demandes d’application est pleine. |
RequestLength | Une limite de longueur de requête a été dépassée. |
Timer_AppPool | La connexion a expiré, car une requête a attendu trop longtemps dans une file d’attente de pool d’applications pour qu’une application serveur soit supprimée de la file d’attente et la traite. Ce délai d’attente est ConnectionTimeout. Par défaut, cette valeur est définie sur deux minutes. |
Timer_ConnectionIdle | La connexion a expiré et reste inactive. La durée par défaut de ConnectionTimeout est de deux minutes. |
Timer_EntityBody | La connexion a expiré avant l’arrivée du corps de l’entité de demande. Lorsqu’une requête a clairement un corps d’entité, l’API HTTP active le minuteur Timer_EntityBody. Au début, la limite de ce minuteur est définie sur la valeur ConnectionTimeout (généralement, deux minutes). Chaque fois qu’une autre indication de données est reçue sur cette requête, l’API HTTP réinitialise le minuteur pour accorder à la connexion deux minutes supplémentaires (ou tout ce qui est spécifié dans ConnectionTimeout). |
Timer_HeaderWait | La connexion a expiré, car l’analyse de l’en-tête pour une requête a pris plus de temps que la limite par défaut de deux minutes. |
Timer_MinBytesPerSecond | La connexion a expiré car le client ne recevait pas de réponse à une vitesse raisonnable. Le taux d’envoi de la réponse était plus lent que la valeur par défaut de 240 octets/s. Qui peut être contrôlée avec la propriété de métabase MinFileBytesPerSec. |
Timer_ReqQueue | La connexion a expiré, car une requête a attendu trop longtemps dans une file d’attente du pool d’applications pour qu’une application serveur soit supprimée de la file d’attente. Ce délai d’attente est ConnectionTimeout. Par défaut, cette valeur est définie sur deux minutes. Spécifique à Windows Vista et versions ultérieures et à Windows Server 2008 et versions ultérieures. |
Timer_Response | Réservé. Actuellement non utilisé. |
Timer_SslRenegotiation |
La connexion a expiré car la renégociation SSL (Secure Sockets Layer) entre le client et le serveur a pris plus de temps que le délai d’attente par défaut de deux minutes. |
URL | Une erreur d’analyse s’est produite lors du traitement d’une URL. |
URL_Length | Une URL a dépassé la taille maximale autorisée. |
Verbe | Une erreur d’analyse s’est produite lors du traitement d’un verbe. |
Version_N/S | Une erreur de version non prise en charge s’est produite (erreur HTTP 505). |
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour