Disable standalone GET SSE Stream option for Streamable HTTP client transport
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 72/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 静か
- 技術スタック
- java
- 領域
- api, networking
調査の方向性
HttpClientStreamableHttpTransport.Builder と、issue で示されているエントリーポイント sendMessage() から始め、connect() とセッション初期化からの GET パスを追跡します。スタンドアロンの GET SSE トリガーを両方とも防止する builder オプションを追加し、無効化されたモードでは GET ストリームを開かず、POST のリクエスト/レスポンス通信だけが送信されることを確認します。
索引モデルが issue の本文から書いたものです。
説明
Expected Behavior
The HttpClientStreamableHttpTransport.Builder should provide an option to completely disable the GET SSE stream, allowing the client to operate in pure request-response mode:
var transport = HttpClientStreamableHttpTransport.builder("https://example.com")
.openSseStream(false) // Disable all GET SSE connections
.build();
When openSseStream(false) is set:
- No GET request is sent during
connect()(regardless ofopenConnectionOnStartup) - No GET request is sent after session initialization in
sendMessage() - The client operates in pure POST request / response mode
- Server-initiated notifications and requests outside of POST response streams are not received
This aligns with the MCP specification, which uses MAY (RFC 2119) for the client GET across all spec versions (2025-03-26 and latest 2025-11-25):
The client MAY issue an HTTP GET to the MCP endpoint. This can be used to open an SSE stream, allowing the server to communicate to the client, without the client first sending data via HTTP POST.
Current Behavior
After the first successful POST response (typically InitializeResult), the transport unconditionally opens a GET SSE stream. The relevant code in HttpClientStreamableHttpTransport.sendMessage():
if (transportSession.markInitialized(
responseEvent.responseInfo().headers().firstValue("mcp-session-id").orElseGet(() -> null))) {
// Once we have a session, we try to open an async stream for
// the server to send notifications and requests out-of-band.
reconnect(null).contextWrite(deliveredSink.contextView()).subscribe();
}
The reconnect(null) call is unconditional — there is no builder flag, callback, or any mechanism to prevent it.
The existing openConnectionOnStartup(false) (which defaults to false) only prevents the eager GET during connect(). It does NOT prevent the GET triggered after the first POST response. There is no combination of existing builder options that achieves "never open a GET SSE stream."
Context
The MCP specification explicitly marks the GET SSE stream as optional — unchanged across both spec versions:
- 2025-03-26: "The client MAY issue an HTTP GET to the MCP endpoint."
- 2025-11-25: "The client MAY issue an HTTP GET to the MCP endpoint."
Despite this, the Java SDK provides no way to opt out. The GET stream is unconditionally opened after session initialization, and its lifecycle is difficult to manage:
Alternatives considered:
openConnectionOnStartup(false)— does not prevent the post-initialization GET- Intercepting at the
HttpClientlevel to return a synthetic405 Method Not Allowedfor GET requests — this tricks the SDK into thinking the server doesn't support SSE streams, and the SDK stops trying. It works, but it's a hack: you have to wrap the HTTP client, intercept by method, and fabricate a response. This should be a first-class builder option, not something consumers need to reverse-engineer from the SDK's 405-handling behavior.
Precedent: The Go SDK already solved this exact problem via go-sdk#729 (merged Jan 11, 2026), adding a DisableStandaloneSSE field to StreamableClientTransport. The Java SDK should provide equivalent functionality.
Proposed fix: Add a builder option (e.g. disableStandaloneSSE(boolean) or openSseStream(boolean)) and guard both GET trigger points with it.
- 主要言語
- Java
- スター
- 3.7k
- フォーク
- 1.1k
- 平均マージ
- 1日 15時間
- マージ済み PR(30日)
- 9
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/java-sdk のほかの issue
-
area/transport bug P2
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
modelcontextprotocol/java-sdk#1136 ·
-
area/client bug P2
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
modelcontextprotocol/java-sdk#1124 · コメント 1 件 ·
-
ServerCapabilities.logging is added unconditionally, overriding the caller's explicit capabilities オープンbug P2 ready for work
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/java-sdk#1086 · コメント 1 件 ·
-
enhancement good first issue P3
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
modelcontextprotocol/java-sdk#1067 ·
-
bug P2 ready for work
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
modelcontextprotocol/java-sdk#898 · コメント 1 件 ·
modelcontextprotocol/java-sdk の issue をすべて見る
似ている issue
-
Bug Java Platform: Java
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
getsentry/sentry-java#6138 · コメント 1 件 ·
-
bug needs triage p2
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
GoogleCloudPlatform/DataflowTemplates#4273 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
bug needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100