Router's NotFound content is never used in new Web project style

[SteveSandersonMS]

The <Router> component still accepts a NotFound fragment (and we supply it in the default template), but it won't ever be used:

• If you don't have an interactive router, then a navigation to a nonexistent URL will return a 404 from the server, and then:
  • If you have enhanced nav enabled (default) then you'll see Error: 404
  • If you don't have enhanced nav enabled, then you'll see either the browser's built-in 404 UI or any custom 404 page returned by the ASP.NET Core server
• If you do have an interactive router, then a navigation to a nonexistent URL won't match any of the @page routes, and so the existing client-side routing logic causes it to do a full-page load
  • Historically with fallback routing this would take you back into the Blazor UI which would then render the NotFound fragment. But since we no longer have fallback routing, you'll now see either the browser's built-in 404 UI or any custom 404 page returned by the ASP.NET Core server

I'm not saying any of these outcomes is wrong, but just that:

1. It definitely doesn't make sense to pass the NotFound parameter in the default project template
2. It's confusing that you even can supply NotFound content when there's no way it can ever be used (except if the developer manually configures a fallback route that maps all URLs to a RazorComponentResult that renders their top-level component).

We should at least consider whether it could make sense to map a fallback route automatically for this case.

[javiercn]

@SteveSandersonMS In my view, we should remove the notfound from the template, and just return 404 letting the ASP.NET Core pipeline deal with it.

There is a general feature for displaying content on 404s, and we would want Blazor to be part of that (in fact, we should see if we can plug it in there).

I would avoid the fallback route as much as possible, it creates a host of problems when there are also APIs and other endpoints in the app.

[SteveSandersonMS]

There is a general feature for displaying content on 404s, and we would want Blazor to be part of that (in fact, we should see if we can plug it in there).

That sounds good, but do you happen to know how best to integrate it? Is this something developers can reasonably do in their own code, or do we need an item on the backlog for .NET 8 for this?

Also we have to take at least some action in framework code, because Router has [EditorRequired] for its NotFound parameter, and throws at runtime if no value was passed. So at the very least we have to change this to be optional and put in some fallback behavior if it's not set but actually would have been used (e.g., in cases where someone does have a fallback route, like an existing site).

[javiercn]

@SteveSandersonMS I think the way to let the server handle 404's is to trigger a 404 response, return and let app.UseStatusCodePagesWithRedirects handle it. By default the template for Razor pages does nothing from what I can tell.

https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/Web.ProjectTemplates/content/RazorPagesWeb-CSharp/Program.Main.cs

For errors we should do the same thing, let it bubble and have it redirect to /Error or similar.

There are two cases for 404 we need to account for.

1. There is a 404 because the route simply doesn't match.
2. There is a 404 because the developer wants to signal that, even though the route matches.
   • For this second case, I think we need an API on NavigationManager to trigger the 404. On SSR, it stops the render process (if possible, returns a 404), and lets the middleware pipeline unwind so that it can be handled in the same way as other 404s. If the response has already started because we are streaming it, it can raise an event to trigger the not found on the router. When running interactive, the router can use it to display the notfound fragment.

[danroth27]

I think we need an API on NavigationManager to trigger the 404

Agreed. Do we want to use this issue to track this API addition? Or should we open a separate issue?

[SteveSandersonMS]

Agreed. Do we want to use this issue to track this API addition? Or should we open a separate issue?

It would be ideal to open a new issue outlining the design.

For timelines, I suspect we can live without this for .NET 8 since we've been doing fine without it all this time and SSR doesn't significantly change the set of cases where you'd want this (people already asked for it in the past when prerendering). If we get time to do it that sounds great, but it won't be a blocker for people if we don't - they already address this by putting in page-specific "no such item" UI and live with returning 200s.

[danroth27]

Related issue: #45654

[marinasundstrom]

I have experienced something similar with authorization. NotAuthorized is not rendered, instead I get a page saying: Error: 401 Unauthorized.

#49515