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

71–80 of 131 posts

Re: RIP HTTP

#71

Post by Matthias247 »

metadat wrote: post #14
koromak wrote: post #12

Earlier quoted context omitted.

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

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. 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) is pretty awesome.

Re: RIP HTTP

#72

Post by Matthias247 »

notfed wrote: post #30

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

Very true. Actually HTTP now also just refers to the semantics. HTTP/2 and HTTP/3 are still HTTP. They all support requests, responses, verbs, status codes, headers, caching semantics, etc.

The only thing that might become less common is "HTTP/1.1 over TCP". But I get that this is much more verbose to write than "RIP HTTP".

Re: RIP HTTP

#73

Post by josefx »

zamnos wrote: post #68
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

ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack, but I'm more curious: Which barriers with HTTPS are you referring to?

With how most of the internet already looks like without adblocker the difference would probably be impossible to even notice.

Edit: Also around half the pages I currently have open are passing through cloudflare anyway and signed by them, so a third party hijacking the connection to throw in ads is just one business minded CEO away.

Re: RIP HTTP

#74

Post by omoikane »

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.

Another plug for http://gfblip.appspot.com/

I guess any site that doesn't auto-upgrade would work, but I have a habit of typing out http:// for this site in particular because it doesn't work over https.

Re: RIP HTTP

#76

Post by chrismorgan »

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

Re: RIP HTTP

#77

Post by chrismorgan »

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.

example.com hasn’t been HTTP-only for quite some years now. It may still serve the page over HTTP rather than issuing a redirect to HTTPS, but that ain’t HTTP-only. Nor is there any guarantee of them retaining this deviation from accepted best practice.

Re: RIP HTTP

#79

Post by chrismorgan »

lolinder wrote: post #24
password4321 wrote: post #13

Earlier quoted context omitted.

Not anymore? (This discussion is pretty much a dupe.) https://news.ycombinator.com/item?id=35789730

See the top reply to that comment: > They're trying to solve the "how do log into this captive portal" problem, and they needed to make this change to handle that typing "neverssl.com" now often evaluates to " https://neverssl.com ". So, yes, it's still useful for WiFi logins. The change in question was specifically for that purpose. https://neverssl.com now redirects to http://neverssl.com so you can log in to WiFi…

Except it actually makes the handling of that case worse, quite apart from making a lie of the name and content of the site.

Re: RIP HTTP

#80

Post by chrismorgan »

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.

HTTPS is not just about tamper protection, but also about confidentiality. Do you want an attacker to be able to identify exactly which packages and which versions of packages you have installed?

(Mind you, you’ll often be able to do a good job of guessing based on the side-channel leak of how much data is transferred.)

See also: pervasive monitoring is an attack https://www.rfc-editor.org/rfc/rfc7258.html>.

I would expect all major operating systems to deliver their updates over HTTPS these days.

(I know Arch Linux’s mirrors are widely available over HTTP and HTTPS, but the first mirror in the list is HTTPS, so the considerable majority of users will get packages over HTTPS—though since the second is HTTP, all it takes is DNS-blocking geo.mirror.pkgbuild.com to cause it to fetch over HTTP.)

As for “so that HTTP caching servers have an opportunity to do their thing”: how much do public intermediaries do caching any more? I don’t know how popular that kind of thing ever was, though I know it did happen sometimes, but with how uncommon plain-text HTTP is now, I’d honestly expect most vendors to just drop that functionality as almost-unused complexity.

Post reply on HN