Repository navigation
mcp: pick the protocol version per request from MCP-Protocol-Version (DEX-79) - #39562
Conversation
eb789a0 to
ac53ac0
Compare
ac53ac0 to
1dd25ea
Compare
| /// Picks the revision from the `MCP-Protocol-Version` header's value, not | ||
| /// its presence: 2025-06-18 and 2025-11-25 clients send the header too. | ||
| fn select(header: Option<&HeaderValue>, modern_enabled: bool) -> Self { | ||
| match header.and_then(|value| value.to_str().ok()) { |
There was a problem hiding this comment.
consider — The transport spec (2025-06-18 onward) says an invalid or unsupported MCP-Protocol-Version MUST get a 400, but here any unknown value (and 2026-07-28 with the flag off) silently falls back to 2025-11-25, and the test pins that. Falling back is fine as a rollout choice, but a 2026-07-28 client hitting a flag-off server will then get handshake-era behaviour instead of a clear error. Is the silent fallback what the follow-up PRs intend? If so, a short note on select saying it is deliberate would help.
written by claude on behalf of @jubrad
There was a problem hiding this comment.
Yes, it's on purpose. If we answered with a 400 and a 2026-07-28 error while the flag is off, dual-era clients would think we speak 2026-07-28 and stop falling back to initialize, so the SDKs in auto mode and Claude Code would break. Rejecting unknown values once the flag is on comes with the version check (DEX-80). Added a note on select.
2 participants
Picks the MCP protocol version per request from the
MCP-Protocol-Versionheader's value. Only2026-07-28withenable_mcp_protocol_2026_07_28on selects the new revision, since 2025-06-18 and 2025-11-25 clients send the header too. No behavior change yet: the version is only logged, and the next PRs use it. Closes DEX-79.Tests: a unit test for the version selection.