Why I forked httpx • Hacker News Board

Re: Why I forked httpx

#71

Post by dirkc » Wed, Mar 25, 2026, 11:21 AM UTC

wging wrote: post #59

dirkc wrote: post #49

Earlier quoted context omitted.

You would think that sending HTTP requests is a basic capability, but I've had fun in many languages doing so. Long ago (2020, or not so long ago, depending on how you look at it) I was surprised that doing an HTTP request on node using no dependencies was a little awkward: const response = await new Promise( (resolve, reject) => { const req = https.request(url, { }, res => { let body = ""; res.on("data", data => { b…

These days node supports the fetch API, which is much simpler. (It wasn't there in 2020, it seems to have been added around 2022-2023.)

Yes, thankfully! It's amusing to read what they say about fetch on nodejs.org [1]:

> Undici is an HTTP client library that powers the fetch API in Node.js. It was written from scratch and does not rely on the built-in HTTP client in Node.js. It includes a number of features that make it a good choice for high-performance applications.

[1] - https://nodejs.org/en/learn/getting-started/fetch

Re: Why I forked httpx

#72

Post by LtWorf » Wed, Mar 25, 2026, 11:22 AM UTC

Kwpolska wrote: post #25

What is it about Python that makes developers love fragmentation so much? Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, stdlib only has the ugly urllib.request, and everyone is using third party stuff like requests or httpx, which aren't always well maintained. (See also: packaging)

The HTTP protocol is easy to implement the basic features but hard to implement a full version that is also efficient.

I've often ended up reimplementing what I need because the API from the famous libraries aren't efficient. In general I'd love to send a million of requests all in the same packet and get the replies. No need to wait for the first reply to send the 2nd request and so on. They can all be on the same TCP packet but I have never met a library that lets me do that.

So for example while http3 should be more efficient and faster, since no library I've tried let me do this, I ended up using HTTP1.1 as usual and being faster as a result.

Re: Why I forked httpx

#73

Post by mananaysiempre » Wed, Mar 25, 2026, 11:30 AM UTC

rglullis wrote: post #27

znpy wrote: post #16

Earlier quoted context omitted.

Oh i recognised one of the involved people immediately, drama person. I still think that hijacking the mkdocs package was the wrong way to go though. The foss landscape has become way too much fork-phobic. Just fork mkdocs and go over your merry way.

Drama around Starlette. Drama around httpx. Drama around MkDocs. I just hope that DRF is not next, I still have some projects that depend on it.

Per TFA, there’s similarly-shaped low-key drama around DRF too[1] although issues and discussions have been reënabled since then.

[1] https://github.com/orgs/encode/discussions/11#discussioncomm...

Re: Why I forked httpx

#74

Post by ffsm8 » Wed, Mar 25, 2026, 11:31 AM UTC

lenkite wrote: post #32

maccard wrote: post #29

Earlier quoted context omitted.

> Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. This seems like a pretty good reason to fork to me. > Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, Or Javascript (well node), or golang (http/net is _wors…

Your java knowledge is outdated. Java's JDK has a nice, modern HTTP Client https://docs.oracle.com/en/java/javase/11/docs/api/java.net....

Ahh, java. You never change, even if you're modern

    HttpClient client = HttpClient.newBuilder()
        .version(Version.HTTP_1_1)
        .followRedirects(Redirect.NORMAL)
        .connectTimeout(Duration.ofSeconds(20))
        .proxy(ProxySelector.of(
           new InetSocketAddress("proxy.example.com", 80)
        ))
        .authenticator(Authenticator.getDefault())
        .build();

       HttpResponse response = client.send(request, BodyHandlers.ofString());

       System.out.println(response.statusCode());
       System.out.println(response.body());

For the record, you're most likely not even interacting with that API directly if you're using any current framework, because most just provide automagically generated clients and you only define the interface with some annotations

Re: Why I forked httpx

#75

Post by mananaysiempre » Wed, Mar 25, 2026, 11:31 AM UTC

forkerenok wrote: post #37

rglullis wrote: post #27

Earlier quoted context omitted.

Drama around Starlette. Drama around httpx. Drama around MkDocs. I just hope that DRF is not next, I still have some projects that depend on it.

What's the drama around starlette? (Can't find anything)

https://github.com/Kludex/starlette/issues/3180 and before that https://github.com/Kludex/starlette/issues/3042

Re: Why I forked httpx

#76

Post by Orygin » Wed, Mar 25, 2026, 11:37 AM UTC

umvi wrote: post #58

maccard wrote: post #29

Earlier quoted context omitted.

> Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. This seems like a pretty good reason to fork to me. > Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, Or Javascript (well node), or golang (http/net is _wors…

What's wrong with Go's? I've never had any issues with it. Go has some of the best http batteries included of any language

I guess he never used Fiber's APIs lol

The stdlib may not be the best, but the fact all HTTP libs that matter are compatible with net/http is great for DX and the ecosystem at large.

Re: Why I forked httpx

#77

Post by noirscape » Wed, Mar 25, 2026, 11:39 AM UTC

mananaysiempre wrote: post #75

forkerenok wrote: post #37

Earlier quoted context omitted.

What's the drama around starlette? (Can't find anything)

https://github.com/Kludex/starlette/issues/3180 and before that https://github.com/Kludex/starlette/issues/3042

I think that may be the first time I've seen licensing drama over something as minor as adding another author to the copyright list.

Pretty sure those are completely standard for major changes in maintainers/hostile forks/acknowledging major contributors. I've seen a lot of abandoned MIT/BSD projects add a new line for forks/maintainers being active again in order to acknowledge that the project is currently being headed by someone else.

From my "I am not a lawyer" view, Kludex is basically correct, although I suppose to do it "properly", he might need to just duplicate the license text in order to make it clear both contributors licensed under BSD 3-clause. Probably unnecessary though, given it's not a license switch (you see that style more for ie. switching from MIT to BSD or from MIT/BSD to GPL, since that's a more substantial change); the intent of the license remains the same regardless and it's hard to imagine anyone would get confused.

I suspect (given the hammering on it in responses), that Kludex asking ChatGPT if it was correct is what actually pissed off the original developer, rather than the addition of Kludex to the list in and of itself.

Re: Why I forked httpx

#78

Post by 72deluxe » Wed, Mar 25, 2026, 11:40 AM UTC

duskdozer wrote: post #30

ayhanfuat wrote: post #8

More related drama: The Slow Collapse of MkDocs ( https://fpgmaas.com/blog/collapse-of-mkdocs/ )

>thread to call out Read the Docs for profiting from MkDocs without contributing back. >They also point out that not opening up the source code goes against the principles of Open Source software development I will never stop being amused when people have feelings like this and also choose licenses like BSD (this project). If you wanted a culture that discouraged those behaviors, why would you choose a license that e…

Yes I agree completely. I am baffled why they choose that license in the first place. It just seems to engender drama when people actually follow the license they've chosen! Perhaps open source is actually powered by drama, where developers have more meaning from the drama they create than the actual things they create?

Re: Why I forked httpx

#79

Post by maltyxxx » Wed, Mar 25, 2026, 11:40 AM UTC

[flagged]

Re: Why I forked httpx

#80

Post by mananaysiempre » Wed, Mar 25, 2026, 11:42 AM UTC

mesahm wrote: post #4

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.

No Trio support yet, right? That’s the main reason to use httpx for me at least, and has been since I first typed “import httpx” some years ago.

(Also the sponsorship subscription thing in the readme gives me vague rugpull vibes. Maybe I’ve just been burned too much—I don’t mean to discourage selling support in general.)