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 remote=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 remote=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 <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
