Sascha, not sure if you followed the discussion regarding the conf
settings bleeding from one request to the next in the apache1 sapis. We
finally tracked it down to a forgotten zend_ini_deactivate() call in the
xbithack handler. There are some reports that this is also a problem
under Apache2. You have changed how conf settings are handled in Apache2,
but as far as I can see you are relying on PHP to reset them at the end of
handling the request. In the couple of cases where after doing an
apply_conf() we don't fall into a regular PHP request it looks to me like
they can bleed. In the php_handler() function, for example, you do an
apply_conf() near the top and then have a bunch of conditions that can
cause a return right away. Don't we need a zend_ini_deactivate() before
the return, or am I missing a hook call in the Apache2 request handling
that will take care of this?
-Rasmus
Sascha, not sure if you followed the discussion regarding the conf
Apparently, the apache2 sapis don't call zend_ini_deactivate
at all. The current configuration is activated using
apply_config(), but we don't attempt to reset it.
So, the bug seems to affect the apache2 sapis as well, albeit
in a more 'reliable' way.
- Sascha
Sascha, not sure if you followed the discussion regarding the conf
Apparently, the apache2 sapis don't call zend_ini_deactivate at all. The current configuration is activated using apply_config(), but we don't attempt to reset it.
Right, that was what I was verifying. I couldn't see any place where a
reset was done at all, so I thought maybe it was hidden away somewhere.
Looks like we need to fix that. I'll have a look at it tomorrow.
-Rasmus
Right, that was what I was verifying. I couldn't see any place where a
reset was done at all, so I thought maybe it was hidden away somewhere.
Looks like we need to fix that. I'll have a look at it tomorrow.
Already done :).
Ilia