Re-evaluate enhanced nav to non-Blazor endpoints

[SteveSandersonMS]

Enhanced links (GET) and enhanced forms (POST) only occur if the target URL is internal to your origin, but it doesn't know or account for whether the target is a Blazor endpoint. It could turn out that you're doing enhanced nav to an MVC page, for example.

Right now this is simply allowed to happen and for most pages it works fine. You see the new content, you're at the new URL, everything continues.

However, this means you have some MVC-emitted markup running in a context it never intended to run in. The page already has scripts running, already has link click interceptors, and any amount of arbitrary Blazor code going in the background. The new content might not work properly because of the existing JS in the page, or because it relies on something like a "document ready" event that's never going to fire because the document was already ready long ago.

Suggestion

We should make Razor Component endpoints/results include an HTTP header, blazor-enhanced-nav: allow. Then we change the JS enhanced nav code so that if the response doesn't include this header:

• If it's a GET request, we simply retry it as non-enhanced nav, so you do a full-page load to the non-Blazor content. This unfortunately means a duplicated request, but it's a GET request so no different from the user simply opening the link twice.
• If it's a POST request, we have no choice but to fail. We can't retry the request. The main mitigation is that for forms, enhanced nav will be opt-in only, so no problem occurs by default. A problem only occurs if a developer enabled enhancement on a form that doesn't actually post to Blazor at all, and they should not do that.
  • Arguably there's a middle-ground problem where the form does target Blazor, but some unrelated middleware intercepts the request and causes it to return other non-Blazor content. We simply have to tell people not to enable form submit enhancement if this might happen. Only badly-behaved middleware would do this anyway, since if it's a POST, you can't return unrelated content, as the user wouldn't know whether their purchase (or whatever) has actually gone through.

In the case of redirections, this is already covered and works well, whether or not the redirection is issued by Blazor code on the server. That's out of scope for this issue; here we're only concerned with getting back HTML from an internal but non-Blazor endpoint.

[SteveSandersonMS]

Done in #50551