php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #81596 PHP in apache with mod_perl ignores locale, while CLI version doesn't.
Submitted: 2021-11-06 18:04 UTC Modified: 2021-11-09 11:18 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: cmanley at xs4all dot nl Assigned:
Status: Open Package: Apache2 related
PHP Version: 7.3.32 OS: Debian 10.11
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: cmanley at xs4all dot nl
New email:
PHP Version: OS:

 

 [2021-11-06 18:04 UTC] 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-11-06 18:49 UTC] cmanley at xs4all dot nl
-Package: Date/time related +Package: Apache2 related
 [2021-11-06 18:49 UTC] 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 19:09 UTC] cmanley at xs4all dot nl
-Summary: strftime: PHP Apache module ignores locale, while CLI module doesn't. +Summary: PHP in apache with mod_perl ignores locale, while CLI version doesn't.
 [2021-11-06 19:09 UTC] 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 19:17 UTC] requinix@php.net
-Type: Bug +Type: Documentation Problem
 [2021-11-06 19:17 UTC] 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-09 11:18 UTC] 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-09 11:54 UTC] 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:58 UTC] 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 15:29 UTC] 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 :-)
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Nov 29 08:05:54 2022 UTC