I played around with the order and didnt get any results, the desired outcome is that the reply_body_max_size limit comes into effect if the external acl is true (returns OK?), therefore any requests that the ext acl helper deems as a match are limited and the end user taken to the "file to big" page, currently this doesnt happen and the requests that should match get let through without any limits, after turning on the debug msgs you suggested it seems that the acl that supposed to trigger the limit never gets fired, or at least never matches, despite currently being "rigged" to always return OK, also the clarify the helper is used by other acls succesfully On 30 May 2012 19:53, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 30/05/2012 7:14 p.m., Cameron Charles wrote: >> >> oops wrong email heres what i wrote in replay from my other email, >> sorry to all for the mixup >> >> >> HI, thanks for the quick response, i have a line like the one you >> mentioned above my replay_body.. line, however further above that line >> i have the following line aswell "hhtp_reply_access deny >> differentacl" >> >> could this be causing a confliction error or something like that, if >> not then i have the lines you suggested in place and still dont get a >> restriction working > > > The one I supplied needs to go first. The "!all" trick allows it to be > tested with no effect on the reply and skip through to other access lines > for real permit/deny decisions. > > > If that positioning is correct.... what are you expecting to see and what > are you actually seeing? HTTP reply headers would help, as would details of > the helper. You can set debug_option 82,9 to get a trae of what the ACL is > doing. > > > Amos
