Also even if HTTPS is forced, it doesn't mean HTTP is dead. HTTP is still the protocol we are running over a TLS connection, so it's here to stay.
This already happens with some major apps.
I don't believe Alt-Svc is required, and as you say Safari is behaving this way already.
https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3
Discovering an HTTP/3 Endpoint
A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.
Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
Don't they already have hardcoded DoH?
HTTP specs are also structured this way now:
• RFC 9110 defines HTTP semantics;
• RFC 9111 defines HTTP caching behaviour;
• RFC 9112 defines HTTP/1.1;
• RFC 9113 defines HTTP/2;
• RFC 9114 defines HTTP/3.
(The previous edition, RFC 7230–7235 for HTTP and HTTP/1.1, plus RFC 7240 for HTTP/2, was really a bit of a weird structure, a regression for practical use compared to RFC 2616 which 7230–7235 obsoleted. Defining version-neutral semantics and then the 1.1, 2 and 3 wire formats is a very sensible design.)
I'm betting that HTTP outlives me and goes beyond the time period I use the www. So far, so good. HTTP/1.1 pipeliing works better than ever. The www is faster than it's ever been and I can consume more web than ever before. I am generally unable to crash the web browser I use to read HTML. All the software I'm using is generally relatively small and solid.
This is only possible because I use TCP clients, TLS proxies and a text-only browser. If I were using a popular web browser I could not make the above statements. Heck, even the supposedly most advanced browser today will choke/become unreasonably sluggish if I try to open a large HTML file, say 20M or more. Whereas I do not hesitate to open/dump 20M HTML files using the text-only browser.
Anyway, I always thought CurveCP was more impressive than HTTP/2 or HTTP/3, which both came later. It did not take a mega-sized "tech" company to create it, only one focused person. No internet advertising needed. I would be willing to bet Mike whatever or whomever at Google used CurveCP for inspiration in creating HTTP/2 and 3. Google, with its trillions of dollars and hundreds of thousands of employees, still has not come up with its own encryption that is any better than what the CurveCP author originally came up with, which is now part of QUIC and myriad other software: https://ianix.com/pub/curve25519-deployment.html
It is what it is. History.
The localhost proxy I use is configured to send all HTTP requests via TLS so the GET request for http://http.rip was sent to https://http.rip, port 443. It appears to have worked. I guess someone forgot to disable HTTPS.
The 5.1M is retrieved using a TCP client, in a shell script, not a browser, and it is saved to a single HTML file. Obviously, I want the HN pages returned in sequential order. Normally I use HTTP/1.1. pipelining for this, and most websites enable it. HN is a rare exception. I have custom utilities I wrote for HTTP/1.1. pipelining. (HTTP/2 fans will often DV comments where I praise 1.1 pipelining since "HOL blocking" is one of their "justifications" for creating HTTP/2. But I'm not using a web browser, I'm not rendering a complex, graphical web page, I'm not loading up advertising, I'm not waiting for real-time ad auctions to complete. "HOL blocking" is not a problem I have ever had because I do not use a web browser to do pipelining.)
TLS proxy listens on localhost address. Authoritative DNS on listens localhost address as well, using a custom root.zone file. DNS points to proxy address for all domains. (This "redirection" could also be accomplished by using a firewall if one is available.)
The proxy has all DNS data pre-loaded into memory. There's no DNS lookups when I access a website. The proxy knows the IP address for every domain name I am interested in.
That's a basic overview.
HoL blocking issues would only happen for requests to the same host anyways. That situation does not apply to resources hosted on separate hosts. The reason its not an issue for you is you are basically using http for bulk transport. You are not latency sensitive and rendering is not being blocked by multiple dependent subresources with different latency characteristics, which is the problem http/2 is trying to solve.
That's great for you and all, but its a little like saying that fancy GPU cards are pointless if you are only using emacs. Certainly true, but also kind of a stupid statement to say technology made for a very different usecase doesn't provide benefits when used in a totally different way than intended. Hammers are bad at screwing in screws is hardly a news story.
[Edit: I re-read this comment, and it was kind of a bit aggressive. Sorry about that]
> and a text-only browser.
So you are saying http/1.1 pipelining works great if, checks notes, your use case is a text browser that probably doesn't download all the separate assets and thus wouldn't use (or just minimally use) pipelining anyways?
So yes,i agree. Http/2 & 3 is pointless if your usecase is different enough from a normal person that all the usecases it is trying to solve don't apply.
For the first time in years.
Hearkened back to ancient days when the internet was less of a war zone.
Whether this anecdote supports or refutes your point is an exercise for the reader.
Alpine is righteous, though.
If being able to read the textual content of a website is the goal, as it is for me and in the case of a text-only browser, then generally, IME, all websites work. The ones that do not work in the text-only browser are usually ones where some JSON is fetched then parsed with Javascript. In those cases, I just fetch the JSON and tranform it into more human-readable text, if necessary. No need for an HTML reader, i.e., browser.
For example, I currently have a list of 96,339 websites that work, meaning I can read the textual content. This is composed mostly from sites submitted to HN over the past 18 months.
It does not make much sense to try to put a Javascript interpreter into a text-only browser. Some have tried and it did not prove worthwhile. There are command line utilities that are much more efficient than Javascript for requesting and parsing JSON to text.
The purpose of a text-only browser is to read text/html, not to run arbitrary code, e.g., "web apps". If a website has some particular graphical presentation, e.g., some "fucntionality" that relies on Javascript, then one does not choose a text-only browser to see it. The text-only browser makes all websites look more or less the same. It's "anti-graphical". It effectively removes most of the variations in appearance and layout across websites, which as one might guess, are usually due to graphics (e.g., fonts), graphical content (e.g., images) and Javascript.
If like Office documents with non-textmode fonts and other graphics, then why use a text-only browser. Text-only browser, by definition, does not display graphics. (I do not use links -g.) Text-only browser is for reading text/html.
If just want to download a document from some Google Docs endpoint, then this can be done with an HTTP client or a TCP client. Could use a text-mode browser for downloading documents but most times it's overkill, not "right tool for the job".
That's unlikely and risky.
Let's just face the fact here: people already tried three times to make a better HTTP protocol and still feeling unsatisfied, so certainly they'll going to make HTTP/4 and 5 etc in the future.
If all future HTTP versions must be identified via some kind of probing (say DNS or Alt-Svc), I would bet HTTP/1.1 will be kept as a baseline for compatibility. That means more versions there are, more important HTTP/1.1 will become.
Plus, to an user, what's the difference between these versions? It's not like some important web feature can only work on new HTTP protocol, but not the old ones.
Also I would not be too hasty to expect the death of any widely used protocol. You can still access gopher sites.
Yep. http/2 in browsers does not support plaintext, the same will likely be true for QUIC
>You can still access gopher sites.
Not via vanilla mainstream browsers.
This is mostly because internet middle boxes choke on plaintext http/2. Plaintext http/2 does not work for a not insignificant portion of users so browsers didn't bother to implement.
But its a thing that does exist and you can use if you really want. Just not on the public WWWW.
HTTP/1.1 has a beautiful, elegant, simplistic essence; super easy to implement servers and clients from scratch with literally no dependencies beyond string formatting and basic TCP network APIs.
Uh, HTTP 1.0 doesn't support the host header, which means that you need unique IP addresses for each host you want to serve.
Ironically, you could solve that problem with IPv6, but...
A QUIC library (or proxy) which reassembles all streams and just sends presents you the stream contents would allow you to run HTTP/1.1 over a QUIC and you have the same visbility. Just replace netcat with a hypothetical quiccat. Now obviously this would bring you not that much value for a real world deployment, since browsers and other tools don't do HTTP/1.1 over QUIC but prefer binary HTTP/3 over QUIC. But the comment about "use a tool that gives you a readable representation" still applies. You can use curl to get a readable request/response, browser dev tools. And if you need more insight, qvis (https://qvis.quictools.info) is pretty awesome.