Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: No, it was my fault. I thought, session variables were primarily available in $_SESSION, then written to the global context with variables order. Previous Comments: [2002-03-14 02:41:00] [EMAIL PROTECTED] Funny, the docs say the S stands for Server variables: http://www.php.net/manual/en/configuration.php#ini.register-globals Furthermore, it doesn't make any comment whatsoever as to the nature of the HTTP_* variables, though the predefined variables page claims some are Apache, and some are environment. http://www.php.net/manual/en/language.variables.predefined.php In this instance, it says HTTP_ACCEPT_CHARSET and HTTP_REFERER are both Apache (presumably, Server, yes?) variables. So are you saying this is a documentation bug? [2002-03-14 02:10:20] [EMAIL PROTECTED] sorry, it's EGPCS by default. [2002-03-14 02:08:47] [EMAIL PROTECTED] are you sure? HTTP_* variables are environment variables. the variables_order is normally set to EGCPS (if not, change it) where S is not Server Variables but SESSION Variables. this behaviour thus looks intentional - first HTTP_ACCEPT_CHARSET is set by the environment, then you overwrite it with a GET. [2002-03-13 18:56:56] [EMAIL PROTECTED] Incidentally, our variables_order flag is set to GPCS. [2002-03-13 18:47:07] [EMAIL PROTECTED] Been there, done that. So, why don't any of the other variables from purportedly the same source (s/b S, yes?) change when I request this on the command line? The point is that either (a) the docs are broken here and the two variables in question aren't from the server, or (b) the EGPCS processing is broken, take your pick. 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/16052 -- Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
read the manual on variables_order
Previous Comments:
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
Previous Comments:
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
Incidentally, our variables_order flag is set to GPCS.
Previous Comments:
[2002-03-13 18:47:07] [EMAIL PROTECTED]
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
are you sure? HTTP_* variables are environment variables. the
variables_order is normally set to EGCPS (if not, change it) where S
is not Server Variables but SESSION Variables. this behaviour thus
looks intentional - first HTTP_ACCEPT_CHARSET is set by the
environment, then you overwrite it with a GET.
Previous Comments:
[2002-03-13 18:56:56] [EMAIL PROTECTED]
Incidentally, our variables_order flag is set to GPCS.
[2002-03-13 18:47:07] [EMAIL PROTECTED]
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
sorry, it's EGPCS by default.
Previous Comments:
[2002-03-14 02:08:47] [EMAIL PROTECTED]
are you sure? HTTP_* variables are environment variables. the
variables_order is normally set to EGCPS (if not, change it) where S
is not Server Variables but SESSION Variables. this behaviour thus
looks intentional - first HTTP_ACCEPT_CHARSET is set by the
environment, then you overwrite it with a GET.
[2002-03-13 18:56:56] [EMAIL PROTECTED]
Incidentally, our variables_order flag is set to GPCS.
[2002-03-13 18:47:07] [EMAIL PROTECTED]
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
