I have never had a use for this feature. To me it introduces another
register_globals style atttack vector. I see no need why people need
to combine post/get/etc variables into the same superglobal. I
actually run unset($_REQUEST) on it at the top of my library to
discourage its use.
For third party products which use it I tell people to combine it
themselves by using array_merge() - like $_REQUEST =
array_merge($_POST, $_GET) etc...
Anyway can someone here please give me a good reasoning why it should
exist? It isn't as easily abused as register_globals but when people
have a session variable they want to access and use $_REQUEST for it I
could easily override it by using a GET param on the url (depending on
how the order of globals get processed)
Simply put, I see no reason why people would not want to clearly
define where they are getting their input from. If for some reason
there is some need to lazily code something I would still say to do
something like:
if(isset($_GET['foo'])) {
$foo = $_GET['foo'];
} elseif(isset($_POST['foo'])) {
$foo = $_POST['foo'];
} else {
$foo = 'default value';
}
... or just do the array merge.
But please someone maybe can justify this to me... I've been using
superglobals before I really understood how important they were and
then one day I see they introduced $_REQUEST and thought .. okay that
seems stupid. I finally am deciding to see if anyone can give me a
reason as to why this is useful and not just a lazy coding practice
that can lead to security risks.
You don't really know if your data is coming from GET, from POST, a
SESSION variable, etc...
I'd love to see a good discussion going on this. I might have
overlooked something important.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
