Servlet-based server transports read request body with wrong charset encoding

Open
#880 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
64/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
backend

Research direction

Locate the servlet-based transport implementations that call request.getReader(), then compare their request-body handling with the StdioServerTransportProvider fix in PR 826. Add regression coverage using a non-ASCII JSON-RPC value and verify that requests without an explicit charset preserve the original characters.

Written by the indexing model from the issue text.

Description

bug P2 ready for work

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

  1. Start an MCP server using any of the servlet-based transports
  2. Send a tool call with a non-ASCII string argument, e.g. a unicode escape sequence like \u2014 (em dash —).
  3. 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

Dominant language
Java
Stars
3.7k
Forks
1.1k
Avg merge
1d 15h
Merged PRs (30d)
9

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/java-sdk

All issues in modelcontextprotocol/java-sdk

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.