asp.net-mvc - mvc - error de servidor en la aplicación ''/''. visual studio 2017
¿Cómo puedo ver el código de estado http de los errores del servidor en una vista genérica de error personalizado en ASP.NET MVC? (2)
Si está utilizando IIS7 + inhabilitaré los "customerrors" de esta manera:
<customErrors mode="Off" />
y usa httpErrors de esta forma:
<system.webServer>
<httpErrors errorMode="DetailedLocalOnly" existingResponse="Replace" defaultPath="/error">
<remove statusCode="404" />
<error statusCode="404" path="/error/notfound" responseMode="ExecuteURL" />
</httpErrors>
....
Esto le permite obtener una página de error que no cambia en la url que se muestra con un código de estado 404 usando lo siguiente en su controlador:
public class ErrorController : Controller
{
public ActionResult notfound()
{
Response.TrySkipIisCustomErrors = true;
Response.StatusCode = (int)HttpStatusCode.NotFound;
return View("OneErrorViewToRuleThemAll");
}
}
PD. "errorMode" necesita cambiar a "Personalizado" para verlo localmente ... dependiendo de su configuración local (es decir, si está usando IISExpress) es posible que no vea el error correcto hasta que lo cargue en un servidor activo.
pps. podría tener la vista única "OneErrorViewToRuleThemAll" para manejar la salida en pantalla de los códigos de estado que decida manejar de esta manera. Cada acción ErrorController terminaría en esta vista.
Estoy tratando de implementar una página de error general personalizada en ASP.NET MVC 4. Básicamente configuré un Diseño de error, que define una sección para generar el código de estado de la respuesta.
La vista a la que quiero que terminen mis errores hereda dicho diseño, y simplemente agrega un mensaje que proviene de su modelo, que fue instanciado y pasado en la llamada a View () en el Controlador (llamado "Error") configuré para manejar errores personalizados, en el web.config.
<customErrors defaultRedirect="/Error" mode="On">
</customErrors>
El controlador de error personalizado :
public class ErrorController : Controller
{
public ActionResult Index()
{
return View(new CustomErrorViewModel(Response.Status));
}
}
La vista de error personalizado :
@{
Layout = "~/Views/Shared/_CustomErrorLayout.cshtml";
}
@using System.Web.Configuration;
@using System.Configuration;
@using MVC_Tests.Models;
@model CustomErrorViewModel
@section HttpCode { @Response.StatusCode }
@Model.Status
El diseño es:
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width" />
<title></title>
<link href="~/Content/CustomError.css" rel="stylesheet" />
</head>
<body>
<div id="divError">
<h1>
<span>Error </span>
@RenderSection("HttpCode")
</h1>
<div id="divErrorMessage">
<p>@RenderBody()</p>
</div>
</div>
</body>
</html>
El error que estoy tratando de manejar es una simple división por cero que agregué a la acción del Índice de Inicio. Tenga en cuenta que quiero una sola vista para manejar diferentes códigos de error de estado http del servidor (familia 500). Sé que tener una vista diferente para cada código de estado http distinto funciona, estoy buscando una sola vista para manejar múltiples códigos.
El manejo de errores personalizados está funcionando, estoy terminando en la vista deseada, pero como señalé anteriormente, esperaba dar salida al código de estado http del error. En cambio, siempre estoy mostrando 200 (OK), lo cual, según mi comprensión y depuración, ocurre porque:
1. Primero, al tropezar con la división por cero, se levanta una excepción.
2. Ahora se produce un redireccionamiento, debido a las instrucciones de mi web.config para manejar los errores de forma personalizada (ya que no se especificó código de estado http específico en el web.config, manejo cada código de error de estado http en el mismo controlador / vista ( "/ Error"). Lo que es crucial aquí es que la redirección es una nueva solicitud.
3. La redirección del paso 2 me envía al controlador de errores y luego me envía a su vista, que se representa.
4. Al renderizar la vista, el código de estado http insertado en la sección de diseño definido, mi mensaje personalizado se agrega, y la salida de la parte del código de estado http es como dije: 200 (OK). ¿Por qué, si un error del lado del servidor 500 fue forzosamente lanzado? Porque, si no me equivoco, la vista se representa dentro de un conducto de solicitud diferente, el redirecciona uno, y al redirigir, no se producen errores, y termino con una respuesta de estado 200 (OK).
Repasé esta publicación de Dino Esposito sobre el manejo de errores en asp.net mvc, pero no quiero agregar filtros (soluciones de atributo OnException y HandleError) a todos los controladores de la aplicación (podría crear un nuevo controlador base que tenga dicho filtro, y hacer que todos los demás hereden de él, pero eso también requiere cambiar todas las clases de controlador). El último enfoque que menciona (manejando el evento Application_Error de global.asax) No estoy seguro si sirve para esto - Tengo que emitir una instrucción de redirección "Response.Redirect" en el controlador, que supera la flexibilidad de poder establecer las páginas personalizadas en el web.config (aún podría redireccionar a una ruta definida en web.config, pero me pregunto si esto no se está volviendo demasiado engorroso para algo que parece tan simple).
¿Cuál es la mejor forma de detectar el código de estado http de la respuesta de cualquier error del servidor en la vista de error personalizada?
La solución que estaba buscando (después de estar a punto de darse por vencido) se describe aquí .
Resumiendo los pasos:
- Configure su web.config para redirigir a una acción del controlador por cada error que desee controlar.
- Establezca la propiedad TryToSkipCustomErrors del objeto Response en verdadero, en cada acción definida en 1.
- Comente los
filters.Add(new HandleErrorAttribute());línea.filters.Add(new HandleErrorAttribute());desde su archivo filterConfig.cs.
Usando este enfoque finalmente logré redireccionar a una página personalizada para el error 500. Parece que hay algún tipo de omisión por defecto de IIS para 500, porque la configuración de una página personalizada para el error 404 no requiere ni los pasos 2 ni 3.
Entonces, al final, para cada código de estado de HTTP quiero presentar una página personalizada, creo una acción de controlador, configuro las propiedades descritas en consecuencia y luego redirijo a la misma vista para todas las acciones, donde visualizo @ Response.Status , convirtiéndome en una solución genérica para mí.