fix: resolve URL path truncation in SSE transport for proxied servers

[SOURABHMISHRA5221]

Summary

Fix SSE endpoint path handling to avoid urllib.parse.urljoin() truncating base paths when servers are behind proxies or mounted at subpaths. Endpoints are treated as relative path segments and stored verbatim.

Motivation

When clients join a base URL with an endpoint starting with “/”, urljoin resets to the host root. This caused paths like http://localhost:8000/some/path/to/sse + /messages/ → http://localhost:8000/messages/. Using a relative segment preserves the base path. Resolves #200.

from urllib.parse import urljoin
urljoin("http://host/hello/world", "/messages/")  # -> http://host/messages/
urljoin("http://host/hello/world/", "messages/")  # -> http://host/hello/world/messages/

What changed

• mcp/server/sse.py
  • Store endpoint verbatim (no auto-leading “/”).
  • Validate endpoint is a relative path (no scheme/host/query/fragment).
  • Add _build_message_path(root_path) to construct the final path robustly from the app mount and root_path.
  • Update comments/docstrings to emphasize relative path semantics and predictable URL construction.
• Tests
  • tests/server/test_sse_security.py: clarify accept/reject cases and document urljoin behavior.
  • tests/shared/test_sse.py: add/clarify param cases; ensure endpoints are stored verbatim.

Backward compatibility

• No breaking changes.

How it was tested

• Endpoint validation tests for relative vs absolute and query/fragment rejection.
• Subpath mounting tests to reproduce and prevent original truncation.
• All existing SSE security/functionality tests pass.
• Verified path construction under various root_path combinations.

Checklist

• Follows repo style guidelines
• Tests added/updated and passing
• Error handling and docs updated

[SOURABHMISHRA5221]

Hi @Kludex!... Can you please review this...

[mconflitti-pbc]

The behavior I saw was: urllib.join("http://example.com/some/path", "/messages/") resulted in http://example.com/messages. I think it would be sufficient to just drop the leading forward slash sense that leads to an unexpected behavior. I would argue that the sdk should not be forcing its route to be at any particular location and that a dev should decide where it gets mounted. Relative path joining should allow that. See comment below for test cases

[SOURABHMISHRA5221]

Hi @mconflitti-pbc! Thanks for reviewing this PR, and apologies for the late reply.

You’re right about the behavior: auto-prepending “/” to “make it relative” actually made the endpoint origin-absolute, which caused urljoin to drop any base path in proxied/subpath setups. This change removes that normalization and stores the endpoint verbatim.

• We validate only that the endpoint is a relative path (no scheme/host/query/fragment).
• Both “/messages/” and “messages/” are accepted; we recommend the relative segment (“messages/”) for predictable joining.
• The final URL is composed from the app’s mount and ASGI root_path, so mounting remains entirely up to the developer.

Thanks again for the thoughtful feedback.

[mconflitti-pbc]

Here is the behavior demonstrated with examples:

>>> from urllib.parse import urljoin
>>> 
>>> urljoin("http://www.google.com/hello/world", "/messages")
'http://www.google.com/messages'
>>> urljoin("http://www.google.com/hello/world", "messages")
'http://www.google.com/hello/messages'
>>> urljoin("http://www.google.com/hello/world/", "messages")
'http://www.google.com/hello/world/messages'
>>> urljoin("http://www.google.com/hello/world/", "/messages")
'http://www.google.com/messages'
>>> urljoin("http://www.google.com/hello/world/", "/messages/")
'http://www.google.com/messages/'
>>> urljoin("http://www.google.com/hello/world/", "messages/")
'http://www.google.com/hello/world/messages/'
>>> urljoin("http://www.google.com/hello/world", "messages/")
'http://www.google.com/hello/messages/'

urllib has some odd behavior imo.

[mconflitti-pbc]

I believe this is the one we want to coerce/enforce:

>>> urljoin("http://www.google.com/hello/world/", "messages/")
'http://www.google.com/hello/world/messages/'

[SOURABHMISHRA5221]

I’ve made the necessary updates based on your feedback (store endpoint verbatim, remove leading “/” coercion, clarify docs/tests). When you have a moment, could you please take another look? Thank you