2026-07-28 SSE responses share one header list, so in-place middleware appends leak across responses
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
- #3704 @guptaishaan による — マージされずにクローズ
評価
調査の方向性
handle_modern_request から始めてください。そこでは SSE レスポンスがモジュールレベルのリスト _SSE_HEADERS で送信されています。レスポンスごとにコピーを作ると、インプレースの追加によるリークが直るかどうかを確認してください。修正を書く前に、クローズされマージされなかった PR #3704 を確認し、マージされなかった理由を調べてください。tests/server/test_streamable_http_modern.py のリグレッションテストが現在の main で失敗し、各 SSE レスポンスが独自のヘッダーリストを持つようになると成功した時点で完了です。
索引モデルが issue の本文から書いたものです。
説明
Initial Checks
- I confirm that I'm using the newest release of my line (the latest 2.x, or the latest 1.x if I'm still on v1)
- I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue
Release line
2.x (current stable)
Description
On the 2026-07-28 HTTP entry, handle_modern_request starts every SSE response with the module-level _SSE_HEADERS list itself:
await send({"type": "http.response.start", "status": _OK_STATUS, "headers": _SSE_HEADERS})
ASGI middleware that adds a header with message["headers"].append(...) therefore appends to the SDK's shared list. The header stays there for the life of the process, so every later SSE response carries one more copy, along with the values set for earlier requests. JSON responses aren't affected, because they build their own header list.
We hit this in production with an observability middleware that appended an x-correlation-id. After about 250 SSE responses in one process, our edge proxy's HTTP client rejected the responses as malformed. Only calls that commit to SSE (a notification, or more than 15 s without one) take this path, so fast calls and most test suites never touch it, and a restart hid it for a while.
The middleware shouldn't mutate a list it doesn't own; Starlette's MutableHeaders(scope=message) copies for exactly this reason. Passing list(_SSE_HEADERS) would keep one middleware's mistake from turning into process-wide header growth and cross-request header leakage.
Expected: each SSE response gets its own header list.
Example Code
import asyncio
import httpx
from mcp.server.mcpserver import Context, MCPServer
from mcp.server.transport_security import TransportSecuritySettings
mcp = MCPServer("repro")
@mcp.tool()
async def slow(ctx: Context) -> str:
await ctx.report_progress(1, 2) # any notification commits the response to SSE
return "done"
inner = mcp.streamable_http_app(
transport_security=TransportSecuritySettings(enable_dns_rebinding_protection=False)
)
async def app(scope, receive, send): # middleware that appends in place
async def send2(msg):
if msg["type"] == "http.response.start":
msg["headers"].append((b"x-correlation-id", b"abc"))
await send(msg)
await inner(scope, receive, send2)
def body(i):
return {"jsonrpc": "2.0", "id": i, "method": "tools/call",
"params": {"name": "slow", "arguments": {}, "_meta": {
"progressToken": i,
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {"name": "r", "version": "0"},
"io.modelcontextprotocol/clientCapabilities": {}}}}
async def main():
async with inner.router.lifespan_context(inner):
async with httpx.AsyncClient(transport=httpx.ASGITransport(app=app), base_url="http://localhost") as c:
for i in range(1, 6):
r = await c.post("/mcp", json=body(i), headers={
"accept": "application/json, text/event-stream",
"mcp-protocol-version": "2026-07-28",
"mcp-method": "tools/call", "mcp-name": "slow"})
print(i, len(r.headers.get_list("x-correlation-id")))
asyncio.run(main())
Output: 1 1, 2 2, 3 3, 4 4, 5 5.
I have a fix ready (list(_SSE_HEADERS) plus a regression test in tests/server/test_streamable_http_modern.py that fails before and passes after) and would be glad to open the PR if you assign this to me. Open PR #3192 carries the same line, in case that's the better place for it.
AI disclosure: I used Claude Code to find the line, write the repro, and draft this issue. I hit the bug in production and have checked the repro and the fix myself.
Python & MCP Python SDK
Python 3.13, mcp 2.3.0 (also present on main at 754254c)
- 主要言語
- Python
- スター
- 24.5k
- フォーク
- 4k
- 平均マージ
- 18時間 31分
- マージ済み PR(30日)
- 38
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/python-sdk のほかの issue
-
bug v1 v2
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
modelcontextprotocol/python-sdk#3698 ·
メンテナーはふだん 1 日以内に返信
-
Streamable HTTP: Content-Type handling is order dependent and accepts invalid values対応中かも @jayzuccarelli が 3 日前に担当しました。 オープンbug v1 v2
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
modelcontextprotocol/python-sdk#3691 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Skills: URI traversal validation skips percent-encoded dot-segments対応中かも @Varshith-Kali が 2 日前に担当しました。 オープンbug v2
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
modelcontextprotocol/python-sdk#3685 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
Type annotation gaps and unhandled FileNotFoundError in src/mcp/cli/cli.py再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンenhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
modelcontextprotocol/python-sdk#3673 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
-
Streamable HTTP server rejects a mixed-case Content-Type with 415対応中かも @CRYPTONIKAV が 5 日前に担当しました。 オープンbug v1 v2
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
modelcontextprotocol/python-sdk#3670 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
modelcontextprotocol/python-sdk の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
jbacalso24/mimry#291 ·
メンテナーはふだん 1 日以内に返信
-
good first issue
難易度 2/5 1時間未満 初心者へのやさしさ 82/100
eli-alvarado/us-watchlist-alerts#14 ·
メンテナーはふだん 1 日以内に返信
-
from-review-extraction python severity:nit
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
LearningCircuit/local-deep-research#7462 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
cathrynlavery/diagram-design#441 ·
メンテナーはふだん 2 日以内に返信
-
[Cleanup] Include the public header in work_split.cpp対応中かも @blozano-tt が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
tenstorrent/tt-metal#60850 ·
メンテナーはふだん 1 日以内に返信