dotnet/aspnetcore · error · Error

Binary protocols over XmlHttpRequest not implementing advanc

Error message

Binary protocols over XmlHttpRequest not implementing advanced features are not supported.

What it means

LongPollingTransport can carry binary payloads (MessagePack) only if the platform's XMLHttpRequest supports responseType, because binary needs responseType='arraybuffer' to avoid corruption. The guard at line 55-57 rejects the combination of TransferFormat.Binary with an XHR that lacks responseType support, since polling binary through plain text XHR would silently corrupt data.

Source

Thrown at src/SignalR/clients/ts/signalr/src/LongPollingTransport.ts:57

        this._running = false;

        this.onreceive = null;
        this.onclose = null;
    }

    public async connect(url: string, transferFormat: TransferFormat): Promise<void> {
        Arg.isRequired(url, "url");
        Arg.isRequired(transferFormat, "transferFormat");
        Arg.isIn(transferFormat, TransferFormat, "transferFormat");

        this._url = url;

        this._logger.log(LogLevel.Trace, "(LongPolling transport) Connecting.");

        // Allow binary format on Node and Browsers that support binary content (indicated by the presence of responseType property)
        if (transferFormat === TransferFormat.Binary &&
            (typeof XMLHttpRequest !== "undefined" && typeof new XMLHttpRequest().responseType !== "string")) {
            throw new Error("Binary protocols over XmlHttpRequest not implementing advanced features are not supported.");
        }

        const [name, value] = getUserAgentHeader();
        const headers = { [name]: value, ...this._options.headers };

        const pollOptions: HttpRequest = {
            abortSignal: this._pollAbort.signal,
            headers,
            timeout: 100000,
            withCredentials: this._options.withCredentials,
        };

        if (transferFormat === TransferFormat.Binary) {
            pollOptions.responseType = "arraybuffer";
        }

        // Make initial long polling request
        // Server uses first long polling request to finish initializing connection and it returns without data

View on GitHub (pinned to 294cab2f9b)

Solutions

  1. Switch the transport to WebSockets (HttpTransportType.WebSockets) which handles binary natively.
  2. Or switch the protocol to JSON (Text format) so binary XHR support is not required.
  3. Upgrade the runtime/browser so XMLHttpRequest.responseType is supported.
  4. If a polyfill is in play, replace it with one that supports responseType, or run on Node where fetch-based transport is used.

Example fix

// before
new HubConnectionBuilder()
  .withHubProtocol(new MessagePackHubProtocol()) // binary
  .withUrl(url, HttpTransportType.LongPolling)    // old XHR
  .build();

// after (option A: text protocol)
new HubConnectionBuilder()
  .withUrl(url, HttpTransportType.LongPolling)
  .build(); // default JSON protocol

// after (option B: keep binary, use WebSockets)
new HubConnectionBuilder()
  .withHubProtocol(new MessagePackHubProtocol())
  .withUrl(url, HttpTransportType.WebSockets)
  .build();
Defensive patterns

Strategy: fallback

Validate before calling

// detect the unsupported combo before building
const binary = protocol instanceof MessagePackHubProtocol;
const longPoll = options.transport === HttpTransportType.LongPolling;
if (binary && longPoll && typeof XMLHttpRequest !== 'undefined'
    && typeof new XMLHttpRequest().responseType !== 'string' /* old XHR */) {
  throw new Error('Binary + LongPolling unsupported on this XHR; use WebSockets or JSON');
}

Type guard

function supportsBinaryXhr(): boolean {
  return typeof XMLHttpRequest === 'undefined'
    || typeof new XMLHttpRequest().responseType !== 'string';
}

Try / catch

try {
  await connection.start();
} catch (e) {
  if (e instanceof Error && e.message.includes('Binary protocols over XmlHttpRequest')) {
    // fall back to JSON protocol or WebSockets transport
  }
}

Prevention

When it happens

Trigger: Selecting MessagePack (binary) protocol together with HttpTransportType.LongPolling in an environment whose XMLHttpRequest does not implement responseType (old browsers, some polyfills, restricted webviews).

Common situations: Legacy/embedded browsers, a polyfilled XHR in a test runner, or a restrictive corporate webview. WebSocket transport is usually fine; the failure is specific to long-polling + binary.

Related errors


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