mesahm
Joined 10 months ago
Karma
57
Submissions
32
Member since
Jan 4
Recent submissions
Comment · 25 days ago
glad you liked it.
Comment · 3 months ago
it should work with Wasmer too, I presume, but I don't see anywhere compat with WASI p2/p3 sockets. I'll look into it asap.
regards,
Comment · 6 months ago
Very stable actually. We've enabled it by default as such.
regards,
Comment · 6 months ago
We've extensively worked the compat layer. And every adapters out there should work as is.
But most of time, we've exposed better way to achieve that (e.g. mTLS in memory, network fine tuning, peer cert retrieval, ...) can be done without extra customization.
regards,
Comment · 6 months ago
Author here. I forked Requests in mid-2023 because it's effectively frozen, and Python's HTTP capabilities have fallen far behind what the protocols and the ecosystem allow today. The Requests API is great; I didn't want to replace it, I wanted to catch it up.
Three years later, here's where things stand:
HTTP/2 by default, HTTP/3 over QUIC when the server advertises it via Alt-Svc or via DNS HTTPS record. No configuration needed, the client negotiates automatically. This alone accounts for most of the performance difference in practice. A quick benchmark (1000 requests to httpbingo.org/get, reproduction steps in the README)
niquests 0.551s (HTTP/2) aiohttp 1.351s (HTTP/1.1) httpx 2.087s (HTTP/2)
Security defaults that should have been there years ago. OS trust store instead of bundled certifi. Certificate revocation checks via OCSP or CRL. Encrypted Client Hello. Post-quantum key exchange. None of this is exotic anymore - browsers have shipped most of it - but Python clients still don't do it.
DNS. DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC, DNSSEC validation. Per-session resolver configuration.
Other things that accumulated over three years: Happy Eyeballs, WebSocket and SSE over all three HTTP versions, in-memory certificates for mTLS, connection-level telemetry (DNS/TCP/TLS timings via response.conn_info), native Unix socket support, and as of 3.18, experimental Pyodide/WASM support.
Migration is boring by design: import niquests as requests. Existing auth flows, cookie jars, .netrc, adapters - they all work. We also maintain compatibility shims for requests-mock, responses, and betamax.
Happy to discuss anything related to the project or HTTP in general.
Comment · 7 months ago
Hi HN,
I am the original author of "rtls". For years now, the Python experts are arguing about OpenSSL mandatory aspect in the distribution, and many other went into compiling CPython themselves against LibreSSL, or AWS-LC, (...)
I wanted the broader community to be able to just "run an alternative ssl backend" without effort.
The main goal is for anyone running a mere high level http client to be able to leverage a memory-safe TLS backend.
Behind the scene it's Rustls, with aws-lc-rs engine.
I'm also the author of Niquests http client, a drop in replacement for Requests. https://github.com/jawah/niquests and yes rtls is supported transparently with it.
Comment · 7 months ago
I spend 3 years developing Niquests, and believe me, HTTP is far from easy. Being a client means you have to speak to everyone, and no one have to speak to you (RFC are nice, but in practice never applied as-is). Once you go deep under the implementation, you'll find a thousand edge cases(...). And yes, the myth that as developer http/1 is "best" only means that the underlying scheduler is weak.
today, via a dead simple script, you'll see http/2+ beat established giant in the http/1 client landscape. see https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1... if you are curious.
Comment · 7 months ago
yes, plenty! testing it extensively, finding edge bugs, (...) and of course: spread the word on other project to help increasing adoption.