Oops... This may not be related to php. It may be resulting from the turkish locale system itself. Let me investigate...

Can you provide some short example script?
And what locale causes this?

no code works. even the example in the php session documentation...
:)

<?php
session_start();
// Use $HTTP_SESSION_VARS with PHP 4.0.6 or less
if (!isset($_SESSION['count'])) {
    $_SESSION['count'] = 0;
} else {
    $_SESSION['count']++;
}
echo "Count {$_SESSION['count']}";
?>

by the way, it's turkish locale
tr_TR
iso8859-9

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?

restore mangled summary and OS entries.

And are the names mangled in $GLOBALS too?
try:

<?php var_dump($GLOBALS); ?>

And check the output for the _COOKIE / _SESSION indexes.

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).

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.

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.

let's close this then. You should propably report this to
the nice apache folks?