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
