61–70 of 131 posts
It is a highly accessible, highly compatible protocol, highly usable protocol.
I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information.
If letsencrypt would offer wildcard certificates with their url based authentification as they offer for non-wildcard certificates, it would be annoying but bearable.
But having to tinker with the DNS infrastructure for each project which wants to use domain wide HTTPS is so much hassle.
HTTPS is still a pain in the ass. If letsencrypt would offer wildcard certificates with their url based authentification as they offer for non-wildcard certificates, it would be annoying but bearable. But having to tinker with the DNS infrastructure for each project which wants to use domain wide HTTPS is so much hassle.
I'm still using HTTP and plan to continue for the next 25 years or so.[1] It is a highly accessible, highly compatible protocol, highly usable protocol. I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information. [1] https://en.wikipedia.org/wiki/Lindy_effect
So much of security is performance or ruining the convenience of things just for the sake of protecting things.
It's really frustrating. But hey it's to protect the kids or something /s
Earlier quoted context omitted.
Wonderful site http://n-gate.com
That one's my go-to as well. Hope the author's all right.
I'm still using HTTP and plan to continue for the next 25 years or so.[1] It is a highly accessible, highly compatible protocol, highly usable protocol. I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information. [1] https://en.wikipedia.org/wiki/Lindy_effect
Earlier quoted context omitted.
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.
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.
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...
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.
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.