Repository navigation
httpx python library issues #533
Description
I work on the azure ansible collection and I've been trying to resolve a no_proxy bug in httpx library since January of this year and it has gone nowhere. Ansible's python libraries rely on kiota and msgraph libraries which both use httpx.
I put forward a pr to fix this here encode/httpx#3741 But this has been ignored by the main developer. Now comments and discussions are turned off for the entire project.
I'm not the only one who noticed this and the project has been forked https://tildeweb.nl/~michiel/httpxyz.html
I would like to start a discussion on what to do next.
Thanks,
Bill
Activity
Use httpxyz library instead of httpx
mhwaage commentedon Jun 24, 2026
For what it's worth, httpxyz.org now recommends httpx2 as the 'preferred' fork.
HardMax71 commentedon Oct 15, 2026
Well, httpx is as good as dead rn: last commit to main was 8 months ago, now probably it is deep in the supply chain issue territory.
I have time to help with migration to httpx2, and 99.99% it will be in small incremental changes, similar to what I do now in #722 .
That is a breaking change I'd say, so maintainers have to decide.
What you think? Vincent Biret (@baywet)
baywet commentedon Oct 16, 2026
Thank you for bringing this up to my attention.
While those kind of situations can be painful in the Open Source ecosystem, they are sometimes necessary to ensure the alignment and long term maintenance of a project. By their very nature, they can take a while to resolve. Is there any specific reason why we'd need to "rush" a migration here? (unaddressed security issues, major bugs, etc...) We could wait and see how/if the situation resolves until we run into such an issue.
Another aspect is that hundreds of projects on the Microsoft organization depend on the same library, it's not like kiota is a fringe project in there. So, if any major issue arises with this dependency, we'd get our internal systems to "suggest" a migration off of it. As of writing, I'm not aware of any advisory like this.
Additionally, migrating this project to another http client would have downstream impacts, namely for consumers and Microsoft Graph Core. This is non-negligeable.
Additionally, httpx is a variant that azure core (on which we depend for azure auth), supports to this date
If we migrated, how would do it:
From a design perspective, another approach would be to have multiple http packages, this was a planned possibility from the early days, and let people select the implementation they want. However, from a funding perspective, I don't think have Microsoft (on this repo) maintain multiple http clients implementations would get any traction. However, the community can perfectly build an alternative. A good candidate hosting organization could be http://github.com/kiota-community/. And if that alternative gains sufficient traction, we might consider moving it upstream to replace the current implementation.
Let me know if you have any additional comments or questions.
baywet commentedon Oct 16, 2026
Incidentally, our auth package seems misaligned:
It should select httpx instead of aiohttp.
It should do so through the variant, not separate dependencies (so no entry for httpx/aiohttp, and
azure-core[httpx]instead of just azure-core)This currently results in multiple http clients packages being installed in the target application.