Draft server: validate body/header protocolVersion mismatch and no-op stray Mcp-Session-Id

[halter73]

Follow-up from #1610 (draft 2026-07-28 sessionless/stateless work). Two small server-side validation gaps that were punted:

1. HeaderMismatch (-32001) protocolVersion validation

The server does not currently compare the HTTP MCP-Protocol-Version header against the per-request _meta io.modelcontextprotocol/protocolVersion value (SEP-2567). When they disagree it should reject with a HeaderMismatch (-32001) error rather than silently trusting one.

2. Stray Mcp-Session-Id on draft requests

A draft (sessionless) request that nonetheless carries an Mcp-Session-Id header currently returns 400. Per the spec the session header is meaningless in sessionless mode and should be ignored (no-op), not rejected.

Notes

Both are server-side; add RawHttpConformanceTests-style regression coverage.

cc #1610

[halter73]

Deep-dive: precise pointers + a correction

Investigated both gaps against the current code. Recommendation: keep both as follow-ups — each is a behavioral/precedence decision rather than a mechanical fix, and #1610 is already large and late. Details so they're trivially actionable:

1. protocolVersion header vs _meta mismatch → -32001

• The HTTP MCP-Protocol-Version header is copied verbatim into message.Context.ProtocolVersion in StreamableHttpHandler.ReadJsonRpcMessageAsync (src/ModelContextProtocol.AspNetCore/StreamableHttpHandler.cs:582-596).
• The per-request _meta io.modelcontextprotocol/protocolVersion (SEP-2567) is parsed separately in McpSessionHandler.PopulateContextFromMeta. Nothing compares the two.
• McpErrorCode.HeaderMismatch (-32001) already exists and is already emitted for the Accept/Origin-style mismatch at StreamableHttpHandler.cs:88, so wiring is in place.
• Approach: after the _meta parse, if both header and _meta protocolVersion are present and differ, reject with HeaderMismatch. Edge cases to decide: header absent (trust _meta), _meta absent (trust header), and case/ordinal comparison. Add RawHttpConformanceTests coverage.
• Severity: hardening, not a correctness bug — conformant clients send consistent values.

2. Stray Mcp-Session-Id on a draft request

• Correction to the issue body: the draft spec doesn't mandate "ignore". SEP-2567 removes Mcp-Session-Id from the draft revision entirely, so the spec is silent on a server receiving a stray one — "ignore vs reject" is an SDK robustness (Postel) choice, not a normative requirement.
• Where the 400 comes from: GetOrCreateSessionAsync (StreamableHttpHandler.cs:350-398). Draft + no session-id → sessionless (line 365). Draft + session-id falls through to the generic guards: Stateless == true → 400 at line 391; stateful → legacy GetSessionAsync at line 396.
• The catch: lines 355-368 deliberately route draft-version-with-session-id through the legacy stateful path for back-compat (MRTR-as-extension-on-initialize). So a naive "draft ⇒ ignore session-id" change would regress that intentional back-compat. The real work is deciding precedence between the SEP-2567 sessionless contract and the legacy opt-in, which is a design call.

I'm happy to implement #1 in #1610 if you'd prefer it land with the sessionless work — it's the more in-scope of the two. #2 I'd leave for a dedicated change after the back-compat precedence is settled.

[halter73]

Resolving and closing — both parts are now as addressed as we want for #1610, and since this was only just opened it's cleaner to close it than to leave a freshly-filed follow-up around.

Part 1 (protocolVersion header vs _meta mismatch) — fixed in #1610 (commit a5686df)

Correction to my original framing: the server already compared the two values in McpSessionHandler.PopulateContextFromMeta — it just threw -32602 InvalidParams. That's an actual bug: a draft client's server/discover probe treats any non-modern JSON-RPC error (including InvalidParams) as a legacy-server signal and falls back to initialize (McpClientImpl catch (McpProtocolException)), so a modern draft server that detected a genuine header/body mismatch would be misread as legacy. Now it emits -32001 HeaderMismatch — the same code already used for the Mcp-Method/Mcp-Name header-vs-body checks and the exact code the client recognizes as a modern-server signal to surface as-is (catch (McpProtocolException ex) when (ex.ErrorCode == McpErrorCode.HeaderMismatch)). Added a RawHttpConformanceTests regression (DraftPost_ProtocolVersionHeaderMetaMismatch_ReturnsHeaderMismatch_Minus32001).

Part 2 (stray Mcp-Session-Id on a draft request) — won't change; not tracking

The current 400 is the better behavior: if a client sends a header we'd otherwise have to silently ignore, rejecting it surfaces the client bug rather than hiding it. SEP-2567 removes the session header from the draft revision, so "ignore vs reject" is a robustness choice, not a normative requirement — and reject is the safer default. We can relax to a no-op later if a real interop need shows up, but it's not worth a standing issue.

Closing.