On 30/09/2016 8:10 p.m., Michael Varun wrote: > Here is the snippet of debug logs > I dont get to see anything missing out there . It does a GET call to the > docker registry on behalf of the requesting client The registry listens on > 443 so squid mimicks client TLS connections post which does a GET call to > the docker registry on the requested blobs Well firstly, going by your earlier config file the client is *not* performing TLS connections. Your proxy is configured to receive plain-text HTTP at port 443. You seem to have stumbled onto two bugs in Squid which are combining to be problematic. There is a bug in the SSL-Bump implementation we have not sorted out yet, which makes the "ssl-bump" on this port enable reverse-proxy mode handling. That seems to be leading to Surrogate feature being enabled and the Authorization:Bearer being removed when it should be relayed to the server. The existence of Authorization header on the request combined with lack of Cache-Control:public on the response means these reponses are private responses associated with that auth credentials token. They cannot be cached and given to anyone else. That brings up what I think may be a second bug. Since the request to the server was sent without Auth header then Squid should be considering it a non-auth response and treating it as cacheable anyway. But probably is just using the client request for that decision. You could try adding the "login=PASSTHRU" option to your cache_peer line. If the server sends "Cache-Control:public" that should enable caching. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
