fix(client): send same-origin Origin header from streamable HTTP client

[Bartok9]

Summary

• The streamable HTTP client now sends a same-origin Origin header by default.
• This lets the official Python client interoperate with spec-compliant servers (e.g. the Go SDK's http.CrossOriginProtection) that otherwise reject the handshake with 403.

Motivation

Closes #2727.

The Python streamablehttp_client opened its POST handshake without an Origin header. The official Go SDK (modelcontextprotocol/go-sdk v1.4.x) wraps every streamable-HTTP handler with Go 1.25's http.CrossOriginProtection, which denies any state-changing request that cannot prove same-origin via Sec-Fetch-Site, a matching Origin, or an allow-listed origin. A legitimate server-to-server connection from the Python client therefore looks like a CSRF attempt → HTTP 403 Forbidden on the first POST, and the client (per #2110) swallows the non-2xx and hangs forever on session.initialize().

The two reference SDKs from the same org were out of sync by one spec revision: the Go server enforces the rule; the Python client never sent the header that satisfies it.

Fix

StreamableHTTPTransport._prepare_headers() now derives a same-origin value (scheme://host[:port]) from the target URL and sends it as the Origin header on every request. The derivation:

• Uses urllib.parse.urlsplit on the configured URL.
• Returns None (adds no header) when the URL has no scheme or host, so malformed/relative URLs are unaffected.

Callers needing a different Origin (e.g. multi-tenant proxies) can still set one on the underlying httpx.AsyncClient default headers.

Verification

• uv run pytest tests/shared/test_streamable_http.py — 63 passed (includes the existing test_streamable_http_client_mcp_headers_override_defaults / custom-header tests, unchanged).
• New tests:
  • test_prepare_headers_includes_same_origin — http://my-go-server:8081/mcp → Origin: http://my-go-server:8081; https://…/path?x=1 → https://example.com.
  • test_prepare_headers_omits_origin_for_invalid_url — no Origin added for a URL lacking scheme/host.
• uv run ruff check / ruff format --check — clean.

Diff: 2 files, +41/-0.

[Bartok9]

CI note: the single red cell (test (3.12, lowest-direct, ubuntu-latest)) is an infra/flake failure unrelated to this change, not a regression from this PR.

• Failing test: tests/shared/test_streamable_http.py::test_streamable_http_client_session_termination_204 (a pre-existing async server test, not added by this PR).
• Root cause in the log: [Errno 98] error while attempting to bind on address ('127.0.0.1', 50093): address already in use → httpx.ConnectError: All connection attempts failed. This is the TOCTOU test-port race tracked in Flaky streamable-HTTP/SSE tests: TOCTOU port race under pytest -n auto #2704.
• The two tests this PR adds (test_prepare_headers_includes_same_origin, test_prepare_headers_omits_origin_for_invalid_url) are synchronous unit tests that instantiate StreamableHTTPTransport, call _prepare_headers(), and assert on the returned dict. They never start a server, bind a port, or open a socket, so they cannot produce a bind/connect error.
• All other 23 test cells pass; all-green aggregate is green; PR is MERGEABLE.

A rerun of the failed job should clear it (I don't have rerun permission on the fork PR). Happy to rebase if main has moved.

[Bartok9]

CI note — rebased onto current main. The only remaining red cell (test (3.14, lowest-direct, …)) is a pre-existing, main-wide failure unrelated to this PR: tests/interaction/transports/test_stdio.py::test_tool_call_and_notification_round_trip… asserts byte-exact child stderr, but anyio==4.9 (the lowest-direct floor) has return inside a finally: in from_thread.py:119, which Python 3.14 emits as SyntaxWarning to stderr and pollutes the snapshot. This PR does not touch stdio or that test. Full root-cause + the 6 parallel fixes already in flight are consolidated in #2734 (comment). All other cells (incl. the previously-flaky termination test, now run in-process via #2767) are green.

[maxisbey]

Thanks for the PR, and sorry it sat here without a proper review.

We're closing most of the open PR backlog. v2 is out and changed a lot of the SDK, so many older PRs no longer apply as written, and we're a small team that realistically doesn't have the capacity to work through the rest.

If this still matters to you on v2, the most useful thing you can do is open an issue (or comment on the existing one) with your use case and a repro. Hearing why it matters to you is what we use to decide what to prioritise.

_{AI Disclaimer}

[Bartok9]

Thanks for the note, and no worries on the wait.

Understood that v2 moved and the backlog is being closed rather than reviewed in place. I won't reopen this PR.

The original case (streamable HTTP client omitting Origin, so spec-compliant servers reject the handshake with 403) is already tracked on #2727. If that still reproduces on v2 I'll add a short repro there; if v2 already sends Origin, I'll leave it.