RIP HTTP • Hacker News Board

Re: RIP HTTP

#31

Post by rgrieselhuber » Wed, May 03, 2023, 4:04 AM UTC

1vuio0pswjnm7 wrote: post #15

superkuh wrote: post #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.

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.

Re: RIP HTTP

#32

Post by appleaday1 » Wed, May 03, 2023, 4:04 AM UTC

ThrowawayTestr wrote: post #20

HTTP belonged to a simpler time, the same way in some communities you don't lock the front door.

the same time I could run email servers on the internet and not have to worry about people breaking into it :/

Re: RIP HTTP

#33

Post by totetsu » Wed, May 03, 2023, 4:06 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.

this is my go to site for triggering wifi captive portals

Re: RIP HTTP

#34

Post by Klonoar » Wed, May 03, 2023, 4:08 AM UTC

judge2020 wrote: post #26

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.

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.

Re: RIP HTTP

#35

Post by jaimex2 » Wed, May 03, 2023, 4:09 AM UTC

mekoka wrote: post #25

We apparently still need http to detect wifi portals.

There's been countless RFCs for a DHCP hook. ie https://www.rfc-editor.org/rfc/rfc8910

Re: RIP HTTP

#36

Post by kazinator » Wed, May 03, 2023, 4:10 AM UTC

There are some small embedded devices that only speak HTTP. E.g. I have a power outlet with a web interface. You can power cycle outlets through that. It speaks only HTTPS. (The current revision of the product has a better embedded system in it with a better TCP/IP stack, and supports https.)

Re: RIP HTTP

#37

Post by melvinmelih » Wed, May 03, 2023, 4:13 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.

I use http://paulgraham.com

Re: RIP HTTP

#38

Post by jaimex2 » Wed, May 03, 2023, 4:14 AM UTC

Pretty ignorant.

HTTP is alive and well. Most people don't realise a lot of software/OS updates come through HTTP so that HTTP caching servers have an opportunity to do their thing.

But but... what abouts th3 securaitai?

The updates are signed. Tamper with them all you like.

Re: RIP HTTP

#39

Post by guidoism » Wed, May 03, 2023, 4:15 AM UTC

judge2020 wrote: post #26

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.

http://captive.apple.com

Oh cool. I worked on the networking layer of the first Kindle iOS (née iPhoneOS) app and that captive portal stuff was a pain in the ass. I would just walk across the street to Tully’s and use their wifi to get that pop up.

Re: RIP HTTP

#40

Post by no_carrier » Wed, May 03, 2023, 4:18 AM UTC

Captive portals can and should have TLS enabled, even if they're internally served, there's nothing stopping you putting on a cert signed by a well known CA.

The way I handle it is I have the captive portal DNS name in public DNS returning a private address. When I order the CA cert from my cert provisioner of choice, I'm able to pass all verification checks. I'd use LetsEncrypt if I could, but good luck getting that going on a Cisco Wireless LAN Controller.