Re: Squid NTLM and helpers

Henrik Nordstrom wrote:
> 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.

Ah, right. The bug is about reconfigure sending helpers into RS state
where then stay. Probably due to a more general bug of not leaving
RESERVED state.

My head is just a bit hung-up from the restart work I've been doing. The
symptoms show up there, but only slow the close sequence to maximum timeout.

>
>> 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.

Good news. So the side issues and overloads mentioned should be fixed no
then. Just the main one.

>
>> 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.
>

OK, so the issue replicable with the supplied script is only that a
client connection close is not un-Reserving. I'll keep looking.
If you can point me at any keywords to short-circuit the search that
would be great.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE17
   Current Beta Squid 3.1.0.12