1. 9
  1.  

  2. 6

    From my experience, Ruby’s Net::HTTP should be avoided if possible. The library is pretty battle-tested in most cases but it can have odd quirks around error handling. Connection issues can raise any number of connections and it tends to be a leaky abstraction around other networking subsystems.

    I know this isn’t necessarily the “ruby way” but I’d much rather have an HTTP library that doesn’t raise exceptions for connection issues, but rather use Go’s pattern of returning an error object. I’d rather reserve exceptions for problems with my code as opposed to external services.

    At my last job we were stuck on old versions of libcurl so many other alternatives weren’t possible. I ended up using Excon (pure ruby, not built on Net::HTTP) as a replacement and found it to be much easier to use and far more consistent when our code fell off the happy path.

    This all points to a larger issue. The post talks about an HTTP client with extra features that wraps another HTTP client with extra features that wrap a leaky abstraction. Why is all this necessary to make HTTP connections? I get that the point of We::Call is to help developers improve how they make external calls but all of this points to an outdated stdlib (seriously no offense to the folks who work on Net::HTTP).

    Why can’t we have a stdlib HTTP client that requires timeouts and is pluggable to use different connection backends (consider this a rhetorical question)? Looking at all the HTTP clients/wrappers in the ruby ecosystem leads me to believe that the stdlib should either be updated or remove in favor of gems that can evolve outside of Ruby’s release cycle.

    1. 4

      FWIW you can use keepalive with Net::HTTP, you just have to set the header. Ruby just doesn’t keep a global cache of connections, it’s meant to be a low-level library after all.

      I think all HTTP libraries suck ass, in that they require pretty detailed knowledge to use 100% properly and usually require reading the source code. I also don’t think this is avoidable, HTTP use varies so wildly in practice that sensible defaults aren’t necessarily even sensible for all applications of the same archetype.

      1. 1

        I think all HTTP libraries suck ass, in that they require pretty detailed knowledge to use 100% properly and usually require reading the source code.

        In general, I agree. I do find the python requests library pretty usable though.

        1. 1

          Yes it’s great for the common use case! But it isn’t perfect for every use case. I bet I’ve done something in the last 3 days that would be annoying to do in requests. In fairness, I also do a lot of weird stuff.

      2. 2

        Relatedly: the 8 year outstanding bug to make Net::HTTP handle character encodings at all.