The caching feature is implemented by Apt-Cacher-NG, but the proxy only works sporadically. Squid seems to be a better choice. The remapping feature, for what I try to find a solution in Squid, is e.g. described at https://blog.packagecloud.io/using-apt-cacher-ng-with-ssl-tls/ in section "Caching objects.
>-----Ursprüngliche Nachricht----- >Von: squid-users <squid-users-boun...@lists.squid-cache.org> Im Auftrag von >Fiehe, >Christoph >Gesendet: Mittwoch, 10. Juli 2024 22:58 >An: squid-users@lists.squid-cache.org >Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy > >No problem. I am just trying to find something that helps to narrow down the >problem. What >I want to achieve is, that a client can use HTTP in the LAN, so that Squid can >cache >distribution packages without making use of SSL intercepting when repos are >only >accessible via HTTPS. In that case the secure connection must start at the >proxy and end >on the target server with or without any upstream proxies in betweem. When the >proxy has >received the payload, it can cache it and send it back to the client via plain >HTTP. When >a new request for this package arrives, the server can just return the >resource from the >cache. > >We have the following setup: > >client -> downstream proxy -> upstream proxy -> https://download.docker.com > >Now let us assume the client wants to retrieve the following resource >http://download.docker.com/linux/ubuntu/dists/jammy/InRelease from the >upstream proxy. > >The client initiates a HTTP GET request and sends it to the downstream proxy. >Now, the URL >gets rewritten. It indicates to use a HTTPS connection instead in order to >talk to the >target server, in our case the result is >https://download.docker.com/linux/ubuntu/dists/jammy/InRelease. Now comes the >critical >point: From my understanding – it may be wrong of course - the downstream >server now has >to send a CONNECT request to the upstream server to advise him to establish a >secure >connection to the target server. After creation, the downstream proxy can >retrieve the >resource and send it back to the client via plain HTTP. > >I suppose, that the GnuTLS occurs because of a missing SSL handshake between >downstream >proxy and download.docker.com. > >Do I get something wrong? > >Regards, >Christoph > > >>-----Ursprüngliche Nachricht----- >>Von: Alex Rousskov <rouss...@measurement-factory.com> >>Gesendet: Mittwoch, 10. Juli 2024 22:15 >>An: squid-users@lists.squid-cache.org >>Cc: Fiehe, Christoph <c.fi...@eurodata.de> >>Betreff: AW: [squid-users] Rewriting HTTP to HTTPS for generic package proxy >> >>On 2024-07-10 15:31, Fiehe, Christoph wrote: >>> The problem is that the proxy just forwards the client GET request to the >>> upstream >proxy >> >>Why does sending a GET request to the upstream proxy represent a problem >>in your use case? I cannot find anything in your prior messages on this >>thread that would preclude sending a GET request to the upstream proxy. >> >> >>> but in that case a CONNECT is required. >> >>Why? >> >>Please do not interpret my response as implying that this "must send >>CONNECT" requirement is wrong (or correct). At this point, I am just >>trying to understand what problem(s) you are trying to solve beyond the >>one you have originally described. >> >> >>Thank you, >> >>Alex. > >_______________________________________________ >squid-users mailing list >squid-users@lists.squid-cache.org >https://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
