ID: 21771
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Variables related
Operating System: linux kernel 2.4.18
PHP Version: 4.3.0
New Comment:
let's close this then. You should propably report this to
the nice apache folks?
Previous Comments:
------------------------------------------------------------------------
[2003-01-30 11:00:38] [EMAIL PROTECTED]
Thanks for checking it out. Can you please close or "bogusify" the bug,
then (I can't, since I'm neither the submitter nor a PHP developer)?
As a last note: probably you will need to use something like
setlocale(LC_CTYPE,"tr_TR")
if you use strtoupper("i") etc., because otherwise PHP cannot know that
you want to get an uppercase I with dot.
------------------------------------------------------------------------
[2003-01-30 03:30:53] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2003-01-29 12:21:06] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
restore mangled summary and OS entries.
------------------------------------------------------------------------
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
