Swap from httpx to httpx2 #16186

This might cause the compatibility issues with third-party libraries.
For example, the issue with respx is still open: lundberg/respx#316

I think a gradual migration would make sense here.

Starlette already supports httpx2 in TestClient, while keeping a fallback to httpx, so FastAPI could potentially follow a similar approach instead of doing a hard switch immediately.

The FastAPI test suite passing is a good sign, but I’d also be cautious about downstream tools like respx or anything that imports/patches httpx directly.

Maybe the safest path is:

• add httpx2 support first
• keep temporary httpx compatibility
• test common integrations
• remove httpx in a later release

That seems like a lower-risk way to move toward the maintained package.

I was able to put together a migration PR with the help of Claude Code (Opus 5). Is there any way we can either grant an exception to the auto-close policy so my PR isn't closed, or could a FastAPI org member open a PR cut from my branch? Otherwise, is there any migration progress from the FastAPI org that I could follow, or is this discussion thread the only place for status updates on the httpx → httpx2 migration?

Also of note: Starlette is now migrated off httpx to httpx2 (see thread here), so it would make sense to cutover sooner rather than later, IMO.