Skip to content

Streamable HTTP server rejects a mixed-case Content-Type with 415 #3670

Open
Open
Streamable HTTP server rejects a mixed-case Content-Type with 415#3670
Labels
bugSomething isn't workingv1Affects the v1.x maintenance linev2Affects the v2 line (2.x on main)

Description

@v0ropaev
v0ropaev
opened on Oct 10, 2026

Release line

v2 (main, verified at 91941ed).

Description

StreamableHTTPServerTransport._check_content_type compares the request's Content-Type media type case-sensitively, so a POST with Content-Type: Application/JSON is answered 415 and the handshake never completes. Media types are case-insensitive per RFC 9110 §8.3.1.

Two things in the same request path already get this right, which is what makes the behaviour inconsistent rather than merely strict.

check_accept_headers (src/mcp/server/streamable_http.py:96) lowercases every Accept media type:

    accept_types = [media_type.strip().split(";")[0].strip().lower() for media_type in accept_header.split(",")]

and TransportSecurityMiddleware._validate_content_type (src/mcp/server/transport_security.py:96) lowercases too:

        return content_type is not None and content_type.lower().startswith("application/json")

The middleware runs first and is the lenient one, so a mixed-case header passes it and then hits the strict comparison in the transport (src/mcp/server/streamable_http.py:534):

        return any(part == CONTENT_TYPE_JSON for part in content_type_parts)

This also makes a note in your own conformance table wrong. tests/interaction/_requirements.py:3136 records a divergence for hosting:http:content-type-415 saying

The transport-security middleware rejects a non-JSON Content-Type with 400 'Invalid Content-Type header' before the request reaches the transport, so the transport's own 415 path is unreachable through any public entry point.

and the call site at line 569 carries # pragma: no cover on that belief. A mixed-case Content-Type is the public entry point that reaches it.

Example Code

Against the repo's own in-process harness on main at 91941ed, after uv sync --frozen:

import pytest
from mcp_types import CallToolRequestParams, CallToolResult, ListToolsResult, PaginatedRequestParams, TextContent

from mcp.server import Server, ServerRequestContext
from tests.interaction._connect import base_headers, initialize_body, mounted_app

pytestmark = pytest.mark.anyio


def _server() -> Server:
    async def list_tools(ctx: ServerRequestContext, params: PaginatedRequestParams | None) -> ListToolsResult:
        return ListToolsResult(tools=[])

    async def call_tool(ctx: ServerRequestContext, params: CallToolRequestParams) -> CallToolResult:
        return CallToolResult(content=[TextContent(text="done")])

    return Server("hosted", on_list_tools=list_tools, on_call_tool=call_tool)


async def test_content_type_casing() -> None:
    async with mounted_app(_server()) as (http, _):
        for value in ("application/json", "Application/JSON", "APPLICATION/JSON", "application/json; charset=utf-8"):
            r = await http.post("/mcp", json=initialize_body(), headers=base_headers() | {"content-type": value})
            print(f"{value!r:45} -> {r.status_code} {r.text[:60]!r}")

Output:

'application/json'                            -> 200 'event: message\r\ndata: {"jsonrpc":"2.0","id":1,"result":{"ca'
'Application/JSON'                            -> 415 '{"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":'
'APPLICATION/JSON'                            -> 415 '{"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":'
'application/json; charset=utf-8'             -> 200 'event: message\r\ndata: {"jsonrpc":"2.0","id":1,"result":{"ca'

The fix is to lowercase the parsed parts before comparing, the way the two siblings do.

Why it matters to me

Being straight about this, since you said that is what you use to prioritise: I do not have a client of my own that sends mixed-case, and I found this while checking the divergence notes in _requirements.py against the code. So the practical weight is not "my deployment is broken", it is that the server rejects a spec-conformant client at the handshake for a header-casing difference, and that your own conformance record currently states the opposite.

A one-line fix and a test are ready if you want a pull request. #2916 was the same fix against v1 and was closed in the backlog sweep, so I am filing the issue first as you asked there rather than opening another pull request unprompted.

Python & MCP Python SDK

Python 3.12 on macOS 27 arm64, repository main at 91941ed with uv sync --frozen.

Activity

  1. claude
    added
    bugSomething isn't working
    v2Affects the v2 line (2.x on main)
    v1Affects the v1.x maintenance line
    on Oct 10, 2026

  2. epistemedeus commented on Oct 10, 2026

    @epistemedeus
    epistemedeus
    on Oct 10, 2026

    Confirmed against v2 main at 91941ed. The case-fold fixes the mixed-case initialize handshake. One useful conformance detail: Text/Plain is still the middleware 400, while application/json-patch+json passes that prefix check and reaches the transport's 415. So the 415 path remains reachable after the casing fix.

    Here are the tested patch and regression cases. The patched owning test path passes 6,101 tests (8 skipped, 1 expected failure), with 100% coverage and a clean strict-no-cover check. An independent replay passed the 17 hosting tests; a fresh installed-wheel consumer accepted five valid case/parameter variants and retained the 400 and 415 refusals.

    Since you already have a fix ready and filed the issue as requested, this is supporting test material, not a competing PR. The patch leaves the modern request-handler path and v1.x unchanged.

  3. CRYPTONIKAV commented on Oct 10, 2026

    @CRYPTONIKAV
    CRYPTONIKAV
    on Oct 10, 2026

    I have the one-line fix ready (lowercase the parsed parts in _check_content_type, mirroring the two siblings) plus a regression test in test_hosting_http.py (mixed-case variants incl. charset → 200, text/plain → 400, suffix types still 415). Verified locally: RED on pristine (Application/JSON → 415), GREEN after (owning file 12/12, server+transports 1456/1456, ruff clean). Could you assign me so I can open the PR per the contributing template?

  4. JingHao-Leon commented on Oct 11, 2026

    @JingHao-Leon
    JingHao-Leon
    on Oct 11, 2026

    Confirming this on main at 4b5fe5a, since the report cites an older commit. I built the extension and called _check_content_type directly with a bare Request, and the behaviour is as described

    'application/json'                      -> True
'application/json; charset=utf-8'       -> True
'Application/JSON'                      -> False
'APPLICATION/JSON'                      -> False
'application/JSON; charset=utf-8'       -> False

    So every mixed-case spelling fails, and the failure is not limited to the bare media type. Content-Type field names and media types are both case-insensitive per RFC 9110 5.1 and 8.3.1.

    The fix is one .lower() on the split parts, which matches what the two call sites in the same request path already do, and I checked that a non-JSON media type still returns False afterwards. I followed the policy in CONTRIBUTING and did not open a pull request, but the branch is on my fork at JingHao-Leon/python-sdk:fix/content-type-case-insensitive in case that is useful.

    One correction to the report, offered as a data point rather than a point. The divergence note in tests/interaction/_requirements.py for hosting:http:content-type-415 says the transport's own 415 path is unreachable because the transport-security middleware answers 400 first. That still holds, and the fix does not change it. What the case sensitivity breaks is any request that reaches the transport without the middleware in front, and the conformance entry cannot see that because the entry is blocked by the same 400

  5. CRYPTONIKAV commented on Oct 11, 2026

    @CRYPTONIKAV
    CRYPTONIKAV
    on Oct 11, 2026

    Hi — I'd like to be assigned to #3670 if possible. I have the one-line fix ready (lowercase the parsed parts in _check_content_type, mirroring the sibling checks) plus tests: an interaction test with mixed-case variants incl. charset (200) and a text/plain negative control (400), and direct unit tests of _check_content_type. My PR #3675 was auto-closed by the linked-issue rule; it should reopen on assignment. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingv1Affects the v1.x maintenance linev2Affects the v2 line (2.x on main)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions