You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update server-fetch proxy implementation for httpx 0.28+ #1146
Is your feature request related to a problem? Please describe.
Proxy handling was recently added to server-fetch using the deprecated proxies argument from httpx<0.28.0: #816
Describe the solution you'd like
Switch to explicit AsyncClient creation as described here: encode/httpx#3424
That way we can update the httpx dependency to newer versions.
I think this is just a matter of changing "proxies" to "proxy" in line 75 and 119 of server.py
See: encode/httpx#2879 for the httpx change. I don't know why they broke this when they could have been backwards-compatible.
I can submit the above change as a PR, but since they created it as an incompatible change to httpx, this would break for versions before that change. Still, I do think the newest version of httpx should probably be supported (and I suppose a "smart" invocation could be added to check if proxies is valid and use that).
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. The fetch server now builds its client with httpx's proxy= argument, so the deprecated proxies= usage that blocked httpx 0.28+ is gone.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see CONTRIBUTING.md.
Activity
fat-tire commentedon May 2, 2025
I think this is just a matter of changing "proxies" to "proxy" in line 75 and 119 of server.py
See: encode/httpx#2879 for the httpx change. I don't know why they broke this when they could have been backwards-compatible.
I can submit the above change as a PR, but since they created it as an incompatible change to httpx, this would break for versions before that change. Still, I do think the newest version of httpx should probably be supported (and I suppose a "smart" invocation could be added to check if
proxiesis valid and use that).cliffhall commentedon Oct 19, 2026
Closing: superseded by the v2 release.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. The fetch server now builds its client with httpx's proxy= argument, so the deprecated proxies= usage that blocked httpx 0.28+ is gone.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see
CONTRIBUTING.md.Thanks for taking the time to report it.