ASP Core 2.0下UseStatusCodePages无法捕获404.7错误的问题咨询

Let's break down your questions one by one—404.7 is a tricky edge case that operates outside the usual ASP.NET Core pipeline, so it behaves differently from standard 404s.

1. Why isn't the middleware catching this error? #

Your app.UseStatusCodePagesWithReExecute middleware only works within the ASP.NET Core request pipeline, but 404.7 errors happen before the request ever reaches that pipeline. IIS has a native security module called Request Filtering that runs early in the request processing chain—way before your ASP.NET Core app gets involved. When you request a file like /Startup.cs, IIS blocks it immediately (since .cs files are in the default list of blocked sensitive extensions) and returns 404.7 directly, skipping the entire ASP.NET Core middleware stack. That's why your custom error logic never sees the request.

2. Where does this error come from? #

The 404.7 status code is generated by IIS Request Filtering, a built-in security feature designed to prevent exposure of sensitive file types. By default, IIS blocks requests for extensions like .cs, .vb, .config, and other source/configuration files—this is a default safeguard to stop accidental leaks of your app's source code or sensitive settings. When a request hits one of these blocked extensions, IIS throws the 404.7 error on its own, without involving your ASP.NET Core application.

3. How to replace it with a custom error page? #

Since this error originates from IIS, you need to configure IIS-level custom errors to route it to your ASP.NET Core error page. Here's the proper approach:

Option 1: Configure custom errors in your project's Web.config #

Add the following section inside the <system.webServer> block of your project's Web.config (create the file in your MVC root if it doesn't exist):

<system.webServer>
  <!-- Keep your existing config settings here -->
  <httpErrors errorMode="Custom" existingResponse="Replace">
    <remove statusCode="404" subStatusCode="7" />
    <error 
      statusCode="404" 
      subStatusCode="7" 
      path="/Error/Index?statusCode=404.7" 
      responseMode="ExecuteURL" />
  </httpErrors>
</system.webServer>

• errorMode="Custom" ensures IIS uses your custom error pages instead of its default ones.
• existingResponse="Replace" tells IIS to overwrite the default 404.7 response with your custom page.
• responseMode="ExecuteURL" forwards the request to your ASP.NET Core error action (no browser redirect, so the URL stays the same).

Critical Notes: #

• Never allow .cs files via Request Filtering: It might be tempting to modify the filter rules to unblock .cs files, but this is a massive security risk—you'd expose your app's source code to anyone who requests those files. Don't do this in any environment, especially production.
• Update your Error Controller to handle the status code: Make sure your ErrorController can accept the statusCode query parameter and display relevant content. For example:

public class ErrorController : Controller
{
    public IActionResult Index(int? statusCode)
    {
        ViewBag.StatusCode = statusCode ?? 404;
        ViewBag.ErrorMessage = statusCode == 4047 
            ? "Requested file type is not allowed." 
            : "The page you're looking for doesn't exist.";
        return View();
    }
}

• For IIS Express (development): The project-level Web.config change should work here, but if you run into issues, you can modify the applicationhost.config file (located at %USERPROFILE%\Documents\IISExpress\config) to update httpErrors settings. The project-level config is still preferred, as it travels with your code.

内容的提问来源于stack exchange，提问作者Gary