Hi Amos, Thanks for detailed explanation. For the case #1 in my original post, is it a bug that will get fixed some time? I was able to get the behavior I want by adding a dummy ACL as follows (after the external ACL line): acl myacl src all deny_info ERR_XXXXX myacl http_access deny myacl http_access deny all myall is same as all, but now even after retaining "http_access deny all", it works correctly. With the above, even the "message" that was set in the external acl helper was also properly used in the error page. I am just not sure it is the right way to do it. Thanks, Sreenath On 1/25/16, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 25/01/2016 5:18 a.m., Sreenath BH wrote: >> Hi All, >> >> I am trying to validate my understanding of external acl, deny_info >> and http_access deny all" interaction. >> >> My squid conf has just two rules. First is external ACL helper and >> then the "deny all" as follows: >> >> Case (1) >> ----------- >> external_acl_type my_helper ttl=0 negative_ttl=0 children-max=2 %PATH >> /usr/local/bin/acl >> acl AclName external my_helper >> deny_info 404:ERR_MY_ACL AclName >> http_access allow AclName >> >> http_access deny all >> -------- >> >> I want a default error code of 404 to be returned, along with a custom >> error message file being sent. >> My observations are as follows: >> >> 1. If my external ACL prints OK, it proceeds with processing. >> 2. If it prints ERR, instead of using the custom message, it proceeds >> to next access rule, which is "http_access deny all" >> >> When that fails it prints a default 403 message. >> >> If I remove "deny all" line it works well. > > That is a bug. It should act the same as if the deny all was still there. > > >> >> Case (2) >> I tried changing "http_access allow" to "http_access deny" follows: >> >> -------- >> external_acl_type my_helper ttl=0 negative_ttl=0 children-max=2 %PATH >> /usr/local/bin/acl >> acl AclName external my_helper >> deny_info 404:ERR_MY_ACL AclName >> http_access deny !AclName >> >> http_access deny all >> ---------- >> >> In this case, whenever the acl helpers send "ERR", it prints the >> correct error message. >> But now, if it succeeds (prints OK), it goes to next line and fails >> there, instead of proceeding with further processing. >> >> Even in this case, removing the next "deny all" will work correctly. >> >> I find is strange that even when external ACL Helper matches and >> prints OK, because of the way >> the http_access line worded, it does not take it as a pass and goes to >> check next http_access line. > > You seem to be confusing the OK/ERR helepr protocol codes with HTTP > pass/reject actions. > > * OK is not a "pass" it is a "match" > > * the "!" means inversion of the match/mismatch value > > So the !AclName means ERR is now a match and OK is a non-match. > > > When the !AclName is a match the request is denied as per your rule and > using the deny_info details in the rejection message. > > When the !AclName is a mis-match it skips and the "deny all" line denies > the request. > > When you remove the "deny all" line the default action for this case #2 > becomes "allow all". > >> >> Is this expected behavior? Or am I missing something? > > > deny_info is the directive tying some specific output to an ACL name. > Which is to be sent if (and only if) that ACL was used on a "deny" line. > > The bug in case #1 is that the last tested ACL is considered to be the > reason for denial and its action performed when a deny happens. But > without that explicit "deny all" the last tested was actually your ACL > test on the "allow" line. > > case #2 is expected behaviour. > > > Amos > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
