René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"SEP-1699: Support SSE polling via server-side disconnect","articleBody":"**Authors:** Jonathan Hefner (@jonathanhefner)\n**Status:** Draft\n**Type:** Standards Track\n**Created:** 2025-10-22\n\n## Abstract\n\nThis SEP proposes changes to the Streamable HTTP transport in order to mitigate issues regarding long-running connections and resumability.\n\n## Motivation\n\nThe Streamable HTTP transport spec [does not allow](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/04c6e1f0ea6544c7df307fb2d7c637efe34f58d3/docs/specification/draft/basic/transports.mdx?plain=1#L109-L111) servers to close a connection while computing a result.  In other words, barring client-side disconnection, servers must maintain potentially long-running connections.\n\n## Specification\n\nWhen a server starts an SSE stream, it MUST immediately send an SSE event consisting of an [`id`](https://html.spec.whatwg.org/multipage/server-sent-events.html#:~:text=field%20name%20is%20%22id%22) and an empty [`data`](https://html.spec.whatwg.org/multipage/server-sent-events.html#:~:text=field%20name%20is%20%22data%22) string in order to prime the client to reconnect with that event ID as the `Last-Event-ID`.\n\nNote that the SSE standard explicitly [permits setting `data` to an empty string](https://html.spec.whatwg.org/multipage/server-sent-events.html#:~:text=data%20buffer%20is%20an%20empty%20string), and says that the appropriate client-side handling is to record the `id` for `Last-Event-ID` but otherwise ignore the event (i.e., not call the event handler callback).\n\nAt any point after the server has sent an event ID to the client, the server MAY disconnect at will.  Specifically, [this part of the MCP spec](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/04c6e1f0ea6544c7df307fb2d7c637efe34f58d3/docs/specification/draft/basic/transports.mdx?plain=1#L109-L111) will be changed from:\n\n\u003e The server **SHOULD NOT** close the SSE stream before sending the JSON-RPC _response_ for the received JSON-RPC _request_\n\nTo:\n\n\u003e The server **MAY** close the connection before sending the JSON-RPC _response_ if it has sent an SSE event with an event ID to the client\n\nIf a server disconnects, the client will interpret the disconnection the same as a network failure, and will attempt to reconnect.  In order to prevent clients from reconnecting / polling excessively, the server SHOULD send an SSE event with a [`retry`](https://html.spec.whatwg.org/multipage/server-sent-events.html#:~:text=field%20name%20is%20%22retry%22) field indicating how long the client should wait before reconnecting.  Clients MUST respect the `retry` field.\n\n## Rationale\n\nServers may disconnect at will, avoiding long-running connections.  Sending a `retry` field will prevent the client from hammering the server with inappropriate reconnection attempts.\n\n## Backward Compatibility\n\n- **New Client + Old Server**: No changes.  No backward incompatibility.\n- **Old Client + New Server**: Client should interpret an at-will disconnect the same as a network failure.  `retry` field is part of the SSE standard.  No backward incompatibility if client already implements proper SSE resuming logic.\n\n## Additional Information\n\nThis SEP supersedes (in part) [SEP-1335](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1335).\n","author":{"url":"https://github.com/jonathanhefner","@type":"Person","name":"jonathanhefner"},"datePublished":"2025-10-22T16:12:37.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/1699/modelcontextprotocol/issues/1699"}