Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

Enregistrement des erreurs dans HTTP APIs

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 820729
Résumé
Cet article décrit les fonctionnalités de journalisation des erreurs HTTP APIs.

Certaines erreurs qui se produisent dans une application HTTP sont automatiquement gérées par l’API HTTP au lieu d’être transmises à une autre application. Ce problème se produit car la fréquence de telles erreurs risque de saturer un journal des événements ou un gestionnaire d’application.

Les rubriques suivantes décrivent les différents aspects de la journalisation des erreurs HTTP API.
  • Configurer les errorlogging de l’API HTTP
    Paramètres de Registre contrôlent l’API HTTP enregistre les erreurs, themaximum autorisé la taille des fichiers journaux et l’emplacement des fichiers journaux.
  • Format de la HTTP APIerror se connecte.
    L’API HTTP crée des fichiers journaux qui sont conformes avec les conventions de fichier journal World Wide Web Consortium (W3C). Vous pouvez utiliser les outils standard pour analyser ces fichiers journaux. Cependant, contrairement aux fichiers de journal W3C, journaux de l’API HTTP font notcontain les noms de colonnes.
  • Types d’erreurs enregistrées par l’API HTTP
    L’API HTTP enregistre de nombreuses erreurs courantes.
Résolution

Configurer la journalisation des erreurs HTTP API

Trois valeurs de Registre sous une clé HTTP \Parameters contrôlent la journalisation des erreurs HTTP API. Ces clés se trouvent dans la clé de Registre suivante :
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 des informations d’identification de l’administrateur/du système Local pour modifier les valeurs de Registre et pour afficher ou modifier les fichiers journaux et le dossier qui les contient.

Informations de configuration dans les valeurs de Registre sont lues lorsque le pilote de l’API HTTP démarre. Par conséquent, si vous modifiez les paramètres, vous devez arrêter et puis redémarrer le pilote afin de lire les nouvelles valeurs. Pour ce faire, tapez les commandes suivantes de la console :
net stop http
Net start http
La convention d’affectation de noms suivante est utilisée pour nommer les fichiers journaux :
HTTPERR + numéro de séquence + .log
Exemple : httperr4.log
Fichiers journaux est défini lorsqu’ils atteignent la taille maximale de la valeur de Registre ErrorLogFileTruncateSize spécifie. 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 n’importe quel type de panne se produit pendant que l’API HTTP écrit les fichiers journaux, l’API HTTP utilise l’enregistrement des événements pour avertir les administrateurs que la journalisation des erreurs n’est pas engendrée.

Le tableau suivant décrit les valeurs de configuration du Registre.
Valeur de RegistreDescription
EnableErrorLoggingValeur DWORD que vous pouvez définir sur TRUE pour activer l’enregistrement des erreurs ou sur FALSE pour le désactiver. La valeur par défaut est TRUE.
ErrorLogFileTruncateSizeDWORD qui spécifie la taille maximale d’un fichier journal des erreurs, en octets. La valeur par défaut est 1 Mo (0 x 100000).

Remarque La valeur spécifiée ne peut pas être inférieure à la valeur par défaut.
ErrorLoggingDirChaî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é et stocke les fichiers journaux dans le sous-dossier. Ce sous-dossier et les fichiers journaux reçoivent les mêmes paramètres d’autorisation. L’administrateur et les comptes système Local ont un accès total. Autres utilisateurs n’ont pas accès.

Voici le dossier par défaut lorsque le dossier n’est pas spécifié dans le Registre :
%SystemRoot%\System32\LogFiles

Remarque La valeur de chaîne de ErrorLoggingDir doit être un chemin local qualifié complet. Toutefois, il peut contenir % SystemRoot%. Un lecteur réseau ou un partage réseau ne peut pas être utilisé.

Retour au début

Format des journaux d’erreurs de l’API HTTP

En général, fichiers journaux des erreurs HTTP API ont le même format que les journaux d’erreurs W3C, sauf que les fichiers journaux des erreurs API HTTP ne contiennent pas d’en-têtes de colonne. Chaque ligne d’un journal d’erreur API HTTP enregistre une erreur. Les champs apparaissent dans un ordre spécifique. Un caractère espace unique (0 x 0020) sépare chaque champ du champ précédent. Dans chaque champ, signes plus (0x002B) remplacent les espaces, les tabulations et les caractères de contrôle non imprimable.

Le tableau suivant identifie les champs et l’ordre des champs dans un enregistrement de journal d’erreur.
ChampDescription
DateLe champ Date suit le format W3C. Ce champ est basé sur le temps universel coordonné (UTC). Le champ Date comporte toujours dix caractères sous la forme aaaa-MM-JJ. Par exemple, le 1er mai 2003 est exprimée sous la forme 2003-05-01.
HeureLe champ Heure suit le format W3C. Ce champ est basé sur l’heure UTC. Le champ heure est toujours huit caractères sous la forme de MM:HH:SS. Par exemple, 5 h 30 (UTC) est exprimée sous forme de 17:30:00.
Adresse IP du clientL’adresse IP du client concerné. 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.
Le Port du clientLe numéro de port pour le client concerné.
Adresse IP du serveurL’adresse IP du serveur concerné. 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 du serveurLe numéro de port du serveur concerné.
Version de protocoleLa version du protocole qui est utilisé.

Si la connexion n’a pas été analysée suffisamment pour apprécier la version du protocole, un trait d’union (0x002D) est utilisé comme un placeholderfor le champ vide.

Si le numéro de version principale ou le numéro de version secondaire qui est analysé isgreater à ou égal à 10, la version est enregistrée en tant que HTTP / ?. ?.
VerbeLe verbe indique que la dernière demande qui est analysé les passes. Les verbes inconnus sont inclus, mais tout verbe qui fait plus de 255 octets est tronqué à cette longueur. Si un verbe n’est pas disponible, un trait d’union (0x002D) est utilisé comme espace réservé pour le champ vide.
CookedURL + requêteL’URL et toute requête qui lui est associé sont enregistrés sous la forme d’un champ est 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 (« traitée »), il est enregistré avec la conversion de page de codes locale et est traitée comme un champ Unicode.

Si cette URL n'a pas été analysée (« traitée ») au thetime de journalisation, il est copié exactement, sans conversion Unicode.

Si l’API HTTP ne peut pas analyser cette URL, un hyphen(0x002D) est utilisé comme espace réservé pour le champ vide.
État du protocoleL’état du protocole ne peut pas être supérieur à 999.

Si l’état du protocole de la réponse à une requestis disponibles, il est enregistré dans ce champ.

Si l’état du protocole n’est pas disponible, un hyphen(0x002D) est utilisé comme espace réservé pour le champ vide.
ID de sitePas utilisé dans cette version de l’API HTTP. Un trait d’union (0x002D) de l’espace réservé s’affiche toujours dans ce champ.
Expression de motifCe champ contient une chaîne qui identifie le type d’erreur qui est enregistré. Ce champ n’est jamais vide.
Nom de la file d’attenteCe nom de la file d’attente la demande.
Lignes d’exemple suivantes proviennent d’un journal d’erreur 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 – nom d’hôte 2002-07-05 19:53:00 127.0.0.1 2894 127.0.0.1 HTTP 80/2.0 GET / 505 - Version_N/S 2002-07-05 20:06:01 172.31.77.6 Timer_MinBytesPerSecond de 80-----64388 127.0.0.1
Retour au début

Types d’erreurs enregistrées par l’API HTTP

L’API HTTP enregistre les réponses d’erreur aux clients, les délais de connexion, demandes orphelines et les pertes de connexion qui sont gérées de manière incorrecte.

La liste suivante identifie les types d’erreurs enregistrées par l’API HTTP :
  • Réponses aux clients L’API HTTP envoie une réponse d’erreur à un client, par exemple, une erreur 400 qui est dû à une erreur d’analyse dans la dernière demande reçue. Une fois que l’API HTTP envoie la réponse d’erreur, il ferme la connexion.
  • Délais de connexion L’API HTTP expire à une connexion. Si une demande est en attente lorsqueles connexion arrive à expiration, la demande est utilisée pour fournir plus d’informations sur la connexion dans le journal des erreurs.
  • Demandes d’orphelins Bien qu’il existe encore en file d’attente des demandes qui sont transmises à ce processus, un processus en mode utilisateur s’arrête inopinément. L’API HTTP enregistre les demandes orphelines dans le journal des erreurs.
Types d’erreurs spécifiques sont désignés par les chaînes d’Expression de motif qui apparaissent toujours comme le dernier champ de chaque ligne de l’erreur. Le tableau suivant identifie les expressions de motif API HTTP.
Expression de motifDescription

AppOfflineUne erreur non disponible service s’est produite (erreur HTTP 503). Le service n’est pas disponible car l’origine d’erreurs d’application hors de l’application.
AppPoolTimerUne erreur non disponible service s’est produite (erreur HTTP 503). Le service n’est pas disponible car le processus de pool d’applications est trop occupé pour traiter la demande.
AppShutdownUne erreur non disponible service s’est produite (erreur HTTP 503). Le service n’est pas disponible parce que l’application s’arrête automatiquement en réponse à la stratégie de l’administrateur.
BadRequestUne erreur d’analyse s’est produite lors du traitement d’une demande.
Client_ResetLa connexion entre le client et le serveur a été fermée avant que la demande peut être attribué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_AppPoolUn processus de travail du pool d’applications a fermer de façon inattendue ou orpheline une demande en attente en fermant son handle.
Connection_Abandoned_By_ReqQueueUn processus de travail du pool d’applications a fermer de façon inattendue ou orpheline une demande en attente en fermant son handle. Spécifiques à Windows Vista et les versions ultérieures et à Windows Server 2008 et les versions ultérieures.
Connection_DroppedLa connexion entre le client et le serveur a été fermée avant que le serveur a pu envoyer son paquet de réponse finale. La cause la plus courante de ce comportement est que le client ferme prématurément sa connexion au serveur.
Connection_Dropped_List_FullLa liste des pertes de connexion entre les clients et le serveur est pleine. Spécifiques à Windows Vista et les versions ultérieures et à Windows Server 2008 et les versions ultérieures.
ConnLimitUne erreur non disponible service 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_RefusedLa mémoire de réserve non paginée du noyau est descendu en dessous de 20 Mo et http.sys a annulé la réception de nouvelles connexions
DésactivéUne erreur non disponible service s’est produite (erreur HTTP 503). Le service n’est pas disponible car un administrateur a déconnecté l’application.
EntityTooLargeUne entité dépasse la taille maximale autorisée.
FieldLengthUne limite de longueur de champ a été dépassée.
InterditUne séquence ou un élément interdit a été rencontré lors de l’analyse.
En-têteUne erreur d’analyse s’est produite dans un en-tête.
Nom d’hôteUne erreur d’analyse s’est produite lors du traitement d’un nom d’hôte.
InterneUne erreur de serveur interne s’est produite (erreur HTTP 500).
Invalid_CR/LFUn saut de ligne ou de retour chariot non autorisé s’est produite.
LengthIl manquait une valeur de longueur requise.
N/AUne erreur non disponible service s’est produite (erreur HTTP 503). Le service n’est pas disponible car une erreur interne (par exemple, un conflit de la liste de réservation d’URL ou d’un échec d’allocation de mémoire) s’est produite.
N / IUne erreur non implémentée s’est produite (erreur HTTP 501) ou une erreur de service non disponible s’est produite (erreur HTTP 503) à cause d’un codage de transfert inconnu.
Numéro deUne erreur d’analyse s’est produite lors du traitement d’un nombre.
Condition préalableIl manquait une condition préalable requise.
QueueFullUne erreur non disponible service s’est produite (erreur HTTP 503). Le service n’est pas disponible car la file d’attente de la demande application est plein.
RequestLengthUne limite de longueur de demande a été dépassée.
Timer_AppPoolLa connexion a expiré car une demande a attendu trop longtemps dans une file d’attente de pool d’applications pour une application de serveur de file d’attente et le traiter. Ce délai d’attente est ConnectionTimeout. Par défaut, cette valeur est définie sur deux minutes.
Timer_ConnectionIdleLa connexion a expiré et reste inactive. La durée de ConnectionTimeout par défaut est de deux minutes.
Timer_EntityBodyLa connexion a expiré avant l’arrivée du corps d’entité de la demande. Lorsqu’une demande a clairement un corps d’entité, l’API HTTP active le minuteur de Timer_EntityBody . Dans un premier temps, la limite de ce minuteur est définie à la valeur ConnectionTimeout (généralement deux minutes). Chaque fois qu’une autre indication de données est reçue sur cette demande, l’API HTTP réinitialise le minuteur pour permettre la connexion de deux minutes (ou tout ce qui est spécifié dans ConnectionTimeout).
Timer_HeaderWaitLa connexion a expiré car l’en-tête d’une demande d’analyse a pris plus de temps que la limite par défaut de deux minutes.
Timer_MinBytesPerSecondLa connexion a expiré car le client ne recevait pas une réponse à une vitesse raisonnable. Le taux d’envoi de réponse a été plus lent que la valeur par défaut de 240 octets/s. Cela peut être contrôlé avec la propriété de métabase MinFileBytesPerSec .
Timer_ReqQueueLa connexion a expiré car une demande a attendu trop longtemps dans une file d’attente de pool d’applications pour une application serveur pour la file d’attente. Ce délai d’attente est ConnectionTimeout. Par défaut, cette valeur est définie sur deux minutes. Spécifiques à Windows Vista et les versions ultérieures et à Windows Server 2008 et les versions ultérieures.
Timer_ResponseRéservé. Pas utilisé actuellement.
Timer_SslRenegotiationLa connexion a expiré car la renégociation SSL entre le client et le serveur a duré plus longtemps que le délai d’expiration par défaut de deux minutes.
URLUne erreur d’analyse s’est produite lors du traitement d’une URL.
URL_LengthUne URL a dépassé la taille maximale autorisée.
VerbeUne erreur d’analyse s’est produite lors du traitement d’un verbe.
Version_N/SUne erreur de version non-prise en charge s’est produite (erreur HTTP 505).

Retour au début
Références
Pour plus d’informations sur l’ajout de champs de journalisation supplémentaires pour la journalisation des erreurs HTTP IIS, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
832975 Des propriétés supplémentaires sont maintenant disponibles pour l’enregistrement dans le fichier Httperr # .log dans IIS 6.0 et IIS 7.0

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 820729 - Dernière mise à jour : 08/06/2016 02:03:00 - Révision : 11.0

Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise, Windows Server 2008 Enterprise, Windows Server 2012 R2 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 for Embedded Systems, Windows Server 2012 R2 Foundation, Windows Server 2012 Standard, Windows Server 2012 Datacenter, Windows Server 2012 Essentials, Windows 10, Windows 10 Enterprise, released in July 2015, Windows 10 Pro, released in July 2015, Windows 10 Version 1511, Windows 8.1, Windows 8.1 Enterprise, Windows 8.1 Pro, Windows 8, Windows 8 Pro, Windows 8 Enterprise, Windows 7 Professionnel, Windows 7 Entreprise

  • kbhttphandlers kbhttp kbapi kberrmsg kbinfo kbmt KB820729 KbMtfr
Commentaires
html>display: none; " src="https://c1.microsoft.com/c.gif?DI=4050&did=1&t=">1&t=">