<div dir="ltr"><pre>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.<br><br><br></pre><pre>Can you refer to the BUD ID if there is one already opened  if not should i submit one for reference ?<br></pre></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 30, 2016 at 1:06 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 30/09/2016 8:10 p.m., Michael Varun wrote:<br>
> Here is the snippet of debug logs<br>
> I dont get to see anything missing out there . It does a GET call to the<br>
> docker registry on behalf of the requesting client The registry listens on<br>
> 443 so squid mimicks  client TLS connections post which does a GET call to<br>
> the docker registry on the requested blobs<br>
<br>
</span>Well firstly, going by your earlier config file the client is *not*<br>
performing TLS connections. Your proxy is configured to receive<br>
plain-text HTTP at port 443.<br>
<br>
You seem to have stumbled onto two bugs in Squid which are combining to<br>
be problematic.<br>
<br>
There is a bug in the SSL-Bump implementation we have not sorted out<br>
yet, which makes the "ssl-bump" on this port enable reverse-proxy mode<br>
handling. That seems to be leading to Surrogate feature being enabled<br>
and the Authorization:Bearer being removed when it should be relayed to<br>
the server.<br>
<br>
The existence of Authorization header on the request combined with lack<br>
of Cache-Control:public on the response means these reponses are private<br>
responses associated with that auth credentials token. They cannot be<br>
cached and given to anyone else.<br>
<br>
That brings up what I think may be a second bug. Since the request to<br>
the server was sent without Auth header then Squid should be considering<br>
it a non-auth response and treating it as cacheable anyway. But probably<br>
is just using the client request for that decision.<br>
<br>
<br>
You could try adding the "login=PASSTHRU" option to your cache_peer<br>
line. If the server sends "Cache-Control:public" that should enable caching.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div>

<br>
<div><span style="font-family:Arial;background-color:white">______________________________<WBR>______________________________<WBR>_</span></div><span style="font-family:Arial;background-color:white"><font color="#808080">The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.</font></span>