RIP HTTP • Hacker News Board

Re: RIP HTTP

#41

Post by Gigachad » Wed, May 03, 2023, 4:19 AM UTC

beardog wrote: post #18

kortex wrote: post #9

Earlier quoted context omitted.

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.

> 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.

Presumably the non secure equivalent for internal services will just be a self signed cert. So you don't lose any existing capabilities.

Re: RIP HTTP

#42

Post by below43 » Wed, May 03, 2023, 4:19 AM UTC

teh_klev wrote: post #6

Not that I make a habit of correcting other's spelling and grammar, however: ocassionally -> occasionally

Glad I'm not the only one that noticed!

Re: RIP HTTP

#43

Post by coolandsmartrr » Wed, May 03, 2023, 4:20 AM UTC

pedropaulovc wrote: post #19

My go-to HTTP-only endpoint is http://example.com . It should be usable for as long as IANA and the Internet as we know it exists.

My go-to used to be http://ihave50dollars.com. After it closed down, http://captive.apple.com became my new go-to.

Re: RIP HTTP

#44

Post by rjh29 » Wed, May 03, 2023, 4:22 AM UTC

Klonoar wrote: post #34

judge2020 wrote: post #26

Earlier quoted context omitted.

http://captive.apple.com

Interestingly enough this doesn't work for me on certain public wifi networks. I often have to go to a different HTTP-only URL, it's weird.

I've also had situations where _only_ neverssl.com wouldn't load but other http sites would switch to https with an invalid cert error. It's really weird.

Re: RIP HTTP

#45

Post by Gigachad » Wed, May 03, 2023, 4:23 AM UTC

notfed wrote: post #30

Seems a little dramatic... HTTP isn't going anywhere. HTTPS is literally just HTTP with a TLS layer on top.

HTTP/3 does not include capability for non-encrypted connections.

Re: RIP HTTP

#46

Post by [deleted] » Wed, May 03, 2023, 4:25 AM UTC

[deleted]

Re: RIP HTTP

#47

Post by [deleted] » Wed, May 03, 2023, 4:26 AM UTC

pedropaulovc wrote: post #19

My go-to HTTP-only endpoint is http://example.com . It should be usable for as long as IANA and the Internet as we know it exists.

[deleted]

Re: RIP HTTP

#48

Post by techaqua » Wed, May 03, 2023, 4:27 AM UTC

my isp used to inject ads to http sites

Re: RIP HTTP

#49

Post by bawolff » Wed, May 03, 2023, 4:41 AM UTC

beardog wrote: post #18

kortex wrote: post #9

Earlier quoted context omitted.

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.

> 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.

> 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.

Re: RIP HTTP

#50

Post by 1vuio0pswjnm7 » Wed, May 03, 2023, 4:42 AM UTC

rgrieselhuber wrote: post #31

1vuio0pswjnm7 wrote: post #15

Earlier quoted context omitted.

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…

Would you mind sharing details on your tools / setup? Intrigued by this.

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.