On 07/30/2018 06:37 PM, Vishali Somaskanthan wrote:
> 2. Can you provide an example where NOT PINNING and not having the
> shared fate breaks *fewer transactions*??
I do not know of any specific services like that, but it is easy to
imagine one. For example, consider a server that sends the clie
Hi Amos, Alex,
Reading your conversations, here is a table of rules for pinning.
*STEP 1* *STEP 2* *STEP 3* *EXPECTED* *IMPLEMENTED*
BUMP - - NO PIN NO PIN
PEEK BUMP - PIN PIN
PEEK STARE BUMP PIN PIN
PEEK PEEK BUMP PIN PIN
SPLICE - - PIN PIN
PEEK SPLICE - PIN PIN
PEEK PEEK SPLICE PIN PIN
PEEK STA
[There is a potentially useful reframing of the question at the end if
you want to skip the details...]
On 07/26/2018 11:11 PM, Amos Jeffries wrote:
> On 27/07/18 16:18, Alex Rousskov wrote:
>> one could argue that Squid should honor a
>> (higher level) client and server assumption that they are
On 27/07/18 16:18, Alex Rousskov wrote:
> On 07/26/2018 09:15 PM, Amos Jeffries wrote:
>> On 27/07/18 13:31, Alex Rousskov wrote:
>>> On 07/26/2018 05:47 PM, Vishali Somaskanthan wrote:
>>>
By re-use I meant to say that the server-connection S (TCP + SSL) is
re-used across 2 client connec
On 07/26/2018 09:15 PM, Amos Jeffries wrote:
> On 27/07/18 13:31, Alex Rousskov wrote:
>> On 07/26/2018 05:47 PM, Vishali Somaskanthan wrote:
>>
>>> By re-use I meant to say that the server-connection S (TCP + SSL) is
>>> re-used across 2 client connections (C1 and C2), from the same client
>>> one
On 27/07/18 13:31, Alex Rousskov wrote:
> On 07/26/2018 05:47 PM, Vishali Somaskanthan wrote:
>
>> By re-use I meant to say that the server-connection S (TCP + SSL) is
>> re-used across 2 client connections (C1 and C2), from the same client
>> one after the other is torn down. I, presume that
>> “
On 07/26/2018 05:47 PM, Vishali Somaskanthan wrote:
> By re-use I meant to say that the server-connection S (TCP + SSL) is
> re-used across 2 client connections (C1 and C2), from the same client
> one after the other is torn down. I, presume that
> “/server_persistent_connection on/” allows for su
Hi,
FYI, in all my examples below, one have the same client and same server
By re-use I meant to say that the server-connection S (TCP + SSL) is
re-used across 2 client connections (C1 and C2), from the same client one
after the other is torn down. I, presume that “*server_persistent_connection
On 07/26/2018 02:49 PM, Vishali Somaskanthan wrote:
> 1. Are there any security reasons behind /pinning the connection/ when a
> peek is done at Step1
I doubt there is some fundamental _security_ reason to pin if you bump
without forwarding the TLS client information to the server. The reasons
to
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::
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 create
Dear Squid users,
There is a connection C1 from the client to squid and that is
bumped at squid which forms a TCP connection with origin server S1. Having
server persistent connection turned on, for subsequent requests, I see that
the same TCP connection is used between the squid and the
12 matches
Mail list logo
