Error de 404 personalizado no redirigiendo correctamente

Question

Tengo esta redirección de error personalizado en mi archivo web.config, pero no parece estar funcionando desde que agregué el redirectMode="ResponseRewrite"

Funciona bien por 500 errores pero no para 404 (simplemente no redirige cuando tengo un 404)

Aquí está el código de web.config

<customErrors mode="On" redirectMode="ResponseRewrite"> 
   <error statusCode="404" redirect="/servererror/default.aspx" /> 
   <error statusCode="500" redirect="/servererror/default.aspx" /> 
</customErrors>

Y aquí está mi servererror/default.aspx código

Dim err As System.Exception = Server.GetLastError()

Dim Errormail = New MailMessage

     'Send email to Bondholder using email address from form
     Errormail.To           = "email@email.co.uk"

     Errormail.From         = "servererror@email.co.uk"
     Errormail.Subject      = "Server Error Alert"
     Errormail.BodyFormat   = MailFormat.Text
     Errormail.Priority     = MailPriority.Normal
     Errormail.Body         = ("Error on page - " & err.InnerException.Message & vbcrlf & vbcrlf & "URL of the page - " & Request.Url.ToString())

     SmtpMail.SmtpServer    = "localhost"

     SmtpMail.Send(Errormail)

Necesito mantener el redirectMode="ResponseRewrite" de manera que la servererror/default.aspx me envía un correo electrónico cuando hay un error

Cualquier ayuda sería muy apreciada

Gracias

Jamie

ACTUALIZAR

Eché un vistazo a la web y he encontrado bastantes otras personas que tienen los mismos problemas, pero no puedo encontrar una respuesta definitiva.

Algunas ideas

Gracias

Jamie

Answer 1

Supongo que está viendo el .NET genérico cuando la página no se puede encontrar.

La solución es como a continuación. Tenga en cuenta la adición de ~ para el camino:

    <customErrors mode="On" redirectMode="ResponseRewrite">
        <error statusCode="404" redirect="~/servererror/default.aspx"/>
        <error statusCode="500" redirect="~/servererror/default.aspx"/>
    </customErrors>

ACTUALIZAR:

Si bien su solución funciona, es un poco hacky: en particular, la forma en que ha utilizado el estado de la sesión sería mal visto en una aplicación a gran escala o entre otros desarrolladores más experimentados. Sugiero que los errores 500 y 404 se dividan en diferentes páginas.

Si su sitio web está disponible a través de la web, es útil mostrar diferentes mensajes de error a usuarios reales, es decir, si la página que buscan se ha ido (404) o hay algunos problemas temporales (500) y puede ser una buena idea verificar volver más tarde. El texto en error cada página debe reflejar esto en consecuencia. También es importante informar a los códigos de estado apropiados de los motores de búsqueda para indicar si una página ya no está disponible, es decir, se ha eliminado de su proyecto y debe ser retirado del índice del motor de búsqueda o si hay un error y el motor de búsqueda debe Regrese para rastrear la página más tarde y no caer desde el índice. No informar estos códigos de estado correctamente puede afectar el rendimiento de su aplicación web a través de los motores de búsqueda. Por lo general, mi web.config se lee a continuación:

<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/GenericError.aspx">
    <error statusCode="404" redirect="~/NotFound.aspx"/>
</customErrors>

Nota: Es importante tener el atributo "DeFaulTredirect" establecido debido a un orificio de seguridad recientemente descubierto dentro del marco .NET (solicite a Google). Configurar esto es una solución para conectar el orificio.

Para informar los códigos de estado HTTP adecuados para volver al cliente (y el bot del motor de búsqueda) puede usar el código a continuación. Simplemente colóquelos en el evento de carga de la página de la página relevante:

Por 500 errores:

Response.Status = "500 Internal Server Error"

Para 404 errores:

Response.Status = "404 Not Found"

Ahora puede eliminar el código de Global.asax y crear una función compartida para su lógica de correo electrónico de error que se puede llamar desde cada página. Si lo prefiere, puede fusionar el código anterior en su página de error existente, sin embargo, siempre prefiero dividirlos como lo encuentro más ordenado.

Si desea probar los códigos de estado HTTP de sus páginas, le recomiendo echar un vistazo a una aplicación gratuita llamada Violinista