Re: Squid NTLM and helpers

tis 2009-07-28 klockan 20:42 +1200 skrev Amos Jeffries:
> IIRC you knew something about the reserved/deferred state requirements
> for NTLM helpers.

A bit.. having rewritten that code about 1.5 times.

> I'm looking at bug 2648, where the helpers are idle in RESERVED "pinned"
> state and causing problems staying there. Is there a reason why they
> can't be closed?

A helper is only supposed to be "pinned" while there is a client
connection currently participating in the NTLM/Negotiate handshake. This
handshake may require a number of HTTP exchanges with unknown amount of
time between them, but all on the same client TCP connection.

If a helper stays RESERVED/pinned after the client have disconnected
(and Squid has acted on the disconnect, see half_closed_clients) then
there is a bug.

> restart, from what I can tell all the links they might be waiting for
> are about to die anyway and all auth is a write-off.

restart is restart.. there everything is reset as we start a new
process.

Where you thinking of reconfigure? A reconfigure does not reset client
connections, and clients with ongoing auth handshakes need to keep their
helper reservation.

> rotate, we are required to close them for cache.log as you taught me.
> But are we also required to keep them alive for active clients, requests
> or pconns ?

As above for the reconfigure case. Same thing only differing in the
possible properties of the helpers assigned to new connections.

> If the answer to both of the above is no, then can you feed my ignorance
> and explain why we even have a RESERVED state?

1 > Client sends a NTLM/Negotiate request

2 < Server responds with NTLM/Negotiate Challenge

3 > Client sends NTLM/Negotiate Auth response

and if Negotiate is used there is one possible additional step

4 < Server response includes Negotiate Auth "ack" with additional
properties (send in the HTTP response, whatever that is.. both
error/success/etc)

note also that the Negotiate scheme is usually short-circuited starting
at the Auth response step (#3 above), but it MAY use all 4 steps.

Between 2 & 3 we are waiting for the client to compute it's response and
sending a new HTTP request. This may take an arbitrary amount of time as
it may include the user entering his login credentials in a login box,
or other kinds of delays due to networking, cpu loads etc..

Step 3 & 2 may even repeat a number of times with the Auth Response
resulting in a new challenge.

Regards
Henrik
Received on Tue Jul 28 2009 - 09:32:05 MDT