#27421 [Com]: mbstring.func_overload set in .htaccess becomes global
ID: 27421
Comment by: info at bert-jan dot com
Reported By: php at strategma dot bg
Status: No Feedback
Bug Type: mbstring related
Operating System: Slackware 9.1 kernel: 2.4.22
PHP Version: 4.3.4
New Comment:
I've tried it on another server running Debian unstable with PHP
5.2.0-8 on Apache 2.2.3 both installed with apt-get and the same issue
is reproducible here too.
Previous Comments:
[2007-01-17 21:57:23] info at bert-jan dot com
FYI: I'm running Slamd64 (Slackware x86-64) with Apache and PHP
installed from source.
Apache:
./configure \
--enable-ssl \
--with-ssl \
--enable-proxy \
--enable-proxy-connect \
--enable-proxy-ftp \
--enable-proxy-http \
--enable-rewrite \
--enable-deflate \
--enable-so \
PHP:
./configure \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql=/usr/local/mysql/ \
--with-zlib \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--with-freetype-dir \
--enable-ftp \
--with-bz2 \
--with-gzip \
--with-openssl \
--enable-shmop \
--enable-posix \
--enable-pcntl \
--enable-sysvsem \
--enable-sysvshm \
--enable-iconv \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--enable-mbstring \
--enable-shmop \
--enable-soap \
--enable-memory-limit
[2007-01-17 21:41:53] info at bert-jan dot com
I'm having this exact same issue on PHP 5.1.6 on Apache 2.0.59. Putting
the mbstring.* settings in the VirtualHost-directive or in .htaccess
doesn't seem to make a difference. The settings are 'leaked' to other
vhosts who start to randomly malfunction and report errors like
Warning: mb_strrpos() [function.mb-strrpos]: Unknown encoding "6" in
/home/bertjan/public_html/functions.php on line 307
As stated in the other comments, the erroneous behaviour isn't
consistent. Sometimes it works but more often it doesn't. The trouble
is quite evident in e.g. Squirrelmail or phpMyAdmin.
[2006-11-17 15:02:35] christophe at saout dot de
I'm still seing a similar problem in PHP 4.4.4.
The site has globally turned on mbstring.func_overload in php.ini.
When turning it off in a .htaccess for a specific directory, the
behaviour experienced by the scripts in that directory becomes random.
Sometimes it works as expected (especially after a fresh start of
apache), but most of the time the script is using the overloaded
mbstring functions e.g. for substr, even though
ini_get("mbstring.func_overload") returns 0.
It looks like the save/restore in the mbstring module somehow gets
confused and leaks overloaded functions between apache requests.
Assuming this is a variant of the bug experienced by the original bug
author, I'm posting this here and requesting a re-opening.
[2004-03-13 05:01:58] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2004-03-07 06:10:30] [EMAIL PROTECTED]
Could you try php-4.3.5RC3 instead of the current CVS snapshots?
http://qa.php.net/
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
http://bugs.php.net/27421
--
Edit this bug report at http://bugs.php.net/?id=27421&edit=1
#27421 [Com]: mbstring.func_overload set in .htaccess becomes global
ID: 27421
Comment by: info at bert-jan dot com
Reported By: php at strategma dot bg
Status: No Feedback
Bug Type: mbstring related
Operating System: Slackware 9.1 kernel: 2.4.22
PHP Version: 4.3.4
New Comment:
FYI: I'm running Slamd64 (Slackware x86-64) with Apache and PHP
installed from source.
Apache:
./configure \
--enable-ssl \
--with-ssl \
--enable-proxy \
--enable-proxy-connect \
--enable-proxy-ftp \
--enable-proxy-http \
--enable-rewrite \
--enable-deflate \
--enable-so \
PHP:
./configure \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql=/usr/local/mysql/ \
--with-zlib \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--with-freetype-dir \
--enable-ftp \
--with-bz2 \
--with-gzip \
--with-openssl \
--enable-shmop \
--enable-posix \
--enable-pcntl \
--enable-sysvsem \
--enable-sysvshm \
--enable-iconv \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--enable-mbstring \
--enable-shmop \
--enable-soap \
--enable-memory-limit
Previous Comments:
[2007-01-17 21:41:53] info at bert-jan dot com
I'm having this exact same issue on PHP 5.1.6 on Apache 2.0.59. Putting
the mbstring.* settings in the VirtualHost-directive or in .htaccess
doesn't seem to make a difference. The settings are 'leaked' to other
vhosts who start to randomly malfunction and report errors like
Warning: mb_strrpos() [function.mb-strrpos]: Unknown encoding "6" in
/home/bertjan/public_html/functions.php on line 307
As stated in the other comments, the erroneous behaviour isn't
consistent. Sometimes it works but more often it doesn't. The trouble
is quite evident in e.g. Squirrelmail or phpMyAdmin.
[2006-11-17 15:02:35] christophe at saout dot de
I'm still seing a similar problem in PHP 4.4.4.
The site has globally turned on mbstring.func_overload in php.ini.
When turning it off in a .htaccess for a specific directory, the
behaviour experienced by the scripts in that directory becomes random.
Sometimes it works as expected (especially after a fresh start of
apache), but most of the time the script is using the overloaded
mbstring functions e.g. for substr, even though
ini_get("mbstring.func_overload") returns 0.
It looks like the save/restore in the mbstring module somehow gets
confused and leaks overloaded functions between apache requests.
Assuming this is a variant of the bug experienced by the original bug
author, I'm posting this here and requesting a re-opening.
[2004-03-13 05:01:58] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2004-03-07 06:10:30] [EMAIL PROTECTED]
Could you try php-4.3.5RC3 instead of the current CVS snapshots?
http://qa.php.net/
[2004-03-06 14:22:29] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
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
http://bugs.php.net/27421
--
Edit this bug report at http://bugs.php.net/?id=27421&edit=1
#27421 [Com]: mbstring.func_overload set in .htaccess becomes global
ID: 27421
Comment by: info at bert-jan dot com
Reported By: php at strategma dot bg
Status: No Feedback
Bug Type: mbstring related
Operating System: Slackware 9.1 kernel: 2.4.22
PHP Version: 4.3.4
New Comment:
I'm having this exact same issue on PHP 5.1.6 on Apache 2.0.59. Putting
the mbstring.* settings in the VirtualHost-directive or in .htaccess
doesn't seem to make a difference. The settings are 'leaked' to other
vhosts who start to randomly malfunction and report errors like
Warning: mb_strrpos() [function.mb-strrpos]: Unknown encoding "6" in
/home/bertjan/public_html/functions.php on line 307
As stated in the other comments, the erroneous behaviour isn't
consistent. Sometimes it works but more often it doesn't. The trouble
is quite evident in e.g. Squirrelmail or phpMyAdmin.
Previous Comments:
[2006-11-17 15:02:35] christophe at saout dot de
I'm still seing a similar problem in PHP 4.4.4.
The site has globally turned on mbstring.func_overload in php.ini.
When turning it off in a .htaccess for a specific directory, the
behaviour experienced by the scripts in that directory becomes random.
Sometimes it works as expected (especially after a fresh start of
apache), but most of the time the script is using the overloaded
mbstring functions e.g. for substr, even though
ini_get("mbstring.func_overload") returns 0.
It looks like the save/restore in the mbstring module somehow gets
confused and leaks overloaded functions between apache requests.
Assuming this is a variant of the bug experienced by the original bug
author, I'm posting this here and requesting a re-opening.
[2004-03-13 05:01:58] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2004-03-07 06:10:30] [EMAIL PROTECTED]
Could you try php-4.3.5RC3 instead of the current CVS snapshots?
http://qa.php.net/
[2004-03-06 14:22:29] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2004-02-27 10:12:38] php at strategma dot bg
Description:
./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--prefix=/usr/local/php --enable-mbstring \
--with-mbregex
apache version 1.3.29
we set in .htaccess
PHP_VALUE mbstring.internal_encoding UTF-8
PHP_VALUE default_charset UTF-8
PHP_VALUE mbstring.http_output UTF-8
PHP_VALUE mbstring.encoding_translation On
PHP_VALUE mbstring.detect_order UTF-8
PHP_VALUE mbstring.func_overload 7
for specific site, but string functions on other web sites at the same
apache doest work (other sites use CP1251 enconding).
The string functions stop to work when anyone access the unicode site.
When we stop apache and start it again cp1251 string functions work
properly.
we tryed the same configuration in the directive at
apache's
httpd.conf for the UNICODE site
and in the but it is the same result
With or without setlocale(LC_ALL,"bg_BG.CP1251") or
bg_BG or bg_BG.UTF-8 we have tryed all combinations and it still doesnt
work.
thanks in advance
Reproduce code:
---
Expected result:
Òîâà å òåñò
Actual result:
--
Òîâà
--
Edit this bug report at http://bugs.php.net/?id=27421&edit=1
