Two years ago, I have helped enabling PCRE regexp in Squid's port, see #223505.
Back then I was using Squid 3.5.x on FreeBSD 11.x and it was fine :-)
Now, I am updating to Squid 4.9 on FreeBSD 12.1 and PCRE regexp don't work anymore, I am getting back the error message I previously had before #223505 : "repetition-operator operand invalid".
I've also tried to install squid3 (3.5.28_3), and got the same error.
The good news, I have found I need to add:
at the end of CONFIGURE_ARGS= in the port Makefile.
This option is documented here: https://github.com/squid-cache/squid/blob/77b1029d207083d583d81d2f2fb7a840e0f23cab/configure.ac#L3615
It does fix my problem, but is it the right way to do it? I mean, in their explanation of the option, they say it is for Windows or old UNIX which don't have a regex lib.
Has anything has changed in FreeBSD 12 regarding regexp? Does anyone know why that happens?
I have tried compiling with and without the PCRE option added in #223505, and it does work in both case: this option seems useless with "--enable-gnuregex".
What should I do to help? Is it OK to directly add this "--enable-gnuregex" option to CONFIGURE_ARGS? Or should I add a configurable option?
I can provide a patch, I just need to know what is best to do :-)
(In reply to OlivierW from comment #0)
thanks a lot for the report! And sorry for the delay.
I'm gonna update squid to 4.10 and try to fix it.
Well, to get right answers about --enable-gnuregex it's better to ask squid maillist instead and rise an discussion there.
I'm trying to understand how it may be fixed the right way.
(In reply to OlivierW from comment #0)
Could you share your example of ACL to check it?
Thanks for your answer!
I currently don't have access to the specific regexes, but they are similar to:
acl example url_regex -i ^http:\/\/www\.example\.com\/.*?\.js
I've tried this one in a VM with FreeBSD 12.1 and Squid 4.10 from ports and I am getting the error.
I've found I can fix it by removing the lazy quantifier (from .*? to .*):
acl example url_regex -i ^http:\/\/www\.example\.com\/.*\.js
Both regexes are accepted with Squid 4.10 compiled with "--enable-gnuregex".
Maybe I should just change my regexes to remove the lazy quantifier? Hoping it's the only case causing a problem.
As you said, I'll ask on Squid's mailing list to know what is the right thing to do.
(In reply to OlivierW from comment #3)
Have you got any answer from squid maillist?
Sorry it took me over a year to ask on Squid's mailing-list :-/
I have just posted a message here: http://lists.squid-cache.org/pipermail/squid-users/2021-June/023765.html
I'll report back when I have answers.
PS: since my first message here, I am now using Squid 4.14 on FreeBSD 13.0 and I still have to compile with the "--enable-gnuregex" option.
I got an answer from Amos: http://lists.squid-cache.org/pipermail/squid-users/2021-June/023766.html
So, GNU regex library is deprecated and will be replaced by std::regex C++ later.
Well, for now I'll just fix and/or remove my problematic rules so I won't need PCRE anymore.
And as I was probably the only one using this on FreeBSD, I think I should revert my patch from 2017: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223505 and completely remove the "PCRE" option of the port.
What do you think?
(In reply to OlivierW from comment #6)
I think we'll remove this option on the next update if you don't mind.
(In reply to timp87 from comment #7)
If the issue affects present port users, it should be addressed independently, such that it can be merged if it also affects quarterly users.
What is the path to resolving this issue as reported?
Created attachment 225982 [details]
remove PCRE option for www/squid as it's not supported officially
(In reply to Kubilay Kocak from comment #8)
I was the one who proposed the PCRE patch back in 2017 (PR #223505), and currently the PCRE functionnality doesn't work at all (if someone has rules needing PCRE, squid don't start and spit errors). As nobody complained about this problem, I would say I am probably the only user being affected by this whole PCRE thing :-)
(In reply to Pavel Timofeev from comment #9)
Thanks for your patch! :-)