dotnet/aspnetcore · error · Error

${responseType} is not supported.

Error message

${responseType} is not supported.

What it means

Thrown by deserializeContent() when the request.responseType is one of 'blob', 'document', or 'json'. SignalR's HTTP client only supports reading the response as 'arraybuffer' or 'text'; the other XMLHttpRequestResponseType values are explicitly rejected because SignalR does not use them. The message interpolates the offending responseType string.

Source

Thrown at src/SignalR/clients/ts/signalr/src/FetchHttpClient.ts:178

            this._jar.getCookies(url, (e, c) => cookies = c.join("; "));
        }
        return cookies;
    }
}

function deserializeContent(response: Response, responseType?: XMLHttpRequestResponseType): Promise<string | ArrayBuffer> {
    let content;
    switch (responseType) {
        case "arraybuffer":
            content = response.arrayBuffer();
            break;
        case "text":
            content = response.text();
            break;
        case "blob":
        case "document":
        case "json":
            throw new Error(`${responseType} is not supported.`);
        default:
            content = response.text();
            break;
    }

    return content;
}

View on GitHub (pinned to 294cab2f9b)

Solutions

  1. Set responseType to 'arraybuffer' for binary (MessagePack) protocol or 'text' for JSON protocol, or omit it (defaults to text).
  2. If you need JSON, request 'text' and call JSON.parse on the content yourself.
  3. Audit any code that sets responseType and remove 'blob'/'document'/'json'.
  4. When using HubConnectionBuilder you never set responseType directly — only custom HttpClient callers hit this.

Example fix

// before
await httpClient.send({ method: 'GET', url, responseType: 'json' });
// 'json is not supported.'

// after
const resp = await httpClient.send({ method: 'GET', url, responseType: 'text' });
const data = JSON.parse(resp.content as string);
Defensive patterns

Strategy: validation

Validate before calling

const ALLOWED: XMLHttpRequestResponseType[] = ['', 'text', 'arraybuffer'];
function assertResponseType(rt?: XMLHttpRequestResponseType) {
  if (rt && !ALLOWED.includes(rt)) {
    throw new Error(`responseType '${rt}' is not supported by SignalR; use 'text' or 'arraybuffer'`);
  }
}
assertResponseType(request.responseType);
await httpClient.send(request);

Type guard

const SUPPORTED = new Set<XMLHttpRequestResponseType>(['', 'text', 'arraybuffer']);
function isSupportedResponseType(rt: unknown): rt is XMLHttpRequestResponseType {
  return typeof rt === 'string' && SUPPORTED.has(rt as XMLHttpRequestResponseType);
}

Try / catch

try {
  await httpClient.send(request);
} catch (e) {
  if (/is not supported/.test(e.message)) {
    request.responseType = 'text'; // downgrade and retry
    await httpClient.send(request);
  } else throw e;
}

Prevention

When it happens

Trigger: Building an HttpRequest with responseType: 'json' or 'blob' and sending it through the HttpClient; a custom caller that sets responseType expecting automatic JSON parsing.

Common situations: A developer assumes responseType:'json' will auto-parse (it won't — SignalR uses text and parses internally for JSON protocol); leftover config from a generic XHR/fetch wrapper; migrating code that used XHR responseType:'blob' for downloads.

Related errors


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