ITADN

[MCP] Streamable HTTP remote MCP servers fail with "400 Invalid session ID" — MCP-Session-Id not propagated through Teleport proxy

#66816Openpnrao1983 创建于 2026-05-15
application-accessMCP
P
pnrao1983commented
**Expected behavior:** When connecting to a remote Streamable HTTP MCP server (e.g. Datadog's `mcp.datadoghq.com`) via `tsh mcp connect`, the MCP-Session-Id issued by the remote server during `initialize` should be propagated correctly on all subsequent requests, allowing stateful sessions to work end-to-end. **Current behavior:** After `initialize` succeeds and the remote server issues a session ID, subsequent requests fail with `400 Invalid session ID`. The Teleport proxy does not appear to be forwarding the `MCP-Session-Id` header from the remote server back through the ALPN WebSocket tunnel to the client, causing the remote server to reject follow-up requests. **Bug details:** - **Teleport version:** - Proxy/Auth: 18.8.0 - Client (tsh): 18.8.0 - **App resource:** ```yaml kind: app version: v3 metadata: name: datadog-mcp labels: Name: stage-mcp-server spec: uri: mcp+https://mcp.datadoghq.com/api/unstable/mcp-server/mcp insecure_skip_verify: true rewrite: headers: - name: DD-API-KEY value: <redacted> - name: DD-APPLICATION-KEY value: <redacted> ``` - **Recreation steps:** 1. Register a remote Streamable HTTP MCP app using `mcp+https://` URI via `tctl create` 2. Ensure the label matches the app service selector on the agent node 3. Run `tsh mcp connect <app-name>` 4. Observe the connection initializes successfully (`Successfully issued certificate`) 5. Attempt any tool call or wait for the client to send a follow-up request 6. Observe `400 Invalid session ID` from the remote server - **Debug logs:** {"level":"info","message":"Successfully fetched app","name":"datadog-mcp","transport":"Streamable HTTP"} {"level":"info","message":"Started a new MCP server connection"} {"level":"info","message":"Successfully issued certificate","name":"datadog-mcp"} {"level":"warning","message":"failed to write notification to server. Notification is dropped.", "error":"notification failed with status 400: Invalid session ID\n"} {"jsonrpc":"2.0","id":null,"error":{"code":-32700,"message":"invalid character 'o' in literal true (expecting 'r')"}} **Additional context:** - stdio MCP servers (e.g. `teleport-mcp-demo`) work correctly - The `goshd-kibana-mcp` server (local Streamable HTTP on `localhost:8000`) fails with a different error: `http: server gave HTTP response to HTTPS client` — separate issue, tracked separately - This error was masked as `-32603` on versions prior to 18.8.0. The upgrade to 18.8.0 exposed the actual underlying `400 Invalid session ID` error - The MCP spec (2025-03-26) requires clients to include `MCP-Session-Id` on all subsequent requests after initialization. The Teleport proxy appears to not be relaying this header bidirectionally through the tunnel. **Reference:** - MCP Streamable HTTP spec: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports - Related PRs: #60519 (streamable HTTP support), #60843 (custom header support)
0 条评论