[squid-users] Caching application/octet-stream

[Amos Jeffries]

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