Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64052
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 213.193.247.34 as permitted sender)
Message-ID: <50B380AC.9000901@php.net>
Date: Mon, 26 Nov 2012 15:46:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10
MIME-Version: 1.0
To: Michael Wallner <mike@php.net>, internals@lists.php.net
References: <50B1F9D7.80000@php.net> <CALJZF3hNQWxaXh5Gn0HgO=9LFJxxE_2Wx_bW3MYGvBC4u=GxHg@mail.gmail.com>
In-Reply-To: <CALJZF3hNQWxaXh5Gn0HgO=9LFJxxE_2Wx_bW3MYGvBC4u=GxHg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------000108050002010206020400"
Subject: Re: Bug 61272
From: langemeijer@php.net (Casper Langemeijer)

--------------000108050002010206020400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 11/26/2012 10:19 AM, Michael Wallner wrote:
> I'm sorry that the new output control layer causes you such headaches. 
> IIRC, 6 years back, when I implemented the new output control 
> functionality, I kindly asked the list, whether to rather implement 
> what's documented, or what the old code did, but I have yet been 
> unable to find according mails.
And now this code hits production for the first time I assume, if this 
is the only issue I think you have done a fab job!
> It pretty well may have been the case that the old code passed the
> output buffer contents through the handler prior discarding, but as it had
> not been documented (and I obviously failed to figure out a use case) I
> apparently implemented the more efficient way it currently is.
Hmm.. I suppose It's up to me to make a strong (if possible watertight) 
plea for the old way. I will try:

1. I don't think my patch impacts the efficiency of php_output_clean(). 
It adds a single if with a binary compare. True: this causes output to 
get piped through the output handler, but the output handler callback 
function could be smart enough to back off when the 
PHP_OUTPUT_HANDLER_CLEAN bit is set in the second parameter of the callback.

2. Current behaviour is *not* according the documentation. ob_start() 
documentation states: " An optional output_callback function may be 
specified. This function takes a string as a parameter and should return 
a string. The function will be called when the output buffer is flushed 
(sent) or **cleaned** (with ob_flush(), ob_clean() or similar function) 
or when the output buffer is flushed to the browser at the end of the 
request. When output_callback is called, it will receive the contents of 
the output buffer as its parameter and is expected to return a new 
output buffer as a result, which will be sent to the browser." 
(*-emphasis mine)

Current behaviour differs:
On calling ob_end_clean() or ob_clean(), output_callback is called, but 
*without* the contents of the output buffer as its parameter.

3. Implementing my patch will never break anything. The output will be 
passed to the callback, but anything returned by it *will* be discarded.

4. If you are not going to pass the contents of the output buffer on 
ob_end_clean() or ob_clean() to the callback function, Why would you 
call the callback anyway?


You may think this is a weird feature, this is how we use it: In 
output_callback we assign the output we catch with output buffering to a 
string variable, and we use that later on in the request to build our 
output.

Greetings, Casper

--------------000108050002010206020400--