Cómo utilizar Errores detallados HTTP en IIS 7.0
por el Equipo de IIS
Introducción
Cada administrador de sitio web o desarrollador web ha visto los mensajes "404: Archivo no encontrado", "401: No autorizado" o "500: Error del servidor" en el explorador. Este artículo le ayuda a comprender cómo y por qué IIS genera estos errores y cómo se pueden configurar.
Muchos podrían pensar que la generación de mensajes de error no merece un artículo completo, pero hay más errores que a simple vista. Los mensajes de error son un tema delicado, ya que cada error revela más de lo que podría querer revelar sobre el sitio web. Cuanta más información se pueda recopilar sobre el sitio, más probabilidad hay de que le hackeen. Una búsqueda de "hackear google" o "scripting entre sitios" muestra una gran cantidad de información sobre este tema.
Sin embargo, los mensajes de error también son una herramienta de gran utilidad para solucionar problemas. Los desarrolladores y administradores de sitios web necesitan tantos detalles como sea posible cuando se produce un error. Idealmente, el mensaje de error proporciona recomendaciones sobre cómo corregir el problema. Este es el modo en que IIS aborda estos objetivos radicalmente opuestos.
Errores, ¿pero qué errores?
Este artículo trata los errores HTTP tal y como se especifica en HTTP RFC (RFC 2616 : sección 6.1.1). Un error HTTP siempre se expresa con el envío de una respuesta al cliente solicitante de un código de estado superior a 400.
Errores de cliente
Los códigos de estado entre 400 y 500 corresponden con un error que causó el cliente, por ejemplo, una sintaxis incorrecta o solicitud a un recurso inexistente. Para probarlo, solicite una dirección URL falsa desde el sitio web que prefiera, por ejemplo: http://<IIS7Server>/esta_url_no_existe. Esto da como resultado un "error 404: archivo no encontrado".
Errores del servidor
Los códigos de estado a partir de 500 corresponden con errores causados por el servidor. Los motivos más comunes de los errores 500 en sistemas IIS son:
- Página ASP o ASPX con un error de sintaxis
- La configuración del servidor web o de la aplicación no se pueden leer o no son válidas
- El sitio se detuvo
Es importante tener en cuenta que los exploradores como IE suelen reemplazar los errores devueltos desde un servidor web por sus propios errores, lo que dificulta la solución de problemas. Puede desactivar esta característica en IE. Vaya al menú "Herramientas", seleccione "Opciones de Internet", haga clic en la pestaña "Avanzadas", busque la casilla "Mostrar mensajes de error HTTP descriptivos" y desmárquela. Para ver la respuesta sin procesar, use herramientas HTTP como WFETCH en el Kit de recursos de IIS 6.0 (consulte "Vínculos relacionados").
Errores HTTP en IIS
Pueden pasar dos cosas cuando el módulo httpError (custerr.dll) encuentra un error:
- Se genera un error personalizado
- Se genera un error detallado
Los errores personalizados son las páginas de error que los usuarios corrientes ven del sitio web. Contienen una breve descripción del error y de por qué se produjo el error, pero nada más. Este es el error personalizado que se genera al solicitar un recurso que no existe, por ejemplo: http://< IIS7Server>/este_recurso_no_existe
Los errores detallados están diseñados para administradores y desarrolladores locales. Se supone que proporcionan información que ayuda a corregir el problema inmediatamente. A continuación, se muestra un ejemplo de la misma solicitud, pero ahora devuelve un error detallado:
Esto conlleva peligro, porque los errores detallados contienen información sobre el funcionamiento interno del sitio web. Solo el personal de confianza debería ver un error detallado. La única manera de garantizar esto es generar un error detallado solo si la petición procede de un equipo local. Tan pronto como la solicitud no sea local, se genera un error personalizado. Observe el siguiente diagrama:
Data Flow
Primero: comprobación de errores
El módulo httpError recibe una notificación si se va a enviar una respuesta (RQ_SEND_RESPONSE notificación). El módulo httpError comprueba el código de estado de esta respuesta y devuelve inmediatamente si el código de estado no supera 400.
Segundo: error personalizado o detallado
El origen de la solicitud (si es local o remota) determina la siguiente comprobación y el valor de la propiedad errorMode. La propiedad errorMode está establecida en DetailedLocalOnly, lo que significa que se generan errores personalizados para cada solicitud remota. Si errorMode está establecida en "Personalizado", todas las respuestas de error se convertirán en Error personalizado. Si errorMode está establecida en "Detallado", todas las respuestas de error se convertirán en Errores detallados. La siguiente tabla detalla este comportamiento:
| errorMode | Origen de la solicitud | Action |
|---|---|---|
| DetailedLocalOnly (predeterminado) | Local | Detalles del error |
| DetailedLocalOnly (predeterminado) | Control remoto | Error personalizado |
| Personalizado | Local | Error personalizado |
| Personalizado | Control remoto | Error personalizado |
| Detallado | Local | Detalles del error |
| Detallado | Control remoto | Detalles del error |
Si el módulo httpError determina que se debe generar un error personalizado, busca en su configuración para ver si puede encontrar un error que coincida. Si encuentra una coincidencia, envía el archivo estático, redirige la solicitud o ejecuta la dirección URL especificada. Si no encuentra ninguna coincidencia, IIS envía un mensaje básico de una línea con el código de estado. La siguiente sección explica la configuración de error personalizado detalladamente.
Si custerr.dll determina que se debe generar un error detallado, se necesita hacer otra comprobación. IIS no manipula la respuesta si un módulo reemplazó la entidad de la respuesta por su propia descripción de error. Puede contener información valiosa. ASP.NET es un buen ejemplo. La entidad de una respuesta de error de ASP.NET puede contener la pila de excepciones y su propia descripción de error. Solo se genera un error detallado si el cuerpo de entidad de la respuesta está vacío.
<httpErrors> Configuración
A continuación se encuentra la sección de error personalizado de IIS obtenida en una instalación limpia:
<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>
Verá que si el código de estado de una respuesta es 401, IIS devolverá un archivo con el nombre 401.htm.
Códigos de subestados de IIS
Muchos errores HTTP tienen un subestado. La configuración predeterminada de errores personalizados de IIS no diferencia códigos basados en subestados. Envía la misma página de error personalizado si escribe las credenciales incorrectas (401.1) o si obtiene acceso denegado según los derechos no válidos para acceder a un archivo (401.3). Puede ver los diferentes códigos de subestado en los archivos de registro o a través de Errores detallados. A continuación se muestra una lista de los diferentes códigos de subestado de error 404 que IIS genera:
| Estado | Descripción |
|---|---|
| 404,1 | No se pudo encontrar el sitio |
| 404,2 | Denegado por Directiva. No se permite la solicitud ISAPI o el programa CGI en la lista de restricciones. |
| 404,3 | El identificador de archivos estáticos no tenía el archivo en su MimeMap y, por tanto, rechazó la solicitud. |
| 404,4 | No se encontró ningún controlador para atender la solicitud. |
| 404,5 | El módulo de filtrado de solicitudes rechazó una secuencia de direcciones URL en la solicitud. |
| 404,6 | El módulo de filtrado de solicitudes denegó el verbo HTTP de la solicitud. |
| 404,7 | El módulo de filtrado de solicitudes rechazó la extensión de archivo de la solicitud. |
| 404,8 | El módulo de filtrado de solicitudes rechazó un segmento de la dirección URL determinado (caracteres entre dos barras diagonales). |
| 404,9 | IIS rechazó servir un archivo oculto. |
| 404,11 | El módulo de filtrado de solicitudes rechazó una solicitud de escape doble. |
| 404,12 | El módulo de filtrado de solicitudes rechazó una solicitud con caracteres de bits altos. |
| 404,14 | El módulo de filtrado de solicitudes rechazó una solicitud con una dirección URL muy larga. |
| 404,15 | El módulo de filtrado de solicitudes rechazó una solicitud con una cadena de consulta muy larga. |
| 413.1 | El módulo de filtrado de solicitudes rechazó una solicitud demasiado larga (solicitud + cuerpo de la entidad). |
| 431 | El módulo de filtrado de solicitudes rechazó un encabezado demasiado largo. |
Puede configurar la sección httpErrors para mostrar un error personalizado para códigos de subestado concretos. Si agrega la siguiente línea a la sección de configuración httpErrors, IIS devuelve 404_3.htm si se solicita un archivo con una extensión que no se incluye en la sección de la configuración MimeMap de IIS (sección de configuración de <staticContent> ).
<error statusCode="404" subStatusCode="3" prefixLanguageFilePath="c:\inetpub\custerr" path="404_3.htm" />
Pasos para hacer que el ejemplo funcione:
- Agregue la entrada anterior a la sección de configuración httpErrors.
- Cree un archivo con el nombre 404_3.htm en el directorio
c:\inetpub\custerr\en-us. - Cree un archivo con el nombre test.yyy en el directorio
c:\inetpub\wwwroot. - Ahora solicite
http://localhost/test.yyy.
La extensión de archivo .yyy no es parte del MimeMap de IIS y el controlador de archivos estáticos no lo atenderá.
Novedad de IIS: errores personalizados en idiomas específicos
Cada explorador más reciente incluye el idioma del cliente como encabezado de solicitud. A continuación vemos un ejemplo de cómo podría ser este encabezado:
Accept-Language: en-us
La sintaxis y el registro de idiomas aceptados se especifican en RFC1766.
Al generar un error, IIS tiene en cuenta este encabezado cuando busca el archivo de error personalizado que devuelve. Genera la ruta de acceso del error personalizado con la siguiente lógica:
valor de configuración prefixLanguageFilePath (por ejemplo c:\inetpub\custerr,) +
encabezado Accept-Language que envía el cliente (por ejemplo, en-us) +
valor de configuración de ruta de acceso (por ejemplo, 404.htm)
Ejemplo:
Si el explorador envía una solicitud para un recurso no existente y el encabezado "Accept-Language" tiene el valor "en-us", el archivo que se devuelve será c:\inetpub\custerr\en-us\404.htm.
Por ejemplo, si su país es Alemania, querrá que los mensajes de error estén en alemán. Para ello, debe instalar el paquete de idioma de Windows Vista de alemán. Esto crea el directorio c:\inetpub\custerr\de-DE con archivos de error personalizados en él. Ahora, si el explorador envía el encabezado "Accept-Language" con el valor "de-DE", el archivo que se devuelve será c:\inetpub\custerr\de-DE\404.htm.
IIS siempre recurrirá al idioma del sistema si el directorio "de-DE" no existe.
Nota:
Internet Explorer le permite configurar el encabezado Accept-Language. Vaya a "Herramientas" - "Opciones de Internet", seleccione la pestaña "General" y haga clic en el botón "Idiomas".
Opciones de error personalizado
En los ejemplos anteriores, IIS envía el contenido del archivo como respuesta de error personalizado. IIS tiene otras dos maneras de responder a un error: mediante la ejecución de una dirección URL o redirección de la solicitud.
ExecuteUrl
Si desea hacer algo más con en el error personalizado, como por ejemplo, enviar un correo electrónico o registrar el error en una base de datos, puede ejecutar una dirección URL. Esto le permite ejecutar contenido dinámico como una página de ASP.NET. El siguiente ejemplo reemplaza el error 404. Ahora IIS ejecuta /404.aspx cada vez que ocurre un error 404.
<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>
Consideraciones sobre la seguridad
Como advertencia: por motivos de arquitectura, IIS solo puede ejecutar la URL si se ubica en el mismo grupo de aplicaciones. Use la característica de redireccionamiento para ejecutar un error personalizado en un grupo de aplicaciones distinto.
IIS también puede devolver un redireccionamiento 302 al explorador cuando se produce un error determinado. El redireccionamiento es útil si tiene una granja de servidores. Por ejemplo, puede redirigir todos los errores a una ubicación central que supervise con detalle.
Sin embargo, existe riesgo: responseMode="File" (que es el valor predeterminado) permite especificar todos los archivos del disco. Esto no funcionará si a usted le preocupa mucho la seguridad.
Un escenario viable puede incluir solo permitir la delegación de la configuración errorMode. Esto permite que un desarrollador reciba errores detallados de su aplicación, incluso si usa un cliente remoto. Solo hace falta establecer errorMode="Detailed". Aquí se muestra cómo configurar este escenario:
Permita la delegación de la sección httpErrors:
<section name="httpErrors" overrideModeDefault="Allow" />
En segundo lugar, vaya a la sección <httpErrors> de applicationHost.config y cámbiela para que solo se delegue errorMode:
<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>
Resumen
Los errores personalizados y detallados son características eficaces de IIS. Le ayudan a solucionar problemas sin poner en peligro la seguridad del servidor IIS. Muchas opciones de configuración le ayudan a personalizar la experiencia de los usuarios. Y lo más importante: diviértase experimentando con ellas.
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de