Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I forked httpx

tildeweb.nl

Post reply on HN
Print view View original

131–140 of 194 posts

Re: Why I forked httpx

#131

Post by b450 »

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.)

Note that node-fetch will silently ignore any overrides to "forbidden" request headers like Host, since it's designed for parity with fetch behavior in the browser. This caused a minor debugging headache for me once.

Re: Why I forked httpx

#132

Post by Pay08 »

dirkc wrote: post #71
wging wrote: post #59

Earlier quoted context omitted.

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

Why is it amusing?

Re: Why I forked httpx

#133

Post by BigTTYGothGF »

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)

I think the python maintainers are still feeling burnt by the consequences of the "batteries included" approach from the old times.

Re: Why I forked httpx

#134

Post by pjmlp »

colejohnson66 wrote: post #117
awkwardpotato wrote: post #90

Earlier quoted context omitted.

What's the matter with this? It's a clean builder pattern, the response is returned directly from send. I've certainly seen uglier Java

The boilerplate of not having sane defaults. .NET is much simpler: using HttpClient client = new(); HttpResponseMessage response = await client.GetAsync("https://..."); if (response.StatusCode is HttpStatusCode.OK) { string s = await response.Content.ReadAsStringAsync(); // ... }

Yeah, so much simpler,

"Common IHttpClientFactory usage issues"

https://learn.microsoft.com/en-us/dotnet/core/extensions/htt...

"Guidelines for using HttpClient"

https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...

And this doesn't account for all gotchas as per .NET version, than only us old timers remember to cross check.

Re: Why I forked httpx

#135

Post by pixl97 »

xnorswap wrote: post #91
pjc50 wrote: post #62

Earlier quoted context omitted.

> dotnet's HttpClient is... fine. Yes, and it's in the standard library (System namespace). Being Microsoft they've if anything over-featured it.

It's fine but it's sharp-edged, in that it's recommended to use IHttpClientFactory to avoid the dual problem of socket exhaustion ( if creating/destroying lots of HttpClients ) versus DNS caching outliving DNS ( if using a very long-lived singleton HttpClient ). And while this article [1] says "It's been around for a while", it was only added in .NET Framework 4.5, which shows it took a while for the API to stabilise…

>"It's been around for a while"

is 14 years not a while?

Re: Why I forked httpx

#136

Post by yoyohello13 »

BigTTYGothGF wrote: post #133
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)

I think the python maintainers are still feeling burnt by the consequences of the "batteries included" approach from the old times.

Most Python developers these days weren't even programming when the 2 -> 3 split happened. Unless you're referencing something else.

Re: Why I forked httpx

#137

Post by Pay08 »

freedomben wrote: post #124
awkwardpotato wrote: post #90

Earlier quoted context omitted.

What's the matter with this? It's a clean builder pattern, the response is returned directly from send. I've certainly seen uglier Java

Just my opinion of course, but: > What's the matter with this? To me what makes this very "Java" is the arguments being passed, and all the OOP stuff that isn't providing any benefit and isn't really modeling real-world-ish objects (which IMHO is where OOP shines). .version(Version.HTTP_1_1) and .followRedirects(Redirect.NORMAL) I can sort of accept, but it requires knowing what class and value to pass, which is look…

> why can't I just pass 20 or 20_000 or something? Do we really need another class and method here?

If you've ever dealt with time, you'll be grateful it's a duration and not some random int.

Re: Why I forked httpx

#138

Post by looperhacks »

freedomben wrote: post #124
awkwardpotato wrote: post #90

Earlier quoted context omitted.

What's the matter with this? It's a clean builder pattern, the response is returned directly from send. I've certainly seen uglier Java

Just my opinion of course, but: > What's the matter with this? To me what makes this very "Java" is the arguments being passed, and all the OOP stuff that isn't providing any benefit and isn't really modeling real-world-ish objects (which IMHO is where OOP shines). .version(Version.HTTP_1_1) and .followRedirects(Redirect.NORMAL) I can sort of accept, but it requires knowing what class and value to pass, which is look…

> but it requires knowing what class and value to pass

Unless you use a text editor without any coding capabilities, your IDE should show you which values you can pass. The alternative is to have more methods, I guess?

> why can't I just pass 20 or 20_000 or something

20 what? Milliseconds? Seconds? Minutes? While I wouldn't write the full Duration.ofSeconds(20) (you can save the "Duration."), I don't understand how one could prefer a version that makes you guess the unit.

> proxy(ProxySelector.of(new InetSocketAddress("proxy.example.com", 80))), geez that's complex

Yes it is, can't add anything here. There's a tradeoff between "do the simple thing" and "make all things possible", and Java chooses the second here.

> .authenticator(Authenticator.getDefault()), why not just pass bearer token or something?

Because this Authenticator is meant for prompting a user interactively. I concur that this is very confusing, but if you want a Bearer token, just set the header.

Re: Why I forked httpx

#139

Post by denimnerd42 »

yoyohello13 wrote: post #136
BigTTYGothGF wrote: post #133

Earlier quoted context omitted.

I think the python maintainers are still feeling burnt by the consequences of the "batteries included" approach from the old times.

Most Python developers these days weren't even programming when the 2 -> 3 split happened. Unless you're referencing something else.

the batteries included approach is the stdlib that can do everything. turns out it’s hard to maintain and make good.

Re: Why I forked httpx

#140

Post by woodruffw »

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)

AFAICT, lacking a (good) standard HTTP library is kind of the norm in popular languages. Python, Ruby, Rust, etc. all either have a lackluster standard one or are missing one. I think it sits between two many decision pressures for most languages: there are a _lot_ of different RFCs both required and implied, lots of different idioms you could pick for making requests, lots of different places to draw the line on what to support, etc.

The notable exception is Go, which has a fantastic one. But Go is pretty notable for having an incredible standard library in general.

Post reply on HN