fix(examples): return 404 for invalid session IDs#1707
fix(examples): return 404 for invalid session IDs#1707owendevereaux wants to merge 2 commits intomodelcontextprotocol:mainfrom
Conversation
Fixes modelcontextprotocol#389 The streamable HTTP server examples were returning 400 for both missing and invalid session IDs. Per the MCP spec: - Missing session ID (non-init request) → 400 Bad Request - Invalid session ID (not found) → 404 Not Found The 404 status is important because it signals to clients that they should start a new session (per spec: 'When a client receives HTTP 404 in response to a request containing an Mcp-Session-Id, it MUST start a new session'). Updated the following examples: - jsonResponseStreamableHttp.ts - simpleStreamableHttp.ts (POST, GET, DELETE handlers) - standaloneSseWithGetStreamableHttp.ts (POST, GET handlers) - elicitationFormExample.ts (POST, GET, DELETE handlers) - elicitationUrlExample.ts (POST, GET, DELETE handlers) - simpleTaskInteractive.ts (POST, GET, DELETE handlers)
🦋 Changeset detectedLatest commit: 64c7a4a The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
travisbreaks
left a comment
There was a problem hiding this comment.
Clean spec-compliance fix. The 400 vs 404 distinction matters: 400 for "you didn't send a session ID" vs 404 for "you sent one but it's gone" tells the client whether to retry with a new session or fix the request format. Good MCP spec citations in the comments.
Two observations:
1. Code duplication
The session ID lookup pattern (missing -> 400, not found -> 404, found -> proceed) is now copy-pasted across 7 example files with minor formatting differences. This is a good candidate for extraction into a shared middleware or helper:
function resolveTransport(sessionId, transports, res) {
if (!sessionId) { res.status(400)...; return null; }
if (!transports[sessionId]) { res.status(404)...; return null; }
return transports[sessionId];
}Not a blocker for this PR, but worth noting as a follow-up.
2. Consistent JSON-RPC error shape
POST handlers return JSON-RPC error objects ({ jsonrpc: '2.0', error: { code, message }, id: null }), but GET and DELETE handlers return plain text (res.status(404).send('Session not found')). Should the response format be consistent across all HTTP methods? A JSON-RPC client might expect structured errors regardless of method.
Straightforward PR. Approve once the consistency question is addressed or intentionally skipped.
|
Thanks for the review! Good catches on both points. Re: Code duplication Re: JSON-RPC error shape consistency
The spec says 'when a client receives HTTP 404... it MUST start a new session'—the status code is what matters, not the body format. A plain text body for HTTP-level errors keeps these handlers simple and avoids inventing a JSON-RPC error for non-JSON-RPC operations. That said, if maintainers prefer structured JSON for all responses (not necessarily JSON-RPC), I can update. What do you think? |
Summary
Fixes #389
The streamable HTTP server examples were returning HTTP 400 for both missing and invalid session IDs. Per the MCP spec, these should be handled differently:
The 404 status is important because it signals to clients that they should start a new session. Per the spec:
Changes
Updated all streamable HTTP examples to differentiate between missing and invalid session IDs:
jsonResponseStreamableHttp.tssimpleStreamableHttp.ts(POST, GET, DELETE handlers)standaloneSseWithGetStreamableHttp.ts(POST, GET handlers)elicitationFormExample.ts(POST, GET, DELETE handlers)elicitationUrlExample.ts(POST, GET, DELETE handlers)simpleTaskInteractive.ts(POST, GET, DELETE handlers)Testing
Manually verified the logic by code review. The changes are straightforward: split the existing
!sessionId || !transports[sessionId]checks into separate conditions with appropriate status codes.Spec Reference
From the MCP Transport specification: