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
