Re: Upload Progress Meter - what's the latest?

Richard Lynch wrote:

Anything you see with "PHP" "upload progress meter" together has to be some kind of hack whose under-pinning is NOT PHP at all, but is JavaScript or similar client-side technology.

Not true. The graphical display is HTML, DHTML, JavaScript, etc...but the means of monitoring the progress from the server side MUST be done with PHP.

I'm sorry. Your original post sounded (to me) like you wanted a progress meter on the browser (client-side) for the user to see their files uploaded.

Yes, I want that also. Really, I want the feature to exist in the PHP language regardless of how I intend to use it. That's the beauty of a programming language vs a program. I want the tools to be able to build what I want however I might want it at the time.

Presumably even the worst browsers have some concept of how large the file is, and how many bytes have been sent to the server. So you certainly DO NOT need server-side information to implement a client-side progress meter of the progress of a file upload!

Agreed. I SHOULD not NEED this feature. Other server-side languages exist, so I technically don't NEED PHP either. I don't really want to debate whether this feature should exist or not, but it seems to me that the replies I've gotten from this list so far suggest that internals of PHP development are seriously opposed to such a feature? I am more interested in which project extensions are leading in momentum to solve the problem I am trying to solve and not blaming other projects (browsers) for not building the feature first.

The code that I have seen so far requires hooks into PHP which execute callback functions periodically in order to update the progress of uploaded files as PHP processes input.

Yes, which is a silly place to try and "fix" this for client-side progress meters, as you then generate traffic back-and-forth from the client to measure the number of bytes received, instead of the browser just measuring bytes sent.

The back-and-forth you refer to is termed 'polling'. With a protocol like HTTP, polling is really the only option unless I implement a socket server which is capable of sending events. This is something I may be building into the project also, but aside from HOW I move the server-side collect data back to a web client, that is independent of needing to collect the information on the server side in a format which can be accessed and read easily.

browser in all cases. From the server side, I need to be able to monitor

    * who is currently uploading files,
    * which files are being uploaded,
    * how big are the files being uploaded,
    * how much time has passed since upload began, and
    * what percentage of those files is completed

I do not need to return this data to a client at all times. Sometimes I just want to use the data system administration, analysis, and tracking. The most popular need would be for returning the information to the client, however, as you suggest.

You'd need a battery of meters, for all running processes, or at least all the ones currently in file upload state.

I would like to have a list of all file uploads in progress, yes. A semi-frequently updated snapshot of the information I defined would be sufficient. If a callback function is invoked periodically it would be equivalent to firing an event and would allow a php program to log the data to a common data repository which could be ready by another process on the system.

You'd also need tie-ins to your login/authentication to determin "who is uploading files" as the only answer inherent to PHP is "the User set in httpd.conf"

Right. Under the callback method example, I would have access to $_SESSION which would already contain enough information about the logged in account for my purposes. This is trivial.

How big they are relies on the browser sending the correct Content-length: for the upload. I don't know how often they get it right, but I'm betting that are some pretty common errors in this area that PHP corrects for already. So your meters would not be accurate in some (hopefully few) cases.

The POST method sets the Content-length, right. So, PHP must trust that the browsers are not lying. For security purposes we don't need to worry about whether this number is wrong because it is only for display. Processing uploaded files does not occur until the file completes uploading.

While I can see where this might be a useful tool to have server-side, I can suggest several possible ways to implement some portions of it without hacking PHP source. First, ... you could write a tool to watch /tmp for files and get a list of the /tmp names being uploaded.

Yes, this is simple.

Using filectime and filemtime would tell you the timing info -- Though Windows will suck (as usual) as it only tracks to the nearest minute or something...

Yes. Using Linux. This will work.

For tying the filenames back to the users who are logged in, you'd have to have an onClick() on the submit button which would send some kind of information (filename, filesize, user) to a PHP script that would log the upload about to begin in a database. The onClick would then return false so that the normal form submission process would kick in.

This will not work. And this is exactly WHY an extention/patch is needed. Between the time PHP choses a /tmp file name and the time the upload is completed, there is not execution of PHP code. Therefor, we don't know the /tmp name assigned to an upload until AFTER the upload is completed and then it's too late.

You're not going to get ... accuracy ... It won't be so hot for tracking who's uploading what in real-time,

It should be. Using the patch, I already have this working. I now want a cleaner, supported solution which doesn't involve a custom patch which will not be supported in the future. Although the patch I am using works, it was build for PHP 5.0.3 RC1 and since I am using 5.1.2 you can understand my concerns that it will fail to continue working when the switch is made to PHP 5.2 or PHP 6.0.

Another option is to provide patch to PHP which gives a special INPUT parameter to a FORM that can be used to provide a callback file to load, and a callback function within that file to call, and then modify the file upload routine to load and call that function.

Passing this from the client form is insecure and can not be trusted. Declaring callback functions needs to remain a server-side declaration either through code or an INI setting, etc.

It seems genuinely useful enough to this naive reader, and should not cause an undue burden for those who don't use it. Check with PHP-Dev to see if such a patch is likely to be accepted before putting in TOO much time on it.

My original email was searching for advice on which project has momentum and what the current state of any discussions about the issue were. Does anybody have information on the PEAR package which appears to be vapor? http://pecl.php.net/package/postparser I see the name Curt Zirzow, but no contact information for that "author". Is there not a package which has been adopted by the community or does every developer share Richard's opinion that this feature doesn't belong in PHP? Dante