noopside

neither does this alternative

will be glad to answer any concerns if you encounter any, the repo issue tracker will welcome your feedbacks.

Glad to hear that. This is actually planned, the miscellaneous control for networking fingerprint (mimic chrome tls handshake). will come soon enough. for now, my own experience shows that it is more resilient as is (with appropriate headers (order being kept already).

there https://github.com/jawah/urllib3.future/issues

This would be done gladly. Open an issue at urllib3.future and a proper tracking will be made.

The internal resolver is recursive, so CNAME are automatically translated into addresses. What remain is the happy eyeball implementation, which is almost completed already. we wanted to wait for an harmonious feature (e.g. available across all 3 protocols)

but can be speeded up if really needed.

Not yet, but is coming soon. We have a minor technical challenge to make it work with QUIC.

Great question, In a nutshell, Niquests goes way beyond httpx capabilities by actually leveraging HTTP/2+ protocols, they are quite shy on its support (HTTP/2) due to the current inability of issuing concurrent requests in a synchronous context. Moreover, this solution has a stable API, and httpx did not settle as of yet (v1 milestone). In terms of performance, they offers similar performances in similar contexts, but keep in mind that Niquests has a higher level of features while keeping a near perfect compatibility with its origin, aka. Requests. Then, when using a multiplexed connection, you can easily beat any mainstream HTTP clients while in a synchronous context. Finaly, no one propose DNS over HTTPS, QUIC, TLS, etc.. As well as DNSSEC, OCSP Certificate Status, Network fine tuning settings, etc.. All of those configurable with a mere simple parameter. It aim at keeping the level of simplicity you grown fund of when discovering Requests. There's more, but I am going to let you discover it by yourself. There's also an article you may find interesting called "10 reasons to quit your HTTP client" onto the README.

Many things, starting with true support for recent protocols. Until now, no solution were able to leverage multiplexing and couldn't issue concurrent requests using one connection. This permit to avoid useless threading and complexity. Then, about security, plain DNS is over 30 years old, and we still rely on it to resolve hostnames, it is dangerous to say the least. With support for encrypted DNS and DNSSEC, you raise the bar higher for potential attacker. Then about certificate validation, you cannot be sure the certificate is not revoked without this solution. Almost every dependencies in the chain are SLSA signed, thus almost eliminating some risks. Finally, getting a fresh evolution without having to re-learn anything or re invent the wheel has some perks. This solution extend the well known Requests and provide both sync and async interfaces, almost no change required. And more, but I'll let you discover the rest by yourself.