HTTP client fails connect when the server acknowledges notifications/initialized with an empty 200
Maintainer thường phản hồi trong vòng 1 ngày
@koic đang làm issue này rồi.
Từ ngày 13/10/2026.
Đánh giá
- Độ khó
- 1/5
- Thời gian dự kiến
- Dưới một giờ
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- ruby
- Lĩnh vực
- backend-api-design
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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:
- TypeScript SDK 1.32.1: after the
202check, the content type is checked only when the POST carried a request. For a notification, any other 2xx reaches the// No requests in message but got 200 OK - still need to release connectionbranch, which cancels the body and returns. - Python SDK 2.3.0: after the
202check, the content-type handling is gated onisinstance(message, JSONRPCRequest), with the comment "The server MUST NOT send a response to notifications." A notification answered with 2xx falls through without reading the body.
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.
- Ngôn ngữ chính
- Ruby
- Star
- 924
- Fork
- 136
- Merge trung bình
- 1 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 35
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelcontextprotocol/ruby-sdk
-
Support modelcontextprotocol/experimental-ext-triggers-eventsCó thể đã có người làm @koic đã nhận 3 ngày trước. Đang mởenhancement
modelcontextprotocol/ruby-sdk#594 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
SEP-2640: Skills ExtensionCó thể đã có người làm @koic đã nhận 21 ngày trước. Đang mởenhancement
modelcontextprotocol/ruby-sdk#568 · 1 bình luận · 2 reaction · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
SEP-2663: Tasks ExtensionCó thể làm lại được @koic đã nhận 108 ngày trước và không có pull request nào đang mở. Đang mởenhancement
modelcontextprotocol/ruby-sdk#391 · 1 reaction · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của modelcontextprotocol/ruby-sdk
Issue tương tự
-
feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100
manyfold3d/manyfold#7346 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
🐞 bug pending triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
CircuitVerse/CircuitVerse#8025 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
we-promise/sure#4199 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Zibi version number updateĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
riscv/riscv-unified-db#2738 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
scanaislop/aislop#482 ·
Maintainer thường phản hồi trong vòng 1 ngày