"Upstream HTTP/1.1 is inherently insecure and consistently exposes millions of websites to hostile takeover." Perhaps the word "upstream" is significant Not a

"Upstream HTTP/1.1 is inherently insecure and consistently exposes millions of websites to hostile takeover." Perhaps the word "upstream" is significant Not all proxies, i.e., authors of proxies, are created equal Some might be incorrect This may be the fault of the proxy authors, not the fault of the protocol designer^1 This blog post makes a claim that HTTP/1.1 only "power[s] a third of the web" I have rarely found a website that will not accept HTTP/1.1 https://http1mustdie.com https://http1mustdie.com accepts HTTP/1.0 and 1.1 I have used HTTP/1.1 pipelining outside the browser for 17 years^2 It works beautifully for me outside the browser Today I use 1.1 pipelining literally every day. Almost all websites I encounter still support and enable it Would love to see some examples of sites that do not accept HTTP/1.1 amd only accept HTTP/[23] 1. Unlike the designers of HTTP/1.1, the designers of HTTP/2 have made mistakes, bad enough to warrant an immediate replacement "This head-of-line blocking in HTTP/2 is now widely regarded as a design flaw, and much of the effort behind QUIC and HTTP/3 has been devoted to reduce head-of-line blocking issues.^[58]^[59]" 58. ^ Huston, Geoff (March 4, 2019). "A Quick Look at QUIC". www.circleid.com. Retrieved August 2, 2019. 59. ^ Gal, Shauli (June 22, 2017). "The Full Picture on HTTP/2 and HOL Blocking". Medium. Retrieved August 3, 2019. This is interesting to me since this is allegedly the "problem" with HTTP/1.1 (cf. problem with advertising-sponsored web browsers) that HTTP/2 was supposed to "solve"^3 2. To retrieve multiple resources from same host in a single TCP connections. (Unlike browsers that routinely open up dozens of TCP connections to multiple hosts, usually for telemetry/advertising/tracking purposes.) It is desirable for me to receive the responses in the same order the requests were sent. As such, "HOL" is a on-issue for me. 3. See "Introduction" https://www.ietf.org/rfc/rfc7540.txt https://www.ietf.org/rfc/rfc7540.txt HTTP/3 reminds me of CurveCP that was published years before QUIC^4 Except the HTTP/3 RFC is written by Akamai employee whereas CurveCP is from an academic, like HTTP/1.1 Also CurveCP needs no "SNI" that leaks domain names in plaintext like TLS and hence needs no complicated Band-Aid like ECH. Still waiting for ECH to be available outside of maybe a limited percentage of sites on a single CDN (Cloudflare)^5 It has been years 4. https://curvecp.org/addressing.html https://curvecp.org/addressing.html 5. https://test.defo.ie https://test.defo.ie