Streamable HTTP server does not validate body/header protocol-version consistency on initialize

Start by locating the PHP SDK's Streamable HTTP server handling for the initialize request and reproduce the mismatch with the provided curl command in both directions. Decide whether mismatches should be rejected or documented as using an authoritative field, then add coverage for the chosen behavior and verify the negotiated version response.

Describe the bug

When the initial initialize request carries an MCP-Protocol-Version HTTP header that disagrees with initialize.params.protocolVersion in the JSON-RPC body, the server accepts the request without error. In both mismatch directions, the server returned 2025-06-18 as the negotiated version rather than following either input value.

The current MCP 2025-11-25 specification does not explicitly require the server to check body/header consistency on initialize, so this is filed as an implementation observation rather than a strict spec-violation claim.

• Environment
  • Reproduced with stable releasev0.5.0 (fb2c8c2e)
  • Also reproduced with a main snapshot from 2026-05-16 (5e0731f7)
  • Transport: Streamable HTTP server (stateful profile)

To reproduce

1. Start a PHP SDK Streamable HTTP server.
2. Send an initialize request where the body protocolVersion is 2025-11-25 but the MCP-Protocol-Version header is 2025-03-26 (or vice versa).
3. Observe that the server returns HTTP 200 with a normal initialize result.
4. Check the negotiated protocol version in the response.

Expected behavior

Option A: the server rejects the mismatch before negotiation, for example with HTTP 400 or a JSON-RPC Invalid Request error.

Option B: the spec clarifies which field is authoritative, and the SDK documents that behavior and covers it with a regression test.

Logs

Both mismatch directions were accepted:

body=2025-11-25 header=2025-03-26 -> HTTP 200, negotiated version = 2025-06-18 (server-determined)
body=2025-03-26 header=2025-11-25 -> HTTP 200, negotiated version = 2025-06-18 (server-determined)

The server returned its own preferred protocol version (2025-06-18) regardless of both the body and header values. In these tests, the negotiated version was server-determined rather than derived from either mismatched input.

With a Streamable HTTP server running, set ENDPOINT to the server endpoint and send an initial initialize request whose HTTP header and JSON-RPC body disagree:

ENDPOINT=http://127.0.0.1:8080/mcp

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-03-26' \
  --data '{"jsonrpc":"2.0","id":"init-conflict-1","method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"version-conflict-repro","version":"0.1.0"}}}'

Repeat with the values reversed: body 2025-03-26, header 2025-11-25.

Additional context

• Related: SEP-2575 introduces a related future-state requirement that, for HTTP requests, the MCP-Protocol-Version header match _meta["io.modelcontextprotocol/protocolVersion"].