Re: config.w32.h...registry configuration

Preston L. Bannister wrote:

From: Andi Gutmans [mailto:andi@zend.com]

At 14:44 02/05/2002 +0300, Zeev Suraski wrote:

At 14:00 02/05/2002, derick@php.net wrote:

On Thu, 2 May 2002, Zeev Suraski wrote:

At 13:36 02/05/2002, derick@php.net wrote:

Some hosters use this feature to have different settigns for different customers...

Do you know this for a fact, or is this an estimate?

This is a fact, some hoster here in .nl uses it.

Ok then, perhaps we should have an .ini setting for it? :) The only two options I see, in that case are: - Add the binary path to the 3 existing lookup places - Add a configuration option that would determine whether CWD would be used, or the binary path would be used. I lean towards option #2 myself...

How about if we don't have a php.in in CWD we fall back to where php.exe is located?

On second thought we *can* have both backwards compatibility AND a default PHP installation that is more secure. The approach is simple: Load php.ini from PHP_CONFIG_FILE_PATH (unix) or the same directory as php.exe (Win32). Do *not* search CWD. Add an "include" directive to the INI file. Looking at the PHP implementation it looks like this could be a psuedo-setting with an on_modify function that loads as an INI file using the value as a file name. So sites that *want* to load from CWD would add: [PHP] include_ini = ./php.ini So sites that want to be less secure have make the above entry once in the site's global php.ini. It is a good thing to require action and thought on the part of the site to become less secure :).

Interesting idea. It doesn't have to be less secure at all. treat it just like .htaccess config parameters. Only certain ini settings can be override the global ini settings. Shane