Repository navigation
Accept any 2xx acknowledgement of a notification in the HTTP client - #600
Merged
koic merged 1 commit intoOct 14, 2026
Conversation
## Motivation and Context `MCP::Client::HTTP` treats only `202 Accepted` as the acknowledgement of a notification. Any other status goes through the response body resolution, which requires a JSON or SSE content type, so a server that answers `notifications/initialized` with an empty 200 and no `Content-Type` fails `connect` with `Unsupported Content-Type: nil` (issue modelcontextprotocol#598). The spec has the server answer a notification with 202 and no body, so such a server is out of spec, but a notification awaits no response, and the TypeScript and Python clients check the content type of a response only for a request: any 2xx acknowledges a notification, whatever the body. The transport now accepts any 2xx without a JSON or SSE body the same way. A notification answered with such a 2xx is acknowledged with `nil`, and an SSE stream that ends without a response acknowledges it too, with no reconnection, since there is no response to resume for. A JSON or SSE body answering a notification is handed over as before, a 3xx keeps its handling, and a request answered with a 2xx other than 202 and without a JSON or SSE body still fails with `unsupported_media_type`. `send_notification`, which `MCP::Client#cancel` uses, never checked the response; `connect` keeps sending `notifications/initialized` through `send_request` so the 401 and 404 handling applies to it. Fixes modelcontextprotocol#598. ## How Has This Been Tested? New tests in `test/mcp/client/http_test.rb`: `connect` succeeds when the notification is acknowledged with an empty 200, a 204, or a `text/plain` 200; a notification answered with an SSE stream carrying no response returns `nil` without reconnecting; a notification answered with a 302 still raises on both paths; a request answered without a JSON or SSE body still raises. Against the previous library the first raises `Unsupported Content-Type: nil` and the second reconnects. ## Breaking Changes None.
5 of 9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
MCP::Client::HTTPtreats only202 Acceptedas the acknowledgement of a notification. Any other status goes through the response body resolution, which requires a JSON or SSE content type, so a server that answersnotifications/initializedwith an empty 200 and noContent-TypefailsconnectwithUnsupported Content-Type: nil(issue #598). The spec has the server answer a notification with 202 and no body, so such a server is out of spec, but a notification awaits no response, and the TypeScript and Python clients check the content type of a response only for a request: any 2xx acknowledges a notification, whatever the body.The transport now accepts any 2xx without a JSON or SSE body the same way. A notification answered with such a 2xx is acknowledged with
nil, and an SSE stream that ends without a response acknowledges it too, with no reconnection, since there is no response to resume for. A JSON or SSE body answering a notification is handed over as before, a 3xx keeps its handling, and a request answered with a 2xx other than 202 and without a JSON or SSE body still fails withunsupported_media_type.send_notification, whichMCP::Client#canceluses, never checked the response;connectkeeps sendingnotifications/initializedthroughsend_requestso the 401 and 404 handling applies to it.Fixes #598.
How Has This Been Tested?
New tests in
test/mcp/client/http_test.rb:connectsucceeds when the notification is acknowledged with an empty 200, a 204, or atext/plain200; a notification answered with an SSE stream carrying no response returnsnilwithout reconnecting; a notification answered with a 302 still raises on both paths; a request answered without a JSON or SSE body still raises. Against the previous library the first raisesUnsupported Content-Type: niland the second reconnects.Breaking Changes
None.
Types of changes
Checklist