Default missing MCP-Protocol-Version to 2025-03-26 in StreamableHTTPTransport#392
Open
koic wants to merge 1 commit into
Conversation
…PTransport ## Motivation and Context MCP 2025-11-25 (basic/transports#protocol-version-header) specifies: > For backwards compatibility, if the server does not receive an > `MCP-Protocol-Version` header, and has no other way to identify the > version - for example, by relying on the protocol version negotiated > during initialization - the server SHOULD assume protocol version `2025-03-26`. PR modelcontextprotocol#347 satisfied only the MUST requirement (reject invalid/unsupported values with 400). The SHOULD requirement to default a missing header to `2025-03-26` was deferred to this follow-up. This change brings the Ruby SDK in line with the Python SDK (`src/mcp/server/streamable_http.py`), which falls back to `DEFAULT_NEGOTIATED_VERSION` and then revalidates against the supported list. ## Behavior A new constant `MCP::Configuration::DEFAULT_NEGOTIATED_PROTOCOL_VERSION` holds `"2025-03-26"`. `validate_protocol_version_header` now substitutes this value when the `MCP-Protocol-Version` header is absent, then runs the same supported-version check. Because `"2025-03-26"` is currently in `SUPPORTED_STABLE_PROTOCOL_VERSIONS`, missing headers continue to pass through as before. Once `"2025-03-26"` is dropped from the supported list in a future change, missing headers will start returning 400 with a message naming the defaulted value. ## How Has This Been Tested? Existing test `POST request without MCP-Protocol-Version header succeeds` continues to pass (observable behavior unchanged today). Added a focused regression test that stubs the supported-version list to exclude `"2025-03-26"` and verifies that a header-less request is rejected with the defaulted value reported in the error message; this exercises the fallback branch directly. ## Breaking Changes None today. The fallback is future-proofing: when `"2025-03-26"` is eventually dropped, header-less requests will start returning 400. That is the intended spec-driven behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
MCP 2025-11-25 (basic/transports#protocol-version-header) specifies:
PR #347 satisfied only the MUST requirement (reject invalid/unsupported values with 400). The SHOULD requirement to default a missing header to
2025-03-26was deferred to this follow-up.This change brings the Ruby SDK in line with the Python SDK (
src/mcp/server/streamable_http.py), which falls back toDEFAULT_NEGOTIATED_VERSIONand then revalidates against the supported list.Behavior
A new constant
MCP::Configuration::DEFAULT_NEGOTIATED_PROTOCOL_VERSIONholds"2025-03-26".validate_protocol_version_headernow substitutes this value when theMCP-Protocol-Versionheader is absent, then runs the same supported-version check. Because"2025-03-26"is currently inSUPPORTED_STABLE_PROTOCOL_VERSIONS, missing headers continue to pass through as before. Once"2025-03-26"is dropped from the supported list in a future change, missing headers will start returning 400 with a message naming the defaulted value.How Has This Been Tested?
Existing test
POST request without MCP-Protocol-Version header succeedscontinues to pass (observable behavior unchanged today). Added a focused regression test that stubs the supported-version list to exclude"2025-03-26"and verifies that a header-less request is rejected with the defaulted value reported in the error message; this exercises the fallback branch directly.Breaking Changes
None today. The fallback is future-proofing: when
"2025-03-26"is eventually dropped, header-less requests will start returning 400. That is the intended spec-driven behavior.Types of changes
Checklist