Sorry I realize my answer was a bit unclear. I should not try to rush these things. On 18/03/2014 9:49 a.m., Amos Jeffries wrote: > On 2014-03-18 05:06, Alan wrote: >> On Mon, Feb 3, 2014 at 4:18 PM, Amos Jeffries wrote: >>> * Fix external_acl_type async loop failures >>> >>> This issue shows up as extra failed authentication checks if the >>> external ACL uses %LOGIN format code and credentials are not already >>> known. This can have nasty side effects when combined with NTLM in older >>> 3.4 releases. >> >> Will this be backported to the 3.3 series? > Doubtful. This was a regression fix for a bug added in the 3.4.0.1 ACL > redesign as far as I can tell. Hope that clarifies. >> How bad is it when using >> Kerberos instead of NTLM? >> This bug does not seem to affect Kerberos. Mainly due to the optimized handshake process there. * It may still show up a bit though if users login with wrong credentials. * It will definitly still show up for Negotiate/NTLM handshakes as much as native NTLM ones. This may be related to *some* negotiate_wrapper failures, though the commonly reported issue with that helper is something else entirely. >> I can't update to 3.4 because of the cpu usage problem described in >> the thread titled "squid 3.4. uses 100% cpu with ntlm_auth". >> >> Would it be too optimistic to think that this fix solves the cpu usage >> problem? > I suspect it is at least part of that report, though some of the mentions did not seem to have external ACL in a way to trigger this one. There are also several configuration reasons possible for achieving 100% CPU with NTLM that have nothing to do with bugs in Squid or even HTTP. In short, it is worth checking again with 3.4.4 to be sure for your case. If the 100% CPU issue still occurs a bit better analysis is still needed. Amos
