5 ms·

The real death of HTTP isn't that HTTPS is being forced. That's good and bad but at least you can chose and it's HTTP underneath. The death of HTTP is "HTTP"/3

The real death of HTTP isn't that HTTPS is being forced. That's good and bad but at least you can chose and it's HTTP underneath. The death of HTTP is "HTTP"/3 which is barely related to past HTTP protocols and doesn't even allow a choice. Eventually the megacorp browsers will drop real HTTP/1.1 support from their browsers for QUIC based transport. That will be the death of HTTP.

kortex 4y ago
What do you mean by "doesn't even allow a choice?" Like there's no option for non-secure? Also I would not be too hasty to expect the death of any widely used protocol. You can still access gopher sites.
- Spivak 4y ago
  Correct, TLS is built into the protocol itself instead of it being HTTP wrapped in a TLS stream.
- beardog 4y ago
  > What do you mean by "doesn't even allow a choice?" Like there's no option for non-secure? 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.
  - Gigachad 4y ago
    Presumably the non secure equivalent for internal services will just be a self signed cert. So you don't lose any existing capabilities.
  - bawolff 4y ago
    > Yep. http/2 in browsers does not support plaintext, the same will likely be true for QUIC 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.
koromak 4y ago
Not educated on this, but whats the problem with it?
- metadat 4y ago
  With HTTP/1.1 you can debug a request via an ASCII telnet session. Not feasible with QUIC. 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.
  - judge2020 4y ago
    Given most sites still support HTTP/1.0, it's very unlikely we'll see anyone drop http/1.1 for another three decades, at least. Especially when you factor in how slow some large chunks of the world are to upgrade their OSes and software suites.
    - henrikschroder 4y ago
      > Given most sites still support HTTP/1.0 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...
  - Matthias247 4y ago
    You can debug it because the telnet tool and the kernels TCP stack reassemble a lot of binary TCP and IP frames for you. If they wouldn't, you would have a much harder time looking at it. 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 https://qvis.quictools.info) is pretty awesome.
1vuio0pswjnm7 4y ago
What's interesting about this doomsday scenario is it suggests that a few web browsers dictate the course of the www, not several billion websites. 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 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 http://http.rip was sent to https://http.rip https://http.rip, port 443. It appears to have worked. I guess someone forgot to disable HTTPS.
- rgrieselhuber 4y ago
  Would you mind sharing details on your tools / setup? Intrigued by this.
  - 1vuio0pswjnm7 4y ago
    Here is an example. I often read HN as a single web page. Today this is about 5.1M for me and there are about 2945 items. In the text-only browser, opening this file works smoothly enough. Whereas if I try opening this 5.1M file in a popular browser, for me, it's sluggish and janky. NB. This is _not_ the sole reason I avoid using a popular browser. It's just an observation. I have been using text-only browsers (not lynx or w3m) for over 20 years and I will keep using them until I am dead. 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.
Matthias247 4y ago
HTTP/3-only will not be a thing in the foreseeable future. One major reason is that clients actually need knowledge that a website supports HTTP/3. And how do they obtain that knowledge? It's over a HTTP/1.1 or HTTP/2 request which returns the Alt-Svc: h3 header. It will probably take decades until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported - and only after that websites can drop HTTP/x over TLS support. HTTP/3 is also just 50% as CPU efficient as TCP based HTTP versions, so using it doesn't make sense for every use-case. 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.
- EwanToo 4y ago
  Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker. This already happens with some major apps.
  - Matthias247 4y ago
    Some might indeed do. According to my knowledge from testing 1 year ago it's mostly Safari that is doing this. Other browsers follow the specification and require Alt-Svc information.
    - EwanToo 4y ago
      I'm not sure the specification says what you describe, it doesn't in my reading. 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 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.
chrismorgan 4y ago
HTTP/3 is absolutely related to past HTTP protocols: it’s built upon HTTP semantics. 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.)
kevin_thibedeau 4y ago
1.1 will survive due to low resource IoT devices where the extra burden of caching state is too much of an imposition.
nirui 4y ago
> Eventually the megacorp browsers will drop real HTTP/1.1 support from their browsers for QUIC based transport 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.

kortex 4y ago

What do you mean by "doesn't even allow a choice?" Like there's no option for non-secure? Also I would not be too hasty to expect the death of any widely used protocol. You can still access gopher sites.

Spivak 4y ago
Correct, TLS is built into the protocol itself instead of it being HTTP wrapped in a TLS stream.
beardog 4y ago
> What do you mean by "doesn't even allow a choice?" Like there's no option for non-secure? 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.
- Gigachad 4y ago
  Presumably the non secure equivalent for internal services will just be a self signed cert. So you don't lose any existing capabilities.
- bawolff 4y ago
  > Yep. http/2 in browsers does not support plaintext, the same will likely be true for QUIC 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.

koromak 4y ago

Not educated on this, but whats the problem with it?

metadat 4y ago
With HTTP/1.1 you can debug a request via an ASCII telnet session. Not feasible with QUIC. 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.
- judge2020 4y ago
  Given most sites still support HTTP/1.0, it's very unlikely we'll see anyone drop http/1.1 for another three decades, at least. Especially when you factor in how slow some large chunks of the world are to upgrade their OSes and software suites.
  - henrikschroder 4y ago
    > Given most sites still support HTTP/1.0 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...
- Matthias247 4y ago
  You can debug it because the telnet tool and the kernels TCP stack reassemble a lot of binary TCP and IP frames for you. If they wouldn't, you would have a much harder time looking at it. 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 https://qvis.quictools.info) is pretty awesome.

1vuio0pswjnm7 4y ago

What's interesting about this doomsday scenario is it suggests that a few web browsers dictate the course of the www, not several billion websites. 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 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 http://http.rip was sent to https://http.rip https://http.rip, port 443. It appears to have worked. I guess someone forgot to disable HTTPS.

rgrieselhuber 4y ago
Would you mind sharing details on your tools / setup? Intrigued by this.
- 1vuio0pswjnm7 4y ago
  Here is an example. I often read HN as a single web page. Today this is about 5.1M for me and there are about 2945 items. In the text-only browser, opening this file works smoothly enough. Whereas if I try opening this 5.1M file in a popular browser, for me, it's sluggish and janky. NB. This is _not_ the sole reason I avoid using a popular browser. It's just an observation. I have been using text-only browsers (not lynx or w3m) for over 20 years and I will keep using them until I am dead. 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.

Matthias247 4y ago

HTTP/3-only will not be a thing in the foreseeable future. One major reason is that clients actually need knowledge that a website supports HTTP/3. And how do they obtain that knowledge? It's over a HTTP/1.1 or HTTP/2 request which returns the Alt-Svc: h3 header. It will probably take decades until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported - and only after that websites can drop HTTP/x over TLS support. HTTP/3 is also just 50% as CPU efficient as TCP based HTTP versions, so using it doesn't make sense for every use-case. 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.

EwanToo 4y ago
Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker. This already happens with some major apps.
- Matthias247 4y ago
  Some might indeed do. According to my knowledge from testing 1 year ago it's mostly Safari that is doing this. Other browsers follow the specification and require Alt-Svc information.
  - EwanToo 4y ago
    I'm not sure the specification says what you describe, it doesn't in my reading. 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 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.

chrismorgan 4y ago

HTTP/3 is absolutely related to past HTTP protocols: it’s built upon HTTP semantics. 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.)

kevin_thibedeau 4y ago

1.1 will survive due to low resource IoT devices where the extra burden of caching state is too much of an imposition.

nirui 4y ago

> Eventually the megacorp browsers will drop real HTTP/1.1 support from their browsers for QUIC based transport 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.