<div dir="ltr">Hi,<div><br></div><div>Resuming the above conversation; When looking at the cache log and the code, I find that when peek is done at step 1 and then bumped, the connection gets pinned after <i style="font-family:verdana,sans-serif">httpsPeeked() </i><font face="arial, helvetica, sans-serif">is called</font>. </div><div><br></div><div>Log:</div><div><br></div><div><div><i><font face="verdana, sans-serif">2018/07/23 11:40:29.572 kid1| 17,4| AsyncCallQueue.cc(55) fireNext: entering ConnStateData::ConnStateData::<span style="background-color:rgb(255,255,0)">httpsPeeked</span>(local=<a href="http://4.16.205.42:33596">4.16.205.42:33596</a> remote=<a href="http://96.43.144.26:443">96.43.144.26:443</a> FD 15 flags=1, request=0x559f3b1a6ed0*5)</font></i></div><div><i><font face="verdana, sans-serif"> 40056 2018/07/23 11:40:29.572 kid1| 17,4| AsyncCall.cc(38) make: make call ConnStateData::ConnStateData::<span style="background-color:rgb(255,255,0)">httpsPeeked</span> [call261]</font></i></div><div><i><font face="verdana, sans-serif"> 40057 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x559f3b64b4a8</font></i></div><div><i><font face="verdana, sans-serif"> 40058 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x559f3b64b4a8</font></i></div><div><i><font face="verdana, sans-serif"> 40059 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x559f3b64b4a8</font></i></div><div><i><font face="verdana, sans-serif"> 40060 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x559f3b64b4a8</font></i></div><div><i><font face="verdana, sans-serif"> 40061 2018/07/23 11:40:29.572 kid1| 17,4| AsyncJob.cc(123) callStart: Http1::Server status in: [ job10]</font></i></div><div><i><font face="verdana, sans-serif"> 40062 2018/07/23 11:40:29.572 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x559f3b64b4a8</font></i></div><div><i><font face="verdana, sans-serif"> 40063 2018/07/23 11:40:29.572 kid1| 33,3| Pipeline.cc(35) front: Pipeline 0x559f3b64b4f0 front 0x559f3b1a9190*2</font></i></div><div><i><font face="verdana, sans-serif"> 40064 2018/07/23 11:40:29.572 kid1| 33,3| Pipeline.cc(35) front: Pipeline 0x559f3b64b4f0 front 0x559f3b1a9190*3</font></i></div><div><i><font face="verdana, sans-serif"> 40065 2018/07/23 11:40:29.572 kid1| 33,3| client_side.cc(4089) unpinConnection:</font></i></div><div><i><font face="verdana, sans-serif"> 40066 2018/07/23 11:40:29.572 kid1| 33,3| client_side.cc(3927) <span style="background-color:rgb(255,255,0)">pinConnection:</span> local=<a href="http://4.16.205.42:33596">4.16.205.42:33596</a> remote=<a href="http://96.43.144.26:443">96.43.144.26:443</a> FD 15 flags=1</font></i></div></div><div><br></div><div>I assume that a pinned connection means <span style="color:rgb(0,0,0);white-space:pre-wrap">a server connection which </span><span style="color:rgb(0,0,0);white-space:pre-wrap">MUST have a 1:1 relationship with some client connection. Accordingly, if the client terminates, then the server connection should also be closing. From the post: </span><font color="#0000ff"><a href="http://lists.squid-cache.org/pipermail/squid-users/2015-June/004298.html">http://lists.squid-cache.org/pipermail/squid-users/2015-June/004298.html</a> </font></div><div><br></div><div><font color="#000000">1. Are there any security reasons behind <i>pinning the connection</i> when a peek is done at Step1 such that server connection get closed if corresponding client closes. Why is that done?</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">2.a) I see a stmt "reusing a pinned conn" in the function </font><font face="verdana, sans-serif" style="font-style:italic">selectPeerForIntercepted(). From</font><font face="arial, helvetica, sans-serif"> the logs, I dont find this function getting called. Under what scenario will this get called? In other words, what is the scenario where a pinned connection can be reused? </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"> b) Which configure option is used to enable </font><i style="font-family:verdana,sans-serif">#if STRICT_ORIGINAL_DST ?</i></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="verdana, sans-serif"><i>#if STRICT_ORIGINAL_DST<br></i></font></div><div><div><font face="verdana, sans-serif"><i>if (isIntercepted && useOriginalDst) {</i></font></div><div><font face="verdana, sans-serif"><i> <span style="background-color:rgb(255,255,0)">selectPeerForIntercepted();</span></i></font></div><div><font face="verdana, sans-serif"><i> // 3.2 does not suppro re-wrapping inside CONNECT.</i></font></div><div><font face="verdana, sans-serif"><i> // our only alternative is to fake destination "found" and continue with the forwarding.</i></font></div><div><font face="verdana, sans-serif"><i> startConnectionOrFail();</i></font></div><div><font face="verdana, sans-serif"><i> return;</i></font></div><div><font face="verdana, sans-serif"><i> }</i></font></div></div><div><font face="verdana, sans-serif"><i>#endif</i></font></div><div><font color="#000000"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 18, 2018 at 5:00 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</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 07/18/2018 03:03 PM, Vishali Somaskanthan wrote:<br>
<br>
> I had a problem after sending too many requests to the same server where<br>
> my persistence stopped working suddenly.<br>
<br>
</span>Please note that there are many reasons why a proxy may close a<br>
connection. For pinned to-server connections (like those created by<br>
SslBump), it may not be possible to open a new to-server connection so<br>
Squid should close both from-client and to-server connections.<br>
<br>
In general, a client should not rely on a connections staying persistent<br>
except in some very unusual/special circumstances.<br>
<span class=""><br>
<br>
> 1. What is the relationship between the caching and the persistence<br>
> connection established?<br>
<br>
</span>Virtually none. Caching decisions are done primarily based on request<br>
and response headers.<br>
<span class=""><br>
<br>
> 2. When will squid use cached results and when will it not if the cache<br>
> deny all directive weren't specified. <br>
<br>
</span>Squid will deliver a response from the cache when HTTP rules and Squid<br>
configuration allow a hit. The details are too complex to document here.<br>
<br>
<br>
> 3. However, this didn't work fully. Even with /cache deny all/<br>
<span class="">> directive, persistence wasn't working when I peeked at the sslBump step<br>
> 1 and then Bumped. <br>
> Persistence worked only when I directly did sslbump allow all (without<br>
> peeking at first step).<br>
<br>
</span>Bumping step should not affect connection persistence AFAICT. I do not<br>
know why it does in your case. This could be a Squid bug or a<br>
misunderstanding. If you can reproduce, Squid logs should contain<br>
reasons for each connection closure (but it may be difficult to find).<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div>Vishali Somaskanthan</div></div>
</div>