Skip to content

fix(transport): match reqwest response media types exactly - #1390

Draft
theamodhshetty wants to merge 1 commit into
modelcontextprotocol:mainfrom
theamodhshetty:fix/reqwest-response-media-types
Draft

theamodhshetty wants to merge 1 commit into
modelcontextprotocol:mainfrom
theamodhshetty:fix/reqwest-response-media-types

Conversation

@theamodhshetty

Copy link
Copy Markdown
Contributor

Motivation and Context

The reqwest Streamable HTTP client rejects valid Application/JSON and Text/Event-Stream responses, while admitting different types such as application/jsonx and text/event-streaming. On a JSON 503 response, the case mismatch also loses the original JSON-RPC error.

Fixes #1389. This is separate from #1382, which changes server request validation.

Use one private matcher for the complete response media-type essence across GET admission, POST JSON/SSE dispatch and JSON error classification. Compare type/subtype case-insensitively, preserve parameter tolerance, and reject suffixes and comma-joined essences. Parameter bytes are left opaque. The existing accepted media types and body-free 429 policy are unchanged. No API or dependency changes.

How Has This Been Tested?

On macOS arm64 with Rust 1.96.1:

  • 22 real HTTP cases against axum listeners: 12 fail on unchanged upstream 2a401c4, with 10 passing controls. All pass with this fix.
  • Two additional byte-level cases preserve opaque parameter bytes and reject a non-ASCII essence.
  • All 411 rmcp library tests and 61 tests across eight related HTTP integration targets pass.
  • Strict Clippy for the library and tests passes with the relevant HTTP and stdio/child-process features enabled. Nightly workspace formatting and diff checks pass.
  • Full cross-platform and feature-matrix CI were not run locally.

The wire tests exercise GET, POST JSON/SSE, parameters, absent headers, case variants, suffix/list rejection, JSON 503 preservation and 429 status handling. No live external service or credentials are used.

Breaking Changes

Previously misclassified response types such as application/jsonx now return the existing unexpected-content-type error on success responses. They are not JSON/SSE media types. Valid response types remain accepted, with added case-insensitive support.

Types of changes

  • Bug fix
  • New feature
  • Breaking API change
  • Documentation update

Additional context

Submitted as a draft under the one-open-ready-PR limit while #1387 is in review. Issue #1389 records the proposal; maintainer agreement on the scope is still pending. This patch is scoped to the reqwest backend; Unix-socket response handling is unchanged. Developed with Codex assistance. Local checks and hosted CI are reported separately.

@github-actions github-actions Bot added T-core Core library changes T-transport Transport layer changes labels Oct 23, 2026
@github-actions
github-actions Bot requested a review from DaleSeo October 23, 2026 06:39
@github-actions

Copy link
Copy Markdown
Contributor

@DaleSeo (assignment failed) is on triage rotation this week and is the reviewer for this one.

Labels come from the PR labeler. Please review the change.

Automated triage. Labels are a first pass and the assigned maintainer has the final say.

This branch has not been deployed

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

Labels

T-core Core library changes T-transport Transport layer changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

reqwest Streamable HTTP client matches response Content-Type by case-sensitive prefix

1 participant