Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85015
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
To: internals@lists.php.net
Date: Mon, 16 Mar 2015 10:31:46 +0100
Message-ID: <1807379.geZHnrMSPX@rofl>
User-Agent: KMail/4.14.4 (Linux/3.19.1-2.gc0946e9-desktop; KDE/4.14.4; x86_64; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: PHP apache2handler virtual() function
From: php@bof.de (Patrick Schaaf)

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