Hi, working on bug 68486 I had a look at the apache2handler virtual() function.
This function, as vaguely documented, is intended to make an Apache subrequest, without terminating the currently running request, i.e. run whatever is behind a different URI (given as an argument to virtual(). The subrequest does NOT run in a fresh interpreter. It uses whatever state the interpreter is in when virtual() gets called, and any modification to the interpreter state made by the subrequest, will persist after virtual() returns. 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? 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 apache2handler SAPI has deconfigured the interpreter). Done this way, there is no mixing up of interpreter state, neither for the initial request, nor for the subrequest made (which does not risk running into duplicate function / constant definitions and all other kinds of fun). The prototype I have, adds a second, long options argument to the virtual() function, with bit 1 indicating the new behaviour should be used, as just described. The second question would be, whether this new behaviour would be a good thing to have. The third question would be, make this new behaviour the default, or optional with a second virtual() argument. Personally I would simply switch to the new behaviour, as the old one does not make sense to me, and adjust the documentation accordingly. But apparently the function has been available for over 10 years, so opinions might differ... best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
