Repository navigation
Conversation
…aracters Signed-off-by: Christopher Krah <48338417+chrikrah@users.noreply.github.com>
🦋 Changeset detectedLatest commit: effb6d6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
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 |
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
|
Verified this against base c05225a plus this branch. On main, decodeMcpParamValue('café') returns 'café' because the non-sentinel path at packages/core-internal/src/shared/mcpParamHeaders.ts:276 hands back any plain value unchecked; this branch gates it at :279. Running pnpm vitest run test/shared/mcpParamHeaders.test.ts test/shared/standardHeaderValidation.test.ts in packages/core-internal gives 92 passed (62 + 30), while the same PR tests against base fail exactly once with "expected 'café' to be undefined". packages/server test/server/mcpParamValidation.test.ts passes 9/9. The interior-tab case ('a\tb') still decodes, matching the 0x09 allowance in the spec. |
|
Read the diff (not run here). The shared Two checks I could not see in the tests: (1) |
The server accepts a plain
Mcp-Param-*orMcp-Namevalue that holds a character outside0x20–0x7Eand tab, becausedecodeMcpParamValue(packages/core-internal/src/shared/mcpParamHeaders.ts:274) returns any value without the Base64 sentinel as it is. The 2026-07-28 spec says servers MUST reject such anMcp-Param-*header. ForMcp-Name, Server Validation lists "a header value contains invalid characters" among the400/-32020failures. Its Value Encoding section says the client must Base64-wrap such a value.Node's HTTP parser passes a raw
0xE9byte through asé, so the value reachescreateMcpHandler. Before, at c05225a, throughhttp.createServerand a raw socket:After:
The new check uses the same character set as
needsBase64in the encoder. Both server checks get it:Mcp-Param-*andMcp-NameinvalidateStandardRequestHeaders. The cost: a client that sends raw Latin-1 in these headers now gets400/-32020, not200. The client in this SDK already wraps such values.v1.xhas no SEP-2243 code, so this is formainonly. A changeset is included. There is no issue for this.Verification
@felixweinberger, I kept the
*-invalid-encodingcells for this rejection because the wire answer is the same-32020. Do you want a separate*-invalid-characterscell for it?