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 from connection state mismatch. If sending the request fails we should propagate this to the client by resetting the client connection and let the client retry. > When using SslBump, the HTTP request is always forwarded using a server > connection "pinned" to the HTTP client connection. Squid does not reuse > a persistent connection from the idle pconn pool for bumped client > requests. Ok. > Squid uses the dedicated pinned server connection instead. > This bypasses pconn race controls even though Squid may be essentially > reusing an idle HTTP connection and, hence, may experience the same kind > of race conditions. Yes.. > However, connections that were just pinned, without sending any > requests, are not "essentially reused idle pconns" so we must be careful > to allow unretriable requests on freshly pinned connections. ? > The same logic applies to pinned connection outside SslBump. Which it quite likely the wrong thing to do. See above. Regards Henrik
