Eliezer, Thankyou for your reply, I tried the following: > Hey Luke, > > Try to use the next line instead: > external_acl_type delay ttl=1 negative_ttl=0 cache=0 %SRC %SRCPORT %URI /tmp/delay.pl > > And see what happens. But it's not introducing a delay into the response. Running strace across the pid of each child helper doesn't show any activity across those processes either. I also tried the approach suggested by Amos: > The outcome of that was a 'ext_delayer_acl helper in Squid-3.5 > > <http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_delayer_acl.html> > > It works slightly differently to what was being discussed in the thread. > see the man page for details on how to configure it. Using the following config: external_acl_type delay concurrency=100000 children-max=2 children-startup=1 children-idle=1 cache=10 %URI /tmp/ext_delayer_acl -w 1000 -d acl http-response-407 http_status 407 acl delay-1sec external delay http_reply_access deny http-response-407 delay-1sec !all Debug information from ext_delayer_acl is written to the cache log; I see the processes start up but they are not hit with any requests by Squid. I also added %SRC %SRCPORT into the configuration, but that didn't seem to help either. Would the developers be open to adding a configuration-based throttle to authentication responses, avoiding the need for an external helper? Or alternatively, is there another way to slow down auth responses? It's comprising about 90% of the log volume (450,000 requests/hr) in badly affected sites at the moment. Luke _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
