mcp: rejected request IDs receive no JSON-RPC error envelope

未关闭
  • 哪里不对？
#1,391 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@skosovsky 已经在做这个了。

开始于 2026年10月12日。

  • #1392 来自 @skosovsky —— 未关闭
  • #1399 来自 @Totopo27 —— 已关闭，未合并

评估

难度
4/5
预计耗时
1-2 天
新手友好度
68/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go
领域
api, backend

调研方向

Start with the StreamableHTTPHandler and IO/stdio request decoding and read paths; the issue does not name specific files or tests. Reproduce the invalid-ID request on both transports, then inspect how each handles decoder rejection and frames errors. Done means both return an Invalid Request (-32600) envelope with id null, HTTP uses 400 and application/json, IO/stdio continues to the following valid request, and the rejected request is not dispatched.

由索引模型根据 Issue 内容生成。

描述

Problem

A syntactically valid, single JSON-RPC request with an ID rejected by the decoder does not receive a JSON-RPC error response:

{"jsonrpc":"2.0","id":true,"method":"ping"}

On upstream main d1a225e:

  • Streamable HTTP returns HTTP 400 with a text/plain body beginning malformed payload, rather than a JSON-RPC error envelope.
  • The IO/stdio transport returns parse error: invalid ID type bool from Read, writes no response, and does not deliver the subsequent valid request in that read call. The connection read loop treats this as a terminal read error.

The same behavior occurs for object and array IDs. These cases reproduce independently of the pending numeric-ID precision fixes.

Expected behavior

For a single request whose ID cannot be accepted, return a JSON-RPC Invalid Request error (-32600) with an explicit id: null. Over HTTP, use HTTP 400 and application/json. Over IO/stdio, write the error and continue reading subsequent valid messages. Do not dispatch the rejected request.

The response ID requirement comes from https://www.jsonrpc.org/specification#response_object. This report concerns structurally invalid IDs, not a new numeric range policy.

Reproduction

HTTP: POST the above body to a StreamableHTTPHandler with Content-Type application/json and Accept application/json, text/event-stream.

IO/stdio: feed the above JSON followed by a newline and {"jsonrpc":"2.0","id":7,"method":"ping"}. The current transport returns an error without writing a JSON-RPC response.

Regression tests reproduce both failures on the unmodified base. Repeating the invalid frame 1000 times before a valid request tests iterative recovery.

Related work and scope

  • #1209 / #1210 concern syntactically malformed JSON and decoder resynchronization. Here JSON decoding succeeds, so that recovery machinery is unnecessary.
  • #976 concerns other malformed request envelopes.
  • #1375 / #1253 address exact numeric identity parsing. Once a numeric ID is rejected by those decoders, it needs the same error framing. This change can be reviewed independently and does not redefine numeric acceptance.

Legacy batch handling, invalid response handling, absent/null request IDs, and malformed JSON recovery are outside this narrowly scoped fix.

主要语言
Go
星标
5.3k
派生
607
平均合并
1 天 17 小时
30 天内合并 PR
80

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/go-sdk 的其他 Issue

查看 modelcontextprotocol/go-sdk 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。