Accept a 2xx acknowledgment of a notification without a body

[dtjldamien]

Motivation and Context

Fixes #598.

MCP::Client::HTTP#connect failed against servers that acknowledge notifications/initialized with 200 OK and an empty body instead of 202 Accepted. send_request passes every response to resolve_response_body, which returns early only for 202 and otherwise raises unsupported_media_type when the response has neither a JSON nor an SSE content type. Freshservice's hosted MCP server answers this way, so connect raised right after a successful initialize.

The spec requires 202 here, but a notification awaits no response, and the TypeScript and Python SDKs accept any 2xx for it: neither checks the content type unless the POST carried a request.

resolve_response_body now returns nil instead of raising in that branch when the message is a notification and the response is 2xx. JSON and SSE bodies are handled as before, so test_send_request_does_not_check_the_body_answering_a_notification is unaffected. Requests answered with an empty 200 still raise unsupported_media_type, and 4xx/5xx responses to a notification still raise through the existing Faraday error handling.

How Has This Been Tested?

Four new tests in test/mcp/client/http_test.rb:

• test_send_request_returns_nil_for_notification_acknowledged_with_empty_200
• test_connect_accepts_initialized_notification_acknowledged_with_empty_200
• test_send_request_raises_error_for_request_answered_with_empty_200
• test_send_request_raises_error_for_notification_answered_with_empty_4xx_or_5xx

Against the previous library, the first two raise unsupported_media_type. rake test passes, and the reproduction script from #598 now connects. Against a live Freshservice MCP server, main fails with Unsupported Content-Type: nil, and this branch connects and lists all 40 tools, the same as the TypeScript and Python SDKs (see the table in #598). rake conformance:test passes: 73/73 server checks, and 476 client checks pass with only the failures listed in expected_failures.yml (auth/dpop, auth/dpop-nonce, auth/wif-jwt-bearer).

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
• 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

[koic]

Closing in favor of #600, which uses the same guard and also handles another case this PR does not cover: a 2xx text/event-stream response that closes without a response message. In this case, the current implementation may raise an error or reconnect with a GET after a priming event, while the TypeScript and Python clients drain or ignore the response body.

#NNN also adds regression tests covering 204 and text/plain acknowledgements, 302 responses on both the body-less and SSE paths, and the absence of reconnection in the SSE case.

Thank you for the report, the comparison with the reference SDKs in #598, and the live-server verification that confirmed the fix for the reported issue.