Servlet-based server transports read request body with wrong charset encoding
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 64/100
Rechercherichtung
Finde die servletbasierten Transportimplementierungen, die request.getReader() aufrufen, und vergleiche deren Verarbeitung des Request-Bodys mit dem Fix für StdioServerTransportProvider in PR 826. Füge eine Regressionstestabdeckung mit einem Nicht-ASCII-JSON-RPC-Wert hinzu und verifiziere, dass Requests ohne expliziten charset die ursprünglichen Zeichen beibehalten.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- Java
- Sterne
- 3.7k
- Forks
- 1.1k
- Ø Merge
- 1 T. 15 Std.
- Gemergte PRs (30 T.)
- 9
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus modelcontextprotocol/java-sdk
-
area/transport bug P2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
modelcontextprotocol/java-sdk#1136 ·
-
area/client bug P2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
modelcontextprotocol/java-sdk#1124 · 1 Kommentar ·
-
ServerCapabilities.logging is added unconditionally, overriding the caller's explicit capabilities Offenbug P2 ready for work
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
modelcontextprotocol/java-sdk#1086 · 1 Kommentar ·
-
enhancement good first issue P3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
modelcontextprotocol/java-sdk#1067 ·
-
bug P2 ready for work
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
modelcontextprotocol/java-sdk#898 · 1 Kommentar ·
Alle Issues in modelcontextprotocol/java-sdk
Ähnliche Issues
-
Bug Java Platform: Java
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
getsentry/sentry-java#6138 · 1 Kommentar ·
-
bug needs triage p2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
GoogleCloudPlatform/DataflowTemplates#4273 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
bug needs triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100