On 7/08/2015 11:48 a.m., Benjamin E. Nichols wrote: > Agreed, whoever decided it was a wise decision to make this a stop error > should be fired or at the very least, slapped in the back of the head. > > On 8/6/2015 6:44 PM, Dan Charlesworth wrote: >> This used to just cause a WARNING right? Is this really a good enough >> reason to stop Squid from starting up? >> >> 2015/08/07 09:25:43| ERROR: '.ssl.gstatic.com >> <http://ssl.gstatic.com/>' is a subdomain of '.gstatic.com >> <http://gstatic.com/>' >> 2015/08/07 09:25:43| ERROR: You need to remove '.ssl.gstatic.com >> <http://ssl.gstatic.com/>' from the ACL named 'cache_bypass_domains' >> FATAL: Bungled /etc/squid/squid.conf line 149: acl >> cache_bypass_domains dstdomain "/acls/lists/8/squid_domains” >> It *seems* very daft. But there actually is a very good reason. Squid stores these data into a splay tree structure as it goes. Adding to a splay tree is a one-way operation. There is no remove short of dumping the entire squid.conf and re-configuring. [ just a side note: we *are* actively in the process of trying to eradicate these splay trees and use another type of fast hash we could remove from. ] There are several cases for what the loaded file may contain: A) .gstatic.com .ssl.gstatic.com B) .gstatic.com .gstatic.com C) .gstatic.com gstatic.com D) .ssl.gstatic.com .gstatic.com E) gstatic.com .gstatic.com Cases (A, B, C) will happily go along and add .gstatic.com to the ACL. The next one is an overlap with a more narrow matching range than already in the tree. These *are* nicely displayed as WARNING, and just ignored by Squid as it continues to run. If you put "acl all src 0.0.0.0" into a squid-3 config you can see that happen. Cases (D, E) are special. The first entry already added to the ACL splay will match *less* than the second one. Now the way using a splay tree works is that for any lookup one of them will be 'closer' and thus match. But not always the same one. So adding both to the splay will cause domains in the non-overlap area to randomly be blocked or allowed. These are what you are seeing displayed as ERROR. So then we get back to how restarting the entire reconfigure process from scratch is needed to remove the first entry from the splay tree. ---> Doing a reconfigure will only load the same details in the same order unless manually fixed first. Squid must halt and wait for you to fix this. If it is left running the config *will not* be doing what you intended Squid to do. That is FATAL. And BTW, finding these issues in manually edited or third-party lists is one of the reasons one should always run "squid -k parse" before loading new config. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
