1. 18

  2. 3

    HTTP/2, we hardly knew you…

    1. 1

      As I understand it, HTTP/3 is largely a binary serialisation of HTTP/2 headers over QUIC, whereas HTTP/2 is a text serialisation of the same protocol over TCP. There are a lot of things in HTTP/2 like multiple streams that need application changes to take advantage of but once you’ve done those you can plug in HTTP/3 at the bottom of your stack and not modify anything at the higher levels.

      1. 4

        well I see it as something complicating the whole http stack even more and is only pushed by big companies that have enough money to throw engineers at any migration

        1. 2

          I’m not sure how the latter follows. HTTP/3 lets you establish a single connection and get multiple resources without packet loss in one stream delay any of the others and reduces latency for establishing encrypted sessions. That’s going to be great for a load of HTTP-based services such as Nextcloud and JMAP (the Nextcloud apps all seem to happily talk HTTP/2). Once your client and server are able to support encryption and multiple streams, moving from HTTP/2 to HTTP/3 should just be a matter of dropping in a different library (and those big companies that you complain about are the ones producing the open source libraries that everyone else will be using) and getting lower latency.

          1. 3

            All well and good, but it means we have well and truly locked out beginners and fast prototypes from building clients and servers at that layer of the stack without depending on those libraries.

            HTTP, for all of its many flaws, can be quickly implemented by anything that can munge text–and has been.

            1. 5

              I am not sure I agree. HTTP depends on TCP, which is something that you want to build from scratch, so you rely on some external provider of a network stack. Typically people actually want HTTPS, and I really hope you’re not implementing your own TLS stack as a beginner and are pulling in a library for that. If you’re willing to depend on a network stack and a TLS library, depending on an HTTP/3 library is not very much more complexity (actually, it’s less in total: QUIC + UDP is a lot simpler than TLS + TCP) and you can put anything you want that can ‘munge text’ on top.

              1. -1

                Why would you implement your own HTTP server? There’s plenty of good implementations that already exist.

                1. 4

                  Well, for people who are writing a programming language, an HTTP server is usually part of the process of building a web framework.

                  There’s also applications like having embedded sensors sending their data via HTTP, or small computers doing the same.

                  1. 3

                    The user I’m replying to is making an argument about beginners being locked out and fast prototyping being difficult.

                    Someone implementing a programming language has plenty on their plate already and are probably not beginners.

                    In terms of performance, if the hardware can run it then there’s probably already an implementation. If it can’t then there’s no point in writing one.

                    1. 1

                      I’d expect embedded sensors to either keep using HTTP/1.0 (most don’t even do 1.1) or something like MQTT. Just because HTTP/3 exists doesn’t mean that you can’t use older versions. If you’re building something for tightly resource-constrained environments then a protocol designed for low latency, high-bandwidth, independent streams might not be the best fit for your use case.