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

111–120 of 194 posts

Re: Why I forked httpx

#111

Post by ffsm8 »

lenkite wrote: post #110
ffsm8 wrote: post #74

Earlier quoted context omitted.

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(respon…

Your http client setup is over-complicated. You certainly don't need `.proxy` if you are not using a proxy or if you are using the system default proxy, nor do you need `.authenticator` if you are not doing HTTP authentication. Nor do you need `version` since there is already a fallback to HTTP/1.1. HttpClient client = HttpClient.newBuilder() .followRedirects(Redirect.NORMAL) .connectTimeout(Duration.ofSeconds(20)) .…

It was literally just copy pasted from the linked source (the official Oracle docs)

Re: Why I forked httpx

#112

Post by PxldLtd »

awkwardpotato wrote: post #90
ffsm8 wrote: post #74

Earlier quoted context omitted.

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(respon…

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

Yeah this is all over Rust codebases too for good reason. The argument is that default params obfuscate behaviour and passing in a struct (in Rust) with defaults kneecaps your ability to validate parameters at compile time.

Re: Why I forked httpx

#113

Post by [deleted] »

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

[deleted]

Re: Why I forked httpx

#114

Post by nathell »

cachius wrote: post #53
nathell wrote: post #17

Congratulations on forking! Always remember that open-source is an author’s gift to the world, and the author doesn’t owe anything to anyone. Thus, if you need a feature that for whatever reason can’t or won’t go upstream, forking is just about the only viable option. Fingers crossed!

This is not merely open-source, but taking part in a huge package ecosystem in a foundational role in an XKCD 2347 type of way for HTTP requests. Put your side project on your personal homepage and walk away - fine. Make it central infrastructure - respond to participants or extend or cede maintainership.

No. Even if it’s a central piece of infrastructure, any and all maintainership effort is still a token of good will of the maintainer – and needs to be appreciated, rather than expected.

If you need stronger guarantees, pay someone to deliver them.

Re: Why I forked httpx

#115

Post by maccard »

francislavoie wrote: post #48
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, Go's net/http is fantastic. I don't understand that take. Many servers are built on it because it's so fully featured out of the box.

The server side is great. Sending a http request is… not

Re: Why I forked httpx

#116

Post by mesahm »

LtWorf wrote: post #72
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 T…

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.

Re: Why I forked httpx

#117

Post by colejohnson66 »

awkwardpotato wrote: post #90
ffsm8 wrote: post #74

Earlier quoted context omitted.

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(respon…

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();
        // ...
    }

Re: Why I forked httpx

#118

Post by matheusmoreira »

duskdozer wrote: post #96
matheusmoreira wrote: post #82

Earlier quoted context omitted.

Everybody's got a different idea of what it means for a library to be "friendly" and "fully-featured" though. It's probably better to keep the standard library as minimal as possible in order to avoid enshrining bad software. Programming languages could have curated "standard distributions" instead that include all the commonly used "best practice" libraries at the time.

https://xkcd.com/927/

That situation should be avoided. People should have to create their own libraries until everyone empirically converges into a de facto standard that can then be made official.

Re: Why I forked httpx

#119

Post by thedanbob »

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)

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

I've noticed that many languages struggle with HTTP in the standard library, even if the rest of the stdlib is great. I think it's just difficult to strike the right balance between "easy to use" and "covers every use case", with most erring (justifiably) toward the latter.

Re: Why I forked httpx

#120

Post by Tostino »

ffsm8 wrote: post #111
lenkite wrote: post #110

Earlier quoted context omitted.

Your http client setup is over-complicated. You certainly don't need `.proxy` if you are not using a proxy or if you are using the system default proxy, nor do you need `.authenticator` if you are not doing HTTP authentication. Nor do you need `version` since there is already a fallback to HTTP/1.1. HttpClient client = HttpClient.newBuilder() .followRedirects(Redirect.NORMAL) .connectTimeout(Duration.ofSeconds(20)) .…

It was literally just copy pasted from the linked source (the official Oracle docs)

And those docs were likely trying to show you how to use multiple features, not the most basic implementation of it
Post reply on HN