Re: [squid-users] Confusing external acl, reply_body_max_size and EXT_LOG combo issue

On 15/07/2014 7:04 p.m., Cameron Charles wrote:
> Hi,
>
> Im having some confusing trouble with an external acl based
> reply_body_max_size setup, but only when the ext_log is brought into
> things.
>
> I have an external acl setup as such:
>
>> external_acl_type response_size_type ttl=300 children-startup=2 children-idle=1 children-max=10 %URI %EXT_LOG %TAG python max_file_size_ext_acl.py
>
>
> which is used to check against some external data to cache the
> response for the reply_body_max_size directive to use, an example of
> which is this:
>
>> acl response_size_31 external response_size_type 31 10.0.1.26
>> http_access allow response_size_31
>> reply_body_max_size 31 MB response_size_31
>
>
> now this works perfectly fine, no issues what so ever, until the
> external acl alters the EXT_LOG (and passes it back), pretty much any
> alteration to the ext_log data causes squid to basically ignore the
> answer it gets back from the external acl and continue on.
> The external acl can take in the ext_log and pass it untouched out the
> other side no issues too, so it doesnt appear to be simply the fact
> its passing the ext_log back.
>
> Im really stumped at to whats going on here, any help would be appreciated.
>
> Cameron Charles
>

Whats going on here is that reply_body_max_size is a "fast" ACL. So ACLs
like external require a pre-cached helper response if they are going to
match at all.

When the helper is executed in http_access there is no EXT_LOG value (or
TAG by the way). So the helper is being called with "%URI - -".

On the reply_body_max_size the http_access has aready been called. So
the helper cache is checked for the lookup, but this time using the
EXT_LOG value given by the previous lookup. Which probably does not
exist in the cache.

This workaround may work for you, it calls the helper twice in
http_access where the lookup using log entry value can be waited on:
  http_access allow response_size_31 response_size_31

Amos
Received on Tue Jul 15 2014 - 07:40:38 MDT