Doc #81596 [Com]: PHP in apache with mod_perl ignores locale, while CLI version doesn't.

Edit report at https://bugs.php.net/bug.php?id=81596&edit=1 ID: 81596 Comment by: rorygwgehman at gmail dot com Reported by: cmanley at xs4all dot nl Summary: PHP in apache with mod_perl ignores locale, while CLI version doesn't. Status: Open Type: Documentation Problem Package: Apache2 related Operating System: Debian 10.11 PHP Version: 7.3.32 Block user comment: N Private report: N New Comment: Greast thanks for this... https://www.myadvocateaurora.us/php.net Previous Comments: ------------------------------------------------------------------------ [2021-11-09 15:29:24] php dot tgoeg at neverbox dot org On a sidenote (also for those fighting with nextcloud): If I uncomment . /etc/default/locale in /etc/apache2/envvars and therefore let Apache apply the default system locales, nextcloud is happy, presumably because setlocale() did not work as well, but still the set locale is correct/not "C"/one of those expected by nextcloud (as it got pushed into the environment upon the web server's start). This is in no means a fix for setlocale() not working but might be more in line with nikic's advice to stop using setlocale() altogether (and - at least that's how I interpret it - set the locale in a different, more global/reliable way). Maybe this should be part of the documentation? I don't quite understand why Apache on Debian does not use the system's default locale as its default as well, though, but maybe I don't have to :-) ------------------------------------------------------------------------ [2021-11-09 11:58:17] php dot tgoeg at neverbox dot org Sorry, our comments overlapped. I am only seeing this with nextcloud, all other PHP services I have tested until now work as they should, even with mod_perl2 enabled. I'll try to figure out whether this is a known issue of nextcloud. Do you mean that setting locales is generally discouraged, i.e. not only when using strftime()? ------------------------------------------------------------------------ [2021-11-09 11:54:33] php dot tgoeg at neverbox dot org I don't think it is enough to blame mod_perl2. The last working setup in my case was Apache 2.4.29 and mod_perl2 2.0.10, mod_php7.2 7.2.24 Now, on Apache 2.4.41 and mod_perl2 2.0.11, mod_php7.4 7.4.3 it does not work anymore. The bug report here states it does not work with php7.3, either. mod_perl2 has only changed its version in the patch level. I took a look at the changelog of mod_perl2 (which is not excessively large ;-) ): =item 2.0.11 October 5, 2019 Fix t/modules/apache_resource.t failures [Steve Hay] Fix [CVE-2011-2767] Arbitrary Perl code execution in the context of the user account via a user-owned .htaccess. Patch from bugs.debian.org #644169. [Jan Ingvoldstad <jani+debian-2011+@ifi.uio.no>] Fix potential test suite hangs due to pipelined response deadlocks. Patch from rt.cpan.org #82409. [Zefram <zefram@fysh.org>] Fix t/compat/request.t failures [Steve Hay] Fix use-after-free segfault in ap_server_config_defines seen on start-up on OpenBSD. [Found/fixed by Sam Vaughan/Joe Orton] Fix build with Perls earlier than 5.13.6. [Rainer Jung <rainer.jung@kippdata.de>] Fix filter/in_bbs_inject_header.t test failure with Apache 2.4.25+. [Stefan Fritsch <sf@sfritsch.de>] Fix apache/read.t test failure with Apache 2.4.25+. [Niko Tyni <ntyni@debian.org>] I also took a look at the exact diff of every file between the two versions at https://fossies.org/diffs/mod_perl/2.0.10_vs_2.0.11/ and the changes are so minor and/or irrelevant that I cannot imagine that a *change* in mod_perl2 can be the cause. That is to say there could be some change in mod_php >7.2 that introduced the incompatibility. Which might be necessary, I am not trying to blame anyone or any product here! I am not an active developer. I am just trying to inquire whether it might be possible to find a way of making php>7.2 work nicely with mod_perl2 as well. It has been working for years, after all. Just stating "there may be problems, so don't use it" feels like the easy way out. I guess there have been lots of Apaches out there serving perl and php happily in parallel. Or maybe the problem lies within apache itself? I can't say. ------------------------------------------------------------------------ [2021-11-09 11:18:02] nikic@php.net No idea what the specific interaction with mod_perl here is, but the general "workaround" for this issue is to stop using locales. PHP 8.1 deprecates strftime() to encourage migration towards alternatives that are not locale-based. ------------------------------------------------------------------------ [2021-11-06 19:17:40] requinix@php.net > Hopefully a fix/workaround can be created, or at least a note about this > conflict with mod_perl can be added to the documentation. Note that there is already a warning about using setlocale() in a multithreaded environment. > Warning > The locale information is maintained per process, not per thread. If you are > running PHP on a multithreaded server API , you may experience sudden changes > in locale settings while a script is running, though the script itself never > called setlocale(). This happens due to other scripts running in different > threads of the same process at the same time, changing the process-wide locale > using setlocale(). On Windows, locale information is maintained per thread as > of PHP 7.0.5. Whatever mod_perl is doing, it's in the same process and it's also screwing around with the locale. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=81596 -- Edit this bug report at https://bugs.php.net/bug.php?id=81596&edit=1