On Wed, 9 Jun 2010 17:22:09 +0100, Jeff Silver <jsilver@xxxxxxxxxxxx> wrote: > I'm using squid/3.1.3. > It is configured with a cache-peer thus: > > cache_peer myproxy parent 8081 0 default no-query no-digest > no-netdb-exchange login=PASS > > 'myproxy' is not squid. It is NTLM-capable. > > The NTLM log-in process works OK, but it looks as if squid is not > maintaining separation between > sessions (what I think used to be called "connection pinning"). In other > words, if two users log in > from two separate browsers, upstream connections are shared across the two > sessions (especially if > the same site is being visited). Are you sure both clients getting TCP_MISS? If one was a HIT then that one never actually used the link, even if it used some content previously fetch through the link. Do you mean Squid itself is sharing the Squid->Upstream link with both clients? Is Squid interleaving their requests? Is squid forcing one to auth to use the link, then forcing the other to re-auth to use it, etc? Squid will 'pin' previously used persistent connections if the client starts sending NTLM auth down it. Also 'unpin' a connection if the client changes its auth type, if auth fails, or the server connection dies. This latter allows persistent client connections if something recoverable happens to the server connection (ie TCP timeout), though the client should be challenged to re-auth the full link. An HTTP trace (of at least the request/reply header flowing over the link), for both the links client->squid and squid->upstream will be needed to look deeper at this. > > I tried adding connection-auth=on to both the cache-peer line and the > http_port line (although squid > 3.1 docs say that this is on by default). > I also tried sending a 'Proxy-support: Session-Based-Authentication' > header from myproxy. > Upstream connections were still being shared. > > Is there anything else I should set in the configuration? > Is this a bug? Persistent connections for both servers and clients is required. Though the default should be to have both on now as well. persistent_connection_after_error should also be left ON. Other than those it should be working. Amos
