[PHP] Re: RFE: $HTTP_POST_VARS = $_POST;
Thanks for your responses (again), it is an unfortunate situation that $HTTP_*_VARS must be retained for backwards compatibility until at least the hypothetical PHPv5.0 mark. Having also read in this group that define() does not support complicated constants, I'm guessing that it's not currently possible to force all predefined variables to be read only (although that seems like the best solution in the long run). Regarding the documenation- it is not clear, and is not emphasized that the arrays are disjoint. Note: Some of these arrays had old names, e.g. $HTTP_GET_VARS. These names still work, but we encourage users to switch to the new shorter, and auto-global versions. $HTTP_GET_VARS An associative array of variables passed to the current script via the HTTP GET method. $_GET An associative array of variables passed to the current script via the HTTP GET method. Automatically global in any scope. Introduced in PHP 4.1.0. ...this will be the last message I'll bother the lists with about this behaviour. I just wanted to make sure that you guys who are developing this stuff receive feedback about how this new behaviour is working out for people using the new versions of PHP. :^) I'm 100% in favor of treating these arrays as read-only, but it would be very nice if E_NOTICE's were thrown when builtin arrays are modified, or simply to treat them as unchangeable constants. Something to keep in mind if we ever get the ability to say: define( '_GET', $_GET ); ...which is interesting in itself... imagine: echo _GET['blah']; ...instead of: echo $_GET['blah']; ...since _GET/etc... are already auto-globals, and you don't want them to be used as left-hand-side values, it seems like they're very close to acting like constants already. Just a thought. ;^) Thanks a bunch! --Robert On Thu, 24 Jan 2002 16:01:24 -0600, Lars Torben Wilson wrote: On Thu, 2002-01-24 at 13:42, Rasmus Lerdorf wrote: I think the real answer here is to treat these as read-only arrays. ie. never use them on the left side of the '=' and you will never run into problems. Or if you do, be consistent and use the same array all the time. You are writing your code with the assumption that these two arrays are the same. Where does this assumption come from? Hopefully not the documentation. -Rasmus No, they are properly--if lightly--documented on the following pages: http://www.php.net/manual/en/language.variables.predefined.php http://www.php.net/release_4_1_0.php Robert, the $HTTP_*_VARS have, indeed, been deprecated, and this is noted in the manual. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Re: RFE: $HTTP_POST_VARS = $_POST;
I disagree based simply on two points:
a) Ideally, the $HTTP_POST/GET and $_POST/$_GET vars should be treated
as read only.
b) There is no good reason to mix the two. Consistancy is the ideal. If
you are working on an existing project, and you have the implied need to
assign values to keys to request variables, then continue to use
$HTTP_GET_VARS. There is no reason to *not* use $_GET/POST if you're
working on a new project, and even less of a reason to MIX
$HTTP_POST/GET and $_POST/GET.
c) What would you expect to happen if you altered a request variable
that was stuffed in $_REQUEST?
d) $GLOBALS['HTTP_POST_VARS']['my_form_var'] is waaay too long. When
I code, I want to complete it as quickly as I can, while maintaining
quality. Things get too complex when I have to use 40 characters just to
access a single variable.
Of course, that's just one LAMP's opinion.
Mike
Robert Ames wrote:
This is the second time in as many weeks that we have been bitten by the
fact that $_POST != $HTTP_POST_VARS; Attached is a real-world example of
why it is currently bad practice to use the _POST variables.
I cannot recommend that anyone use $_POST[..] in their scripts.
$GLOBALS['HTTP_POST_VARS'][..] is a much safer, portable, and sane
solution, unless $HTTP_POST_VARS is marked as depracated, scheduled to be
phased out.
For those new to the problem, $_GET and $HTTP_GET_VARS are two totally
separate arrays which happen to hold the same data at the beginning of
script execution. After script execution has begun, it is VERY DANGEROUS
to modify the data contained in either of these arrays, because changes
in one are not propagated to the other.
The simplest example script is:
?php
echo $_GET['test'];
echo $HTTP_GET_VARS['test'];
$_GET['test'] = 'changed.';
echo $_GET['test'];
echo $HTTP_GET_VARS['test'];
?
...The second set of echo statements will print two different values.
The situation is worse when you are trying to integrate the usage of
$_GET/$_POST into scripts which already make use of $HTTP_*_VARS.
The following script is my real-world example of a difficult to trace
logic bug caused by $_POST != $HTTP_POST_VARS.
The situation is that we have a form with a radio button toggling between
two input elements as follows.
PRICING:
( ) Fixed: $[__]
( ) Negot: $[__]
The radio field is named option, and the two input fields are named
asking1 and asking2 respectively. On the back end, we store whether
the user selected fixed or negotiable, and then 'push' asking1 or
asking2 into a variable called asking_price. We don't care which field
they type the price into, but asking1 and asking2 must be named
differently so that the browser will not stomp asking prices over each
other when posting the information.
Our function gpc stands for Get/Post/Cookie, and is very similar to
the new $_REQUEST array, except that it returns FALSE if nothing was
posted, preventing us from having to do:
if( isset($_REQUEST['blah']) )
$result = $_REQUEST['blah'];
(because we run with E_NOTICE E_ALL, and have register_globals turned off)
...instead, we can say:
$result = gpc('blah');
...anyway, we've been using PHP for a while now (since well before 4.1
;^), and already have many many scripts and libraries which use the
HTTP_*_VARS method of accessing things. It is unsafe to use $_GET and
$HTTP_GET_VARS in the same environment.
My proposed solutions again:
1) Temporary workaround: $HTTP_GET_VARS = $_GET;
2) Throw an E_NOTICE if $HTTP_*_VARS or $_* is used as the left-hand side
of an assignment. (ie: officially discourage changing $HTTP_*_VARS)
3) Propagate any changes made to $_GET over to $HTTP_GET_VARS and
$_REQUEST.
#1 works for the most part, but changes is $_GET are not propagated into
$_REQUEST, which opens the door for more data inconsistency issues.
#2 could possibly be implemented by making $HTTP_*_VARS and $_* into
constants... forcing them to be read only.
#3 sounds like it would be annoying to implement, but would make it
easiest for end-users to use PHP, and have some nice things happen
'magically'.
--Robert
(crossposting to php.general because I'm sure other people might be
running into this problem as well).
?PHP
## example script
/* return the user-submitted value of $varname, or false if not found */
function gpc( $varname )
{
if( isset( $GLOBALS['HTTP_GET_VARS'][$varname] ) )
return( $GLOBALS['HTTP_GET_VARS'][$varname];
elseif( isset( $GLOBALS['HTTP_POST_VARS'][$varname] ) )
return( $GLOBALS['HTTP_POST_VARS'][$varname];
elseif( isset( $GLOBALS['HTTP_COOKIE_VARS'][$varname] ) )
return( $GLOBALS['HTTP_COOKIE_VARS'][$varname];
else
return( FALSE );
}
$option = gpc('price_option');
if ( $option == 'fixed' )
{
$_POST['asking_price'] = isset($_POST['asking1']) ? $_POST['asking1'] : '';
}
elseif ( $option ==
[PHP] Re: RFE: $HTTP_POST_VARS = $_POST;
Just a correction on that. It started as two points, then grew into 4..
I should proof read more often ;)
Mike
Mike Eheler wrote:
I disagree based simply on two points:
a) Ideally, the $HTTP_POST/GET and $_POST/$_GET vars should be treated
as read only.
b) There is no good reason to mix the two. Consistancy is the ideal. If
you are working on an existing project, and you have the implied need to
assign values to keys to request variables, then continue to use
$HTTP_GET_VARS. There is no reason to *not* use $_GET/POST if you're
working on a new project, and even less of a reason to MIX
$HTTP_POST/GET and $_POST/GET.
c) What would you expect to happen if you altered a request variable
that was stuffed in $_REQUEST?
d) $GLOBALS['HTTP_POST_VARS']['my_form_var'] is waaay too long. When
I code, I want to complete it as quickly as I can, while maintaining
quality. Things get too complex when I have to use 40 characters just to
access a single variable.
Of course, that's just one LAMP's opinion.
Mike
Robert Ames wrote:
This is the second time in as many weeks that we have been bitten by the
fact that $_POST != $HTTP_POST_VARS; Attached is a real-world example of
why it is currently bad practice to use the _POST variables.
I cannot recommend that anyone use $_POST[..] in their scripts.
$GLOBALS['HTTP_POST_VARS'][..] is a much safer, portable, and sane
solution, unless $HTTP_POST_VARS is marked as depracated, scheduled to be
phased out.
For those new to the problem, $_GET and $HTTP_GET_VARS are two totally
separate arrays which happen to hold the same data at the beginning of
script execution. After script execution has begun, it is VERY DANGEROUS
to modify the data contained in either of these arrays, because changes
in one are not propagated to the other.
The simplest example script is:
?php
echo $_GET['test'];
echo $HTTP_GET_VARS['test'];
$_GET['test'] = 'changed.';
echo $_GET['test'];
echo $HTTP_GET_VARS['test'];
?
...The second set of echo statements will print two different values.
The situation is worse when you are trying to integrate the usage of
$_GET/$_POST into scripts which already make use of $HTTP_*_VARS.
The following script is my real-world example of a difficult to trace
logic bug caused by $_POST != $HTTP_POST_VARS.
The situation is that we have a form with a radio button toggling between
two input elements as follows.
PRICING:
( ) Fixed: $[__]
( ) Negot: $[__]
The radio field is named option, and the two input fields are named
asking1 and asking2 respectively. On the back end, we store whether
the user selected fixed or negotiable, and then 'push' asking1 or
asking2 into a variable called asking_price. We don't care which field
they type the price into, but asking1 and asking2 must be named
differently so that the browser will not stomp asking prices over each
other when posting the information.
Our function gpc stands for Get/Post/Cookie, and is very similar to
the new $_REQUEST array, except that it returns FALSE if nothing was
posted, preventing us from having to do: if(
isset($_REQUEST['blah']) ) $result = $_REQUEST['blah'];
(because we run with E_NOTICE E_ALL, and have register_globals
turned off)
...instead, we can say:
$result = gpc('blah');
...anyway, we've been using PHP for a while now (since well before 4.1
;^), and already have many many scripts and libraries which use the
HTTP_*_VARS method of accessing things. It is unsafe to use $_GET and
$HTTP_GET_VARS in the same environment.
My proposed solutions again:
1) Temporary workaround: $HTTP_GET_VARS = $_GET;
2) Throw an E_NOTICE if $HTTP_*_VARS or $_* is used as the left-hand side
of an assignment. (ie: officially discourage changing $HTTP_*_VARS)
3) Propagate any changes made to $_GET over to $HTTP_GET_VARS and
$_REQUEST.
#1 works for the most part, but changes is $_GET are not propagated into
$_REQUEST, which opens the door for more data inconsistency issues.
#2 could possibly be implemented by making $HTTP_*_VARS and $_* into
constants... forcing them to be read only.
#3 sounds like it would be annoying to implement, but would make it
easiest for end-users to use PHP, and have some nice things happen
'magically'.
--Robert
(crossposting to php.general because I'm sure other people might be
running into this problem as well).
?PHP
## example script
/* return the user-submitted value of $varname, or false if not found */
function gpc( $varname )
{
if( isset( $GLOBALS['HTTP_GET_VARS'][$varname] ) )
return( $GLOBALS['HTTP_GET_VARS'][$varname];
elseif( isset( $GLOBALS['HTTP_POST_VARS'][$varname] ) )
return( $GLOBALS['HTTP_POST_VARS'][$varname];
elseif( isset( $GLOBALS['HTTP_COOKIE_VARS'][$varname] ) )
return( $GLOBALS['HTTP_COOKIE_VARS'][$varname];
else
return( FALSE );
}
$option = gpc('price_option');
if (
[PHP] Re: RFE: $HTTP_POST_VARS = $_POST;
Mike- If you're a LAMP user, then this vi mapping might help you out ;^) :imap ~P $GLOBALS['HTTP_POST_VARS']['']Eschi ...and I believe I have addressed most of your points in my previous posting on the subject. Forgive me if you've already read it, or if it doesn't explain my position fully. http://marc.theaimsgroup.com/?l=php-devm=101061406505517w=2 To address your points: a) Yes, please. Add and E_NOTICE or E_WARNING if any predefined array is assigned to. A more radical approach would be to do away with $_GET, and use _GET instead (a global constant. see my post earlier today). b) There is a very good reason to mix the two. We have a site/project with at least 2000 scripts/files/directories. Some parts are old and stable. They use HTTP_*_VARS. In our newer code, we'd like to use $_GET and friends, but there's no guarantee that we aren't depending on changing $_GET or $HTTP_GET_VARS (for certain library functions, paging functions, sorting functions, etc). c) Therein lies the problem. I gave some thought to it and responded in my previous message (at the URL above), but my current opinion is that the best way to handle it is to treat all predefined variable arrays as constants, since changing all of them is officially frowned upon. :^) d) Vi is you friend. ;^) Thanks for your response, it's interesting to hear other people's opinions on the matter. --Robert On Thu, 24 Jan 2002 17:45:34 -0600, Mike Eheler wrote: I disagree based simply on two points: a) Ideally, the $HTTP_POST/GET and $_POST/$_GET vars should be treated as read only. b) There is no good reason to mix the two. Consistancy is the ideal. If you are working on an existing project, and you have the implied need to assign values to keys to request variables, then continue to use $HTTP_GET_VARS. There is no reason to *not* use $_GET/POST if you're working on a new project, and even less of a reason to MIX $HTTP_POST/GET and $_POST/GET. c) What would you expect to happen if you altered a request variable that was stuffed in $_REQUEST? d) $GLOBALS['HTTP_POST_VARS']['my_form_var'] is waaay too long. When I code, I want to complete it as quickly as I can, while maintaining quality. Things get too complex when I have to use 40 characters just to access a single variable. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
