TL;DR: Any encrypted transport protocol (e.g. https) breaks caching.

On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:

This could be useful for both the "I've got a slow uplink and would like
it to not be overwhelmed at the BSP I'm hosting for my Debian friends"
type as well as the "I'm an ISP and I want to provide a mirror to Debian users so we can reduce our uplink connection a bit" type of situations.

Yes, please. Another situation is: "My home houses around 10 Debian
machines, some of which are mobile."

I'm actually doing this since around 10 years.

My first implementation (predating both auto-apt-proxy and squid-deb-proxy-client) was a custom DHCP option containing a proxy.
I've locally used that with success for quite a while in my own
environments. It does have a few downsides:
* Integrating it with isc-dhcp-client was impossible in a
policy-compliant way.
* IPv4 only.
* As others have pointed out: Breaks with https.

Other commenters mentiond squid-deb-proxy-client using
_apt_proxy._tcp. via avahi.

auto-apt-proxy has a few techniques beyond that.

Unfortunately, none of them are enabled by default, so in general it
doesn't just work.

In any case, I for one would actively opt out of https, because it would
make apt unusable for me. My cache has a byte hit rate around 90% - 95%.
It seems to deliver around 4TB of .debs and stuff per year here. How
would you get that through DSL? Using https would make apt unbearably
slow for me.

Honouring _apt_proxy._tcp. by default would be cool indeed.
apt-cacher-ng automatically publishes this as does squid-deb-proxy.
However doing so would completely break if we were to go https by
default.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)