Hi! > i.e. when it works at all. With Apache 2.4 the ap_rflush() in zif_virtual() > terminates the currently running main request, in my testing, resulting in a > completely crashing apache. This might be remedied, though. > > At the moment, as part of my efforts to fix bug 68486, I have modified things > to that the PHP interpreter is NEVER reentered. virtual() continues to work, > but only with URIs that do not again enter the apache2handler. > > First question here: would this be an acceptable bugfix?
Do you mean that you can call virtual() only on non-php URLs but on PHP urls it would fail? I'd assume that is a pretty big BC break then so it'd be better if we could avoid it. But if it's not avoidable then I guess we should do what we need to avoid crashing. > Furthermore, I have a working prototype of changing the behaviour of > virtual() > in the following way: _remember_ which subrequest should be made, but then > only really make it when the current request ends (php_handler() in the That's probably useful but not the case for virtual(), as virtual() is meant to be replacement for SSI #include, i.e. work in-place, and if it's deferred till the end of the request the output will be broken. I'm not sure how many people actually use virtual() (it's pretty limited use case) but ones that do probably need it to work in place. Not sure PHP support in it is required though (since you could include PHP code directly I presume). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
