dotnet/aspnetcore · error

The server responded with status ${response.status}.

Error message

The server responded with status ${response.status}.

What it means

Thrown by fetchWithErrorHandling in the PasskeySubmit component when an HTTP response to /Account/PasskeyCreationOptions or /Account/PasskeyRequestOptions has a non-2xx status. The wrapper attaches credentials:'include', reads the body for console logging, and rethrows a status-coded Error so the caller can react.

Source

Thrown at src/ProjectTemplates/Web.ProjectTemplates/content/BlazorWeb-CSharp/BlazorWebCSharp.1/Components/Account/Shared/PasskeySubmit.razor.js:15

const browserSupportsPasskeys =
    typeof navigator.credentials !== 'undefined' &&
    typeof window.PublicKeyCredential !== 'undefined' &&
    typeof window.PublicKeyCredential.parseCreationOptionsFromJSON === 'function' &&
    typeof window.PublicKeyCredential.parseRequestOptionsFromJSON === 'function';

async function fetchWithErrorHandling(url, options = {}) {
    const response = await fetch(url, {
        credentials: 'include',
        ...options
    });
    if (!response.ok) {
        const text = await response.text();
        console.error(text);
        throw new Error(`The server responded with status ${response.status}.`);
    }
    return response;
}

async function createCredential(signal) {
    const optionsResponse = await fetchWithErrorHandling('/Account/PasskeyCreationOptions', {
        method: 'POST',
        signal,
    });
    const optionsJson = await optionsResponse.json();
    const options = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJson);
    return await navigator.credentials.create({ publicKey: options, signal });
}

async function requestCredential(email, mediation, signal) {
    const optionsResponse = await fetchWithErrorHandling(`/Account/PasskeyRequestOptions?username=${email}`, {
        method: 'POST',
        signal,

View on GitHub (pinned to 294cab2f9b)

Solutions

  1. Inspect the logged response body in the browser console for the exact server error.
  2. Verify the user is still authenticated; redirect to login on 401/403.
  3. Confirm /Account/PasskeyCreationOptions and /Account/PasskeyRequestOptions are registered and anti-forgery is valid.
  4. Check server logs for the 5xx root cause; ensure the fido2/WebAuthn server library is configured.

Example fix

// before
// no auth refresh; stale cookie -> 401

// after
try {
  await obtainCredential(...);
} catch (e) {
  if (/status 401|403/.test(e.message)) location.href = '/Account/Login?ReturnUrl=' + encodeURIComponent(location.pathname);
}
Defensive patterns

Strategy: try-catch

Validate before calling

async function fetchPasskeyOptions(url, signal) {
  const r = await fetch(url, { method:'POST', credentials:'include', signal });
  if (!r.ok) throw new Error('HTTP ' + r.status);
  return r;
}

Type guard

null

Try / catch

try { await obtainCredential(); } catch (e) {
  const s = (e.message.match(/status (\d+)/)||[])[1];
  if (s === '401' || s === '403') location.href = '/Account/Login';
  else showError(e.message);
}

Prevention

When it happens

Trigger: Passkey creation or request flow hits a 4xx/5xx: 401 (not authenticated / cookie expired), 400 (malformed request, missing username), 500 (server-side passkey library error), 404 (anti-forgery/account endpoints misconfigured), 502/503 (reverse proxy).

Common situations: Session/auth cookie expired while the page sat idle; anti-forgery token missing or stale; the Account endpoints were customized/removed; rate limiting (429); the server's WebAuthn/fido2 library throwing.

Related errors


AI-assisted analysis of dotnet/aspnetcore@294cab2f9b (2026-08-06). Data as JSON: /api/errors/d7b71564ad2bb13a. Report an issue: GitHub.