Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13807 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31719 invoked by uid 1010); 10 Nov 2004 15:50:09 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 31668 invoked from network); 10 Nov 2004 15:50:08 -0000 Received: from unknown (HELO took.shire) (68.125.98.48) by pb1.pair.com with SMTP; 10 Nov 2004 15:50:08 -0000 Received: (qmail 88893 invoked by uid 1001); 10 Nov 2004 15:54:26 -0000 Date: Wed, 10 Nov 2004 15:54:26 +0000 To: internals@lists.php.net Message-ID: <20041110155426.GI31167@bagend.shire> Mail-Followup-To: internals@lists.php.net References: <418B4909.7010203@ailis.de> <255444644.20041105104900@marcus-boerger.de> <418B4FF6.4020503@ailis.de> <20041108173840.GA25573@redhat.com> <4191C2CC.7050308@ailis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4191C2CC.7050308@ailis.de> User-Agent: Mutt/1.4.1i Subject: Re: [PHP-DEV] Upload Progress Meter Patch From: curt@php.net (Curt Zirzow) * Thus wrote Klaus Reimer: > Joe Orton wrote: > >>It is a user interface problem, so it should be done there. > >It's really the only place it can be done safely > > Web browsers don't offer any API to allow a client-side progress bar. > The only client-side solution I know of is ActiveX and Java and these > solutions are not available to all users. Actually, the little blue bar in the lower right corner is a standard place for the progress bar. Unfortantly It isn't as 'friendly'. > >sending an HTTP > >response before the request body has been entirely read is fundamentally > >risky, too: HTTP clients are not required to read response data > >concurrently to sending request bodies, so sending the upload meter > >stuff can fill the TCP send buffer server-side and deadlock the > >connection for a compliant HTTP client. > > Sending the upload meter stuff to the client while the client still > uploads? In the same request? I have the bad feeling that the idea > behind the progress meter bar was not fully understood. It's working > like this: I'm aware of how the patch you originally proposed works. The issue I see is if we're making changes to how uploads work within php, It would be nice to be able to, easily, do other things like: - authenticate a user before accepting a download - stream the download through an encryption algorithm. > > So ne need to send a response while the request is still read. The whole > scenario can also work without Javascript if frames/iframes are used to > separate the upload from the progress bar. But even this does not > matter. It's all up to the user how it's implemented. All the dirty work > can be done in an external PHP Extension and in PHP code. Only this > little patch I sent a few days ago is needed in PHP itself. You can provide a progress bar, as php stands right now, without any patch. Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid!