> 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 _worse_ than urllib IMO), Rust , Java (UrlRequest is the same as python's), even dotnet's HttpClient is... fine.

Honestly the thing that consistently surprises me is that requests hasn't been standardised and brought into the standard library

▲ francislavoie 6 hours ago | parent | next [-]

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.

	▲	maccard 2 hours ago \| parent [-]
		The server side is great. Sending a http request is… not

▲ lenkite 6 hours ago | parent | prev | next [-]

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

▲ ffsm8 4 hours ago | parent [-]

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

▲ lenkite 3 hours ago | parent | next [-]

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

▲

ffsm8 3 hours ago | parent [-]

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

	▲	Tostino 2 hours ago \| parent [-]
		And those docs were likely trying to show you how to use multiple features, not the most basic implementation of it

▲ awkwardpotato 3 hours ago | parent | prev [-]

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

▲ freedomben 2 hours ago | parent | next [-]

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 lookups/documentation reference. These are spread out over a bunch of classes. But we start getting so "Java" with the next ones. .connectTimeout(Duration.ofSeconds(20)) (why can't I just pass 20 or 20_000 or something? Do we really need another class and method here?) .proxy(ProxySelector.of(new InetSocketAddress("proxy.example.com", 80))), geez that's complex. .authenticator(Authenticator.getDefault()), why not just pass bearer token or something? Now I have to look up this Authenticator class, initialize it, figure out where it's getting the credentials, how it's inserting them, how I put the credentials in the right place, etc. The important details are hidden/obscured behind needless abstraction layers IMHO.

I think Java is a good language, but most modern Java patterns can get ludicrous with the abstractions. When I was writing lots of Java, I was constantly setting up an ncat listener to hit so I could see what it's actually writing, and then have to hunt down where a certain thing is being done and figuring out the right way to get it to behave correctly. Contrast with a typical Typescript HTTP request and you can mostly tell just from reading the snippet what the actual HTTP request is going to look like.

	▲	looperhacks an hour ago \| parent \| next [-]
		> 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.
	▲	Pay08 an hour ago \| parent \| prev [-]
		> 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.

▲ colejohnson66 2 hours ago | parent | prev | next [-]

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

	▲	pjmlp an hour ago \| parent \| next [-]
		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.
	▲	lmz 2 hours ago \| parent \| prev [-]
		That's just an example. It does have defaults: https://docs.oracle.com/en/java/javase/11/docs/api/java.net.... (search for "If this method is not invoked")

▲ PxldLtd 3 hours ago | parent | prev [-]

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.

	▲	Pay08 32 minutes ago \| parent [-]
		It does have defaults, the above example manually sets everything to show people reading the docs what that looks like.

▲ umvi 5 hours ago | parent | prev | next [-]

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

▲

2 hours ago | parent | next [-]

[deleted]

▲

Orygin 4 hours ago | parent | prev [-]

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.

	▲	maccard 2 hours ago \| parent [-]
		Thr comment I replied to was talking about sending a http requests. Go’s server side net/http is excellent, the client side is clunky verbose and suffers from many of the problems that Python’s urllib does.

▲ localuser13 6 hours ago | parent | prev | next [-]

>Honestly the thing that consistently surprises me is that requests hasn't been standardised and brought into the standard library

Instead, official documentation seems comfortable with recommending a third party package: https://docs.python.org/3/library/urllib.request.html#module...

>The Requests package is recommended for a higher-level HTTP client interface.

Which was fine when requests were the de-facto-standard only player in town, but at some point modern problems (async, http2) required modern solutions (httpx) and thus ecosystem fragmentation began.

	▲	Spivak 6 hours ago \| parent [-]
		Well, the reason for all the fragmentation is because the Python stdlib doesn't have the core building blocks for an async http or http2 client in the way requests could build on urllib. The h11, h2, httpcore stack is probably the closest thing to what the Python stdlib should look like to end the fragmentation but it would be a huge undertaking for the core devs.

▲ Kwpolska 6 hours ago | parent | prev | next [-]

Node now supports the Fetch API.

▲ pjc50 5 hours ago | parent | prev | next [-]

> dotnet's HttpClient is... fine.

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

▲

xnorswap 3 hours ago | parent [-]

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. There were other ways to make web requests before that of course, and also part of the standard library, and it's never been "difficult" to do so, but there is a history prior to HttpClient of changing ways to do requests.

For modern dotnet however it's all pretty much a solved problem, and there's only ever been HttpClient and a fairly consistent story of how to use it.

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

▲

pixl97 an hour ago | parent [-]

>"It's been around for a while"

is 14 years not a while?

	▲	xnorswap 5 minutes ago \| parent [-]
		It is, but it's also a decade after the language was first released.

▲ gjvc 5 hours ago | parent | prev [-]

requests is some janky layer onto of other janky layers. last thing you want in the stdlib.

it's called the STD lib for a reason...