[rightbyte]

> And I only managed to load news pages, national or foreign, a few times during the hours of outage

I think this is a problem with https. I remember intermittent connectivity as way better before Google forced the issue.

And yes I like https. But it comes with drawbacks. E.g. no isp caching.

[blahaj]

I don't think ISP caching would be a thing without https. It would bring a lot of additional complexity and resource requirements for them. I can hardly imagine that being worth it to save some bandwidth. Maybe it made sense in a world where bandwidth was very limited.

Also I am very happy that it is not a thing and that ISPs cannot do that. When I go to a website I want to get the website from the webserver exactly as the server delivers it and not some other page that my ISP thinks is how the website should look.

Besides with global CDNs we have something very similar but better anyway. I don't get the site from the other side of the world but from the closest CDN server that does caching. The important difference is that the CDN server is authorized by the website to cache the page and the webmaster has control over what it does.

[cesarb]

> I don't think ISP caching would be a thing without https. It would bring a lot of additional complexity and resource requirements for them. I can hardly imagine that being worth it to save some bandwidth. Maybe it made sense in a world where bandwidth was very limited.

Transparent squid proxies were common back when most sites were on http. They let ISPs reduce the use of their limited upstream bandwidth, while also making sites load faster. The complexity and resource requirements were modest: install squid on a server, and configure the router to redirect (masquerade) all outgoing TCP port 80 connections to the port configured for squid on that server.

[blahaj]

The internet is much bigger, more diverse and complex today. You need a lot of storage to get any meaningful impact. Caching the http of Wikipedia won't get you much. You need to cache lots of YouTube videos. Or you just get them from the data center you peer with over the fat link you built.

With bandwidth usage the diversity of the data retrived over the internet has also gone up. You can't just cache the few most popular websites and save most bandwidth. But bandwidth capacity has scaled a lot so you probably also do not need to.

[rightbyte]

> When I go to a website I want to get the website from the webserver exactly as the server delivers it and not some other page that my ISP thinks is how the website should look.

You could have some hash check to prevent hijacking. The old method would be naive today.

There would be some privacy concerns I guess. But it could be opt-in on the site owners part. I think caching some videos and pictures would save a lot of power.

> Besides with global CDNs we have something very similar but better anyway.

Sure but they are some switches away.

[blahaj]

> You could have some hash check to prevent hijacking. The old method would be naive today.

But how do you know that the cached site is up to date? How does the ISP know that? What about dynamic content? What about consistency between different requests that are part of the same page load?

> Sure but they are some switches away.

My point is that this does not matter much. Usually, at least in non sparsely populated parts of the world with modern infrastructure, these switches are close and there is lots of bandwidth capacity.

I just don't think it makes sense for ISPs to save bandwidth on these links by building their own local data centers when they peer with a CDN data center anyway.

[rightbyte]

The root html would govern what caches are up to date with the hash for some non-dynamic payloads and the root html would not be cached. Etc.

It would be interesting to know how much bandwidth would be saved by caching X gb of the most downloaded films, pictures and textfiles at a neighbourhood level.

In the 90s early 00s I think the share was way bigger than it would be now.