Thanks for the great explanation. Much appreciated. On Fri, Aug 30, 2019, at 2:10 PM, Alex Rousskov wrote: > On 8/30/19 2:41 PM, squid@xxxxxxxxxxxxxx wrote: > > > All requests will always start with www.example.com /.... or origin-www.example.com/ > > If that is true, why check domain names at all? When you write an ACL > that checks for X, it is reasonable to assume that X may not happen. My > evaluation of your rules made that assumption. > > > Are you saying I should have the following for .4 and .5 instead of what I'm currently using? > > > > cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin > > cache_peer_access 192.168.1.5 allow limited > > cache_peer_access 192.168.1.5 allow all_requests > > cache_peer_access 192.168.1.5 deny all > > No, the above does not match what you want to achieve AFAICT. If domain > names matter, then you should have something like this: > > > cache_peer_access 192.168.1.5 allow limited all_requests > > cache_peer_access 192.168.1.5 deny all > > > Needless to say, the name "all_requests" is very misleading, pointing to > the same inconsistency/problem we are discussing. I will use "myDomains" > below but you may find a better name based on your business logic. > > The "limited" name also looks like a poor choice because all ACLs > (except "all") limit matching. I will use mapOneOrTwo below instead. > > If you fix the names, the rules become simpler/readable. For example: > > cache_peer_access 192.168.1.1 deny mapOneOrTwo > cache_peer_access 192.168.1.1 allow myDomains > cache_peer_access 192.168.1.1 deny all > > ... > > cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains > cache_peer_access 192.168.1.5 deny all > > > You can achieve even better clarity if you use negation, but I usually > recommend against negating ACLs: > > cache_peer_access 192.168.1.1 allow !mapOneOrTwo myDomains > cache_peer_access 192.168.1.1 deny all > > ... > > cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains > cache_peer_access 192.168.1.5 deny all > > > > Finally, if domain names do _not_ matter, then you will just have: > > cache_peer_access 192.168.1.1 deny mapOneOrTwo > cache_peer_access 192.168.1.1 allow all > > ... > > cache_peer_access 192.168.1.5 allow mapOneOrTwo > cache_peer_access 192.168.1.5 deny all > > > HTH, > > Alex. > P.S. If possible, mapOneOrTwo should be replaced with something more > meaningful according to your business logic. > > > > On Fri, Aug 30, 2019, at 11:41 AM, Alex Rousskov wrote: > >> On 8/30/19 11:44 AM, creditu@xxxxxx wrote: > >>> We use several squid servers in accelerator mode for load balancing to send public requests to backend servers. The squids don't do any caching, they just forward requests to the backend. > >>> > >>> We have cache_peer directives to send the incoming requests to the backend Apache servers. What I need to do is send requests to a certain page to a specific backend server and all others to the other backends. The site has many pages, subpages etc. > >>> > >>> What I want to do is if someone requests: > >>> https://www.example.com/anything/anything/script.php or https://origin-www.example.com/anything/anything/etc/etc/script.php > >>> > >>> Send the request to only .1, .2,.3. > >>> > >>> If someone requests : > >>> https://www.example.com/anything/tst/map2/script.php or https://origin-www.example.com/anything/anything/tst/map1/etc/script.php > >>> > >>> Send that request only to .4 and .5. > >>> > >>> It seems to work most of the time, but tailing the access logs on the servers I sometimes see one of the requests for ../tst/map2/... or map1 show up on .1,.2, or .3. > >> > >> > >> Do Squid access logs have the corresponding records as well? What cache > >> peer selection algorithm does Squid record for those misdirected > >> transactions? > >> > >> > >>> Is there something I'm missing? > >> > >> Could Squid go direct to one of those origin servers (e.g., when all > >> eligible cache peers were down)? > >> > >> BTW, please note that your cache_peer_access rules look inconsistent: > >> Your cache_peer_access .1-3 rules require certain domain names but .4-5 > >> rules do not. This does not explain the discrepancy you are describing > >> above, but you may want to adjust your rules for consistency sake > >> (either to ignore dstdomain completely or to require correct domains for > >> all cache peers). > >> > >> > >> HTH, > >> > >> Alex. > >> > >> > >>> acl all_requests dstdomain -n www.example.com origin-www.example.com > >>> acl limited url_regex -i /tst/map1|/tst/map2 > >>> > >>> > >>> cache_peer 192.168.1.1 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin > >>> cache_peer_access 192.168.1.1 deny limited > >>> cache_peer_access 192.168.1.1 allow all_requests > >>> cache_peer_access 192.168.1.1 deny all > >>> > >>> cache_peer 192.168.1.2 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin > >>> cache_peer_access 192.168.1.2 deny limited > >>> cache_peer_access 192.168.1.2 allow all_requests > >>> cache_peer_access 192.168.1.2 deny all > >>> > >>> cache_peer 192.168.1.3 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin > >>> cache_peer_access 192.168.1.3 deny limited > >>> cache_peer_access 192.168.1.3 allow all_requests > >>> cache_peer_access 192.168.1.3 deny all > >>> > >>> cache_peer 192.168.1.4 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin > >>> cache_peer_access 192.168.1.4 allow limited > >>> cache_peer_access 192.168.1.4 deny all > >>> > >>> cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin > >>> cache_peer_access 192.168.1.5 allow limited > >>> cache_peer_access 192.168.1.5 deny all > > _______________________________________________ > 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
