Erro personalizado 404 não redirecionando corretamente

Question

Eu tenho esse erro de erro personalizado no meu arquivo web.config, mas ele não parece estar funcionando desde que adicionei o redirectMode="ResponseRewrite"

Funciona bem para 500 erros, mas não para 404 (simplesmente não é redirecionado quando tenho um 404)

Aqui está o 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>

E aqui está o meu 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)

Eu preciso manter o redirectMode="ResponseRewrite" para que o servererror/default.aspx me envia um e-mail quando há um erro

Qualquer ajuda seria muito apreciada

Obrigado

Jamie

ATUALIZAR

Eu dei uma olhada na web e encontrei algumas outras pessoas tendo os mesmos problemas, mas não consigo encontrar uma resposta definitiva.

Alguma ideia

Obrigado

Jamie

Answer 1

Suponho que você esteja vendo o .NET genérico quando a página não pode ser encontrada?

A solução é conforme abaixo. Observe a adição do ~ para o caminho:

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

ATUALIZAR:

Embora sua solução funcione, é um pouco hacky - em particular a maneira como você fez uso do estado da sessão seria desaprovado em uma aplicação em larga escala ou entre outros desenvolvedores mais experientes. Sugiro que os erros de 500 e 404 sejam divididos em páginas diferentes.

Se o seu site estiver disponível na Web, é útil exibir diferentes mensagens de erro para usuários reais, ou seja, se a página que eles estão procurando foi (404) ou há alguns problemas temporários (500) e pode ser uma boa ideia verificar volte depois. O texto em erro que cada página deve refletir isso de acordo. Também é importante relatar os códigos de status apropriados dos mecanismos de pesquisa para indicar se uma página não está mais disponível, ou seja, ela foi removida do seu projeto e deve ser retirada do índice do mecanismo de pesquisa ou se houver um erro e o mecanismo de pesquisa deve Retorne para rastejar a página mais tarde e não cair do índice. Não relatar esses códigos de status corretamente pode prejudicar o desempenho do seu aplicativo da Web por meio dos mecanismos de pesquisa. Normalmente, meu web.config diz como abaixo:

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

NOTA: É importante ter o conjunto de atributos "AmaultrredirEct" devido a um buraco de segurança descoberto recentemente dentro da estrutura .NET (Ask Google). Definindo isso é uma solução alternativa para conectar o orifício.

Para relatar códigos de status HTTP adequados de volta ao cliente (e do botão do mecanismo de pesquisa), você pode usar o código abaixo. Basta colocá -los no evento de carga da página da página relevante:

Para 500 erros:

Response.Status = "500 Internal Server Error"

Para 404 erros:

Response.Status = "404 Not Found"

Agora você pode remover o código do global.asax e criar uma função compartilhada para sua lógica de e -mail de erro que pode ser chamada de cada página. Se você preferir, pode mesclar o código acima na sua página de erro existente, no entanto, eu sempre prefiro dividi -los como o mais inteiro.

Se você deseja testar os códigos de status HTTP de suas páginas, recomendo dar uma olhada em um aplicativo gratuito chamado Violinista