fix(streamable-http-server): answer a session-less non-initialize POST with 400

[jensholdgaard]

🤖 AI-generated PR, prepared with Claude Code and reviewed by the submitter.

Fixes #1376.

Problem

In legacy session mode, StreamableHttpService answers a POST that has no Mcp-Session-Id header and is not initialize with 422 Unprocessable Entity (Unexpected message, expect initialize request). GET and DELETE without a session id already return 400 Bad Request (Bad Request: Session ID is required), so POST was the odd one out, and the spec asks for 400 here.

The Session Management section of the Streamable HTTP transport says, in 2025-11-25 (and in the same words in 2025-06-18):

Servers that require a session ID SHOULD respond to requests without an MCP-Session-Id header (other than initialization) with HTTP 400 Bad Request.

What changed

• server_side_http.rs: unexpected_message_response (422) is replaced by session_id_required_response (400, Bad Request: Session ID is required). The two POST call sites were its only callers.
• tower.rs: both session-less POST branches (a non-initialize request, and a notification or response) now return that response. The GET and DELETE handlers use the same helper in place of their inline copies, with no change in behaviour.

Stateless mode and the session-less server/discover path are untouched. They never reached these branches.

Tests

• stateful_rejected_initial_posts_do_not_create_sessions: the expected status for a session-less tools/list changes from 422 to 400. The old value encoded the spec deviation.
• New stateful_post_without_session_id_is_bad_request: a session-less request and a session-less notification each get 400 with the same body as GET and DELETE, and no session is created.
• test_discover_http_client_startup.rs still uses a mock legacy server that returns 422. It stands for already-deployed servers, and the client's discover fallback accepts any non-auth 4xx, so it is left as is.

How it was found

An MCP client was reconnecting after the server had reaped an idle session. Its request with the stale session id got 404 Not Found, as the spec requires. Its next session-less request then got 422 instead of 400, before the client re-initialized.

[github-actions]

@connor4312 is on triage rotation this week and is the reviewer for this one.

Labels come from the PR labeler. Please review the change.

_{Automated triage. Labels are a first pass and the assigned maintainer has the final say.}