Michiel's Blog - #httpxyz

Talk at PyGrunn on httpxyz

2026-05-03T22:00:00+02:00

On Friday 8th of May 2026 I will be giving a talk on our new fork of the popular python package httpx called httpxyz at PyGrunn. PyGrunn is a full day Python (“and friends”) conference in Groningen, The Netherlands. httpx is a top-100 Python package for sending http requests but has not had a release since end of 2024, plus, recently all issues were set to hidden and all discussions are closed. httpxyz is our friendly fork with lots of fixes for serious and more niche issues. Read for more info my announcement post for httpxyz. I will talk about why we did the fork and how we approach it. I’ll also delve into how to build a performant API client in Python and technical details of HTTP.

This is an expanded version of the talk I gave at PyAmsterdam last week, and is part of my ‘promotion efforts’ for httpxyz. I look forward to giving my talk & see you there!

httpxyz one month in

2026-04-27T09:00:00+02:00

It has been roughly a month since we forked httpx and named our package httpxyz. For the reasons why I refer you to Why I forked httpx. In this post I will explain where we are now, one month ‘into’ having created the fork.

TL;DR: httpxyz has now many bug fixes and significantly better performance than httpx, and we would encourage anyone to move to our version!

Where we are now

Initial version of fork

Our first version of httpxyz contained just the fixes to get zstd working, and the fixes to get the test suite running on python 3.14, some ‘housekeeping’ changes related to the renaming, as well as some minor and trivial fixes that had already been merged in httpx and had not been released yet.

End of March: bugfixes, and performance improvements

Then at the end of March we did another release of httpxyz, containing a compatibility shim that allows you to use httpxyz even with third-party packages that import httpx themselves, as long as you import httpxyz first. We’ve added a nice documentation page for this.

This release also included a change that lazily imports the CLI for httpxyz, which is typically not used in your app; in my measurements this makes httpxyz import in half the time needed by httpx. This PR has been sitting idle at the httpx repository for over a year ref and we’ve kindly adopted it, thanks to Nate Hardison for providing it!

And apart from that we adopted a bunch of other smaller and bigger bug fixes and improvements in this release.

httpcorexyz!

But we realized pretty soon that there were some problems that httpx was having, that were actually caused by the underlying ‘transport’ which is defined in a different module, httpcore. This module also had no release in over a year, and there were a bunch of issues reported by users, with fixes even, that were not landing. So we ended up also forking httpcore and created httpcorexyz.

Here we fixed a WHOLE bunch of performance related issues:

Use anyio.Lock(fast_acquire=True) and anyio.Semaphore(fast_acquire=True) to skip unnecessary event loop yields on uncontended lock acquires. Reduces async GET latency by ~3.3x. Reinstates encode/httpcore#953 which was reverted upstream for non-technical reasons. Requires anyio >= 4.5.0. ref
Retire map_exceptions() context manager in favour of plain try/except on hot paths (socket reads, writes, connects). try/except with no exception is nearly free; @contextmanager-based with blocks have measurable overhead. (encode/httpcore#1044) PR 14
Make Origin hashable via Origin.__hash__() for use in sets and dicts. (encode/httpcore#1038)
Release the HTTP/2 max-streams semaphore and decrement _concurrent_streams when NoAvailableStreamIDError is raised, preventing permanent deadlock. (encode/httpcore#1061) PR 10
Move del self._events[stream_id] inside the _state_lock in _response_closed() to prevent a race condition with concurrent coroutines. (encode/httpcore#1062)
Close proxy connection when tunnel TLS handshake fails, preventing the pool from stalling at max_connections. (encode/httpcore#1049)
Propagate the connect timeout through the SOCKS5 handshake to prevent indefinite hangs with non-responsive proxies. (encode/httpcore#1055) ref
Explicitly close async generators via safe_async_iterate() context managers to prevent Trio warnings and unpredictable GC-dependent behaviour. (encode/httpcore#1019) ref
Reduce lock contention in PoolByteStream.close(): pool requests are marked as closed outside the lock and cleaned up lazily inside _assign_requests_to_connections(). (encode/httpcore#1038) ref

These are serious issues, and it’s not even all. Almost all of these were already fixed by ‘the community’ and were living in unmerged pull requests. We code reviewed them, fixed them up where needed and adapted them to our code base. We also now added a benchmarks section to the documentation; httpxyz is now MUCH faster than httpx in many serious use cases.

Then we released a new version of HTTPXYZ earlier this week: 0.31.0 with this updated version of httpcorexyz and also more bug fixes of its own.

Where I previously stated having the fork is about future-proofing and I would not necessarily recommend people to switch to httpx, with this new version 0.31.0 I now feel that you should definitely move to httpxyz. With All new fixes and performance improvements it now makes ‘business sense’ to switch from httpx to httpxyz, the ‘churn’ is worth it now!

Adoption

We’re happy to see projects moving to using our package, even though it’s not much yet. We encourage everyone to do so, and please tell others and convince them! If you would find issues with your switchover, which I do not expect, please just open an issue and I’m sure we can figure it out!

Quotes

I'm a big user of httpx... Thanks for the fork. Here's to hoping it gained some traction. (Michael Kennedy, Founder, Talk Python)

Thank you for forking httpx. httpx is a joy to work with, but clearly a bit dead in the water. Really nice to see it moving forward again. (hhartzer)

If you want to have traction, you should probably move to GitHub instead of using Codeberg (Marcelo Trylesinski aka Kludex / FastAPI)

On Codeberg

We explained the last time why we chose Codeberg; we’re not unhappy about our choice. We got 39 ‘stars’ so far on our Codeberg repository and many of those are from ‘fresh’ accounts. If us being on codeberg helps a tiny little bit making github a bit less dominant, I think this is a good thing, and I hope it can inspire other projects to do the same. And after all, for most users, who would just pip install httpxyz or uv add httpxyz it does not matter where the source is hosted.

Thanks, and have fun!

Talk at PyAmsterdam on httpxyz

2026-04-21T22:00:00+02:00

On Wednesday 29th of April 2026 I will be giving a lightning talk on our new fork of the popular python package httpx called httpxyz at PyAmsterdam. httpx is a top-100 Python package for sending http requests but has not had a release since end of 2024, plus, recently all issues were set to hidden and all discussions are closed. httpxyz is our friendly fork with lots of fixes for serious and more niche issues. Read for more info my announcement post for httpxyz. I will talk about why we did the fork and how we approach it. The event is fully booked and there is a wait list.

As the organizer of Python Leiden, I am happy to be checking out another Python meetup group.

Plus, I’m excited to be giving a talk on HTTPXYZ; my first blog post about it got a lot of views on Hacker News but not (yet) so much adoption in real life, and we definitely need to “spread the word” more.

I look forward to giving my talk & see you there!

Check the details for the Meetup.com event

Why I forked httpx

2026-03-25T22:00:00+01:00

Yesterday I forked httpx. The new fork is called httpxyz.

Reasons for the fork

HTTPX is a very popular HTTP client for Python. There is lots of code depending on it.

In 2024, I contributed zstd content decoding. This got merged and released! I was very happy and proud. Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. Me, and others, asked repeatedly for a release containing my fix. I sent email to the author personally. I got response when I added that I was considering forking. The author replied “1.0 development is on course”. Which is probably true but it has been in the planning for over two years now ref. Even the ‘patch level’ release for 0.28.2 has been in draft for over a year.

And apart from this, there’s:

Recently issues have been made hidden on the github repository, and discussions have been turned off. Having issues hidden makes it more difficult for people to contribute to the package but also to use the package since issues are linked all over in code and documentation also. See reddit thread
There has been talk about an upcoming 1.0 release for years now, back to 2020 or so. In a discussion from October 2024, it was laid out that the 1.0 might look very different than the current version of httpx. Simon Willison added his points eloquently, please read them.
Probably as a result, both openai and anthropic python packages, that depend on httpx, have put guards in their pyproject.toml to not install version 1.0.
The author previously added breaking changes in minor updates, causing churn for many people, stating “The httpx package is not yet at a 1.0 SEMVER release” ref. It’s pre-1.0, that is right, but if so many people use your package a bit more consideration for compatibility seems in place.
The author also created Django REST framework, and turned off issues and discussions there, a little over a year ago. This made life for people using the product more difficult ref
The author also created MkDocs, of which an interesting blog post was published recently. Some patterns seem to be recurring.

All this together made me think creating a fork is the best way forward, to provide a stable path for people invested in httpx.

I do understand about maintainer burnout, and preferring to work on ‘next’, and that there is life outside of Python, but I think not doing anything for maintenance and also not letting other people help out in maintaining, for such a high profile module, is problematic.

I do hope that Kim will go on to make much more beautiful software and that there will be a HTTPX2 that will be excellent!

FAQ

Q: Why did you fork?

See all the reasons above

Q: So what is the plan now?

Maintain a stable fork of httpx. No great rewrites, no breaking changes, no big changes to the project setup (for now). The motto is: Move a little faster and not break things.

Q: But are you not also going to burn out? Surely it’s lots of work

There has been no release since 2024 for httpx. A little more frequent would go a long way. My buddy Sander Wegter is a co-maintainer to spread the load.

Q: Why is your code on Codeberg and not on Github?

I feel that as a tech community we have put too many eggs in one basket. GitHub has been great for developers over the years, but I’m worried about the monoculture. Codeberg is still a little “rough” but for most intents and purposes, it just works. You can see the repository here. Codeberg is run as a non-profit instead of by a megacorp. Plus, I spoke with a bunch of them on FOSDEM this year and they’re very nice people.

Q: Should I port all my code now?

If you want, you’d be welcome. But if everything just works for you now, I’m not sure it’s warranted. The idea is that there is a path for you if you need it. That said, we’re fixing lots of bugs. UPDATE: with our new fixes we changed this position; httpxyz is much faster now than httpx and has much less bugs, we encourage everyone to upgrade! ref: httpxyz one month in

Q: but what about plugins?

If you’d use import httpxyz as httpx, many things will just work. And for packages that itself depend on httpx, if you import httpxyz before you load that package, you’ll use our new package instead. See httpx compatibility I think that with the 0.3.0 release we’ve covered all bases, if you still have problems, please just open an issue and I’m sure we can figure it out!

Thanks, and have fun!

Discussion on Hacker News here