Enviáis una petición HTTP y recibís un error HTTP, pero con una página de error HTML que no esperabais… ¿qué está pasando? 🤔

Por ejemplo, puede que hayáis intentado LEER un recurso FHIR (por ejemplo, /Patient/123) y recibáis una página de error 404, aunque con otros IDs de Patient sí obtenéis la carga útil del recurso. Es decir, “la página” definitivamente existe… ¿por qué os está devolviendo una página de error 404? 🙄

La respuesta a estas preguntas está relacionada con el comportamiento del servidor web IIS respecto al manejo de errores.

IIS tiene 3 opciones para mostrar errores:

• Mostrar siempre solo páginas de error personalizadas
• Mostrar siempre errores detallados del servidor
• Para solicitudes locales, mostrar errores detallados, pero para solicitudes remotas, mostrar las páginas de error personalizadas

Esta última opción es más segura (que mostrar siempre errores detallados) porque, en ocasiones, los detalles del error podrían exponer información interna que no queréis que usuarios externos vean. Por eso, esta es la configuración por defecto de IIS.

Pero esto significa que si estáis probando contra un servidor remoto, los errores reales estarán ocultos. Por ello, querréis cambiarlo a “Errores detallados” (al menos durante las fases de depuración, teniendo en cuenta el acceso externo y, quizá, limitándolo).

Consultad más detalles sobre esta configuración en un artículo relacionado de IIS (y también podéis ver esta sección relacionada en nuestra documentación que lo explica).

El ejemplo específico de FHIR que mencioné es un caso interesante, ya que un error 404 podría simplemente significar que un recurso FHIR concreto no se encontró (el ID que intentabais leer no está en el repositorio), y no que haya algún problema con el servidor (“página no encontrada”).

Por ejemplo, si podéis ver el error detallado, veríais algo como esto:

Pero sin el error detallado, solo recibiríais una página de error personalizada, así:

Y esto podría ser engañoso, así que tened en cuenta esta configuración de IIS.