|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #32337 Per Directory Values registry not working
Submitted: 2005-03-16 14:30 UTC Modified: 2021-02-21 04:22 UTC
Avg. Score:4.2 ± 0.8
Reproduced:4 of 4 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (25.0%)
From: jsonger at maintree dot com Assigned: cmb (profile)
Status: No Feedback Package: *Configuration Issues
PHP Version: 5.0.3 OS: Windows 2000
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
41 - 30 = ?
Subscribe to this entry?

 [2005-03-16 14:30 UTC] jsonger at maintree dot com
In both 5.0.3 and 5.0.4RC1 built on Mar 16 2005 10:19:30, the ISAPI module is not using the Per Directory Values registry settings.

I have not tried this with the CGI version.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-17 10:30 UTC] baricak at post dot cz
Hello, I have the same problems. 
I just installed on IIS5 with Windows 2000 as ISAPI module and Per Directory Values does not work with some of the settings.
For instance, display_errors directive works fine, but register_globals DOES NOT.
The another problem is, phpinfo() output is not correct. When I set display_errors in the registry to a different value as in php.ini, in the output of phpinfo() the value of "local" column stays  untouched, even though the system reactions are like the new value was set.
The Version 5.0.3 has the same problems.
 [2005-03-17 10:38 UTC] baricak at post dot cz
And Last But not Least: When I try to 

echo ini_get(<ini_directive>);

,the value is correct as set in the registry, but the system does not work like it says- phpinfo() returns the old php.ini value and the system reacts as only the old php.ini was set.
 [2005-03-18 19:16 UTC]
This registry thing does NOT work for any option.
It's just before script execution so it techinally can't work with e.g. register_globals.

 [2005-03-18 20:10 UTC] jsonger at maintree dot com
It read point needs to be adjusted then so it can work for register_globals.  I don't want to for register_globals on for everyone just because a couple of my customers have older scripts that like it.

I also don't understand why this is such a problem since the Apache module can do it with a .htaccess file.  In a practicle since, I don't see a difference between the .htaccess file in apache and the registry in IIS.
 [2005-03-19 21:54 UTC] baricak at post dot cz, i am sorry, what is your point? I was setting up different servers last week, with Apache and .htaccess there was not any problem. Just because these scripts have to be at the IIS, I do not come around it. I thought the sense of Per Directory Values Windows Registry paradigm was reading out the registry at the starting point of IIS, and setting local values for some directories, for specific configuration settings.
According to register_globals is of type PHP_INI_PERDIR, which actually means you can set it locally. Moreover, with Apache1.3 and Apache2.0 this actually WORKS! So what's wrong with the Windows implementation?
I would not turn my scripts to register_globals on, but just as jsonger I have some external scripts running on this server. Thats why I want to have php.ini set to register_globals off and turn it on just for the foreign scripts...
 [2005-03-21 12:28 UTC]
Documented for now in XML sources.
 [2016-06-13 13:18 UTC]
-Package: Feature/Change Request +Package: *Configuration Issues
 [2021-02-11 13:12 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-02-11 13:12 UTC]
ISAPI has been retired long ago, so it appears that this feature
request is obsolete, or am I missing something?
 [2021-02-21 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Jul 03 07:03:35 2022 UTC