Better HTTP/1 connection reuse - The Go Programming Language
go.dev
Go 1.27 includes a change to the HTTP client that can make programs sending many sequential HTTP/1 requests significantly faster.
  • lobsters__kingmob@crustaceanson.theshelf.topM
    1·
    16 days ago

    As someone who used to maintain a FOSS web server project for a few years, I’ve always lamented the fact that HTTP/2 did not displace HTTP/1.1 more thoroughly.

    I’ve heard multiple variants of the argument that “HTTP/2’s improvements don’t warrant the extra complexity for internal networks”, but the counterargument is inefficiencies like this one, caused by HTTP/1’s connection and request/response models. (H1 pipelining is another problem.)

    HTTP/2 is just a much more logical and efficient model. (Though it had its serious missteps too, like server push or the original priority mechanisms.)

    score 1 · canonical

    • lobsters__yoric_003c@crustaceanson.theshelf.topM
      1·
      16 days ago

      A big part of it is the complexity of the specification. The various HTTP 1.1 specifications are by no means trivial as there are a lot of small details developers are likely to forget about, but HTTP 2 is a lot more complex, such as due to it’s header compression algorithm amongst other things.

      As for HTTP 3: while HTTP 2 does provide clear benefits over HTTP 1.1 for end users/efficiency, the difference between HTTP 2 and HTTP 3 is a lot smaller and honestly just not worth the trouble, unless maybe you’re operating at Netflix/Cloudflare/etc scale

      score 1 · canonical

      • lobsters__kingmob@crustaceanson.theshelf.topM
        1·
        16 days ago

        All I can say is I personally didn’t find H2 too complex. Supporting streams was the real source of complexity, at least for us. To be fair, we built on lower-level libraries for things like frame unpacking, so the lowest levels were handled already.

        Headers were actually easier in our case: compression was handled by an external library, and the elimination of futzing around with upper/lowercase simplified some code.

        Some H2 complexities exist, but nobody uses them anymore, so I skipped them. Server push is effectively unworkable in the wild without heroic efforts and interrogating browser caches. RFC7540’s original priority signaling was deemed too complex and got deprecated; browsers interpreted the values differently, and servers were uneven in implementation.

        I mostly agree on H3. What makes it interesting is not in HTTP itself, but the underlying transport changes to use QUIC/UDP. For internal networks, this is a lot of churn for little benefit. (H3 has some slight benefits, especially for mobile users, so I wouldn’t say you must be cloud scale, but it’s definitely pretty low on the priority list.)

        score 1 · canonical