modelcontextprotocol / modelcontextprotocol/java-sdk

Streamable HTTP accepts unsupported or malformed MCP-Protocol-Version headers

Offen
#957 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

bug P2
Vorherrschende Sprache
Java
Sterne
3.7k
Forks
1.1k
Ø Merge
1 T. 15 Std.
Gemergte PRs (30 T.)
9

Beschreibung

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 main snapshot 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

  1. Start a Java SDK Streamable HTTP server.
  2. Complete a normal initialize followed by notifications/initialized flow.
  3. Send a valid JSON-RPC request, such as tools/list, with MCP-Protocol-Version set to a well-formed but unsupported value such as 1900-01-01.
  4. Repeat with a malformed value such as not-a-version.
  5. 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.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne am Request-Einstiegspunkt des Streamable HTTP server transport und reproduziere das Problem mit der bereitgestellten curl-Sequenz, wobei du sowohl nicht unterstützte als auch fehlerhaft formatierte MCP-Protocol-Version-Werte testest. Verfolge die Validierung vor der Request-Weiterleitung und füge Transporttests hinzu oder aktualisiere sie, sodass beide Fälle HTTP 400 statt HTTP 200 zurückgeben.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
java
Bereich
api, backend
Issue-Typ
Bug
Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
68/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.