Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33479 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63388 invoked by uid 1010); 27 Nov 2007 23:44:09 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 63372 invoked from network); 27 Nov 2007 23:44:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Nov 2007 23:44:08 -0000 Authentication-Results: pb1.pair.com header.from=enugroho@spikesource.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=enugroho@spikesource.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain spikesource.com from 209.10.209.56 cause and error) X-PHP-List-Original-Sender: enugroho@spikesource.com X-Host-Fingerprint: 209.10.209.56 unknown Linux 2.6 Received: from [209.10.209.56] ([209.10.209.56:7216] helo=spikemail.spikesource.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 86/85-25304-7CBAC474 for ; Tue, 27 Nov 2007 18:44:08 -0500 Received: by spikemail.spikesource.com (Postfix, from userid 65534) id 5C14957C824; Tue, 27 Nov 2007 15:44:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on spikemail.spikesource.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0 Received: from localhost (localhost [127.0.0.1]) by spikemail.spikesource.com (Postfix) with ESMTP id F138357C9E0 for ; Tue, 27 Nov 2007 15:39:17 -0800 (PST) Received: from spikemail.spikesource.com ([127.0.0.1]) by localhost (spikemail.spikesource.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30542-05 for ; Tue, 27 Nov 2007 15:39:17 -0800 (PST) Received: from ganges.spikesource.com (ganges.spikesource.com [172.16.20.210]) by spikemail.spikesource.com (Postfix) with ESMTP id 55A9A57C94B; Tue, 27 Nov 2007 15:39:16 -0800 (PST) Reply-To: enugroho@spikesource.com To: Rasmus Lerdorf Cc: PHP Developers Mailing List In-Reply-To: <474BA22F.2020608@lerdorf.com> References: <1196124442.21880.15.camel@ganges.spikesource.com> <474BA22F.2020608@lerdorf.com> Content-Type: text/plain Organization: Spikesource, Inc. Date: Tue, 27 Nov 2007 15:38:42 -0800 Message-ID: <1196206722.31863.16.camel@ganges.spikesource.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Open-Xchange Express amavisd-new at spikemail.spikesource.com Subject: Re: [PHP-DEV] Reliable header sending mechanism in php 6 From: enugroho@spikesource.com (Ezra Nugroho) On Tue, 2007-11-27 at 14:50 +1000, Rasmus Lerdorf wrote: > 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. In my mind, it is still unreliable... When I write my library, how can I enforce people who adopt it to enable ob? Furthermore, I think it's quite annoying that some functions may not work just because of an inclusion of a blank space somewhere in a file that you don't maintain. As php applications get bigger, and developers have only a small scope of the big picture, the reliability of the functions becomes bigger and bigger deal.