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
On Monday 16 March 2015 10:31:46 Patrick Schaaf wrote:
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).
A related implementation question: ideally for this new behaviour to be sane,
I would like to make, in this case, virtual() not return at all when it thinks
it can make the subrequest. (a false return could still happen when apache
cannot route the request, I do not change the up-front lookup_uri call).
How would I go about doing that, though? i.e. in a PHP_FUNCTION(virtual), how
to I in effect do what the EXIT opcode normally does?
Patrick
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
smalyshev@gmail.com