auth_param ntlm keep_alive interaction with new http/1.1 keepalive behaviour
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. -- Regards, Stephen Thorne Development Engineer Netbox Blue
Re: auth_param ntlm keep_alive interaction with new http/1.1 keepalive behaviour
Amos, As I understand it, keep-alive off is for this exchange: GET 407 NTLM PC:Close * (reconnect) GET NTLM hash 407 NTLM hash GET NTLM authdetails But the situation I am experiencing is after a rejected authentication attempt. I.e. here: GET 407 NTLM PC:Close (reconnect) GET NTLM hash 407 NTLM hash GET NTLM authdetails 407 NTLM ** (reconnect here is required to avoid multiple auth prompts) GET NTLM hash 407 NTLM hash GET NTLM authdetails I have had this problem reported with both MSIE and Firefox. Rigerous testing with tcpdumps has only been performed with firefox. -- Regards, Stephen Thorne Development Engineer Netbox Blue
access_log acl not observing my_port
G'day, I've been looking into a problem we've observed where this situation does not work as expected, this is in squid-2.7.STABLE4: acl direct myport 8080 access_log /var/log/squid/direct_proxy.log common direct I did some tracing through the code and established that this chain of events occurs: httpRequestFree calls clientAclChecklistCreate calls aclChecklistCreate But aclChecklistCacheInit is the function that populates the checklist-my_port, which is required for a myport acl to work, and it isn't called. I have attached a patch that fixes this particular problem for me, which simply calls aclChecklistCacheInit in clientAclChecklistCreate. -- Regards, Stephen Thorne Development Engineer NetBox Blue - 1300 737 060 Scanned by the NetBox from NetBox Blue (http://netboxblue.com/) Scanned by the NetBox from NetBox Blue (http://netboxblue.com/) --- squid/src/client_side.c 2008-11-14 15:07:55.0 +1000 +++ squid/src/client_side.c.new 2008-11-14 15:08:32.0 +1000 @@ -211,6 +211,7 @@ ch = aclChecklistCreate(acl, http-request, conn-rfc931); +aclChecklistCacheInit(ch); /* * hack for ident ACL. It needs to get full addresses, and a
