+1 and pour one out for HTTP/1.1. HTTP/1.1 is very flexible, and easily incrementally understandable, which makes sense since it's the last iteration of a relatively simple technology that took over the world. (okay, with some well-known limitations -- head of line blocking, pipelining is far better in theory than in practice, etc.) The same cannot (yet) be said for http/2 or http/3, especially if you look at the current installed bases of same, mostly in the web area. We were able to take HTTP/1.1 and build on it as a basis for a delay-tolerant network approach to transport and delivery in intermittent connectivity -- not the web, but a more email-like store-and-forward delivery of associated files. https://http-dtn.sourceforge.io/ (this didn't go anywhere much, because explaining but-it's-not-the-web you're-not-browsing to people is actually quite hard, you can't get the interest of big names like google because it's not their use case, etc.) I'd hesitate to attempt the same -dtn with http/2 and http/3 - their web use case optimizations and complexity would make that much more difficult. and... I don't really understand those documents. Fiendishly difficult. Never mind their implementations. Unlike HTTP/1.1. The putative IETF deep space group (to be called TipTop, I believe) is looking at using QUIC as its base for long-distance interplanetary comms. We'll see how that goes. https://datatracker.ietf.org/wg/tiptop/about/ HTTP/1.1 has made full standard, which means that it's finally dead and now ready to be buried with honours and a fulsome tombstone describing its attributes. Vale HTTP/1.1; we never really appreciated you until you were gone. Lloyd Wood lloyd.wood@xxxxxxxxxxx On Wednesday 8 January 2025 at 05:14:25 GMT+11, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: > I was pleased to see the HTTP 1.1 become a full standard relatively recently, because I'm a cautious fellow I had been holding off deploying or using anything based on HTTP because of my concerns that it wasn't really stable and might still significantly change ;-). > My concern wasn't that nobody was using HTTP/1.1, it was that it is really difficult to tell people IETF standards status matters when the most widely used application protocol didn't become a standard for decades after it was finished. > Of course, for similar reasons, I suspect that is much wiser/safer to stick with the full Internet Standard HTTP 1.1 rather then be very brazen and implement or deploy the updated H/2, or H/3, neither or which are real standards, just something proposed to be a standard in future. > > My real point being that our existing naming/categorisation isn't clear and useful to readers, or consumers of RFCs since I really think that H/2 and H/3 are the "current" stable versions of HTTP, and HTTTP 1.1 is legacy/historic. > I don't believe HTTP/1.1 is historic or that HTTP/2 is the right replacement for HTTP/1.1 in Web services. And I speak as the person who was writing probably the first 'Web Services' back at CEN in 1993 and the first person to make use of keep-alive. The reason we ended up with every application protocol being layered on HTTP was to get round the corporate firewalls. And now we use HTTPS. Corporations like firewalls because they are a cheap way to get the auditors off their back. I implemented OAUTH2 last week and today's fun is going to be ACME. And they each have slightly different approaches to the HTTP/1.1 binding. Neither of which is exactly right or wrong but standards are the process of making choices that don't matter. Having the two be the same would make it a lot simpler to build and also to manage. The reason people like JSON is that it facilitates debugging because the tools know how to format it which is less true of CBOR and not at all true for ASN.1 HTTP/2 was designed to optimize the protocol for its primary use case: Web browsing. And that was totally the right choice.But HTTP/2 is a terrible basis for Web Services, it has zero benefits unless your 'application' is essentially content retrieval and thus a subset of Web browsing. HTTP/3 is even worse because now you have multiple streams in parallel and while that can be very useful in the context of a WebService, it isn't going to work unless the application developer has given a lot of thought to the implications of concurrency within a transaction. What we need is a WebServices over QUIC protocol that provides the capabilities that are relevant to WebServices. So that instead of every application protocol describing a slightly different way to layer over HTTP/1.1, there is a common approach. As it happens, the MOQ group is producing what is likely to be the first instance of such. If we can generalize that approach into Web Services over QUIC (WSOQ), then we can think about retiring HTTP/1.1, but not until.
