Re: auth_param ntlm keep_alive interaction with new http/1.1 keepalive behaviour

Stephen Thorne wrote:
> G'day,
>
> Today I had a report of a problem seen with a late version of 3.1.6 + http/1.1,
> chunked response and keepalive patches. The problem occurs in the following
> situation.
>
> Laptop is on domain ONE, user bob.
> Proxy is on domain TWO, and accepts user alice.
>
> What happens with an older version of squid (with no auth_param ntlm keep_alive
> line in the config) is this:
>
>> GET
> < 407, NTLM
>> GET, NTLM hash
> < 407, NTLM hash
>> GET, NTLM hash for ONE/bob
> *** < 407 NTLM, Proxy-Connection: Close
> *** (connection torn down and re-established at this point)
>> GET
> < 407, NTLM
>> GET, NTLM hash
> < 407, NTLM hash
>> GET, NTLM hash for TWO/alice
> < 200 OK
>
> What happens with newer code that does http/1.1 with more aggresive keep-alive:
>
>> GET
> < 407 NTLM
>> GET, NTLM hash
> < 407 NTLM hash
>> GET, NTLM hash for ONE/bob
> *** < 407 NTLM Proxy-Connection: keep-alive
>> GET
> < 407, NTLM
>> GET, NTLM hash
> < 407, NTLM hash
>> GET, NTLM hash for TWO/alice
> < 200 OK
>
> *** marks the lines that are different between the two exchanges.
>
> The behaviour seen by the user in the latter case above is many authentication
> dialogs in firefox(3.6.x), approximately 1 per proxy-connection established.
>
> Setting "auth_param ntlm keep_alive off" causes the user's authentication
> dialogs to stop appearing.
>
> Perhaps with 3.1.7 or 3.2 we should consider defaulting to ntlm keep_alive off.
>

The 'new' behaviour you are seeing as I understand it is correct NTLM
persistent connection behaviour. Although the popup-per-connection is a
bit extreme, its probably caused by race condition in firefox between
parallel connections being rejected vs the new credentials being
confirmed. Please report it to the firefox people as well, they need to
fix that user-annoying behaviour regardless of what we do.

"off" is the only setting for keep_alive of NTLM and Negotiate configs
which has done anything. In both cases it has always acted as a
hack/workaround to force closed the connection immediately after Squid
offers its range of possible auth methods to the browser. "fixing"
interactions between Squid with NTLM and broken servers and clients.

PS. Does this occur with IE? IMO we can take that browser as the
benchmark for NTLM.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.6
   Beta testers wanted for 3.2.0.1