ASP.NET Custom 404 Devolver 200 OK En lugar de 404 No encontrado

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

La solución a esto fue agregar

Response.TrySkipIisCustomErrors = true;

Antes de cambiar la Respuesta.Código de estado.

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

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

<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

Intenta llamar a Respuesta.End() para omitir el renderizado...

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

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

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

El patrón que he implementado omite la solución de redirección personalizada de.NET en la web.config como he escrito mi propio para manejar todos los escenarios con el código de estado HTTP correcto en el encabezado.

Primero, la web.la sección customErrors de 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 un opción all-else-fails para el defaultRedirect de error.htm. Esto será útil cuando no tengo un controlador para el error específico, o hay algo en las líneas de una conexión de base de datos rota.

Segundo, aquí está el evento de error global de 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 un error no ha sido manejado. 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 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 localizar el controlador de errores apropiado para el tipo de error que se emite. Es importante usar la excepción.GetBaseException() en este nivel, porque casi todos los errores serán envueltos en una excepción de nivel superior. Por ejemplo, haciendo "lanza un nuevo Sistema.Exception () " desde cualquier página aspx resultará en que se reciba una HttpUnhandledException en este nivel, no un Sistema.Salvedad.

El código "factory" 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" que se definen, 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 apropiadamente. A 404 status el código requerirá un servidor.Transferencia en lugar de una solicitud.Redireccionar, junto con el código de estado apropiado escrito en el encabezado.

Espero que esto ayude.