Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

HTTP client fails connect when the server acknowledges notifications/initialized with an empty 200

Geschlossen
  • Stimmt etwas nicht?
#598 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@koic arbeitet bereits daran.

Seit 13.10.2026.

  • #599 von @dtjldamien — ohne Merge geschlossen
  • #600 von @koic — offen

Bewertung

Schwierigkeit
1/5
Geschätzter Aufwand
Unter einer Stunde
Anfängerfreundlichkeit
20/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
ruby
Bereich
backend-api-design

Rechercherichtung

Read MCP::Client::HTTP#send_request and resolve_response_body, which the issue identifies as the failing path. Check the existing tests for the notifications/initialized response and the linked pull requests #599 and #600 to see the work already underway. Done means a notification acknowledged with a bodyless 2xx no longer raises, while a request with the same response still raises unsupported_media_type.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug

Observed behavior

With mcp 1.7.0 (and 0.15.0), MCP::Client#connect with the legacy initialize handshake over Streamable HTTP fails against servers that acknowledge notifications/initialized with 200 OK, an empty body and no Content-Type, instead of 202 Accepted:

MCP::Client::RequestHandlerError: Unsupported Content-Type: nil. Expected application/json or text/event-stream.
error_type: :unsupported_media_type

The initialize request succeeds. The error comes from the following notifications/initialized POST: send_request passes the response to resolve_response_body, which returns early only for 202 and raises for any other response without a JSON or SSE content type.

For example, Freshservice's hosted MCP server (Freshworks, https://<account>.freshservice.com/mcp) responds this way:

POST /mcp  {"jsonrpc":"2.0","method":"notifications/initialized"}

HTTP/1.1 200 OK
Content-Length: 0

I ran each SDK's client against the same Freshservice server, with the same OAuth token, on 2026-10-13:

Client notifications/initialized response Result
TypeScript SDK 1.32.1 (StreamableHTTPClientTransport) 200, no Content-Type Connects, listTools returns 40 tools
Python SDK 2.3.0 (streamable_http_client) 200, no Content-Type Connects, list_tools returns 40 tools
Ruby SDK main (7735046) 200, no Content-Type Unsupported Content-Type: nil

Expected behavior

The spec says the server MUST return 202 Accepted with no body when it accepts a notification (Transports, Sending Messages to the Server), so the server is out of spec here. Still, a notification awaits no response, and both reference SDKs accept any 2xx for it:

In both, a request answered the same way is still an error: TypeScript throws StreamableHTTPError and Python returns a JSON-RPC error, each with "Unexpected content type".

I'd expect connect to succeed when a notification is acknowledged with a 2xx and no body. Requests should keep raising unsupported_media_type for the same response.

Reproduction

require "mcp"
require "webmock"
include WebMock::API
WebMock.enable!

url = "https://example.com/mcp"
stub_request(:post, url)
  .with { |req| JSON.parse(req.body)["method"] == "initialize" }
  .to_return(
    status: 200,
    headers: { "Content-Type" => "application/json" },
    body: { jsonrpc: "2.0", id: "1", result: { protocolVersion: "2025-11-25", capabilities: {}, serverInfo: { name: "s", version: "1" } } }.to_json,
  )
stub_request(:post, url)
  .with { |req| JSON.parse(req.body)["method"] == "notifications/initialized" }
  .to_return(status: 200, body: "")

MCP::Client.new(transport: MCP::Client::HTTP.new(url: url)).connect(mode: :legacy)
# => MCP::Client::RequestHandlerError: Unsupported Content-Type: nil. ...

Fix: #599. It returns nil instead of raising in that branch when the message is a notification and the status is 2xx, matching the behaviour above.

Vorherrschende Sprache
Ruby
Sterne
924
Forks
136
Ø Merge
1 T. 5 Std.
Gemergte PRs (30 T.)
37

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modelcontextprotocol/ruby-sdk

Alle Issues in modelcontextprotocol/ruby-sdk

Ähnliche Issues

Weitere Issues zu Ruby

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.