fix: accept 200 with empty body notification responses in addition to 202

[alexhancock]

Motivation and Context

Some Streamable HTTP MCP servers return 200 OK with an empty body for JSON-RPC notifications like notifications/initialized, instead of the spec-required 202 Accepted. Previously this could fail with UnexpectedContentType(None). This change treats empty successful responses to notifications/responses/errors as accepted.

How Has This Been Tested?

Added a focused test for an empty 200 OK response to a client notification.

Ran:

cargo test -p rmcp --test test_streamable_http_empty_2xx_notification --features client,transport-streamable-http-client,transport-streamable-http-client-reqwest
cargo fmt -- --check
git diff --check

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the [MCP Documentation](https://modelcontextprotocol.io)
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This improves compatibility with non-compliant servers while preserving the existing behavior for normal JSON/SSE responses.

[jamadeo]

In the past, we've opted to be pretty strict about non-compliant clients. This does have the benefit of exposing issues that other tools might mask.

But other than that, I think it is probably harmless to accept empty 200s as equivalent to 202s.

I would suggest putting a comment note here though, just to state we're deliberately allowing something outside of the spec.

[alexhancock]

added a comment