Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:13747
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sat, 6 Nov 2004 03:42:31 +0000
To: internals@lists.php.net
Message-ID: <20041106034231.GV31167@bagend.shire>
Mail-Followup-To: internals@lists.php.net
References: <418B4909.7010203@ailis.de> <255444644.20041105104900@marcus-boerger.de> <418B4FF6.4020503@ailis.de> <1306684207.20041105111518@marcus-boerger.de> <418B5929.30709@ailis.de> <20041105174245.GT31167@bagend.shire> <418BC266.3060502@ailis.de> <20041105183910.GU31167@bagend.shire> <418BCEA0.9060604@ailis.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <418BCEA0.9060604@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:
> Curt Zirzow wrote:
> >>And this extension is working WITHOUT callbacks in main/rfc1867.c?
> >correct. The only thing that needs to go into the core of php is a
> >new php.ini option to disable parsing the input.

One thing to add is that I surely dont think its php's
responsibilty to provide a way to show progress of an uploaded
file.  The client that is uploading the file knows better and
should be the one with the responsibilty.

The main benefit I see having php, either using callbacks or some
extension, is the ability to authenticate a user (or some logical
decision) before actually downloading a file.

> 
> Ok, then you can do with PHP the same as I have done with a CGI program 
> before I found the mentioned patch. But then you have to do all the 
> multipart/form-data parsing yourself. And you have to put all the 
> uploaded data into the $_FILES array to stay compatible with PHP's file 
> receiver. So you have to rewrite all the stuff that PHP is already doing 
> very good in your PECL extension.

The extensions' main responsibilty is to parse the
multipart/form-data.  The way my extension works now is something
like:

$fp = fopen('php://stdin', 'r');

$parser = postparser_init($fp);

while ($token = postparser_token($parser) ) {
  switch ($token['type']) {

    case 1: // POST VAR
      //...
      $_POST[$token['name']] = stream_get_contents($parser);
      break;

    case 2: // FILE
      while (! feof($parser)) {
        $buf = fread($parser, $size);
      }
  }
}


> 
> Implementing some callbacks in rfc1867.c sounds better to me. Then a 
> PECL extension can focus on the progress informations and let PHP handle 
>  the data.

      
After some thought, it might be even better just to implement a
filter. So  postparser_token could be replaced with
stream_get_meta_data(). The extension works much like a filter
already, anyway.

If we add a ini option for php not to read the stdin on a multipart
post, and rework some of  rfc1867.c functions to be accessable from
outside of rfc1867.c's namespace, a custom filter could easily be
written and not have to duplicate the current code.


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!