Podría usar el StatusCodePagesMiddleware para esto. El siguiente es un ejemplo:

 public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { app.UseStatusCodePagesWithReExecute("/StatusCodes/StatusCode{0}"); app.UseMvcWithDefaultRoute();

Controlador que maneja las solicitudes de código de estado:

 public class StatusCodesController : Controller { public IActionResult StatusCode404() { return View(viewName: "NotFound"); // you have a view called NotFound.cshtml } ... more actions here to handle other status codes }

Algunas notas:

• Verifique otros métodos de extensión como UseStatusCodePagesWithRedirects y UseStatusCodePages para otras capacidades.
• Intenté tener StatusCode como una cadena de consulta en mi ejemplo, pero parece que este middleware no maneja cadenas de consulta, pero puede echarle un vistazo a este código y solucionar este problema.

¿Cómo puedo lograr esto en las nuevas aplicaciones ASP.NET MVC 6? ¿Puedo hacer esto usando el método integrado UseErrorHandler?

Respuesta rápida: no de una manera elegante.

Explicación/Alternativa: para comenzar, veamos primero qué está haciendo realmente el método UseErrorHandler : https://github.com/aspnet/Diagnostics/blob/6dbbe831c493e6e7259de81f83a04d1654170137/src/Microsoft.AspNet.Diagnostics/ErrorHandlerExtensions.cs#L25 que agrega el siguiente middleware: https://github.com/aspnet/Diagnostics/blob/6dbbe831c493e6e7259de81f83a04d1654170137/src/Microsoft.AspNet.Diagnostics/ErrorHandlerMiddleware.cs Tenga en cuenta las líneas 29-78 (el método de invocación)

El método de invocación se ejecuta cada vez que ingresa una solicitud (controlada por la ubicación de su application.UseErrorHandler("...") en su Startup.cs ). Por lo tanto, UseErrorHandler es una forma gloriosa de agregar un middleware personalizado: middleware = componente que puede actuar en una solicitud http.

Ahora con ese trasfondo, si quisiéramos agregar nuestro propio middleware de error que diferenciara las solicitudes. Podríamos hacer esto agregando un middleware similar que es como el ErrorHandlerMiddleware predeterminado modificando estas líneas: https://github.com/aspnet/Diagnostics/blob/6dbbe831c493e6e7259de81f83a04d1654170137/src/Microsoft.AspNet.Diagnostics/ErrorHandlerMiddleware.cs#L48-L51 Con ese enfoque, podríamos controlar la ruta de redirección en función del código de estado.

En MVC 5, tuvimos que usar la sección system.web customerrors para ASP.NET y la sección system.webServer httpErrors en el archivo web.config, pero era difícil trabajar con un comportamiento difícil de manejar y muy extraño. ¿MVC 6 hace esto mucho más simple?

Respuesta: Seguro que sí :). Al igual que la respuesta anterior, la solución radica en agregar middleware. Hay un atajo para agregar middleware simple a través de IApplicationBuilder en su Startup.cs ; al final de su método Configure , puede agregar lo siguiente:

 app.Run(async (context) => { await context.Response.WriteAsync("Could not handle the request."); // Nothing else will run after this middleware. });

Esto funcionará porque significa que llegó al final de su canalización http sin que se manejara la solicitud (ya que está al final de su método Configure en Startup.cs ). Si desea agregar este middleware (de manera rápida) con la opción de ejecutar el middleware después de usted, así es como se hace:

 app.Use(async (context, next) => { await context.Response.WriteAsync("Could not handle the request."); // This ensures that any other middelware added after you runs. await next(); });

¡Espero que esto ayude!