modelcontextprotocol / modelcontextprotocol/java-sdk
Streamable HTTP accepts unsupported or malformed MCP-Protocol-Version headers
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 3.7k
- Forks
- 1.1k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 9
Description
Bug description
After a normal Streamable HTTP initialization flow, the server transport accepts requests with an unsupported or malformed MCP-Protocol-Version header and dispatches them normally with HTTP 200. The MCP Streamable HTTP specification for 2025-11-25 requires that if a server receives a request with an invalid or unsupported MCP-Protocol-Version, it MUST respond with HTTP 400 Bad Request.
This is a server-side validation issue. It is separate from client-side fixes that make the Java SDK client send the negotiated protocol version correctly.
Environment
- Java SDK: reproduced with
v1.1.2 - Also reproduced with a
mainsnapshot from 2026-05-11 (87e2c7d4dec60dc98a981ff24fedc2afc960de72) - Transport: Streamable HTTP server
- Java: Java 17 target
- Spring MCP integration: not required for reproduction
- Vector store: not used
Steps to reproduce
- Start a Java SDK Streamable HTTP server.
- Complete a normal
initializefollowed bynotifications/initializedflow. - Send a valid JSON-RPC request, such as
tools/list, withMCP-Protocol-Versionset to a well-formed but unsupported value such as1900-01-01. - Repeat with a malformed value such as
not-a-version. - Observe that the request is dispatched and returns HTTP 200.
Expected behavior
The server should reject the request before dispatching it:
HTTP/1.1 400 Bad Request
Minimal Complete Reproducible example
Set ENDPOINT to a Java SDK Streamable HTTP endpoint:
ENDPOINT=http://127.0.0.1:8080/mcp
Initialize and copy the returned Mcp-Session-Id header into SID:
curl -i -sS --http1.1 -X POST "$ENDPOINT" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: 2025-11-25' \
--data '{"jsonrpc":"2.0","id":"init-1","method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"version-header-repro","version":"0.1.0"}}}'
Send the initialized notification:
curl -i -sS --http1.1 -X POST "$ENDPOINT" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: 2025-11-25' \
-H "Mcp-Session-Id: $SID" \
--data '{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}'
Send an otherwise valid request with an unsupported protocol version:
curl -i -sS --http1.1 -X POST "$ENDPOINT" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: 1900-01-01' \
-H "Mcp-Session-Id: $SID" \
--data '{"jsonrpc":"2.0","id":"bad-version-1","method":"tools/list","params":{}}'
Observed response:
HTTP/1.1 200 OK
{"jsonrpc":"2.0","result":{"tools":[...]},"id":"bad-version-1"}
The same behavior is observed with a malformed header value:
curl -i -sS --http1.1 -X POST "$ENDPOINT" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: not-a-version' \
-H "Mcp-Session-Id: $SID" \
--data '{"jsonrpc":"2.0","id":"bad-version-2","method":"tools/list","params":{}}'
Observed response:
HTTP/1.1 200 OK
{"jsonrpc":"2.0","result":{...},"id":"bad-version-2"}
Additional context
- Related: #436 reports a client-side failure when a server responds with an unsupported protocol version during initialization. This is the opposite direction: the Java SDK server accepts unsupported or malformed protocol-version headers on subsequent HTTP requests.
- Related: #883 and #931 discuss client-side version emission on GET reconnect. Those are useful context, but this report is about server-side validation before dispatch.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the Streamable HTTP server transport request entry point and reproduce the issue with the provided curl sequence, testing both unsupported and malformed MCP-Protocol-Version values. Trace validation before request dispatch and add or update transport tests so both cases return HTTP 400 rather than HTTP 200.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100