SSE transport: author reports server process exit after /sse request with disallowed Host header (single unreproduced report)

Finding: One external report says that on the mcp Python SDK SSE transport (FastMCP/sse_app, an older mcp 1.x release pinned via mcp<2, Windows 11, Python 3.14, uvicorn), a single request to /sse with a Host header rejected by DNS-rebinding protection was followed by the whole server process disappearing, not just that request failing. The exact version is unknown. The described reproduction uses a Host header only; Origin is mentioned only in the general impact statement and no Origin test is described. Source: https://github.com/modelcontextprotocol/python-sdk/issues/3661 Reported details: The author says connect_sse in src/mcp/server/sse.py sends the rejection response (e.g. 421 Invalid Host header) and then raises ValueError('Request validation failed'). That text comes from source code quoted in the issue; the author offered a traceback but none was posted, so no observed log containing it is supplied. The author says the client was correctly rejected (421/403) and that, afterward, the uvicorn PID was gone (per their host process list) and the port stopped listening. The author says handle_sse uses connect_sse in an async with block without try/except, so the exception escapes the ASGI app; this is their reading of the code. They say the same raise-after-send pattern is on current main, also their own source reading. The reproduction is a curl to /sse with a disallowed Host header while DNS-rebinding protection is enabled (default for localhost-bound hosts). The issue calls it reproducible, but no independent confirmation is shown. That the raise causes the process exit is the author's inference, not a confirmed cause. (https://github.com/modelcontextprotocol/python-sdk/issues/3661) Unknowns: The author states they could not determine why the raise-after-send pattern would kill the whole process rather than one connection, and suggests only a possible ASGI double-response or mounting issue. This is a hypothesis, not a maintainer-confirmed cause. No maintainer has responded in the supplied thread. Proposed fix status: A commenter says they opened PR #3663, which makes handle_sse swallow the ValueError while keeping connect_sse's send-then-raise behavior. They self-report a regression test showing 421 followed by continued serving, plus passing security and server test suites. This is a self-reported, unmerged proposal; the PR itself was not supplied, and no merged commit or released version is supplied. (https://github.com/modelcontextprotocol/python-sdk/issues/3661#issuecomment-6078894873) Another comment only argues generally for per-request error isolation and early header validation; it adds no reproduction evidence. (https://github.com/modelcontextprotocol/python-sdk/issues/3661#issuecomment-6081646177) Limitation: this is an external report only. It was not reproduced by KFA, and no independent reproduction or confirmation is in the sources. Model synthesis (not source-reported guidance): if a rejected /sse request in your version is followed by a process exit, one possible check is whether an exception from connect_sse propagates out of handle_sse. The source does not offer this as a diagnostic procedure.