#21771 [Fbk->Opn]: variable names changing in turkish locale

From: Date: Thu, 30 Jan 2003 09:30:54 +0000
Subject: #21771 [Fbk->Opn]: variable names changing in turkish locale
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-31665@lists.php.net to get a copy of this message
ID: 21771 User updated by: tufan@metu.edu Reported By: tufan@metu.edu -Status: Feedback +Status: Open Bug Type: Variables related Operating System: linux kernel 2.4.18 PHP Version: 4.3.0 New Comment: Hmm... Indeed, this seems to be a apache problem. I took a look at the locale definition files for my OS (RedHat 7.2) and they seem to contain correct definitions of uppercase and lowercase letters (and their correspondance). when register_globals=on LC_CTYPE=tr_TR script.php?ID=some_value works perfectly. with the same settings, a var_dump($GLOBALS) gives: ["HTTP_ACCEPT_ENCODÝNG"]=> string(38) "deflate, gzip, x-gzip, identity, *;q=0" ["HTTP_CONNECTÝON"]=> string(14) "Keep-Alive, TE" ["HTTP_COOKÝE"]=> string(42) "PHPSESSID=4035cdd7974d97ccdcd79f9f711299c1" ["HTTP_COOKÝE2"]=> string(10) "$Version=1" Note the Ý in the variable names. However, names of variables such as SCRIPT_FILENAME, SERVER_ADMIN, or SERVER_SIGNATURE are correct, i.e. they contain an I and not an Ý. In fact, as much as I can see, variables with this problem are only those containing "COOKIE", "ENCODING", and "CONNECTION" words (whether they are global or indices in the _SERVER or HTTP_SERVER_VARS). The other variables containing "I" are correct. So my original problem was actually: Since the register_globals off and since apache did not pass cookies due to the incorrect variable name (when it started with LC_CTYPE=tr_TR), my session script didn't work. The same (or similar) problem occurs with mod_mime_magic.so, when enabled, apache does not start at all, giving the error message "Invalid command 'MIMEMagicFile', perhaps mis-spelled or...". So, unset LC_ALL LC_CTYPE=C (or LC_CTYPE=en_US) export LC_CTYPE works (but you should do apachectl stop and apachectl start, instead of apachectl restart). Since this is probably a problem at the server side itself, a setlocale(LC_ALL,"en_US") in the php script itself does not work (a friend of mine had recommended trying, I gave a shot). Thank you all for your help. Previous Comments: ------------------------------------------------------------------------ [2003-01-29 12:21:06] michael.mauch@gmx.de Tufan, can you please (after answering Sniper's questions) try and put the following lines into your apachectl: unset LC_ALL LC_CTYPE=C export LC_CTYPE See my comments on http://bugs.php.net/bug.php?id=21919 (in short: perhaps this is Apache's problem, because it happens also with mod_perl). ------------------------------------------------------------------------ [2003-01-28 23:19:43] sniper@php.net And are the names mangled in $GLOBALS too? try: <?php var_dump($GLOBALS); ?> And check the output for the _COOKIE / _SESSION indexes. ------------------------------------------------------------------------ [2003-01-21 19:10:33] sniper@php.net restore mangled summary and OS entries. ------------------------------------------------------------------------ [2003-01-21 11:26:21] hholzgra@php.net strange ... this was fixed for functions constants but should not affect variables, as these are case insensitive (so no conversions take place while resolving them) or is there something different going on with the super-globals? does this affect $_SESSION only? what if you have register_globals enabled and try to pass something like "...script.php?ID=test"? do you have $ID or $ÝD set in your script then? ------------------------------------------------------------------------ [2003-01-21 06:27:16] tufan@metu.edu by the way, it's turkish locale tr_TR iso8859-9 ------------------------------------------------------------------------ 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/21771 -- Edit this bug report at http://bugs.php.net/?id=21771&edit=1

« previous php.bugs (#31665) next »