ASP.NET Custom 404 Devuelve 200 OK en lugar de 404 no encontrado

Question

Después de intentar configurar mi sitio para las Herramientas para webmasters de Google, descubrí que mi página ASP.NET 404 personalizada no devolvía el código de estado 404. Mostraba la página personalizada correcta y le decía al navegador que todo estaba bien. Esto se considera un 404 suave o un 404. falso. A Google no le gusta esto. Así que encontré muchos artículos sobre el tema, pero la solución que quería no parecía funcionar.

La solución que quiero trabajar es agregar las siguientes dos líneas al código detrás del método Page_Load de la página 404 personalizada.

Response.Status = "404 Not Found";
Response.StatusCode = 404;

Esto no funciona. La página aún devuelve 200 OK. Sin embargo, descubrí que si codifico el siguiente código en el código de diseño, funcionará correctamente.

<asp:Content ID="ContentMain" ContentPlaceHolderID="ContentPlaceHolderMaster" runat="server">

<%
    Response.Status = "404 Not Found";
    Response.StatusCode = 404;
%>

 ... Much more code ...

</asp:content>

La página está usando una página maestra. Y estoy configurando páginas de error personalizadas en mi web.config. Realmente preferiría usar la opción de código subyacente, pero parece que no puedo hacer que funcione sin poner un código en línea de pirateo en el diseño / diseño.

Answer 1

Solución :

Resultó que el problema era el uso de la página maestra. Lo hice funcionar estableciendo el código de estado más adelante en el ciclo de vida de las páginas, obviamente la representación de la página maestra lo estaba restableciendo, así que anulé el método de representación y lo configuré después de que se completó la representación.

protected override void Render(HtmlTextWriter writer)
{
    base.Render(writer);
    Response.StatusCode = 404;
}

Se podría hacer más trabajo para averiguar exactamente cuándo la página maestra está configurando el estado, pero se lo dejaré a usted.

---

Publicación original:

Pude hacer que una aplicación web de prueba funcionara bien, al menos mostraba la página de error personalizada y devolvía un código de estado 404. No puedo decirte qué está mal con tu aplicación, pero puedo decirte lo que hice:

1) Editó el web.config para errores personalizados:

<customErrors mode="On">
  <error statusCode="404" redirect="404.aspx"/>
</customErrors>

2) Agregó una página 404.aspx y configuró el código de estado en 404.

public partial class _04 : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Response.StatusCode = 404;
    }
}

De eso se trata, si voy a cualquier extensión de página procesada por Asp.Net y no existe, mi registro de violinista muestra claramente un 404, aquí está el encabezado:

HTTP/1.1 404 Not Found
Server: Microsoft-IIS/5.1
Date: Sun, 07 Dec 2008 06:04:13 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 533

Ahora, si voy a una página que no es procesada por Asp.Net, como un archivo htm, la página personalizada no se muestra y se muestra el 404 configurado por IIS.

Aquí hay una publicación que incluye algunos detalles más que pueden ser útiles para usted y su problema, mi prueba hace una redirección a la nueva página, por lo que la URL del archivo solicitado se pierde (excepto en el cadena de consulta).

Google 404 y .NET Custom Error Pages

Respuesta de espía de encabezado:

HTTP/1.1 404 Not Found
Date: Sun, 07 Dec 2008 06:21:20 GMT

Answer 2

Tuve un problema similar, quiero mostrar una página personalizada como 404 (que es ASPX) y funcionó bien en localhost, pero tan pronto como un visitante remoto se conectara, obtendrían el IIS 404. genérico

La solución a esto fue agregar

Response.TrySkipIisCustomErrors = true;

Antes de cambiar el Response.StatusCode.

Encontrado a través de Rick Strahl http://www.west-wind.com/ weblog / posts / 745738.aspx

Answer 3

La solución de IIS 7 es simplemente agregar esto a su archivo web.config:

<system.webServer>
  <httpErrors existingResponse="Replace">
    <remove statusCode="500" subStatusCode="-1" />
    <remove statusCode="404" subStatusCode="-1" />
    <error statusCode="404" prefixLanguageFilePath="" path="404.htm" responseMode="File" />
    <error statusCode="500" prefixLanguageFilePath="" path="500.htm" responseMode="File" />
  </httpErrors>
</system.webServer>

http://forums.asp.net/t/1563128.aspx/1

Answer 4

Intente llamar a Response.End () para omitir la representación ...

Response.Status = "404 Not Found";
Response.StatusCode = 404;
Response.End();
return;

Answer 5

Después de muchas pruebas y resolución de problemas, parece que ciertos proveedores de hosting pueden interferir con el código de retorno. Pude evitar esto aplicando un "hack" en el contenido.

<%
// This code is required for host that do special 404 handling...
Response.Status = "404 Not Found";
Response.StatusCode = 404;
%>

Esto permitirá que la página devuelva el código de retorno correcto sin importar qué.

Answer 6

Pude solucionar este problema usando la siguiente configuración en formularios web asp.net usando .NET 3.5.

El patrón que he implementado omite la solución de redireccionamiento personalizado de .NET en web.config, ya que he escrito el mío para manejar todos los escenarios con el código de estado HTTP correcto en el encabezado.

Primero, la sección customErrors de web.config se ve así:

<customErrors mode="RemoteOnly" defaultRedirect="~/error.htm" />

Esta configuración garantiza que el modo CustomErrors esté activado, una configuración que necesitaremos más adelante, y proporciona una opción de todos los demás fallos para la Redirección predeterminada de error.htm. Esto será útil cuando no tenga un controlador para el error específico, o haya algo similar a una conexión de base de datos rota.

Segundo, aquí está el evento global de error asax:

protected void Application_Error(object sender, EventArgs e)
    {
       HandleError();
    }

    private void HandleError()
    {
        var exception = Server.GetLastError();
        if (exception == null) return;

        var baseException = exception.GetBaseException();

        bool errorHandled = _applicationErrorHandler.HandleError(baseException);
        if (!errorHandled) return;


        var lastError = Server.GetLastError();
    if (null != lastError && HttpContext.Current.IsCustomErrorEnabled)
    {
        Elmah.ErrorSignal.FromCurrentContext().Raise(lastError.GetBaseException());
        Server.ClearError();
    }
    }

Este código está pasando la responsabilidad de manejar el error a otra clase. Si el error no se maneja y CustomErrors está activado, eso significa que tenemos un caso en el que estamos en producción y de alguna manera no se ha manejado un error. Lo limpiaremos aquí para evitar que el usuario lo vea, pero inicie sesión en Elmah para que sepamos qué está pasando.

La clase applicationErrorHandler tiene este aspecto:

public bool HandleError(Exception exception)
        {
            if (exception == null) return false;

            var baseException = exception.GetBaseException();

            Elmah.ErrorSignal.FromCurrentContext().Raise(baseException);

            if (!HttpContext.Current.IsCustomErrorEnabled) return false;

            try
            {

                var behavior = _responseBehaviorFactory.GetBehavior(exception);
                if (behavior != null)
                {
                    behavior.ExecuteRedirect();
                    return true;
                }
            }
            catch (Exception ex)
            {
                Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
            }
            return false;
        }

Esta clase esencialmente usa el patrón de comando para localizar el controlador de error apropiado para el tipo de error que se emite. Es importante usar Exception.GetBaseException () en este nivel, porque casi todos los errores se incluirán en una excepción de nivel superior. Por ejemplo, haciendo " lanzar nuevo System.Exception () " desde cualquier página aspx dará como resultado que se reciba una HttpUnhandledException a este nivel, no una System.Exception.

La " fábrica " el código es simple y se ve así:

public ResponseBehaviorFactory()
    {
        _behaviors = new Dictionary<Type, Func<IResponseBehavior>>
                        {
                            {typeof(StoreException), () => new Found302StoreResponseBehavior()},
                            {typeof(HttpUnhandledException), () => new HttpExceptionResponseBehavior()},
                            {typeof(HttpException), () => new HttpExceptionResponseBehavior()},
                            {typeof(Exception), () => new Found302DefaultResponseBehavior()}
                        };
    }

    public IResponseBehavior GetBehavior(Exception exception)
    {                                                                               
        if (exception == null) throw new ArgumentNullException("exception");

        Func<IResponseBehavior> behavior;
        bool tryGetValue = _behaviors.TryGetValue(exception.GetType(), out behavior);

        //default value here:
        if (!tryGetValue)
            _behaviors.TryGetValue(typeof(Exception), out behavior);

        if (behavior == null)
            Elmah.ErrorSignal.FromCurrentContext().Raise(
                new Exception(
                    "Danger! No Behavior defined for this Exception, therefore the user might have received a yellow screen of death!",
                    exception));
        return behavior();
    }

Al final, tengo una configuración de esquema de manejo de errores extensible. En cada uno de los "comportamientos" eso está definido, tengo una implementación personalizada para el tipo de error. Por ejemplo, una excepción Http será inspeccionada para el código de estado y manejada adecuadamente. Un código de estado 404 requerirá un Server.Transfer en lugar de un Request.Redirect, junto con el código de estado apropiado escrito en el encabezado.

Espero que esto ayude.