Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64062
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
In-Reply-To: <50B380AC.9000901@php.net>
References: <50B1F9D7.80000@php.net>
	<CALJZF3hNQWxaXh5Gn0HgO=9LFJxxE_2Wx_bW3MYGvBC4u=GxHg@mail.gmail.com>
	<50B380AC.9000901@php.net>
Date: Tue, 27 Nov 2012 10:11:10 +0100
Message-ID: <CALJZF3jvgpbaGm=jMh0uYd18Q-9_Lgf3+VmB7OP98qoERSrOCw@mail.gmail.com>
To: Casper Langemeijer <langemeijer@php.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: Bug 61272
From: mike@php.net (Michael Wallner)

On 26 November 2012 15:46, Casper Langemeijer <langemeijer@php.net> wrote:

> 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)

Which emphasizes the fact, that implementation and documentation differed
quite a bit.  The ob_clean note was obviously added in 2008 [1] [2], when
the new output code was sleeping in the PHP6 branch.

>
> 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?

I guess I got your argument now :) I'll have a look.

Thanks for spending your time to make PHP better.


[1] http://svn.php.net/viewvc/phpdoc/en/trunk/reference/outcontrol/functions/ob-start.xml?r1=246628&r2=268496
[2] https://bugs.php.net/bug.php?id=44150
-- 
Regards,
Mike