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 dataView on GitHub (pinned to 294cab2f9b)
Solutions
- Switch the transport to WebSockets (HttpTransportType.WebSockets) which handles binary natively.
- Or switch the protocol to JSON (Text format) so binary XHR support is not required.
- Upgrade the runtime/browser so XMLHttpRequest.responseType is supported.
- 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
- Default the transport to negotiate (HttpTransportType.None) so SignalR picks WebSockets when available.
- If you must use LongPolling, prefer the JSON protocol (Text).
- Feature-detect XMLHttpRequest.responseType in constrained webviews before forcing binary.
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
- Incomplete message.
- Message is incomplete.
- Cannot read message size.
- Messages bigger than 2GB are not supported.
- Invalid input for JSON hub protocol. Expected a string.
AI-assisted analysis of dotnet/aspnetcore@294cab2f9b (2026-08-06).
Data as JSON: /api/errors/5367e8b69bfd3987.
Report an issue: GitHub.