Support for API Gateway Path Prefixes in SSE Client URL Handling
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 52/100
Piste de recherche
Commencez dans src/mcp/client/sse.py, au niveau de la gestion de l’URL autour de l’URL du client et de l’appel à urljoin. Reproduisez l’exemple de gateway-prefix de l’issue et examinez comment l’endpoint SSE fournit le chemin messages. C’est terminé lorsque l’endpoint messages conserve le préfixe spécifique au déploiement tout en conservant le comportement existant des URL.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Is your feature request related to a problem? Please describe.
When using the client SDK to connect MCP server behind an API gateway that adds a deployment-specific prefix (e.g., /gateway_prefix/<deployment_name>), the backend mcp server is unaware of this prefix and only exposes routes like /v1/sse and /v1/messages. The client SDK currently only supports url and uses urljoin to resolve endpoint URLs, which causes the gateway prefix to be dropped when joining paths that start with /. This results in incorrect routing through the gateway.
debug logs:
❯ python3 client.py
DEBUG:asyncio:Using selector: KqueueSelector
INFO:mcp.client.sse:Connecting to SSE endpoint: https://example.com/gateway_prefix/<deployment_name>/v1/sse
DEBUG:httpcore.connection:connect_tcp.started host='https://example.com' port=443 local_address=None timeout=5 socket_options=None
DEBUG:httpcore.connection:connect_tcp.complete return_value=<httpcore._backends.anyio.AnyIOStream object at 0x10889fef0>
DEBUG:httpcore.connection:start_tls.started ssl_context=<ssl.SSLContext object at 0x10895ca50> server_hostname='example.com' timeout=5
DEBUG:httpcore.connection:start_tls.complete return_value=<httpcore._backends.anyio.AnyIOStream object at 0x107fb45c0>
DEBUG:httpcore.http11:send_request_headers.started request=<Request [b'GET']>
DEBUG:httpcore.http11:send_request_headers.complete
DEBUG:httpcore.http11:send_request_body.started request=<Request [b'GET']>
DEBUG:httpcore.http11:send_request_body.complete
DEBUG:httpcore.http11:receive_response_headers.started request=<Request [b'GET']>
DEBUG:httpcore.http11:receive_response_headers.complete return_value=(b'HTTP/1.1', 200, b'OK', [(b'cache-control', b'no-store'), (b'content-type', b'text/event-stream; charset=utf-8'), (b'date', b'Fri, 23 May 2025 15:45:20 GMT'), (b'x-accel-buffering', b'no'), (b'x-upstream-service-time', b'7'), (b'transfer-encoding', b'chunked')])
INFO:httpx:HTTP Request: GET https://example.com/gateway_prefix/<deployment_name>/v1/sse "HTTP/1.1 200 OK" <== correct sse endpoint
DEBUG:mcp.client.sse:SSE connection established
DEBUG:httpcore.http11:receive_response_body.started request=<Request [b'GET']>
DEBUG:mcp.client.sse:Received SSE event: endpoint
DEBUG:mcp.client.sse:urljoin: https://example.com/gateway_prefix/<deployment_name>/v1/sse + /v1/messages/?session_id=80b1237100a34eaa9795a5993661c76a <== wrong messages endpoint
INFO:mcp.client.sse:Received endpoint URL: https://example.com/v1/messages/?session_id=80b1237100a34eaa9795a5993661c76a
INFO:mcp.client.sse:Starting post writer with endpoint URL: https://example.com/v1/messages/?session_id=80b1237100a34eaa9795a5993661c76a
Describe the solution you'd like
The client SDK should preserve the gateway prefix when joining endpoint URLs, so that requests are routed correctly through the gateway. Ideally, the SDK should provide a way to configure or detect the gateway prefix and ensure all endpoint URLs are constructed with it.
Describe alternatives you've considered
Additional context
Example:
url = "https://example.com/gateway_prefix/<deployment_name>/v1/sse"
path = "/v1/messages"
urljoin(url, path)
# Actual: https://example.com/v1/messages
# Expected: https://example.com/gateway_prefix/<deployment_name>/v1/messages
This is a common pattern for API gateways and reverse proxies, so supporting this would improve compatibility.
similar request:
https://github.com/modelcontextprotocol/python-sdk/issues/412#issuecomment-2820077952
https://github.com/modelcontextprotocol/python-sdk/issues/733
https://github.com/modelcontextprotocol/python-sdk/pull/386
- Langage dominant
- Python
- Étoiles
- 24.3k
- Forks
- 4k
- Merge moyen
- 1 j 19 min
- PR mergées (30 j)
- 29
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de modelcontextprotocol/python-sdk
-
Streamable HTTP client logs a WARNING for valid 202 Accepted on session termination (DELETE) Ouvertev1 v2
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
modelcontextprotocol/python-sdk#3546 · 5 commentaires ·
-
v1 v2
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
modelcontextprotocol/python-sdk#3545 · 1 commentaire ·
-
v1 v2
Difficulté 1/5 Moins d'une heure Accessibilité débutants 91/100
modelcontextprotocol/python-sdk#3508 · 2 commentaires ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
modelcontextprotocol/python-sdk#3504 ·
-
v1 v2
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
modelcontextprotocol/python-sdk#3492 · 1 commentaire ·
Toutes les issues de modelcontextprotocol/python-sdk
Issues similaires
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
learningequality/ricecooker#747 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
run-llama/llama_index#23199 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
KhronosGroup/glTF-Blender-IO#2769 ·