Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#598 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@koic y travaille déjà.

Depuis le 13/10/2026.

  • #599 par @dtjldamien — fermée sans fusion
  • #600 par @koic — ouverte

Évaluation

Difficulté
1/5
Temps estimé
Moins d'une heure
Accessibilité débutants
20/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
ruby
Domaine
backend-api-design

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Ruby
Étoiles
924
Forks
136
Merge moyen
1 j 6 h
PR mergées (30 j)
38

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/ruby-sdk

Toutes les issues de modelcontextprotocol/ruby-sdk

Issues similaires

Plus d'issues Ruby

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.