On 10/27/2017 09:43 AM, Yuri wrote: > So, in each separate case we're should make testcase for EACH regex in > acl to make sure it will or not will work. > > Generally speaking, with thousands of regular expressions and thousands > of sites - it sounds pretty dumb, right? Many to many relasions, > thousands tests etc. What an admin has to do is onerous, but not as bad as you make it sound: * A handful of test cases is sufficient to validate whether Squid instance X supports all extended regular expressions used by its ACLs. In fact, Squid can be easily modified to run such test cases on startup! * If you want to test that each of the 10K ACLs matches what you want it to match, then you have to write a lot more test cases, of course, but such deployment-specific functionality testing is a completely different topic out of this thread scope. > What could be simpler is to clearly document the following: "Never use > anything other than POSIX Basic in regular expressions because we do not > guarantee and can not guarantee it will work"? You are right: Adding the above text to squid.cond.documented is fairly simple. If Squid actually supports extended regular expressions in some environments, then such a text will also be a bit misleading/misguiding. Wiki updates or pull requests improving Squid documentation are always welcomed! Personally, I cannot volunteer to add this documentation because I do not know whether Squid can support extended regular expressions in some environments, and I do not want to spend time adding potentially misleading/misguiding documentation. Long-term, we should introduce a configuration option that specifies the exact regex flavor an admin wants _and_ forces Squid to quit if that exact flavor is not supported by the running Squid instance. Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
