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