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
Received on Sat Dec 01 2012 - 00:31:37 MST
This archive was generated by hypermail 2.2.0 : Sat Dec 01 2012 - 12:00:32 MST