dotnet/aspnetcore · error · Error

Enhanced navigation does not support making a non-GET…

Error message

Enhanced navigation does not support making a non-GET request to a non-Blazor endpoint. Avoid enabling enhanced navigation for forms that post to a non-Blazor endpoint.

What it means

During enhanced navigation, Blazor treats a successful (2xx) response without the 'blazor-enhanced-nav: allow' header as coming from a non-Blazor endpoint whose body is not designed to be patched into the existing DOM. For GET requests it falls back to a full page load, but for non-GET submissions it cannot safely replay the form, so it throws rather than render unrelated content. The fix is either to not enhance such forms or to ensure the endpoint is a real Blazor endpoint.

Solutions

  1. Remove data-enhance / enhanced navigation from forms whose action targets a non-Blazor endpoint.
  2. Make the target a real Blazor endpoint (Razor component with @attribute [Route(...)] or a Blazor-form-handling endpoint) so the response carries blazor-enhanced-nav: allow.
  3. Change the form method to 'get' so Blazor falls back to a full page load instead of throwing.
  4. Verify the form's action URL resolves to a Blazor route, not an MVC/static handler.

Example fix

<!-- before -->
<form method="post" action="/api/upload" data-enhance="true">
<!-- after: post to a Blazor endpoint, or drop enhancement -->
<form method="post" action="/upload" data-enhance="true"> <!-- /upload is a Razor component -->
<!-- or -->
<form method="post" action="/api/upload"> <!-- no enhance -->
Defensive patterns

Strategy: validation

Validate before calling

// Ensure enhanced POST forms target a Blazor endpoint before enabling enhancement
async function endpointSupportsEnhancedNav(actionUrl: string): Promise<boolean> {
  // probe with HEAD to read the blazor-enhanced-nav header if exposed
  const r = await fetch(actionUrl, { method: 'HEAD' });
  return r.headers.get('blazor-enhanced-nav') === 'allow';
}
// if (form.method === 'post' && !(await endpointSupportsEnhancedNav(form.action))) form.removeAttribute('data-enhance');

Try / catch

try {
  await enhancedNavSubmit(form);
} catch (e) {
  if (/non-Blazor endpoint/i.test((e as Error).message)) {
    form.removeAttribute('data-enhance');
    (form as HTMLFormElement & { submit(): void }).submit();
  } else throw e;
}

Prevention

When it happens

Trigger: Thrown at line 258 when isSuccessResponse is true, response.headers.get('blazor-enhanced-nav') !== 'allow' (non-Blazor success), and isGetRequest is false — i.e. an enhanced POST/PUT hit a static file, MVC controller, or other non-Blazor route returning 2xx.

Common situations: An enhanced form whose action points at an MVC/Razor Pages/static-file endpoint instead of a Blazor endpoint; posting to an API controller that returns 200; a misrouted form where the action URL doesn't match any Razor component route.

Related errors

AI-assisted analysis of dotnet/aspnetcore@3600ca084e (2026-08-11). Data as JSON: /api/errors/bf5f1ed2a0357d2f. Report an issue: GitHub.

Appendix: source

Thrown at src/Components/Web.JS/src/Services/NavigationEnhancement.ts:258

        } else {
          throw new Error('Enhanced navigation does not support making a non-GET request to an endpoint that redirects to an external origin. Avoid enabling enhanced navigation for form posts that may perform external redirections.');
        }
      }

      if (isSuccessResponse && response.headers.get('blazor-enhanced-nav') !== 'allow') {
        // This appears to be a non-Blazor-Endpoint success response. We don't want to use enhanced nav
        // because the content we receive is not designed to be patched into an existing frame,
        // and may be incompatible with the Blazor JS that's already here.
        // The reason we don't apply the same logic for non-success responses is that:
        //  - We don't want to retry as then developers will get double-failures in logs
        //  - We really want to show error pages to avoid losing vital debugging info
        // ... and since error pages can be considered terminally fatal, we don't have to worry about
        // whether the page has complex client-side behaviors that are incompatible with our JS.
        if (isGetRequest) {
          retryEnhancedNavAsFullPageLoad(internalDestinationHref);
          return;
        } else {
          throw new Error('Enhanced navigation does not support making a non-GET request to a non-Blazor endpoint. Avoid enabling enhanced navigation for forms that post to a non-Blazor endpoint.');
        }
      }

      // For 301/302/etc redirections to internal URLs, the browser will already have followed the chain of redirections
      // to the end, and given us the final content. We do still need to update the current URL to match the final location,
      // then let the rest of enhanced nav logic run to patch the new content into the DOM.
      if (changeUrl && (response.redirected || treatAsRedirectionFromMethod)) {
        const treatAsGet = treatAsRedirectionFromMethod ? (treatAsRedirectionFromMethod === 'get') : isGetRequest;
        if (treatAsGet) {
          // For gets, the intermediate (redirecting) URL is already in the address bar, so we have to use 'replace'
          // so that 'back' would go to the page before the redirection
          history.replaceState(null, '', response.url);
        } else {
          // For non-gets, we're still on the source page, so need to append a whole new history entry
          if (response.url !== location.href) {
            history.pushState(null, '', response.url);
          }
        }

View on GitHub (pinned to 3600ca084e)