feat!: remove SSE transport support #562
Conversation
github-actions
bot
added
T-documentation
SSE transport has been removed from the MCP specification in favor of streamable HTTP. This removes all SSE-specific transport code: - Remove `transport-sse-client` and `transport-sse-server` features - Remove `SseClientTransport` and `SseServer` types - Remove SSE-specific examples (`counter_sse`, `counter_sse_directly`) - Migrate auth examples from SSE to streamable HTTP - Update tests to remove SSE transport usage - Update documentation BREAKING CHANGE: The following have been removed: - `transport-sse-client` feature - `transport-sse-client-reqwest` feature - `transport-sse-server` feature - `SseClientTransport` type - `SseServer` type - `sse_client` and `sse_server` modules Users should migrate to streamable HTTP transport which provides equivalent functionality. See `StreamableHttpClientTransport` and `StreamableHttpService` for the replacement APIs. Ref: #561 (comment)
domdomegg
force-pushed
the
adamj/remove-sse-transport
branch
from
dc6cada to
ba3d8ef
Compare
|
I think removing SSE now is too early for SDK. |
|
SSE is super unstable ... There is no reason to promote it . It not a bug, it just the wrong architecture. SSE needs sticky sessions and it very hostile load balancers. HTTP streamable is preferred way to connect remotely. |
This is not promoting it, but rather it existed in spec 2024-11-05 before, and we cannot start deleting it directly. Marking it as obsolete and deleting it in a later version would be more suitable for code evolution. As an SDK, we are not following the upper application layer, but rather adopting a gradual strategy based on specifications, especially for features that need to be abandoned. |
|
This is an SDK not a consumer API. You can drop and refactor as much you need to make the SDK cleaner and more secure. It won't force auto update on people repos. This is a Rust context, that means if someone upgrade blindly, the compiler will not warn, it will refuse to obey. There is no (I shipped it, production blew because protocol was removed... javascript/ruby/python style) They have 2 options:
Your thinking is not wrong, but this SDK case is an exception. The SSE spec was rushed and was afterthought, it never worked more than few minutes. The STDIO in 2024 is still used in few abandoned repos, but SSE had no production implementation , zero serious user base. IDEs implemented remote MCP after HTTP streamable got released, and Claude code and other are supporting spec of June 2025+. I will stand corrected if you show me 1 single serious app that still depends on 2024 SSE. The work is already done by @domdomegg. We just have to merge it. |
SSE transport has been removed from the MCP specification in favor of streamable HTTP. This removes all SSE-specific transport code.
Changes
transport-sse-clientandtransport-sse-serverfeaturesSseClientTransportandSseServertypescounter_sse,counter_sse_directly)Breaking changes
The following have been removed:
transport-sse-clientfeaturetransport-sse-client-reqwestfeaturetransport-sse-serverfeatureSseClientTransporttypeSseServertypesse_clientandsse_servermodulesUsers should migrate to streamable HTTP transport. See
StreamableHttpClientTransportandStreamableHttpServicefor the replacement APIs.Ref: #561 (comment)