Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33448
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <474BA22F.2020608@lerdorf.com>
Date: Tue, 27 Nov 2007 14:50:55 +1000
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: enugroho@spikesource.com
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <1196124442.21880.15.camel@ganges.spikesource.com>
In-Reply-To: <1196124442.21880.15.camel@ganges.spikesource.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Reliable header sending mechanism in php 6
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Ezra Nugroho wrote:
> Can I ask for the following support, at least to begin conversation
> about it if it hasn't been done before.
> 
> Currently, the header() function still carries the following warning in
> its online documentation:
> 
> "Remember that header() must be called before any actual output is sent,
> either by normal HTML tags, blank lines in a file, or from PHP. It is a
> very common error to read code with include(), or require(), functions,
> or another file access function, and have spaces or empty lines that are
> output before header() is called. The same problem exists when using a
> single PHP/HTML file."
> 
> This is quite annoying since this makes header() or setcookie() calls to
> be unreliable. 
> 
> I am aware that it can be done more reliably by turning the output
> buffering on. This is less of an issue if you are writing your own
> webapp. However, this is much more difficult if a person writes a
> library for other people's consumptions. The library cannot enforce
> output buffering in the webapp.
> 
> Can we please give it a thought in PHP 6? Maybe by turning output
> buffering on by default, or even by enforcing output buffering.
> 
> In Java, you can get the request object, and the response object of a
> web request. I find this very useful and reliable.
> 
> Any thoughts or comments about this?

There is nothing unreliable about is as far as I am concerned.  You have
full control over output buffering from your script.  Forcing people to
 buffer output by default will mean higher memory usage and higher
latency for existing scripts with no gain given their code is working today.

-Rasmus