On Fri, Sep 11, 2009 at 10:49 AM, Arno Kuhl <akuhl@xxxxxxxxxxxx> wrote:
> You're right, you can't change register_globals in script but you can query
> it in script, which is what I was referring to. There aren't many settings
> you can change in script, about the only useful one that we use is
> max_execution_time. Either way, what I find in testing is that on our host
> php returns the value reported in phpinfo as the "local value" which is
> correct, because that's the value that should be in effect (combination of
> httpd.conf, php.ini, .htaccess and values set in script), but the value
> that's actually in effect is the master value.
>
> For example, if php.ini sets register_globals on and .htaccess sets
> register_globals off, then the code
>
> ini_get('register_globals')
>
> reports register_globals is off (it's reporting the local value) but in fact
> register_globals is on. In this particular case our app would stop with a
> configuration error if it found register_globals on, but it thinks it's off
> so happily carries on.
>
> Local is supposed to override master values but they have master overriding
> local values. I'm trying to confirm that local is supposed to override
> master, and find a proper reference that I can show to my hosting guys. I
> searched php.net but they don't mention which one takes precedence. Anyone
> know of any references?
For some reason, I was thinking that even values overriden in
.htaccess would be reported as "master" and that only values set in
ini_set() would be "local", but don't hold me to that. At any rate, if
for some reason register_globals was disabled during script execution
(but was enabled at script invocation) that would mess with your code.
> BTW Andrew, were those hosting servers that wouldn't allow override in
> .htaccess running FastCGI? Maybe FastCGI doesn't allow config settings in
> .htaccess but I can't find anything conclusive about that either.
>
> Cheers
> Arno
I think they are using CGI, but I don't think it's a restriction on
FastCGI. I just assumed that since it was shared hosting PHP was
running inside of some sort of sandbox that allowed each site to
customize things without affecting other clients hosted on the same
box (and probably prevent scripts on one site from accessing scripts
belonging to another site on the same box). Someone with more server
administration experience than I could probably answer that.
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
