Vous envoyez une requête HTTP et recevez une erreur HTTP, mais accompagnée d'une page d'erreur HTML inattendue… Que se passe-t-il ? 🤔

Par exemple, vous avez peut-être essayé de lire une ressource FHIR (par exemple, /Patient/123) et vous obtenez une erreur 404, alors qu'avec d'autres identifiants de patient, vous recevez bien la ressource. La page existe donc bel et bien… Pourquoi obtenez-vous une erreur 404 ? 🙄

La réponse à ces questions est liée au comportement du serveur web IIS face aux erreurs.

IIS propose trois options d'affichage des erreurs :

• Afficher uniquement les pages d'erreur personnalisées
• Afficher les erreurs serveur détaillées
• Pour les requêtes locales, afficher les erreurs détaillées ; pour les requêtes distantes, afficher les pages d'erreur personnalisées.

Cette dernière option est plus sécurisée (que l'affichage systématique des erreurs détaillées) car ces dernières peuvent parfois révéler des informations internes confidentielles. C'est pourquoi elle est activée par défaut pour IIS.

Cependant, cela signifie que si vous effectuez des tests sur un serveur distant, les erreurs réelles vous seront masquées. Il est donc conseillé de modifier ce paramètre et d'opter pour « Erreurs détaillées » (au moins pour les phases de débogage, et en tenant compte des accès externes, voire en les limitant).

Pour plus d'informations sur ce paramètre, consultez un article IIS dédié (et la section correspondante de notre documentation).

L'exemple FHIR que j'ai mentionné est un cas intéressant : une erreur 404 peut simplement signifier qu'une ressource FHIR spécifique est introuvable (l'ID que vous tentiez de lire n'est pas présent dans le référentiel), et non un problème avec le serveur (« page introuvable »).

Par exemple, si vous affichez l'erreur détaillée, vous verrez quelque chose comme ceci :

Mais sans le message d'erreur détaillé, vous n'obtiendriez qu'une page d'erreur personnalisée, comme celle-ci :

Cela pourrait induire en erreur, alors gardez ce paramètre IIS à l'esprit.