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

121–130 of 131 posts

Re: RIP HTTP

#121

Post by JonathanBeuys »

bawolff wrote: post #84
JonathanBeuys wrote: post #82

Earlier quoted context omitted.

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.

Which users have access to put files into .well-known/ of the root domain?

I am not aware of any service that allows that.

Can you give an example? What do you mean by "lots of people"?

Re: RIP HTTP

#122

Post by brokenmachine »

prepend wrote: post #109
greyface- wrote: post #51

Earlier quoted context omitted.

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.

I don’t miss the seemingly arbitrary restrictions from university IT admins. A university I attended blocked all BitTorrent traffic at the protocol level. They theoretically allowed exceptions per their policy but when I applied for some bioinformatics images to be allowed they said they would only allow specific files for a 24 hour window. I applied for a file and got no response. I applied for 1000 files and got no…

>Then I gave up.

I'm surprised you didn't set up your own system to work around the stupid restrictions.

Re: RIP HTTP

#123

Post by brokenmachine »

nrabulinski wrote: post #78

I always just open the router IP and the captive page shows up I never even thought of opening a http website

How do you know the router IP when you're on a phone? I know you can dive into network settings, but seems like a hassle.

Re: RIP HTTP

#124

Post by smitty1e »

hdjjhhvvhga wrote: post #93
smitty1e wrote: post #81

Earlier quoted context omitted.

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.

Unfortunately lynx, links and and w3m will only work on a subset of websites.

Crying shame, that.

Re: RIP HTTP

#125

Post by 1vuio0pswjnm7 »

hdjjhhvvhga wrote: post #93
smitty1e wrote: post #81

Earlier quoted context omitted.

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.

Unfortunately lynx, links and and w3m will only work on a subset of websites.

Can you provide some examples of websites that do not "work". I really want to know.

If being able to read the textual content of a website is the goal, as it is for me and in the case of a text-only browser, then generally, IME, all websites work. The ones that do not work in the text-only browser are usually ones where some JSON is fetched then parsed with Javascript. In those cases, I just fetch the JSON and tranform it into more human-readable text, if necessary. No need for an HTML reader, i.e., browser.

For example, I currently have a list of 96,339 websites that work, meaning I can read the textual content. This is composed mostly from sites submitted to HN over the past 18 months.

It does not make much sense to try to put a Javascript interpreter into a text-only browser. Some have tried and it did not prove worthwhile. There are command line utilities that are much more efficient than Javascript for requesting and parsing JSON to text.

The purpose of a text-only browser is to read text/html, not to run arbitrary code, e.g., "web apps". If a website has some particular graphical presentation, e.g., some "fucntionality" that relies on Javascript, then one does not choose a text-only browser to see it. The text-only browser makes all websites look more or less the same. It's "anti-graphical". It effectively removes most of the variations in appearance and layout across websites, which as one might guess, are usually due to graphics (e.g., fonts), graphical content (e.g., images) and Javascript.

Re: RIP HTTP

#126

Post by GoblinSlayer »

Matthias247 wrote: post #118
GoblinSlayer wrote: post #113

Earlier quoted context omitted.

>until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported Don't they already have hardcoded DoH?

DNS over HTTP is something different than Service Discovery over HTTP ( https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... ). The latter is plain DNS, but allows to transfer alternate service responses as part of the DNS response packet. As you can see from the link, it's still in a draft state.

If they have their own DoH, it can send them any response format. http3 drafts are supported in the wild too.

Re: RIP HTTP

#127

Post by smitty1e »

1vuio0pswjnm7 wrote: post #125
hdjjhhvvhga wrote: post #93

Earlier quoted context omitted.

Unfortunately lynx, links and and w3m will only work on a subset of websites.

Can you provide some examples of websites that do not "work". I really want to know. If being able to read the textual content of a website is the goal, as it is for me and in the case of a text-only browser, then generally, IME, all websites work. The ones that do not work in the text-only browser are usually ones where some JSON is fetched then parsed with Javascript. In those cases, I just fetch the JSON and tranf…

I would expect Google Docs to fare poorly in text mode.

Re: RIP HTTP

#128

Post by [deleted] »

smitty1e wrote: post #127
1vuio0pswjnm7 wrote: post #125

Earlier quoted context omitted.

Can you provide some examples of websites that do not "work". I really want to know. If being able to read the textual content of a website is the goal, as it is for me and in the case of a text-only browser, then generally, IME, all websites work. The ones that do not work in the text-only browser are usually ones where some JSON is fetched then parsed with Javascript. In those cases, I just fetch the JSON and tranf…

I would expect Google Docs to fare poorly in text mode.

[deleted]

Re: RIP HTTP

#129

Post by 1vuio0pswjnm7 »

smitty1e wrote: post #127
1vuio0pswjnm7 wrote: post #125

Earlier quoted context omitted.

Can you provide some examples of websites that do not "work". I really want to know. If being able to read the textual content of a website is the goal, as it is for me and in the case of a text-only browser, then generally, IME, all websites work. The ones that do not work in the text-only browser are usually ones where some JSON is fetched then parsed with Javascript. In those cases, I just fetch the JSON and tranf…

I would expect Google Docs to fare poorly in text mode.

Yep, graphics do not work. That's why it's called a "text-only browser".

If like Office documents with non-textmode fonts and other graphics, then why use a text-only browser. Text-only browser, by definition, does not display graphics. (I do not use links -g.) Text-only browser is for reading text/html.

If just want to download a document from some Google Docs endpoint, then this can be done with an HTTP client or a TCP client. Could use a text-mode browser for downloading documents but most times it's overkill, not "right tool for the job".

Re: RIP HTTP

#130

Post by beej71 »

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

Yikes. We use example.com all the time in my intro to network programming class. HTTPS would get in the way of learning the basics, so I'm glad there are some HTTP options out there still.

(Yeah, they could just run a local one-liner web server, but that's not as fun.)

Post reply on HN