Jeff Foster wrote:
There appears to be a problem with the connection pinning in both
versions squid-2.7.stable7 and
squid-3.1.0.7. I have some network captures that show the client
(IE6) creating multiple TCP
connections to the squid proxy and the proxy creating multiple TCP
connections to an IIS server.
....
I have tcpdump traces for both versions available.
In the 3.1 dump summary, note that the client packet 207 is the server
packet 210.
The server should be on port 37159 and it is on port 37161.
Can a developer look at this?
There are quite a few pinning issues resolved since 3.1.0.7 (beta) was
released.
Try 3.1.0.16 beta.
Amos
Sorry I mis-typed, I am running version 3.1.0.16.
Not sure how connection pinning works. Does it tie a client TCP socket
to an upstream TCP socket? Or does it tie a client URL to an upstream
socket?
Jeff F>
'tis complicated.
The simplest view is that it ties a client TCP link, to a destination
domain name.
Warning, technical details ahead. As I understand it...
It ties each input triplet (client TCP link, client IP, destination
domain name) which has been NTLM or Kerberos auth "signed" by an auth
request/challenge passing through them to a particular output pair
(server TCP link, destination domain) where the auth challenge was
answered correctly.
It stays tied as long as both links are open.
Requires persistent connections to be ON for both servers and clients.
Requires http_port connection-auth=on or =auto
Requires any cache_peer involved to also have connection-auth=on or =auto
These last two requirements are met by default in Squid-3.1.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE23
Current Beta Squid 3.1.0.16
