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

51–60 of 131 posts

Re: RIP HTTP

#51

Post by greyface- »

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 was mine, too, until I started regularly using a (university) network where the local resolver resolved example.com to 127.0.0.1. I complained, and was told that RFC2606 gave them license to override it to anything they wanted, and that this behavior would not be changed. Doesn't square with my reading of the RFC, but complaining further wasn't going to achieve anything.

Now I use neverssl.com.

Re: RIP HTTP

#52

Post by bawolff »

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…

> 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 trying to solve don't apply.

Re: RIP HTTP

#53

Post by rgrieselhuber »

1vuio0pswjnm7 wrote: post #50
rgrieselhuber wrote: post #31

Earlier quoted context omitted.

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

This is the kind of thing I really come here for. Thanks for sharing.

Re: RIP HTTP

#55

Post by bawolff »

1vuio0pswjnm7 wrote: post #50
rgrieselhuber wrote: post #31

Earlier quoted context omitted.

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

> HTTP/2 fans will often to 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 and all pages I'm requesting come from the same host. "HOL blocking" is not a problem I have ever had

HoL blocking issues would only happen for requests to the same host anyways. That situation does not apply to resources hosted on separate hosts. The reason its not an issue for you is you are basically using http for bulk transport. You are not latency sensitive and rendering is not being blocked by multiple dependent subresources with different latency characteristics, which is the problem http/2 is trying to solve.

That's great for you and all, but its a little like saying that fancy GPU cards are pointless if you are only using emacs. Certainly true, but also kind of a stupid statement to say technology made for a very different usecase doesn't provide benefits when used in a totally different way than intended. Hammers are bad at screwing in screws is hardly a news story.

[Edit: I re-read this comment, and it was kind of a bit aggressive. Sorry about that]

Re: RIP HTTP

#56

Post by [deleted] »

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…

[deleted]

Re: RIP HTTP

#57

Post by [deleted] »

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…

[deleted]

Re: RIP HTTP

#58

Post by 1vuio0pswjnm7 »

rgrieselhuber wrote: post #53
1vuio0pswjnm7 wrote: post #50

Earlier quoted context omitted.

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

This is the kind of thing I really come here for. Thanks for sharing.

It's why I am here, too. Because there are folks who can appreciate it. Cheers.

Re: RIP HTTP

#60

Post by [deleted] »

bawolff wrote: post #55
1vuio0pswjnm7 wrote: post #50

Earlier quoted context omitted.

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

> HTTP/2 fans will often to 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 and all pages I'm requesting come from the same host. "HOL blocking" is not a problem I have ever had HoL blocking issues would only happen for requests to the same host anyways. That situation does not apply to resources hosted on separate ho…

[deleted]
Post reply on HN