4 ms·

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

• lenkite 7mo ago
  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.http/java/net/http/HttpClient.html https://docs.oracle.com/en/java/javase/11/docs/api/java.net....
  • ffsm8 7mo ago
    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
    • awkwardpotato 7mo ago
      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
      • PxldLtd 7mo ago
        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 7mo ago
          It does have defaults, the above example manually sets everything to show people reading the docs what that looks like.
      • colejohnson66 7mo ago
        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(); // ... }
        • lmz 7mo ago
          That's just an example. It does have defaults: https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.Builder.html https://docs.oracle.com/en/java/javase/11/docs/api/java.net.... (search for "If this method is not invoked")
        • pjmlp 7mo ago
          Yeah, so much simpler, "Common IHttpClientFactory usage issues" https://learn.microsoft.com/en-us/dotnet/core/extensions/httpclient-factory-troubleshooting https://learn.microsoft.com/en-us/dotnet/core/extensions/htt... "Guidelines for using HttpClient" https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/httpclient-guidelines?source=recommendations 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.
          • 7mo ago
    • lenkite 7mo ago
      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 7mo ago
        It was literally just copy pasted from the linked source (the official Oracle docs)
        • Tostino 7mo ago
          And those docs were likely trying to show you how to use multiple features, not the most basic implementation of it
          • ffsm8 7mo ago
            I mean dont get me wrong, I work with Java basically 8 hours per day. I also get _why_ the API is as it is - It essentially boils down to the massive Inversion of Control fetish the Java ecosystem has. It does enable code that "hides" implementation very well, like the quoted examples authentication API lets you authenticate in any way you can imagine, as in literally any way imaginable. Its incredibly flexible. Want to only be able to send the request out after you've touched a file, send of a Message through a message broker and then maybe flex by waiting for the response of that async communication and use that as a custom attribute in the payload, additionally to a dynamically negotiated header to be set according to the response of a DNS query? yeah, we can do that! and the caller doesnt have to know any of that... at least as long as it works as intended Same with the Proxy layer, the client is _entirely_ extensible, it is what Inversion of Control enables. It just comes with the unfortunate side-effect of forcing the dev to be extremely fluent in enterprisey patterns. I dont mind it anymore, myself. the other day ive even implemented a custom "dependency injection" inspired system for data in a very dynamic application at my dayjob. I did that so the caller wont even need to know what data he needs! it just get automatically resolved through the abstraction. But i strongly suspect if a jr develeoper which hasnt gotten used to the java ecosystem will come across it, he'll be completely out of his depth how the grander system works - even though a dev thats used to it will likely understand the system within a couple of moments. Like everything in software, everything has advantages and disadvantages. And Java has just historically always tried to "hide complexity", which in practice however paradoxically multiplies complexity _if youre not already used to the pattern used_.
• localuser13 7mo ago
  >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-urllib.request 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 7mo ago
    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.
    • zahlman 7mo ago
      > but it would be a huge undertaking for the core devs. More importantly, it would be massively breaking to remove the existing functionality (and everyone would ignore a deprecation), and confusing not to (much like it was when 2.x had both "urllib" and "urllib2"). It'd be nice to have something high level in the standard library based on urllib primitives. Offering competition to those, not so much.
• Kwpolska 7mo ago
  Node now supports the Fetch API.
• francislavoie 7mo ago
  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 7mo ago
    The server side is great. Sending a http request is… not
• umvi 7mo ago
  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
  • Orygin 7mo ago
    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 7mo ago
      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.
  • deleted 7mo ago
    [deleted]
  • jerf 7mo ago
    Go's net/http Client is built for functionality and complete support of the protocol, including even such corner cases as support for trailer headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Trailer https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... Which for a lot of people reading this message is probably the first time they've heard of this. It is not built for convenience. It has no methods for simply posting JSON, or marshaling a JSON response from a body automatically, no "fluent" interface, no automatic method for dealing with querystring parameters in a URL, no direct integration with any particular authentication/authorization scheme (other than Basic Authentication, which is part of the protocol). It only accepts streams for request bodys and only yields streams for response bodies, and while this is absolutely correct for a low-level library and any "request" library that mandates strings with no ability to stream in either direction is objectively wrong, it is a rather nice feature to have available when you know the request or response is going to be small. And so on and so on. There's a lot of libraries you can grab that will fix this, if you care, everything from clones of the request library, to libraries designed explicitly to handle scraping cases, and so on. And that is in some sense also exactly why the net/http client is designed the way it is. It's designed to be in the standard library, where it can be indefinitely supported because it just reflects the protocol as directly as possible, and whatever whims of fate or fashion roll through the developer community as to the best way to make web requests may be now or in the future, those things can build on the solid foundation of net/http's Request and Response values. Python is in fact a pretty good demonstration of the risks of trying to go too "high level" in such a client in the standard library.
• pjc50 7mo ago
  > 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 7mo ago
    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/httpclient-factory https://learn.microsoft.com/en-us/dotnet/core/extensions/htt...
    • pixl97 7mo ago
      >"It's been around for a while" is 14 years not a while?
      • xnorswap 7mo ago
        It is, but it's also a decade after the language was first released.
        • Kwpolska 7mo ago
          Python’s urllib2 (now urllib.request) started out in the year 2000 [0]. .NET’s WebRequest was available in .NET Framework 1.1 in 2003 [1]. But since then, Microsoft noticed the issues with WebRequest and came up with HttpClient in 2012. It has some issues and footguns, like those related to HttpClient lifetime, but it’s a solid library. On the other hand, the requests library for Python started in 2011 [2], but the stdlib library hasn’t seen many improvements. [0] https://github.com/python/cpython/blob/6d7e47b8ea1b8cf82927dacc364689b8eeb8708b/Lib/urllib2.py https://github.com/python/cpython/blob/6d7e47b8ea1b8cf82927d... [1] https://learn.microsoft.com/en-us/dotnet/api/system.net.webrequest?view=netframework-1.1 https://learn.microsoft.com/en-us/dotnet/api/system.net.webr... [2] https://github.com/psf/requests/blob/main/HISTORY.md#001-2011-02-13 https://github.com/psf/requests/blob/main/HISTORY.md#001-201...
• gjvc 7mo ago
  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...