I agree about needing to clean up some of the other PHP ini options first. I started creating an "uber-clean" project not long ago, with my first goal being to get PHP into a 'known-good' state no matter what the end-user has set up as a configuration option.
E_ALL & E_NOTICE track_vars ON register_globals OFF magic_quotes OFF I tried some of the options listed in... http://www.php.net/manual/en/configuration.php ...but was disappointed that not all options can be set by a script. It appears as though register_globals must be set using a configuration directive, and all of the .htaccess files I tried to create caused apache to give back 500's Internal Server Errors. (Probably because I'm really bad at configuring apache ;^) As it stands right now, I'm thinking of: <?php $exemptions = array( 'GLOBALS', '_GET', '_POST', '_REQUEST', ... ); foreach( array_keys( $GLOBALS ) as $to_clear ) { if( !in_array( $exemptions, $to_clear ) ) unset($$to_clear); } ?> To 'fake' unregistering all globals at the script level. Personally, I'm in favor of removing the HTTP_*_VARS (or at least having the option to remove them) because they are scheduled for depracation. Right now, it's a mess to have to deal with both types of variables, especially in new projects, and if people are not supposed to be using them, might as well let them be turned off. :^) The other exciting thing I've heard about is the ability to "su" for scripts, especially for PHP scripts which I write, hoping that they can place data into the user's home directory (ie: a photo album thumbnailer and manager). I haven't downloaded and played with that extension yet, but it fills an important gap to be able to "su $owner" within a PHP script. --Robert On Fri, 25 Jan 2002 03:29:11 -0600, Yasuo Ohgaki wrote: > Derick Rethans wrote: >>>Are we going to depreciate long track vars? Does anyone mind if I add >>>ini option "long_track_vars" to turn on and off long track vars? >> Why do we need it? >> > Since I use Japanese for my web sites. I usually convert all user inputs > to different format. For example, multi-byte(full width) number to > single-byte(half width) number. > > If there are $HTTP_*_VARS, I could end up with having 2 different values > even if I don't need old values. If $HTTP_*_VARS does not exist, I can > save memory & CPU time a bit. (sometimes a lot) > > However, I also think it may *not* be a good idea. If there is a ini > option for disabling long track vars, PHP application developers may > have headache with this... It may be ok for PHP5, though. > > Anyway, I'll wait for a while. We need to fix "variables_order" and > "register_globals" issue first. > -- PHP Development 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]
