[Streamable HTTP][Server] GET should open a server→client SSE listener

从 vendor/mcp/sdk/src/Server/Transport/StreamableHttpTransport.php 开始，跟踪 handleRequest()、handlePostRequest()、createStreamedResponse()、CallbackStream 和 flushOutgoingMessages()。在适用的情况下复用现有的会话验证和流式处理路径，然后验证 GET 需要有效会话、生成 SSE 响应、排空排队的消息，并在断开连接时干净地终止。

Problem

StreamableHttpTransport only handles OPTIONS, POST, and DELETE. GET falls into the match default arm and gets a 405 Method Not Allowed with Allow: POST, DELETE, OPTIONS.

vendor/mcp/sdk/src/Server/Transport/StreamableHttpTransport.php (current main):

return match ($request->getMethod()) {
    'OPTIONS' => $this->handleOptionsRequest(),
    'POST'    => $this->handlePostRequest(),
    'DELETE'  => $this->handleDeleteRequest(),
    default   => $this->createErrorResponse(Error::forInvalidRequest('Method Not Allowed'), 405),
};

This contradicts both the MCP spec and the SDK's own CORS advertisement on the same class:

'Access-Control-Allow-Methods' => 'GET, POST, DELETE, OPTIONS',

Per the MCP Streamable HTTP transport spec, a client may issue GET against the MCP endpoint to open a long-lived SSE channel for server→client messages (notifications and server-initiated requests outside the request/response loop). Refusing the GET breaks that channel.

Observed impact

Spec-conformant clients open this listener immediately after initialize. The 405 kills the channel. In our deployment we see two session rows created in the session store on every fresh client startup — one for the working POST request/response loop, one orphaned from the failed listener that the client retries under a new session id.

Proposal

Add handleGetRequest() to StreamableHttpTransport and route GET to it from the match in handleRequest().

Behavior:

• Require Mcp-Session-Id; without it return 400 (consistent with handleDeleteRequest()).
• Validate the session exists in the configured SessionStoreInterface; on miss return 404.
• Open an SSE response (Content-Type: text/event-stream) and stream:
  • any queued outgoing messages for this session (the same queue flushOutgoingMessages() already drains in createStreamedResponse());
  • server-initiated requests/notifications produced via the existing Protocol/Fiber machinery.
• Honor Last-Event-ID for resumption per the spec (can land in a follow-up; the initial PR can document the gap).
• Cleanly terminate when the client disconnects.

The mechanics already exist — CallbackStream and flushOutgoingMessages() from PR #109 do the streaming half inside handlePostRequest(). The new method is essentially the same loop without a triggering POST body.

Backward compatibility

Purely additive. Clients that never issue GET see no change. The Access-Control-Allow-Methods header already advertises GET, so the surface is unchanged from the client's perspective — only the server's response to a method it claims to accept changes from 405 to a valid SSE stream.

Related

• PR #109 — added CallbackStream + flushOutgoingMessages() for SSE inside handlePostRequest. Provides the streaming primitives this proposal reuses.
• Issue #226 — fixed the previous 500 response for unsupported methods to 405 + Allow. That work treated GET as legitimately unsupported; this issue argues GET is actually supported by the spec and should be wired up.
• Issue #275 — separate concurrency race on the per-session outgoing message queue. Independent, but a working GET listener will exercise the same queue and would benefit from the same fix.