Pinned protocol version is sent as a duplicate header ("2025-11-25, 2026-07-28"), breaking connect with a 502

[stijnhaus]

Summary

Setting Connection overrides → Protocol version to a specific value (e.g. 2026 RC (2026-07-28)) on a remote HTTPS server makes the client send two values in one MCP-Protocol-Version header, comma-joined:

MCP-Protocol-Version: 2025-11-25, 2026-07-28

Spec-compliant servers match that header exactly, so they reject it as an unsupported version and return 400. The hosted app surfaces this as a Request failed (502) toast from its own proxy, which makes it look like a server outage rather than a malformed request. The pin feature is therefore unusable against
any server that validates the header.

Steps to reproduce

1. Add a remote HTTPS MCP server (OAuth auth) in the hosted app.
2. ⋮ → Configure → Connection overrides → Protocol version → 2026 RC (2026-07-28) → Save Changes.
3. Toggle the server on.

Expected: the client sends MCP-Protocol-Version: 2026-07-28 and connects.
Actual: Request failed (502). Server-side, the request arrives with MCP-Protocol-Version: '2025-11-25, 2026-07-28' and is rejected as an unsupported version. A second connect attempt never reaches the server at all (client-side short-circuit).

Setting Protocol version back to Client default connects instantly against the same server, same credentials — so this is specific to the pin path, not the server or the OAuth session.

Root cause

StreamableHTTPClientTransport._commonHeaders (@modelcontextprotocol/client, observed on 2.0.0-beta.4) sets the header lowercase and then spreads the caller's connection-level requestInit.headers verbatim:

new Headers({ "mcp-protocol-version": negotiated, ...requestInit.headers })

Headers treats field names case-insensitively but an object literal does not de-duplicate across different casings, so a canonical-cased MCP-Protocol-Version supplied by the caller appends instead of replacing. Reproducible standalone on Node 24:

new Headers({ "mcp-protocol-version": "2025-11-25", "MCP-Protocol-Version": "2026-07-28" }).get("mcp-protocol-version")
// => "2025-11-25, 2026-07-28"

The SDK's RESERVED_REQUEST_HEADER_NAMES guard covers per-request options.headers only — not connection-level requestInit.headers — so nothing upstream catches it.

The app used to have its own case-insensitive de-dup that prevented this; it was removed in #3317 (merged 2026-07-20) and not replaced. The per-server pin UI then landed in #3365 (merged 2026-07-22), which is when the combination became reachable.

[dosubot]

Hi @stijnhaus! I'm Dosu and I'm helping the MCPJam team.

I can confirm the issue. The root cause is in mergeProjectConnectionHeaders in client-config.ts, which merges project-level and server-level headers via plain object spread:

return {
  ...normalizeProjectConnectionHeaders(projectHeaders),
  ...normalizeExplicitConnectionHeaders(serverHeaders),
};

This is case-sensitive, so when the SDK later sets "mcp-protocol-version" (lowercase) and the app's connection defaults supply "MCP-Protocol-Version" (canonical case), both survive the spread and the Headers constructor combines them into the comma-joined value you're seeing.

The normalization helpers (normalizeProjectConnectionHeaders / normalizeExplicitConnectionHeaders) only filter out invalid entries (empty keys, non-string values) but do not normalize header name casing [1].

One small correction on the report: PR #3317 removed the stateless preview client and tool-header-map machinery, but it didn't actually remove a case-insensitive de-dup — that logic didn't exist in the merge path [2]. The gap has been there since the merge path was written; it just wasn't reachable until #3365 made the protocol-version pin available in the UI [3].

The fix would be to add case-insensitive de-duplication in mergeProjectConnectionHeaders (or its normalization helpers) so that later values win regardless of casing. I don't see an open PR addressing this yet.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[chelojimenez]

@stijnhaus thanks for reporting! we've been trying to make this experience better and might've introduced this. taking a look

[stijnhaus]

Thanks! I can take a look as well, if you like. Our app (https://www.air-lock.ai) is fully 2026-07-28 ready (unless the specs drifted since this morning) if you need something to test with.