On 5/12/2012 9:19 a.m., Alex Rousskov wrote:
On 12/01/2012 06:02 PM, Alex Rousskov wrote:
To summarize, our choices for a pinned connection created for the
current client are:
Before sending the request:
1. Reopen and repin used pconns to send unretriable requests,
just like non-pinned
On 12/06/2012 05:21 AM, Amos Jeffries wrote:
On 5/12/2012 9:19 a.m., Alex Rousskov wrote:
On 12/01/2012 06:02 PM, Alex Rousskov wrote:
To summarize, our choices for a pinned connection created for the
current client are:
Before sending the request:
1. Reopen and repin used pconns to send
On 12/01/2012 06:02 PM, Alex Rousskov wrote:
To summarize, our choices for a pinned connection created for the
current client are:
Before sending the request:
1. Reopen and repin used pconns to send unretriable requests,
just like non-pinned connection code does. This eliminates
lör 2012-12-01 klockan 18:02 -0700 skrev Alex Rousskov:
a) If we are talking about unretriable requests, the client already
violated HTTP by sending such a request over the persistent client
connection. Some of these clients may fail to handle resets properly.
End-user-agents have much more
fre 2012-11-30 klockan 23:07 -0700 skrev Alex Rousskov:
I am not sure what you are asking about, but I can try to rephrase: This
bug is difficult to fix because some pinned connections should be reused
and some should not be. Pinned connections that can be re-pinned but
have not had any HTTP
On 12/01/2012 11:20 AM, Henrik Nordström wrote:
fre 2012-11-30 klockan 23:07 -0700 skrev Alex Rousskov:
Does the !flags.canRePin exception address your concern?
Yes, if used where needed (TPROXY, NTLM).
By default, the canRePin flag is not set and pinned connections are
reused, even for
On 11/30/2012 08:27 PM, Amos Jeffries wrote:
On 1/12/2012 1:31 p.m., Henrik Nordström wrote:
fre 2012-11-30 klockan 15:30 -0700 skrev Alex Rousskov:
Squid is sending POST requests on reused pinned connections, and
some of those requests fail due to a pconn race, with no possibility for
Hello,
It just occurred to me that there is nothing wrong, from theoretical
protocol point of view, with reseting the client connection when a
server-side race condition is detected _and_ we know that the client was
the one that caused Squid to open the server connection. I personally do
not
lör 2012-12-01 klockan 11:42 -0700 skrev Alex Rousskov:
come. Why can't TPROXY reopen a server-side connection?
Because it tries to use the original source ip:port, but it's in
TIME_WAIT from the previous connection and can't be reused.
Regards
Henrik
fre 2012-11-30 klockan 15:30 -0700 skrev Alex Rousskov:
Squid is sending POST requests on reused pinned connections, and
some of those requests fail due to a pconn race, with no possibility for
a retry.
Yes... and we have to for NTLM, TPROXY and friends or they get in a bit
of trouble
On 1/12/2012 1:31 p.m., Henrik Nordström wrote:
fre 2012-11-30 klockan 15:30 -0700 skrev Alex Rousskov:
Squid is sending POST requests on reused pinned connections, and
some of those requests fail due to a pconn race, with no possibility for
a retry.
Yes... and we have to for NTLM,
On 11/30/2012 05:31 PM, Henrik Nordström wrote:
fre 2012-11-30 klockan 15:30 -0700 skrev Alex Rousskov:
Squid is sending POST requests on reused pinned connections, and
some of those requests fail due to a pconn race, with no possibility for
a retry.
Yes... and we have to for NTLM,
12 matches
Mail list logo
