HN Debrief

Migrating to HTTPX2

  • Programming
  • Open Source
  • Developer Tools
  • AI

OpenAI’s note explains how to move its Python client onto `httpx2`, a fork of the popular `httpx` HTTP client that keeps the existing API instead of following the breaking path planned for `httpx` 1.0. The guide also calls out one real behavior change: TLS trust now comes from the operating system trust store instead of `certifi`, which removes a common pain point for companies with internal certificate authorities but can still break some managed corporate environments.

If your Python stack depends on `httpx`, treat this as a supply-chain signal, not just an SDK footnote. Audit whether you are pinned to the original project, and expect more teams to prefer forks with boring governance and API stability over upstream purity.

Discussion mood

Mostly negative toward the original `httpx` project’s stewardship and positive about converging on `httpx2` as the safer, more stable fork. The strongest reactions came from frustration with private development, closed community channels, and years of uncertainty around a breaking 1.0 release.

Key insights

  1. 01

    The fork exists to freeze the old API

    It frames `httpx2` as a defensive move against a long-promised `httpx` 1.0 that would break callers without delivering a dependable public roadmap. That changes the story from “OpenAI swapped libraries” to “large SDKs are choosing an API-preserving fork because upstream no longer looks safe to build on.”

    If you maintain a library that depends on `httpx`, favor the branch that minimizes downstream churn. Stability for your users now likely outweighs any loyalty to the original package name.

      Attribution:
    • simonw #1 #2
  2. 02

    Ecosystem gravity is settling on one fork

    `httpx2` is not just another fork in a fragmented field. It has Pydantic backing, involvement from the new Starlette maintainer, and even `httpxyz` now says it is upstreaming fixes there. That gives it the institutional support a replacement needs to become the default rather than just a protest project.

    Watch where related framework maintainers and competing forks are sending patches. That is usually a better predictor of the winning dependency than benchmark claims or branding.

      Attribution:
    • simonw #1
    • kelvinjps10 #1
    • networked #1
  3. 03

    Trust store change may matter more than the fork

    Switching from `certifi` to the operating system trust store solves a very concrete enterprise problem. Internal root certificates stop requiring awkward workarounds in virtual environments and containers. At the same time, anyone who relied on the bundled `certifi` roots for consistency across hosts may see environment-specific TLS failures.

    Test this migration in the exact environments where your code runs, especially corporate desktops, CI images, and containers. Certificate handling is the part most likely to surprise you in production.

      Attribution:
    • tosh #1
    • kova12 #1
    • zx8080 #1
    • skullone #1
  4. 04

    People still pick HTTPX-style clients for async

    The enduring reason to use this family of libraries over `requests` is native async support, plus extra transports that make in-process testing easier. That is why “just fund `requests`” does not answer the same need. For modern SDKs talking to network APIs at high concurrency, sync-only clients are a mismatch.

    If your SDK or service client may need streaming, concurrency, or async integration, do not treat `requests` as an equivalent fallback. Check your runtime model first, then pick the dependency.

      Attribution:
    • 12_throw_away #1
    • oersted #1
    • imp0cat #1

Against the grain

  1. 01

    Maintainers do not owe perpetual openness

    It pushes back on the outrage and says people are acting entitled to free labor. A maintainer can shut down public collaboration, go private, or walk away entirely. That does not make the choice good for users, but it does mean forks are the proper response rather than moral claims on the original project.

    Design your dependency strategy around the possibility that a maintainer may disappear or change course without notice. Healthy exit paths matter more than assuming open source norms will hold forever.

      Attribution:
    • mmerickel #1
    • trallnag #1
    • dgellow #1
  2. 02

    Alternatives may outperform but carry their own risk

    `niquests` was reported as much faster in one localhost benchmark, but its governance and technical choices raised immediate trust concerns, including monkey-patching `urllib3` and deleting issue history. That undercuts the idea that leaving `httpx` automatically lands you in a healthier place.

    Do not let a single benchmark decide infrastructure dependencies. Check maintenance style, upgrade path, and operational behavior before chasing raw throughput.

      Attribution:
    • jtbaker #1
    • awoimbee #1

In plain english

API ↩
Application Programming Interface, a defined way for software to expose functions or data to other software.
ASGI ↩
Asynchronous Server Gateway Interface, a Python standard for async web apps, websockets, and long-lived connections.
certifi ↩
A Python package that bundles a curated set of trusted root certificates for verifying HTTPS connections.
httpx ↩
A popular Python library for making HTTP requests, especially valued for async support and a modern client API.
httpx2 ↩
A fork of the Python `httpx` library that aims to keep the older API stable rather than introducing breaking changes.
niquests ↩
An alternative Python HTTP client mentioned as a possible replacement, with claims of strong performance but unclear governance.
Pydantic ↩
A widely used Python project for data validation and settings management that now sponsors the `httpx2` fork.
pyqwest ↩
A Python HTTP client built on Rust networking libraries, presented as another alternative to `httpx`.
requests ↩
The long-dominant Python HTTP client library, known for a simple synchronous API.
Starlette ↩
A lightweight Python web framework and toolkit that underpins many async web applications.
TLS ↩
Transport Layer Security, the standard protocol used to encrypt network traffic.
urllib3 ↩
A lower-level Python HTTP library that powers many other networking packages, including `requests`.
WSGI ↩
Web Server Gateway Interface, a standard way for Python web applications to talk to web servers in synchronous setups.

Reference links

Project and migration references

Maintainer and governance context

Alternative clients and performance

  • wreq-python
    Shared as a Rust-backed alternative used by one commenter when `urllib.request` was not enough.
  • niquests
    Raised as a possible alternative to `httpx2`.
  • HTTP client benchmark gist
    Used to claim that `niquests` and `httpx2` substantially outperform `httpx` in one local benchmark.
  • pyqwest
    Presented as another migration target with Rust internals and an `httpx`-compatible transport.

Feature references