Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

2026-07-28 SSE responses share one header list, so in-place middleware appends leak across responses

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#3,701 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

  • #3704 par @guptaishaan — fermée sans fusion

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
backend

Piste de recherche

Commence dans handle_modern_request, où la réponse SSE est envoyée avec la liste au niveau du module _SSE_HEADERS, et vérifie si une copie par réponse corrige la fuite causée par l'ajout en place. Avant d'écrire le correctif, examine la PR #3704, fermée et non fusionnée, pour comprendre pourquoi elle n'a pas été retenue. C'est terminé lorsqu'un test de régression dans tests/server/test_streamable_http_modern.py échoue sur la branche main actuelle et réussit une fois que chaque réponse SSE dispose de sa propre liste d'en-têtes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug spec-2026-07-28 v2
Initial Checks
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)
Langage dominant
Python
Étoiles
24.5k
Forks
4k
Merge moyen
18 h 3 min
PR mergées (30 j)
39

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/python-sdk

Toutes les issues de modelcontextprotocol/python-sdk

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.