mesahm

hace 3 mesesdiscuss

Very stable actually. We've enabled it by default as such.

regards,

hace 3 mesesdiscuss

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,

mesahm

hace 3 mesesdiscuss

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.

mesahm

hace 3 mesesdiscuss

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.

mesahm

hace 4 mesesdiscuss

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.

mesahm

hace 4 mesesdiscuss

yes, plenty! testing it extensively, finding edge bugs, (...) and of course: spread the word on other project to help increasing adoption.

mesahm

hace 4 mesesdiscuss

help for getting it working is appreciated, we have it in mind. duly noted about the sponsorship, we accept constructive criticism, and alternative can be considered.

mesahm

hace 4 mesesdiscuss

nice to hear :)

mesahm

hace 4 mesesdiscuss

Thank you. Appreciated, you're welcome here anytime.

mesahm

hace 4 mesesdiscuss

agreed. as I said, it was a mistake from my end. and clearly looking to better myself.

mesahm

hace 4 mesesdiscuss

it's the gitmoji thing, I really don't like it, it was a mistake. Thinking to stop it soon. I was inspired by fastapi in the early days. I prefer conventionalcommits.org

mesahm

hace 4 mesesdiscuss

nee-quests, I am French native.

mesahm

hace 4 mesesdiscuss

ahah, "en effet"! je m'en souviendrai.

more seriously, all that is needed is our collective effort. I've done my part by scarifying a lot of personal time for it.

mesahm

hace 4 mesesdiscuss

aiohttp is an excellent library. very stable. I concurs, but! it's too heavily tied to HTTP/1, and well, I am not a fan of opening thousands of TCP conn just to keep up with HTTP/2 onward. niquests easily beat aiohttp just using 10 conn and crush httpx see https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1...

fwiw, HTTP/2 is twelve years old, just saying.

mesahm

hace 4 mesesdiscuss

the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests https://github.com/jawah/niquests

I am trying to resolve what you've seen. For years of hard work.

mesahm

hace 4 mesesdiscuss

And most importantly, we managed to get almost every plugin/3rd party tool bound to Requests in a working condition with this fork.

mesahm

hace 4 mesesdiscuss

Hi HN,

I'm the maintainer of Niquests.

For years, Python's Requests library was the gold standard, but it has been under feature freeze. As the web moved on, the Python ecosystem fractured: we got aiohttp (async only) and httpx (great, but currently struggles in high throughput scenarii for years with no visible solution merged so far).

I wanted the beautiful, ergonomic API of requests, but I wanted it to speak the modern web and solve most seen struggles around HTTP consumption. So I built Niquests as a drop-in replacement, you can literally do import niquests as requests. I didn't want to reinvent the wheel, I wanted to start on solid ground. Requests and urllib3 are both rock solid, so this was the starting point, learning from them and extend them for the modern web.

Under the hood, it's a different beast. I've added:

* HTTP/2 & HTTP/3 over QUIC out of the box * Multiplexing and full thread/task safety (fixed the old concurrency bottlenecks over thousands of TCP connections) * OS trust store support by default (no more certifi issues) * Both sync and async support (in one library) * Deep DNS control (DoH, DoQ, DoT, DNSSEC), "Happy Eyeballs" for fast connects * Integrated WebSocket extension over HTTP/1, HTTP/2, and HTTP/3 * Works in WASM (Pyodide), and compatible with ASGI/WSGI apps * And much more(...)

Here’s a real-world benchmark: Niquests completes a 1000-request multiplexed workload in 0.55s, compared to httpx (2.08s) and aiohttp (1.35s). See https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1... to verify yourself. And yes it does scale as long as your server can take it.

I've worked hard to make this the most advanced Python HTTP client. without losing the simplicity and readability we love from requests.

Would love feedback, technical questions (especially around HTTP/2+ and multiplexing!), or discussion about the state of Python HTTP clients.

mesahm

hace 6 mesesdiscuss

Hi HN,

I'm the maintainer of Niquests. It is a drop-in replacement for the Python requests library that focuses on bringing modern HTTP features to the familiar API we all know.

I started this because requests is effectively feature-frozen, but I really missed having support for newer standards like HTTP/2 and HTTP/3 without switching to a completely different tool. Not only due to Requests current state but, as some of you may be aware, httpx is in a tough situation too, risking to take the same path forward as Requests did(...)

Some of the main differences from the original library:

    Modern Protocols: It supports HTTP/2 and HTTP/3 over QUIC by default with a true multiplexing support.
    Async Support: You can use it synchronously just like requests, or asynchronously with await.
    Security: It uses your system's OS truststore (no more bundled certs) and supports OCSP revocation checks and DNSSEC.
    Performance: In our benchmarks, our multiplexing scheduler offer significant speed improvements over requests, httpx, and even aiohttp.

The goal is to let you upgrade your network stack just by changing your import to "import niquests as requests".

I'd love to hear your feedback or answer any questions about the implementation!

mesahm

hace 6 mesesdiscuss

Hey HN,

We (a team of 3 based in France) built this page because we were frustrated by how hard it is to own your identity online without any related knowledge.

We recently launched a tool (Happymail) to solve this, but this post is more about the philosophy of why we think the 'firstname.lastname' era is dying and why we should fix it.

Happy to answer questions, Regards

Submissions

Show HN: I built a PC-part picker that handles compatibility and shortages

Show HN: Niquests – A Requests fork, three years of catching Python's HTTP up

Show HN: A drop-in replacement and memory-safe TLS back end for Python

Show HN: I forked Python's Requests to add HTTP/3, async, and multiplexing

Show HN: Safest, Fastest, Easiest, and Most Advanced Python HTTP Client

Bringing uv-like performance leaps to Python HTTP

DNS was meant for people, not just websites

comments