Pregunta ASP.NET Custom 404 que devuelve 200 OK en lugar de 404 no encontrado


Después de intentar configurar mi sitio para las Herramientas para webmasters de Google, descubrí que mi página personalizada ASP.NET 404 no devolvía el código de estado 404. Mostró la página personalizada correcta y le dijo al navegador que todo está bien. Esto se considera un 404 suave o falso 404. 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 dos líneas siguientes 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, encontré que si codificaba el código siguiente en el código de diseño funcionaría 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. Preferiría usar la opción de código detrás, pero parece que no puedo hacer que funcione sin poner un código en línea en el diseño / diseño.


74
2017-12-07 05:26


origen


Respuestas:


Solución:

El problema, resultó ser el uso de la página maestra. Conseguí que funcionara estableciendo el código de estado más adelante en el ciclo de vida de las páginas, obviamente el renderizado de la página maestra estaba restableciéndolo, así que anulé el método de renderizado y lo configuré después de que se completara el renderizado.

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 dejo a usted.


Publicación original:

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

1) Editó 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;
    }
}

Eso es todo, si voy a cualquier extensión de página que sea procesada por Asp.Net y no exista, mi registro de viñeta 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 entra en algunos detalles más que pueden ser útiles para usted y su problema, mi prueba hace un redireccionamiento a la nueva página por lo que la url del archivo solicitado se pierde (excepto en la cadena de consulta) .

Páginas de error personalizadas de Google 404 y .NET

Respuesta de Spy del encabezado:

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

69
2017-12-07 06:13



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ía el IIS 404 genérico.

La solución a esto era 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


27
2018-06-22 23:28



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


12
2018-04-03 08:05



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

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

10
2017-09-22 00:06



Después de muchas pruebas y solución de problemas, parece que ciertos proveedores de hosting pueden interferir con el código de retorno. Pude solucionar esto aplicando un "truco" 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é.


6
2017-12-08 01:54



Pude solucionar este problema utilizando la siguiente configuración en webforms asp.net utilizando .NET 3.5.

El patrón que he implementado omite la solución de redirección personalizada de .NET en el archivo 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.

En primer lugar, 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 all-else-fail para el defaultRedirect de error.htm. Esto será útil cuando no tengo un controlador para el error específico, o hay algo parecido a una conexión de base de datos rota.

En segundo lugar, aquí está el evento Global asax Error:

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á transfiriendo la responsabilidad de manejar el error a otra clase. Si no se maneja el error 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 borraremos aquí para evitar que el usuario lo vea, pero inicie sesión en Elmah para saber qué está pasando.

La clase applicationErrorHandler se ve así:

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 utiliza esencialmente el patrón de comando para ubicar el controlador de error apropiado para el tipo de error emitido. Es importante usar Exception.GetBaseException () en este nivel, ya que casi todos los errores se envolverán en una excepción de nivel superior. Por ejemplo, si se ejecuta "throw new System.Exception ()" desde cualquier página aspx, se recibirá una HttpUnhandledException en este nivel, no una excepción System.Exception.

El código de "fábrica" ​​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" definidos, tengo una implementación personalizada para el tipo de error. Por ejemplo, se inspeccionará una excepción Http para el código de estado y se manejará de manera adecuada. 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.


1
2018-04-20 17:32