lucaspardue
There is a draft [1] that would support Alt-Svc in DNS. Lots to consider there but it is being presented to IETF.
[1] - https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc...
The client uses its local knowledge (and maybe other heuristics) to decide if it wants to change protocols.
The gain of moving to binary was the ability to multiplex multiple requests is a single TCP connection. It also fixes a whole class of error around request and response handling - see the recent request smuggling coverage from Blackhat [1].
HTTP/2 isn't perfect but I dont buy that HTTP/1.1 is the ideal simple protocol. There are a ton of issues with its practical usage and implementation.
We live in complex times and the threat models are constantly advancing. Addressing those requires protocols that by their nature end up more complex. The "simple" protocols of the past weren't designed under the same threat models.
[1] https://portswigger.net/blog/http-desync-attacks-request-smu...
HTTP/2's binary syntax addresses some of those edge cases mainly through better-formed header fields and a common chunking of body data.
SCTP is undeployable on the Internet. HTTP/2 is deployed on the Internet. It brings multiplexing and of course that brings some additional complexity and constraints. But these have proven more deployable than HTTP/1.x-style solutions such a pipe lining.
HTTP/3 is actually a simpler application mapping than HTTP/2. This is due to the complexity getting pulled into the transport. But it's a zero sum game, just moving the concerns around doesn't mean they are automatically fixed.
Even if the proxy does cache locally to memory or disk. Without infinite space, there will be some chance of cache eviction and a need to fetch from the upstream again.
Our scenarios are different ends of a broad spectrum, and there's a lot in between. Which is why getting prioritisation right is a hard nut to crack.
However, the primary axiom is of a web server that is serving static content that is located on the device. That, in a sense, gives almost infinite time and knowledge to deciding prioritisation of work.
For HTTP proxies that have to fetch resources from some other server, the time and knowledge window becomes much shorter. Decision making needs to be done quickly in order to minimise the latency of returning anything. And the upstream server may response in unexpected ways.
This is the challenge for today's CDN deployments. And developing a solution that works for the huge variety of how websites are developed is the really interesting bit.
It is feasible for a similar mechanism for also work for HTTP/3, just no-one has gone to the effort yet.
QUIC TCPUnfortuantely, this means that a HTTP/3 client has to tunnel HTTP/1.1 or HTTP/2 to the target server. I realised this was a shortcoming last year and prepared an I-D called HiNT that explores the problem space and some candidate solutions:
https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-n...
This was presented, along with some nicer tunnel diagrams, at the IETF 102 meeting. Slides in pdf: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102...