Re: Squid extended keepalive support

On Thu, 31 Mar 2005, Matt Hamilton wrote:

> The main issue is that whilst squid (2.5 at least) supports keepalives to
> the clients and the parent/neighbour caches there is no real way to get
> all the requests in one keepalive session to go to the same neighbour
> cache. This is a requirement in order to get NTLM to work through the
> cache.

Proxying of NTLM requires connection pinning, not only persistent
connections. This has been discussed a couple of times before and is
generally viewed as something we should eventually implement, but not very
important.

> I have been working through the squid code for a bit now and have managed
> to implement a neighbour selection policy that keeps track of the initial
> neighbour selected for a keepalive session and then subsequently re-uses
> this.

This is not sufficient to solve your problem. You need to reuse the exact
same connection, not only peer. And you need to make sure no other clients
can use that connection while it is idle. If not horror will arise when
there is multiple clients accessing the same server.

   Client A request some authenticated resource.

   Client B request some authenticated resource and gets the server
connection opened by client A as this is now an idle persistent
connection.

   At this stage your server will think it was Client A who sent both
requests.

There is also similar problems during the authentication handshake as
such, which will cause random failures if not dealt with correctly.

So in essense you are looking at the problem from a slightly bad angle,
causing you to go down the wrong and very dangerous path in solving this
problem.

Generally it is best (and easiest) if you do the NTLM on the reverse
proxy, and only forward the user name to the web server using the
login=*:secret cache_peer option.

You could also implement connection pinning but this assumes that you
have straight forwarding on a domain basis, not selecting different
backend servers depending on what file/directory is requested. This is due
to NTLM being connection oriented making it impossible to maintain
authentication for the same client connection with two different backend
web servers.

Regards
Henrik
Received on Thu Mar 31 2005 - 16:05:27 MST