[squid-users] Squid behaviour with external_acl_type

[Amos Jeffries]

On 29/03/2015 4:55 a.m., Ashish Patil wrote:
> Hello,
> 
> I am faced with a weird situation with an external acl that I have built.
> 
> The external acl gets the acl name and the IP information, does a lookup in
> a MySQL table if that IP belongs to a group ( read: acl name ) and returns
> an output.
> 
> The situation is as follows:
>  On the first client request coming to the external helper, it performs as
> expected, and the correct action is taken. Whereas from the second request
> onwards, Squid just waits on the external acl, even though a response was
> sent by the acl, and the same was received by Squid.
> 
> My acl's are as follows:
> external_acl_type grpname ttl=10 children-startup=1 concurrency=1 %SRC %ACL
> /usr/local/squid/libexec/grpname_helper
> acl two external grpname
> acl twoext urlpath_regex
> "/usr/local/squid/etc/custom/blacklisted-two-extensions"
> deny_info http://192.168.3.11/error.html two
> http_access deny twoext two
> 

> 
> To verify Squid was getting the responses from the external acl, I ran a
> strace on the squid process. Below is the trimmed output:
> 

> write(19, "0 192.168.3.243 two\n", 20)  = 20
> read(19, "OK\n\0", 4095)                = 4


Problem #1:
 Squid is using concurrency channels. The helper is not sending the
channel-ID field in the reply. Try setting concurrency=0 on squid.conf
to fix that - or better, update the helper to use concurrency properly.


Problem #2:
 The helper is sending a '\0' octet after the \n.
 The \n delimits the first and second response. So the \0 is left in the
buffer until the seond response is being handled.

When the second lookup happens its response is "\0OK" not the "OK" you
were expecting. Same thing also happens with all following lookups on
this helper.

Amos