> we contributed upstream to ensure these HTTP clients can route requests directly through the JavaScript `fetch` API in WebAssembly environments
Some context from an urllib3 maintainer:
urllib3 received and merged large contributions adding Pyodide/Emscripten support a few years ago, and later JSPI support, which is what made this work for Requests.
As far as I know, the funding for this work went to the external contributor who implemented it, not to the urllib3 maintainers. We reviewed and merged the changes, and the project is now responsible for maintaining the resulting backend.
This matters because the Emscripten backend is still considered experimental in urllib3, and is explicitly out of scope in our security policy.
CVE-2025-50182 is one example of the problems we've run into. urllib3's redirect controls did not have the expected behavior when requests were routed through `fetch`. There are potentially many more differences like this because browser/`fetch` networking semantics are quite different from urllib3's normal backend.
I'm glad the work was contributed upstream and is useful to Pyodide and Cloudflare. But I think there is a meaningful difference between funding a contribution to an upstream project and funding the upstream maintainers who have to support it afterwards.
> I'm glad the work was contributed upstream and is useful to Pyodide and Cloudflare. But I think there is a meaningful difference between funding a contribution to an upstream project and funding the upstream maintainers who have to support it afterwards.
Any of the upstream maintainers consider blocking merge unless Cloudflare signs a support contract?
Not an easy process to navigate, but if you find an internal champion that can help make the case, maintenance can be funded. For critical deps, companies are generally down to budget some financial support if you ask and know how to work the process.
The Emscripten support has actually been merged in urllib3 for a while.
We intentionally keep that module experimental and don't actively maintain it in urllib3. The maintainers don't currently work on new features, bug fixes, or security hardening for it, and we explicitly say so in our security policy.
So this isn't really a case of blocking a merge until someone funds it. The code is already upstream; we just haven't taken on the ongoing maintenance of that backend.
If Cloudflare needs ongoing support for it, we'd be happy to discuss that with them.
illia-v · · focus · HN ↗
Some context from an urllib3 maintainer:
urllib3 received and merged large contributions adding Pyodide/Emscripten support a few years ago, and later JSPI support, which is what made this work for Requests.
As far as I know, the funding for this work went to the external contributor who implemented it, not to the urllib3 maintainers. We reviewed and merged the changes, and the project is now responsible for maintaining the resulting backend.
This matters because the Emscripten backend is still considered experimental in urllib3, and is explicitly out of scope in our security policy.
CVE-2025-50182 is one example of the problems we've run into. urllib3's redirect controls did not have the expected behavior when requests were routed through `fetch`. There are potentially many more differences like this because browser/`fetch` networking semantics are quite different from urllib3's normal backend.
I'm glad the work was contributed upstream and is useful to Pyodide and Cloudflare. But I think there is a meaningful difference between funding a contribution to an upstream project and funding the upstream maintainers who have to support it afterwards.
meagher · · focus · HN ↗
Any of the upstream maintainers consider blocking merge unless Cloudflare signs a support contract?
Not an easy process to navigate, but if you find an internal champion that can help make the case, maintenance can be funded. For critical deps, companies are generally down to budget some financial support if you ask and know how to work the process.
illia-v · · focus · HN ↗
We intentionally keep that module experimental and don't actively maintain it in urllib3. The maintainers don't currently work on new features, bug fixes, or security hardening for it, and we explicitly say so in our security policy.
So this isn't really a case of blocking a merge until someone funds it. The code is already upstream; we just haven't taken on the ongoing maintenance of that backend.
If Cloudflare needs ongoing support for it, we'd be happy to discuss that with them.