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

[email protected] ("php dot tgoeg at neverbox dot org")
Newsgroups php.doc.bugs
Message-ID <[email protected]> 
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:

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.


Previous Comments:
------------------------------------------------------------------------
[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.

------------------------------------------------------------------------
[2021-11-06 18:49:22] cmanley at xs4all dot nl

Other locale aware functions also do not respect the set locale in Apache such as:
printf("%.2f\n", 1000000.123);
which outputs 1000000.12 in Apache and 1000000,12 in the CLI (after setting locale   succesfully to nl_NL.utf8

------------------------------------------------------------------------
[2021-11-06 18:04:15] cmanley at xs4all dot nl

Description:
------------
This is bizar.
Printing the output of strftime('%c') in my preferred locale nl_NL.utf8 returns the expected output in the CLI version of PHP but in the Apache module it returns an English datetime string even though setlocale succeeded.

Checks done to exclude noob causes:
- After setting the locale in php, I check that it succeeded with setlocale(LC_TIME, 0) and it returns my preferred locale.
- The locale exists in the output of "locale -a".
- "sudo pkg-reconfigure locales" done
- Apache restarted
- Machine even restarted.
- The installed CLI and Apache PHP packages are the exact same version.


Test script:
---------------
<?php
ini_set('default_mimetype','text/plain');
print "locale -a:\n" . shell_exec('locale -a') . "\n\n";
date_default_timezone_set('Europe/Amsterdam');
setlocale(LC_TIME, "nl_NL.utf8");
print 'locale after setlocale: ' . setlocale(LC_TIME, 0) . "\n";
print 'php apache ' . phpversion() . ' strftime %c: ' . strftime("%c\n");
print 'php cli    ' . shell_exec('php -r \'print phpversion();\'') . ' strftime %c: ' . shell_exec('php -r \'setlocale(LC_TIME, "nl_NL.utf8"); print strftime("%c\\n");\'');


Expected result:
----------------
locale -a:
C
C.UTF-8
POSIX
de_DE
de_DE.iso88591
de_DE.iso885915@euro
de_DE.utf8
de_DE@euro
deutsch
dutch
en_GB
en_GB.iso88591
en_GB.iso885915
en_GB.utf8
en_US
en_US.iso88591
en_US.iso885915
en_US.utf8
fr_FR
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
fr_FR@euro
french
german
nl_NL
nl_NL.iso88591
nl_NL.iso885915@euro
nl_NL.utf8
nl_NL@euro


locale after setlocale: nl_NL.utf8
php apache 7.3.31-1~deb10u1 strftime %c: za 06 nov 2021 18:46:33 CET
php cli    7.3.31-1~deb10u1 strftime %c: za 06 nov 2021 18:46:33 CET

Actual result:
--------------
locale -a:
C
C.UTF-8
POSIX
de_DE
de_DE.iso88591
de_DE.iso885915@euro
de_DE.utf8
de_DE@euro
deutsch
dutch
en_GB
en_GB.iso88591
en_GB.iso885915
en_GB.utf8
en_US
en_US.iso88591
en_US.iso885915
en_US.utf8
fr_FR
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
fr_FR@euro
french
german
nl_NL
nl_NL.iso88591
nl_NL.iso885915@euro
nl_NL.utf8
nl_NL@euro


locale after setlocale: nl_NL.utf8
php apache 7.3.31-1~deb10u1 strftime %c: Sat Nov  6 18:46:33 2021
php cli    7.3.31-1~deb10u1 strftime %c: za 06 nov 2021 18:46:33 CET


------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=81596&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.