Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RIP HTTP

http.rip

Post reply on HN
Print view View original

81–90 of 131 posts

Re: RIP HTTP

#81

Post by smitty1e »

bawolff wrote: post #52
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…

> HTTP/1.1 pipeliing works better than ever > 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 tr…

I just installed lynx the other day in an Alpine guest machine to pull down some source code.

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.

Re: RIP HTTP

#82

Post by JonathanBeuys »

JodieBenitez wrote: post #64
JonathanBeuys wrote: post #63

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've been using Caddy for personal projects and I don't even think about HTTPS anymore. Except when I have to use another web server at work :-/

That is fine for simple projects where all you have to do is automate cert updates for the root domain or a few subdomains. The problem is not to automate this process. It's easy to write a shellscript that regularly updates certs for a root domain or some subdomains.

The problem is that letsencrypt does not offer url based authentification for wildcard certs.

So you have to temper with your DNS infrastructure so that you can automate DNS updates for your domain.

Re: RIP HTTP

#83

Post by bawolff »

forgotmypw17 wrote: post #61

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

> I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information.

That's not the only attack TLS is trying to thwart (although it is a major one). Passive surveillance resistance is also a big use case of TLS.

I think the biggest thing though, is everyone has pages that are sensitive some of the time (e.g., I want to visit my bank over TLS). It is really really difficult UI problem to give people actual security when TLS is only on some of the time. Users never really understand how the security stuff works, and it is usually trivial to trick them unless you basically do forced TLS everywhere. Its also hard to know what is sensitive to users as it varies by place (e.g. Tianamin square article on wikipedia. Maybe in other places, websites about abortion, etc. Some places nobody cares if you look that up. In other places it is a big deal. Difficult to make things secure only for the users where it matters.)

Re: RIP HTTP

#84

Post by bawolff »

JonathanBeuys wrote: post #82
JodieBenitez wrote: post #64

Earlier quoted context omitted.

I've been using Caddy for personal projects and I don't even think about HTTPS anymore. Except when I have to use another web server at work :-/

That is fine for simple projects where all you have to do is automate cert updates for the root domain or a few subdomains. The problem is not to automate this process. It's easy to write a shellscript that regularly updates certs for a root domain or some subdomains. The problem is that letsencrypt does not offer url based authentification for wildcard certs. So you have to temper with your DNS infrastructure so tha…

> The problem is that letsencrypt does not offer url based authentification for wildcard certs.

For good reason though. You shouldn't be able to get a cert for a domain you cannot prove you control. Lots of people have webserver access to a specific domain but not all subdomains.

Re: RIP HTTP

#85

Post by bawolff »

jaimex2 wrote: post #38

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.

You mean like - https://justi.cz/security/2019/01/22/apt-rce.html?

tbf, I'm being a bit hyperbolic. Its totally reasonable to have security at different layers. One good thing about HTTPS though is it is a very well tested layer. Crypto is such an easy thing to screw up, even when doing just basic stuff.

Re: RIP HTTP

#86

Post by kevin_thibedeau »

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.

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

Re: RIP HTTP

#87

Post by EwanToo »

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

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 o…

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.

Re: RIP HTTP

#88

Post by citrin_ru »

Matthias247 wrote: post #71
metadat wrote: post #14

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.

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

You can effectively debug unencrypted HTTP using tcpdump, no reassembly usually required because a request with headers and a response headers fit one IP packet. If they don’t, someone uses way too big headers (or too many).

Re: RIP HTTP

#89

Post by Matthias247 »

EwanToo wrote: post #87
Matthias247 wrote: post #70

Earlier quoted context omitted.

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 o…

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.

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.

Re: RIP HTTP

#90

Post by nirui »

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.

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

Post reply on HN