ID: 21771
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: linux kernel 2.4.18
PHP Version: 4.3.0
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2003-01-21 11:26:21] [EMAIL PROTECTED]
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?
------------------------------------------------------------------------
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
