apache2 sapis and conf handling

php.internals

Rasmus Lerdorf

22 years ago
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 Schumann

22 years ago
On Wed, 28 Jan 2004, Rasmus Lerdorf wrote:
> 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

Rasmus Lerdorf

22 years ago
On Thu, 29 Jan 2004, Sascha Schumann wrote:
> On Wed, 28 Jan 2004, Rasmus Lerdorf wrote: > > > 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

Ilia A.

22 years ago
On January 29, 2004 01:01 am, Rasmus Lerdorf wrote:
> 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