Servlet-based server transports read request body with wrong charset encoding
維護者通常 3 天內回覆
評估
研究方向
找出呼叫 request.getReader() 的 servlet 型傳輸實作，然後將它們對請求本文的處理方式與 PR 826 中 StdioServerTransportProvider 的修正進行比較。使用非 ASCII 的 JSON-RPC 值新增回歸測試涵蓋，並驗證未明確指定 charset 的請求能保留原始字元。
由索引模型根據 Issue 內容生成。
描述
Bug description
The servlet-based server transports call request.getReader() without first calling request.setCharacterEncoding("UTF-8"). Per the Jakarta Servlet spec, getReader() defaults to ISO-8859-1 when the request's Content-Type doesn't include an explicit charset parameter. Since Content-Type: application/json (without charset) is standard and correct per RFC 8259, any non-ASCII characters in the JSON-RPC request body are silently corrupted.
This affects everything in the request payload — tool names, argument values, notification data — for any MCP client that doesn't redundantly declare charset=utf-8 in its Content-Type header. The analogous issue in StdioServerTransportProvider was fixed in https://github.com/modelcontextprotocol/java-sdk/pull/826.
Environment
- MCP Java SDK: 1.0.0
- Java: 21
- No Spring AI or vector store involved — this is a bug in the core servlet request reading logic, not specific to any framework or integration.
Steps to reproduce
- Start an MCP server using any of the servlet-based transports
- Send a tool call with a non-ASCII string argument, e.g. a unicode escape sequence like \u2014 (em dash —).
- The server receives mojibake (e.g. — → â).
Expected behavior
Non-ASCII characters in the JSON-RPC request body (tool names, argument values, etc.) should be preserved correctly. JSON is UTF-8 by definition, so the server should decode request bodies as UTF-8 regardless of whether the client includes charset=utf-8 in the Content-Type header.
Related
- 主要語言
- Java
- 星號
- 3.7k
- 分支
- 1.2k
- 平均合併
- 2 天 5 小時
- 30 天內合併 PR
- 4
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
modelcontextprotocol/java-sdk 的其他 Issue
-
HttpServletStreamableServerTransportProvider: GET stream sends no status or headers until the first event可能已有人在做 @karthiksenv 於 3 天前認領。 未關閉area/server area/transport P3
難度 2/5 1-3 小時 新手友好度 86/100
modelcontextprotocol/java-sdk#1155 ·
維護者通常 3 天內回覆
-
Client request handlers that complete empty send no JSON-RPC response可能已有人在做 @1fanwang 於 33 天前認領。 未關閉area/client bug P2
難度 2/5 1-3 小時 新手友好度 84/100
modelcontextprotocol/java-sdk#1124 · 5 則留言 ·
維護者通常 3 天內回覆
-
ServerCapabilities.logging is added unconditionally, overriding the caller's explicit capabilities可能已有人在做 @1yuxiangJ 於 48 天前認領。 未關閉bug P2 ready for work
難度 2/5 1-3 小時 新手友好度 68/100
modelcontextprotocol/java-sdk#1086 · 1 則留言 ·
維護者通常 3 天內回覆
-
Reject listRoots if not supported by client, without sending any request可能已有人在做 @nikita-kibitkin 於 71 天前認領。 未關閉enhancement good first issue P3
難度 2/5 1-3 小時 新手友好度 82/100
modelcontextprotocol/java-sdk#1067 · 1 則留言 ·
維護者通常 3 天內回覆
-
StdioClientTransport missing explicit UTF-8 charset in InputStreamReader (same issue as #295, but on client side)可能已有人在做 @suryateja-g13 於 142 天前認領。 未關閉bug P2 ready for work
難度 2/5 1-3 小時 新手友好度 74/100
modelcontextprotocol/java-sdk#898 · 1 則留言 ·
維護者通常 3 天內回覆
查看 modelcontextprotocol/java-sdk 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 86/100
-
Make branch and label autocomplete matching locale-independent可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 2/5 1-3 小時 新手友好度 83/100
jenkinsci/gitlab-plugin#1950 ·
-
It's not necessary to copy the memory block in the readWrite() of org.h2.store.fs.mem.FileMemData未關閉
難度 2/5 1-3 小時 新手友好度 78/100
h2database/h2database#4435 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
micronaut-projects/micronaut-core#13717 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
ADORSYS-GIS/token-status-link#145 ·
維護者通常 3 天內回覆