Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22037
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060228183807.0afb5068@zend.com>
Date: Tue, 28 Feb 2006 18:45:27 +0200
To: Michael Wallner <mike@php.net>
Cc: internals@lists.php.net
In-Reply-To: <68.AB.30574.5C7E2044@pb1.pair.com>
References: <68.AB.30574.5C7E2044@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Revisiting output control code
From: zeev@zend.com (Zeev Suraski)

At 13:51 27/02/2006, Michael Wallner wrote:
>Hi,
>
>I'd like to suggest that we revisit the output control (output 
>buffering) code base.
>The current implementation uses way too less commands to do too many different
>operations, which almost always causes problems with output handlers that need
>to maintain a state or context.
>
>Short example:
>ob_clean() causes havoc with ext/zlib ob handlers and any handlers 
>found in pecl/http.
>ob_clean() passes currently buffered input through the handler and 
>discards it, which
>means in the case of the gz handler that the gzip/zlib header bytes 
>(and more) are
>missing from the sent data.

Why would you call ob_end_clean() in those cases?  It seems to me 
that what you want to do is actually create another layer of output 
buffering on top of those custom output handlers, if you want to 
control the contents itself.  If you think of custom output buffers 
as a filter, then it makes perfect sense that calling ob_end_clean() 
would cause problems.  If you do it in another layer of output 
buffering, then the format of zlib/gz will remain intact without any problems.

I'm also not sure about what you're saying with the gzip/zlib headers 
missing - do you mean the footers?

Zeev