Recent changes break some SSE serves due to URL parsing

[howardjohn]

Describe the bug

My MCP server returns:

event: endpoint
data: ?sessionId=25a6b490-aec4-40ba-b825-8a83f70f849f

This used to be fine. However, we now do sse_endpoint.parse::<http::Uri>(). This is not a URI so it fails.

Previously, we joined this with the base URL; the python SDK does the same https://github.com/modelcontextprotocol/python-sdk/blob/29c69e6a47d0104d0afcea6ac35e7ab02fde809a/src/mcp/client/sse.py#L76

The specification doesn't really have a clear definition of the format of the endpoint so its maybe vague

[jokemanfire]

It means your endpoint's format is not URI format? Do you think we need to relax the restrictions?

[howardjohn]

I believe the intent of the endpoint is to be joined with the base url. So it may also be at a sub path not returned in the event and we need to join like the python SDK. This is also how this library behaved until the streamable http refactoring

[4t145]

/?session_id=xxx is a valid uri while ?session_id=xxx is invalid. So we may parse it as PathAndQuery while it started with ?

And according to specification

When a client connects, the server MUST send an endpoint event containing a URI for the client to use for sending messages. All subsequent client messages MUST be sent as HTTP POST requests to this endpoint.

So it's reasonable to parse the returned endpoint as uri. But it's also okay to do some compatibility work

[howardjohn]

I think the behavior is supposed to be, if the base url is http://localhost/sse:

• ?sessionID=x -> http://localhost/sse?sessionID=x
• /path?sessionID=x -> http://localhost/path?sessionID=x

This is how both the Python SDK behaves, and how this package used to behave. The spec is not 100% explicit but its clearly not sending the entire URI in the event (since the host/port are excluded) so its meant to be join -- the spec just under-specifies how to join it.