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).
That would be awesome if even just for tcp protocols.
I've been looking at contrib.resolver in urllib3.future and noticed that you only parse A,AAAA,HTTPS from responses, but you do not handle a CNAME. I wonder, because kubernetes service can return a CNAME for app to follow:
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)
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.
The prefered style of the titles in HN is more dry. The guidelines [1] ask to use the origianl title, but sometimes it's too bad and the subtitle is a good alternative. If you repost it, my sugestion is to use a reduced version of the first sentence "Niquests is a simple, yet elegant, HTTP library. It is a drop-in replacement for Requests that is no longer under feature freeze.", something like "Niquests: A HTTP library for Python that is a drop-in replacement for Requests"
