dotnet/aspnetcore · error · Error

Binary protocols over XmlHttpRequest not implementing…

Error message

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

What it means

Thrown by LongPollingTransport.connect when binary transfer format is requested but the environment's XMLHttpRequest lacks advanced features — specifically when `new XMLHttpRequest().responseType` is not a string property (i.e. the browser/XHR implementation is too old to support binary response types). LongPolling cannot receive binary frames without XHR responseType support, so the connect is refused up front.

Solutions

1. Use a text-based hub protocol (JSON) when LongPolling is the only available transport on legacy XHR.
2. Upgrade the runtime/browser to one with a complete XMLHttpRequest implementation.
3. Prefer the WebSockets or ServerSentEvents transport which do not rely on XHR responseType.

Example fix

// before - forcing binary over legacy long-polling
new HubConnectionBuilder()
  .withUrl(url, { transport: HttpTransportType.LongPolling })
  .withHubProtocol(new MessagePackHubProtocol())
  .build();
// after - keep JSON for long polling
new HubConnectionBuilder()
  .withUrl(url, { transport: HttpTransportType.LongPolling })
  .build(); // default JSON protocol

function supportsBinaryLongPolling(): boolean {
  return typeof XMLHttpRequest !== "undefined"
    && typeof new XMLHttpRequest().responseType !== "string";
}

function xhrSupportsBinary(): boolean {
  try {
    return typeof new XMLHttpRequest().responseType !== "string";
  } catch { return false; }
}

When it happens

Trigger: Configuring a connection that negotiates LongPolling as the transport with a binary hub protocol (e.g. MessagePack), in a browser/runtime where XMLHttpRequest does not implement responseType. The check fires only when transferFormat === Binary.

Common situations: Legacy browser (old IE, embedded WebViews, or a polyfilled XHR that omits responseType), or running in an unusual JS runtime where the global XMLHttpRequest is a partial shim.

Related errors

• Expected data to be of type
• Message is incomplete.
• Authentication refresh is only supported with HTTP-based…
• 'EventSource' is not supported in your environment.
• HttpConnection.stopConnection

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

Appendix: 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 3600ca084e)