modelcontextprotocol / modelcontextprotocol/java-sdk

Disable standalone GET SSE Stream option for Streamable HTTP client transport

Đang mở
#1,068 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

enhancement P3
Ngôn ngữ chính
Java
Star
3.7k
Fork
1.1k
Merge trung bình
1 ngày 15 giờ
Pull request đã merge (30 ngày)
9

Mô tả

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 of openConnectionOnStartup)
  • 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 HttpClient level to return a synthetic 405 Method Not Allowed for 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.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu tại HttpClientStreamableHttpTransport.Builder và điểm vào sendMessage() được nêu trong issue, sau đó lần theo đường dẫn GET từ connect() và quá trình khởi tạo session. Thêm một tùy chọn builder để ngăn cả hai trigger GET SSE độc lập, đồng thời xác minh rằng chế độ bị vô hiệu hóa chỉ gửi lưu lượng request/response POST mà không mở stream GET.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
java
Lĩnh vực
api, networking
Loại issue
Tính năng
Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức độ hoạt động
Ít trao đổi
Độ rõ ràng
Đặc tả rõ ràng
Mức phù hợp với người mới
72/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.