Lorsque le serveur web IIS héberge un site ou un webservice, et qu'il reçoit une demande qu'il ne peut pas traiter, il retourne par défaut un code HTTP sans aucun détail. Cela permet une sécurité maximale, par exemple en ne renvoyant jamais au navigateur un emplacement physique réel du serveur.

Cette restriction de sécurité peut être pénalisante en phase de déploiement, durant la configuration d'un serveur web. Il est donc possible temporairement d'ajouter du détail aux erreurs renvoyées par IIS. Voici le réglage à effectuer :

• sélectionner le site concerné (s'il y en a d'autre que "Default Web Site"),
• sélectionner "Pages d'erreurs",
• sélectionner dans les actions à droites "Modifier les paramètres de fonction...",
• cocher suivant votre besoin "Erreurs détaillées" ou "Erreur détaillées pour les demandes locales".

Attention, surtout si le serveur héberge des sites et webservices utilisés depuis le monde entier, l'option ne doit être activée que très temporairement le temps de finaliser une mise au point.

Rappelons que IIS dispose également de log de toutes les requêtes HTTP qu'il reçoit. Par défaut les logs sont dans le dossier C:\inetpub\logs\LogFiles\W3SVC???. Le ??? du dossier correspond à l'identifiant du site dans IIS :

Ces logs permettent de rapprocher une erreur HTTP 500, HTTP 403 (...) d'une requête reçue.

-- Mise à jour 14/4/2021 --

Dans des cas exceptionnels on peut avoir besoin de connaître toutes les actions faites par IIS pour traiter une requête. C'est possible avec la fonctionnalité de suivi des requêtes. Voici le mode opératoire complet :

• Fermer la console de gestion de IIS INETMGR si elle est ouverte,
• dans l'assistant de fonctionnalités de Windows, ajouter le suivi pour Internet Information Services :
  
  
  
• ouvrir la console IIS (INETMGR)
• sélectionner le site virtuel qui exécute la requête HTTP récalcitrante dont on souhaite avoir le suivi complet,
• sélectionner "Suivi des demandes ayant échoué..." dans la rubrique "Configurer",
  
• Cocher "Activer" et valider :
  
  
  
• Ouvrir "Règles de suivi des demandes ayant échoué",
  
  
  
• valider toutes les étapes en donnant 400-599 pour étudier toutes les erreurs (ou une erreur précise si elle est identifiée) :
  
• Exécuter la requête HTTP dont on veut effectuer le suivi,
• Immédiatement après revenir dans la configuration "Suivi des demandes ayant échoué..." afin de décocher le suivi.,
• dans le dossier des logs de IIS (C:\inetpub\logs\ par défaut) un nouveau dossier a été créé :
  C:\inetpub\logs\FailedReqLogFiles\W3SVC?
  Avec ? le numéro du site virtuel comme détaillé précédemment pour le log standard.
• Les fichiers XML et XSL créés détaillent la requête exécutée en erreur. Il est conseillé d'utiliser un navigateur pour visualiser ce fichier XML, grâce à son style XSL il sera davantage lisible que dans un éditeur texte.

Voici un exemple de XML obtenu lorsque le suivi est actif, et qu'une adresse invalide est demandée à IIS. Pour l'exemple, le serveur est appelée avec l'adresse http://localhost:80/pasok, avec "pasok" qui n'existe pas ni en tant que page ou dossier ou autre :

L'intéret du suivi est minime ici dans le cas d'une erreur HTTP 404. Par contre il se peut que IIS ne donne pas la réponse attendue, sans donner un retour HTTP explicite. Dans ce cas le suivi est la solution pour orienter efficacement les recherches.

Astuce : pour une visualisation immédiate et rapide du suivi tel qu'on le voit dans le navigateur ci-dessus, il est possible de copier / coller les fichierx XML et XSL dans une dossier accessible en HTTP par IIS, par exemple sa racine c:\inetpub\wwwroot. On peut alors directement visualiser le XML via une requête http://<adresse serveur>/<nom>.XML :
http://localhostfr000001.xml