[GTanger]

Summary

Refs #1030. Addresses the Streamable HTTP client JSON/error response scope described in #1180 and redirected to #1030 by the maintainer. The stdio work in #1049 remains separate; this PR should not close the combined tracker on its own.

The built-in clients already bound individual SSE events, but buffer JSON and HTTP error bodies before parsing them. This change adds configurable pre-decode bounds without replacing the transports or adding dependencies.

Changes

• Add StreamableHttpResponseLimits and transport config setters. Defaults: 16 MiB per complete JSON response, 64 KiB per HTTP diagnostic prefix, and the unchanged independent 16 MiB SSE-event limit.
• Share bounded and prefix readers between reqwest and Unix socket backends. JSON is rejected with ResponseBodyTooLarge { max_size } if Content-Length exceeds its limit or a chunk would exceed it. Count bytes even when the length is missing or understated; do not drain oversized JSON to EOF.
• For non-JSON HTTP error pages and unchallenged 401/403 responses (even when application/json), read_truncated_body retains at most the diagnostic limit and stops immediately when that prefix is full, without polling for another chunk or EOF. Large legacy 4xx pages can still reach the existing server/discover -> initialize fallback. The fallback eligibility rules are unchanged.
• Other application/json error responses use the same complete-body JSON limit as successful responses. Parse the full bounded body before considering discovery fallback or truncating diagnostic text. Never parse a diagnostic prefix as a complete JSON-RPC message. Malformed/non-error JSON gets only a diagnostic prefix; oversized JSON still fails without fallback/retry.
• Align the Unix socket backend with reqwest by forwarding complete HTTP JSON-RPC errors as StreamableHttpPostResponse::Json, before synthetic discovery fallback. This also fixes the previous backend discrepancy for these errors.
• Forward limits through all six POST sending sites, including startup, discovery fallback, initialized notifications, ordinary/control requests, and session recovery. AuthClient preserves them across token refresh.
• Keep the old POST entry points and provide a default implementation of the new trait method that delegates to the old SSE-limit override. Built-in backends apply the new defaults through old entry points too.

Compatibility and limits

Custom HTTP backends remain source-compatible, but must override post_message_with_response_limits to enforce JSON/diagnostic limits; the default cannot bound a body already decoded by custom code. The API docs explain this distinction and the JSON-versus-diagnostic behavior.

JSON bodies above the 16 MiB default fail unless callers raise max_json_response_size; callers can adjust each limit independently. A zero JSON limit accepts only empty bodies. A zero diagnostic limit omits diagnostic text rather than rejecting a non-JSON or 401/403 error response.

Existing 202/204, authentication challenge, session-expired, within-limit malformed-success-JSON, and backend-specific success-body-I/O-error behavior is preserved. An error-body I/O failure before the diagnostic limit still uses the existing read-failure placeholder (subject to the diagnostic prefix limit). This does not subsume #1208's separate malformed-JSON proposal.

Limits count bytes yielded by the HTTP backend (decompressed bytes when decompression is enabled). They bound accumulated body length, not backend/decompressor allocations, vector capacity, UTF-8 conversion, or JSON parser allocations, and are not a total RSS bound.

Validation

• Formatting (cargo +nightly fmt --all -- --check), rustdoc (RUSTDOCFLAGS="-D warnings"), and strict Clippy (--all-targets --all-features and computed non-local feature set) pass with zero warnings.
• Targeted integration suites (test_streamable_http_response_limits with and without reqwest/charset, test_unix_socket_response_limits, test_streamable_http_limit_lifecycle, test_streamable_http_default_error_limit, test_streamable_http_initialize_error, test_auth_error_classification, test_streamable_http_reconnect_classification) and full rmcp unit/integration suites pass.
• Coverage includes >16 MiB base64 tool results rejected by default and accepted with an opt-in limit, unchallenged 401/403 JSON responses truncated at max_error_response_size without buffering up to max_json_response_size on both backends, old POST APIs, zero limits, EOF-free diagnostic prefixes, partial-JSON negatives, auth/session precedence, independent SSE limits, and lifecycle limit forwarding.

Prepared with AI assistance; reviewed and tested locally before submission.

[DaleSeo]

This has merge conflicts with main now. Could you rebase onto the latest main and resolve them? Thanks!

[GTanger]

Thanks @DaleSeo! Rebased onto the latest main (8aec389) and resolved the merge conflicts in auth/streamable_http_client.rs, reqwest/streamable_http_client.rs, and unix_socket.rs.

[GTanger]

Rebased onto the latest main (f2b0ddf) and resolved the conflicts with 3e0156c (v3.9.0):

• Preserved the v3.9.0 StreamableHttpError::ResponseBodyTooLarge { max_size } variant, common::client_side_http module layout, HTTP 5xx HttpStatusError metadata fallback, and reqwest charset/BOM error-body decoding.
• Kept configurable StreamableHttpResponseLimits (64 MiB complete JSON default across statuses, 64 KiB non-JSON diagnostic prefix truncation via read_truncated_body to preserve legacy server/discover fallback, and 16 MiB SSE event default), Unix socket HTTP JSON-RPC error alignment, and limit forwarding across all worker POST sites and AuthClient refreshes.

[DaleSeo]

@GTanger, can you resolve the conflict? Then we can move this forward.