Edit report at https://bugs.php.net/bug.php?id=81596&edit=1
ID: 81596
Comment by: php dot tgoeg at neverbox dot org
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:
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 :-)
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2021-11-06 19:09:19] cmanley at xs4all dot nl
According to the bug report in the link below, it seems that mod_perl is the culprit and that is
what I have installed too:
https://bugs.mageia.org/show_bug.cgi?id=25411
I wasn't able to reproduce the bug on a few other Debian 10.11 machines that I tested that did
not have mod_perl installed, so I assume that that is the case.
Hopefully a fix/workaround can be created, or at least a note about this conflict with mod_perl can
be added to the documentation.
------------------------------------------------------------------------
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