Streamable HTTP server never returns the spec-mandated 405 for GET requests it won't serve as SSE (406/400 instead) — breaks client SSE-probe fallback

[fgranata]

Summary

The streamable-HTTP server transport never answers a GET it won't serve with 405 Method Not Allowed, even though the spec makes 405 the required signal:

The server MUST either return Content-Type: text/event-stream in response to this HTTP GET, or else return HTTP 405 Method Not Allowed, indicating that the server does not offer an SSE stream at this endpoint.
— Streamable HTTP § Listening for Messages from the Server

Instead, a GET that can't be served yields:

Pre-session GET /mcp with…	Server response
Accept: */*, Accept: application/json, or no Accept	406 Not Acceptable (_handle_get_request → _check_accept_headers, which does literal prefix matching so */* is not honored)
Accept: text/event-stream (stateful server, no mcp-session-id)	400 Bad Request: Missing session ID (_validate_session)

So in stateful mode there is no request shape for which a pre-session GET returns 405. (405 is used elsewhere: DELETE without a session and unsupported methods.)

Why it matters — real interop break

Several client transports probe with exactly this GET before initialize to ask "do you offer a standalone SSE stream?", and treat only 405 as the graceful "no SSE — fall through to POST" signal (e.g. the TypeScript SDK's _startOrAuthSse explicitly special-cases 405). Any other status is a transport error, so against a stock python-SDK server the connection aborts before initialize is ever sent.

We hit this in production between two independently-built agents: the client authenticated successfully, then its GET probe got 406 (its relay sent Accept: */*), the transport threw, and the handshake never reached initialize — surfacing as "server doesn't respond to MCP protocol" while the server looked perfectly healthy to every python-SDK client (which only GETs after initialize, with a session id). We've deployed a workaround (a small ASGI shim returning 405 + Allow: POST for session-less GETs on the MCP path), but every stock python-SDK deployment presumably reproduces this.

Repro (mcp 1.28.1, stateful StreamableHTTP server)

curl -i -X GET http://localhost:8000/mcp -H 'Accept: */*'                 # → 406, expected 405
curl -i -X GET http://localhost:8000/mcp -H 'Accept: text/event-stream'  # → 400, expected 405 (no session yet)

Suggested behavior

For a GET the server cannot serve as an SSE stream, respond 405 with an Allow header per the spec quote above — at minimum for the pre-session case (no mcp-session-id), where returning 400 makes the spec'd client probe impossible to satisfy. Separately (or as part of this), _check_accept_headers honoring */* / text/* per RFC 9110 §12.5.1 would remove the 406 arm for wildcard clients.

Related

• Streamable HTTP transport rejects Accept: text/event-stream without application/json #2349 covers the POST-side strict dual-Accept requirement; this issue is about the GET/405 contract, which is distinct.
• MCP Server won't work with wildcard in "Accept" header and therefore is non‑compliant with HTTP spec #1641 raised wildcard-Accept non-compliance and is closed, but on 1.28.1 _check_accept_headers still does literal prefix matching, and the GET path 406s wildcard clients.

Happy to provide full header traces or a PR if the maintainers agree on the intended shape.

[dosvk]

I'd like to help get this fixed — I work with MCP streaming transports in production and have contributed transport-adjacent fixes to strands-agents-tools (#439, #440), and this GET/405 contract break is exactly the kind of interop failure we've had to shim around.

@fgranata since you offered a PR pending maintainer direction: happy to either collaborate or take the implementation if you'd rather not — your writeup already nails the root cause.

Proposed shape, for maintainer feedback:

1. Pre-session GET (no mcp-session-id) that can't be served as SSE → 405 Method Not Allowed + Allow: POST, DELETE, per the spec clause quoted in the issue. This restores the TypeScript SDK's _startOrAuthSse fallback path.
2. _check_accept_headers honors */* and text/* per RFC 9110 §12.5.1, removing the 406 arm for wildcard clients (follows up on MCP Server won't work with wildcard in "Accept" header and therefore is non‑compliant with HTTP spec #1641, which is closed but still reproduces on 1.28.1).
3. Regression tests covering: pre-session GET with Accept: */*, Accept: application/json, no Accept, and Accept: text/event-stream — all asserting 405 with Allow; plus the client-probe fallback sequence end-to-end.

If maintainers confirm this is the intended shape, I can have a PR up within a week.

[fgranata]

Thanks @dosvk — that would be great. We're happy to verify a fix quickly: we run a production streamable-HTTP server on the stock SDK and have the exact failing client transport on the other side, so we can confirm end-to-end (pre-session GET with Accept: */* / application/json / text/event-stream all currently land on 406/400 instead of 405). One design note from our side: whatever shape you pick, keep the sessionful GET path (valid mcp-session-id → SSE listen/resume and its 400/404 session semantics) untouched — the 405 only makes sense for the pre-session probe case. Tag me on the PR and we'll test it against our setup.

[dosvk]

@fgranata the PR is up: #3129 — and your design note is exactly the shape it takes:

• The 405 fires only for the pre-session probe case (stateful mode + no mcp-session-id header), and it's rejected at the session-manager layer before any session is created, so probes don't leak server state.
• The sessionful GET path is untouched: valid mcp-session-id + Accept: text/event-stream still serves SSE (listen/resume unchanged), and the wrong-session-id semantics are preserved — there are explicit regression tests for both (test_standalone_transport_get_with_wrong_session_returns_404, plus the existing SSE suite passing unmodified).
• All four of your failing probe shapes (*/*, application/json, no Accept, text/event-stream) are covered in test_pre_session_get_returns_405, each asserting 405 + Allow: GET, POST, DELETE.

CI is fully green across the matrix. An end-to-end confirmation against your production server + the real client transport would be fantastic — that's the one thing unit tests can't give us. If you can point your client at a server built from the branch (dosvk:fix/3102-get-405-spec-compliance), I'd love to hear whether the SSE-probe fallback completes through initialize.