¿Cuál es la diferencia entre customErrors y httpErrors?

¿Cuál es la diferencia entre las secciones customErrors y httpErrors del archivo web.config en las aplicaciones ASP.NET MVC?

¿Cuáles son las pautas para usar cada sección?

Descargo de responsabilidad: Esto es por mi experiencia y hecho no comprobado.

Ambos se usan para definir el manejo de errores para un sitio web, pero un software diferente se refiere a diferentes elementos de configuración.

customErrors es un elemento heredado (compatible con versiones anteriores), utilizado por Visual Studio Development Server (también conocido como VSDS o Cassini).

httpErrors es el nuevo elemento que solo utiliza IIS7.

Esto resalta el posible problema al desarrollar sitios web ASP.NET mientras usa VSDS en lugar del IIS local.

Además, consulte esta publicación por mí mismo acerca de cómo manejar los mensajes de error con IIS7, si desea tener control total de la salida del error.

Resumen:

  • Desarrollando en VSDS – use customErrors
  • Publicando el sitio a IIS6 – use customErrors
  • Publicando el sitio a IIS7 – use httpErrors .

y si desarrolla con VSDS pero publica en IIS7 , entonces supongo que necesitará ambos.

* Actualizado en abril de 2016

El atributo customErrors se usa cuando el código .net arroja una excepción (404, 403, 500, etc.) y el atributo httpErrors se usa cuando IIS mismo lanza una excepción.

  • / myfakeextensionslessurl -> httpErrors 404
  • /myfakeaspsx.aspx -> customErrors 404
  • /myfakeimage.jpg -> httpErrors 404
  • /throw500.apx -> customErrors 500
  • / throw500 -> customErrors 500

Hay muchas trampas tratando de configurar esto correctamente. Entonces, si está buscando un ejemplo rápido, las mejores 2 opciones que tiene son:

Ejemplo 1: Uso de páginas html

                  

Ejemplo 2: usar páginas aspx

                  

Y en las páginas de error de aspx necesita hacer algo como esto (página de ejemplo 404):

 < % Response.StatusCode = 404; Response.TrySkipIisCustomErrors = true; %> 

Nota: ¡ No es posible usar las URL de extensión reducida en la sección customErrors ! . (sin hacks)

Una solución alternativa es deshabilitar los errores personalizados y permitir que los errores http manejen la página personalizada. Un amigo ha creado dicha configuración, cuando encuentre algo de tiempo, compartiré el código.

Fondo

Una buena página de error personalizado:

  1. Muestre la excepción real cuando visita localmente la página problemática
  2. Mostrar una página personalizada cuando visita la página problema de forma remota
  3. No se redireccionará, sino que simplemente se mostrará el contenido de la página de error (por razones de seo)
  4. Mostrará el código de estado correcto

Para aclarar algunas opciones en nuestra configuración:

  1. customErrors mode = “RemoteOnly”. Puede especificar aquí: On, Off, RemoteOnly. On = Mostrar siempre páginas de error personalizadas, Off = Mostrar siempre el error real, RemoteOnly = Mostrar localmente el error, pero mostrar la página de error personalizada de forma remota. Entonces queremos RemoteOnly para la statement 1
  2. customeErrors redirectMode = “ResponseRewrite”. Puede sepcificar aquí: ResponseRedirect, ResponseRewrite. El modulo ResponseRedirect redirigirá la página de error a la página de error personalizada. Para un rastreador de enlaces (seo), esto dará como resultado 302 -> 500. Si bien desea que el rastreador de enlaces obtenga simplemente un error de 500.
  3. httpErrors errorMode = “DetailedLocalOnly”, este es el equivalente del modo customErrors. Opciones que tiene: personalizado, detallado, detalladoLocalOnly

Una buena publicación de blog que me ayudó mucho es: http://benfoster.io/blog/aspnet-mvc-custom-error-pages

versus


  • todavía disponible en IIS7 +
  • especifique páginas de error personalizadas para las solicitudes manejadas por ASP.NET
  • solo maneja las solicitudes dentro de la aplicación ASP.NET
  • archivos estáticos como archivos HTML o URL de directorio (“amigables”) no se manejan

  • introducido en IIS7
  • especificar páginas de error personalizadas para las solicitudes manejadas por IIS
  • maneja las solicitudes dentro de la aplicación ASP.NET Y / O maneja las solicitudes fuera de la aplicación – ASP.NET *
  • todos los archivos y URL se manejan *

Nota: ya no es necesario usar customErrors

Fuente citada: Custom 404 y páginas de error en ASP.NET (excelente artículo)


ExecuteURL sirve contenido dynamic como, por ejemplo, una página .aspx (el valor de la path debe ser una URL relativa al servidor ):

       

File sirve un archivo de error personalizado, como una página .html:

       

Referencia: Errores de HTTP (www.iis.net)

para más detalles, lea el enlace de http://www.iis.net arriba

La sección de errores en la configuración web es para proporcionar un enfoque personalizado de manejo de errores http; hay dos secciones, un CustomErrors dentro de la sección system.web y otro httpErrors dentro de la sección system.webServer (como se muestra a continuación)

CustomErrors: esta sección estaba en uso antes de que se introdujera IIS 7, IIS 6 5 y antes de utilizar por completo esta sección para gestionar los errores http personalizados de acuerdo con el código de estado http.

httpErrors: IIS 7 y versiones posteriores utilizan esta sección y la sección customErrors para controlar los errores http personalizados en función de sus extensiones de archivo si se solicita la extensión de página con ISAPI dll (.aspx, ashx, .asmx, .svc, etc.) como index.aspx y luego La configuración de recuperación de IIS de la sección customeErrors más recoge configuración de httpErrors (el modo alojado de IIS 7 debe configurarse como modo integrado no clásico)

a continuación se muestran los ejemplos para el enlace de verificación de manejo de errores 404:

httperrors vs customerrors en webconfig, iis, asp.net