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:         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 <[email protected]>]

Fix potential test suite hangs due to pipelined response deadlocks. Patch
from rt.cpan.org #82409. [Zefram <[email protected]>]

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
<[email protected]>]

Fix filter/in_bbs_inject_header.t test failure with Apache 2.4.25+. [Stefan
Fritsch <[email protected]>]

Fix apache/read.t test failure with Apache 2.4.25+. [Niko Tyni
<[email protected]>]

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] [email protected]

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] [email protected]

> 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