Journalisation des erreurs dans les API HTTP

  • Article

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.

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