Utilisation des erreurs détaillées HTTP dans IIS 7.0
par l'équipe IIS
Introduction
Chaque administrateur de site web ou développeur web a vu « 404 - Fichier introuvable », « 401 - Non autorisé » ou « 500 - Erreur du serveur » dans son navigateur. Cet article vous aide à comprendre comment et pourquoi IIS génère ces erreurs et comment elles peuvent être configurées.
Beaucoup peuvent penser que la génération de messages d’erreur ne semble pas justifier un article complet. Mais il y a plus d’erreurs que de rencontrer l’œil. Les messages d’erreur sont une rubrique sensible, car chaque erreur révèle plus d’informations sur votre site web que vous souhaiterez peut-être révéler. Plus d’informations peuvent être collectées sur votre site, la plus semblable, c’est que vous serez piraté. Une recherche de « piratage google » ou de « script intersites » révèle une multitude d’informations sur ce sujet.
Toutefois, les messages d’erreur sont également un outil précieux pour résoudre les problèmes. Les développeurs et les administrateurs de site web nécessitent autant de détails que possible lorsqu’une erreur se produit. Dans l’idéal, le message d’erreur fournit des recommandations sur la façon de résoudre le problème. Voici comment IIS répond à ces objectifs fondamentalement opposés.
Des erreurs, quelles erreurs ?
Cet article traite des erreurs HTTP spécifiées dans HTTP RFC (RFC 2616 - section 6.1.1). Une erreur HTTP est toujours exprimée en envoyant une réponse avec un code d’état supérieur à 400 au client demandeur.
Erreurs de client
Les codes d’état compris entre 400 et 500 spécifient une erreur que le client a effectuée, par exemple une syntaxe incorrecte ou une demande à une ressource qui n’existe pas. Vous pouvez essayer cela en demandant une URL incorrecte à partir du site web de votre choix, par exemple : http://<IIS7Server>/this_resource_does_not_exist. Vous obtenez une erreur « 404 - Fichier introuvable ».
Erreurs de serveur
Les codes d’état commençant par 500 sont des erreurs provoquées par le serveur. Les causes les plus courantes des erreurs 500 sur les systèmes IIS sont les suivantes :
- Page ASP ou ASPX qui contient une erreur de syntaxe
- La configuration du serveur web ou la configuration de l’application ne peut pas être lue ou n’est pas valide
- Le site est arrêté
Il est important de noter que les navigateurs comme Internet Explorer remplacent souvent les erreurs retournées par un serveur web par leurs propres erreurs. Cela rend la résolution des problèmes plus difficile. Dans Internet Explorer, vous pouvez désactiver cette fonctionnalité. Accédez au menu « Outils », sélectionnez « Options Internet », cliquez sur l’onglet « Avancé » et recherchez la case à cocher « Afficher les messages d’erreur HTTP conviviaux » et décochez-la. Pour afficher la réponse brute, utilisez des outils HTTP comme WFETCH dans le Kit de ressources IIS 6.0 (voir « Liens connexes »).
Erreurs HTTP dans IIS
Il existe deux choses qui peuvent se produire lorsque le module httpError (custerr.dll) rencontre une erreur :
- Une erreur personnalisée est générée
- Une erreur détaillée est générée
Les erreurs personnalisées sont des pages d’erreurs que les utilisateurs réguliers de votre site web voient. Ils contiennent une brève description de la raison pour laquelle l’erreur s’est produite, mais rien d’autre. Voici l’erreur personnalisée générée lorsque vous demandez une ressource qui n’existe pas, par exemple : http://<IIS7Server>/this_resource_does_not_exist
Les erreurs détaillées sont destinées aux administrateurs et développeurs locaux. Ils sont censés fournir des informations qui aident à résoudre immédiatement le problème. Voici un exemple de même requête, mais retourne maintenant une erreur détaillée :
Cela est dangereux, car les erreurs détaillées contiennent des informations sur les fonctionnements internes de votre site web. Seul le personnel approuvé doit voir une erreur détaillée. La seule façon de s’assurer que cela consiste uniquement à générer une erreur détaillée si la requête provient de l’ordinateur local. Dès que la requête n’est pas locale, une erreur personnalisée est générée. Examinez le diagramme de flux suivant :
Flux de données
Tout d’abord : vérification des erreurs
Le module httpError reçoit une notification si une réponse est sur le point d’être envoyée (notification RQ_SEND_RESPONSE). Le module httpError vérifie le code d’état de cette réponse et retourne immédiatement si le code d’état n’est pas supérieur à 400.
Ensuite : Erreur personnalisée ou erreur détaillée
La vérification suivante est déterminée par l’origine de la requête (il s’agit de la demande d’une requête locale ou distante) et du paramètre de la propriété errorMode. La propriété errorMode est définie sur DetailedLocalOnly, ce qui signifie que les erreurs personnalisées sont générées pour chaque requête distante. Si errorMode est défini sur « Personnalisé », toutes les réponses d’erreur deviennent une erreur personnalisée. Si errorMode est défini sur « Détaillé », toutes les réponses d’erreur deviennent des erreurs détaillées. Le tableau suivant clarifie ce comportement :
| errorMode | Origine de la demande | Action |
|---|---|---|
| DetailedLocalOnly (par défaut) | Local | Erreur détaillée |
| DetailedLocalOnly (par défaut) | Remote | Erreur personnalisée |
| Personnalisée | Local | Erreur personnalisée |
| Personnalisée | Remote | Erreur personnalisée |
| Detailed | Local | Erreur détaillée |
| Detailed | Remote | Erreur détaillée |
Si le module httpError détermine qu’une erreur personnalisée doit être générée, elle examine sa configuration pour voir s’il peut trouver une erreur correspondante. Si une correspondance est trouvée, elle envoie le fichier statique, redirige la requête ou exécute l’URL spécifiée. Si aucune correspondance n’est trouvée, IIS envoie un message d’une ligne de base contenant le code d’état. La section suivante explique en détail la configuration d’erreur personnalisée.
Si custerr.dll détermine qu’une erreur détaillée doit être générée, une autre vérification est nécessaire. IIS ne touche pas la réponse si un module dépasse l’entité de la réponse avec sa propre description d’erreur. Il peut contenir des informations précieuses. ASP.NET est un bon exemple. L’entité d’une réponse d’erreur ASP.NET peut contenir la pile d’exceptions et sa propre description d’erreur. Une erreur détaillée est générée uniquement si le corps de l’entité de la réponse est vide.
<httpErrors> Configuration
Voici la section d’erreur personnalisée IIS obtenue sur une installation propre :
<httpErrors>
<error statusCode="401" prefixLanguageFilePath="c:\inetpub\custerr" path="401.htm" />
<error statusCode="403" prefixLanguageFilePath="c:\inetpub\custerr" path="403.htm" />
<error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />
<error statusCode="405" prefixLanguageFilePath="c:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="c:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="c:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="c:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="c:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="c:\inetpub\custerr" path="502.htm" />
</httpErrors>
Si le code d’état d’une réponse est 401, IIS retourne un fichier nommé 401.htm.
Codes de sous-état
De nombreuses erreurs HTTP ont un sous-état. La configuration des erreurs personnalisées par défaut IIS ne différencie pas les codes de sous-état basés. Il envoie la même page d’erreur personnalisée si vous entrez les informations d’identification incorrectes (401.1) ou si vous obtenez un accès refusé en fonction des droits non valides pour accéder à un fichier (401.3). Vous pouvez voir les différents codes de sous-état dans les fichiers journaux ou via des erreurs détaillées. Voici une liste des différents codes de sous-état 404 produits par IIS :
| Statut | Description |
|---|---|
| 404,1 | Impossible de trouver le site |
| 404,2 | Refusé par la stratégie. Le programme ISAPI ou CGI de demande n’est pas autorisé dans la liste des restrictions. |
| 404,3 | Le gestionnaire de fichiers statiques n’a pas le fichier dans son MimeMap et a donc rejeté la requête. |
| 404,4 | Aucun gestionnaire n’a été trouvé pour traiter la demande. |
| 404,5 | Le module de filtrage des requêtes a rejeté une séquence d’URL dans la requête. |
| 404,6 | Le module de filtrage des requêtes a refusé le verbe HTTP de la requête. |
| 404,7 | Le module de filtrage des demandes a rejeté l’extension de fichier de la requête. |
| 404,8 | Le module de filtrage des requêtes a rejeté un segment d’URL particulier (caractères entre deux barres obliques). |
| 404,9 | IIS a refusé de servir un fichier masqué. |
| 404,11 | Le module de filtrage des requêtes a rejeté une requête qui a été double échappée. |
| 404,12 | Le module de filtrage des requêtes a rejeté une requête qui contenait des caractères binaires élevés. |
| 404,14 | Le module de filtrage des requêtes a rejeté une requête avec une URL trop longue. |
| 404,15 | Le module Filtrage des requêtes a rejeté une requête avec une chaîne de requête trop longue. |
| 413.1 | Le module de filtrage des requêtes a rejeté une requête trop longue (requête + corps d’entité). |
| 431 | Le module de filtrage des requêtes a rejeté un en-tête trop long. |
Vous pouvez configurer la section httpErrors pour afficher une erreur personnalisée pour des codes de sous-état particuliers. Si vous ajoutez la ligne suivante à la section de configuration httpErrors, IIS retourne 404_3.htm si un fichier avec une extension de fichier est demandé qui n’est pas inclus dans IIS MimeMap (<staticContent> section de configuration).
<error statusCode="404" subStatusCode="3" prefixLanguageFilePath="c:\inetpub\custerr" path="404_3.htm" />
Voici comment faire fonctionner l’exemple :
- Ajoutez l’entrée ci-dessus à votre section de configuration httpErrors.
- Créez un fichier nommé 404_3.htm dans votre répertoire
c:\inetpub\custerr\en-us. - Créez un fichier nommé test.yyy dans votre répertoire
c:\inetpub\wwwroot. - À présent, demandez
http://localhost/test.yyy.
L’extension de fichier .yyy ne fait pas partie de IIS MimeMap et le gestionnaire de fichiers statiques ne le servira pas.
Nouveautés d’IIS : Erreurs personnalisées spécifiques au langage
Chaque navigateur plus récent inclut la langue du client en tant qu’en-tête de requête. Voici un exemple de la façon dont cet en-tête peut ressembler :
Accept-Language: en-us
La syntaxe et le registre des langues acceptées sont spécifiés dans RFC1766.
Lors de la génération d’une erreur, IIS prend en compte cet en-tête lorsqu’il recherche le fichier d’erreur personnalisé qu’il retourne. Il génère le chemin d’accès pour l’erreur personnalisée à l’aide de la logique suivante :
Paramètre de configuration prefixLanguageFilePath (par exemple c:\inetpub\custerr)+
En-tête Accept-Language envoyé par le client (par exemple en-us) +
Paramètre de configuration du chemin d’accès (par exemple, 404.htm)
Exemple :
Si le navigateur envoie une demande pour une ressource non existante et que l’en-tête « Accept-Language » a la valeur « en-us », le fichier retourné est c:\inetpub\custerr\en-us\404.htm.
Par exemple, si vous êtes en Allemagne, vous souhaitez que vos messages d’erreur soient en allemand. Pour ce faire, vous devez installer le module linguistique Windows Vista pour l’allemand. Cela crée le répertoire c:\inetpub\custerr\de-DE avec des fichiers d’erreur personnalisés. Maintenant, si le navigateur envoie l’en-tête « Accept-Language » avec la valeur « de-DE », le fichier retourné sera c:\inetpub\custerr\de-DE\404.htm.
IIS revient toujours à la langue système si le répertoire « de-DE » n’existe pas.
Remarque
Internet Explorer vous permet de configurer l’en-tête Accept-Language. Accédez à « Outils » - « Option Internet », sélectionnez l’onglet « Général », puis cliquez sur le bouton « Langues ».
Options d’erreur personnalisées
Dans les exemples ci-dessus, IIS envoie le contenu du fichier en tant que réponse d’erreur personnalisée. IIS a deux autres façons de répondre à une erreur : en exécutant une URL ou en redirigeant la requête.
ExecuteUrl
Si vous souhaitez effectuer davantage d’opérations dans votre erreur personnalisée, par exemple en envoyant un e-mail ou enregistrant l’erreur dans une base de données, vous pouvez exécuter une URL. Cela vous permet d’exécuter du contenu dynamique comme une page ASP.NET. L’exemple ci-dessous remplace l’erreur personnalisée 404. IIS exécute maintenant /404.aspx chaque fois qu’une erreur 404 se produit.
<httpErrors>
<!-- default custom error for 401 errors -->
<!-- <error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />-->
<!-- ExecuteURL replaces default file response mode -->
<error statusCode="404" path=/404.aspx" responseMode="ExecuteURL"/>
<error statusCode="403" prefixLanguageFilePath="c:\inetpub\custerr" path="403.htm" />
<error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />
<error statusCode="405" prefixLanguageFilePath="c:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="c:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="c:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="c:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="c:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="c:\inetpub\custerr" path="502.htm" />
</httpErrors>
Security Considerations
Un mot de prudence : pour des raisons architecturales, IIS ne peut exécuter l’URL que s’il se trouve dans le même pool d’applications. Utilisez la fonctionnalité de redirection pour exécuter une erreur personnalisée dans un autre pool d’applications.
IIS peut également retourner une redirection 302 vers le navigateur lorsqu’une erreur particulière se produit. La redirection est bonne si vous disposez d’une batterie de serveurs. Par exemple, vous pouvez rediriger toutes vos erreurs vers un emplacement central que vous surveillez étroitement.
Toutefois, il existe un risque : responseMode="File" (qui est la valeur par défaut) vous permet de spécifier chaque fichier sur le disque. Cela ne fonctionnera pas si vous êtes très conscient de la sécurité.
Un scénario utilisable peut inclure uniquement l’autorisation de la délégation du paramètre errorMode. Cela permet à un développeur de recevoir des erreurs détaillées pour son application même s’il utilise un client distant. Tout ce qui est nécessaire consiste à définir errorMode="Detailed". Voici comment configurer ce scénario :
Autorisez la délégation de la section httpErrors :
<section name="httpErrors" overrideModeDefault="Allow" />
Ensuite, accédez à la section <httpErrors> dans applicationHost.config et modifiez-la afin que seul errorMode soit délégué :
<httpErrors lockAllAttributesExcept="errorMode" lockElements="error">
<error statusCode="404" prefixLanguageFilePath="E:\inetpub\custerr" path="404.htm" />
<error statusCode="401" prefixLanguageFilePath="E:\inetpub\custerr" path="401.htm" />
<error statusCode="403" prefixLanguageFilePath="E:\inetpub\custerr" path="403.htm" />
<error statusCode="405" prefixLanguageFilePath="E:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="E:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="E:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="E:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="E:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="E:\inetpub\custerr" path="502.htm" />
</httpErrors>
Résumé
Les erreurs personnalisées et détaillées sont des fonctionnalités IIS puissantes. Ils vous aident à résoudre les problèmes sans compromettre la sécurité de votre serveur IIS. De nombreuses options de configuration vous aident à personnaliser l’expérience de vos utilisateurs. Plus important encore : expérimenter avec elle est amusant.