submersible_toaster has asked for the wisdom of the Perl Monks concerning the following question:

Forgive me if there are existing nodes regarding this, I felt as though there would be , however a Super Search was unrevealing.

I am interested in the use of Apache::Request , specifically it's UPLOAD_HOOK callback. Having read some discussions about upload progress indicators here at the Monastery and abroad , it seems the consensus is to store some unique identifier server-side regarding the upload session, supply the calling browser with enough javascript to launch a window, calling /cgi/upload-status.pl with the initial unique identifier so it can stat the temporary file. So when the the request is created Apache::Request->new all the UPLOAD_HOOK callback can hope to achieve is to initialise the relationship (in a DB for example) between the present file upload location, and the unique upload identifier.

That makes even less sense to me having written it down..I will try point form

  1. Deliver upload form to client, containing uploadID (hidden field?), onSubmit() script that will launch a new window pointed at /cgi/uploadstatus.pl?uploadID=
  2. When the client submits the form, Apache::Request is configured to execute a callback (like a callback to a Tk event? a sub ref \&prep_for_upload) passing it the upload_tempfile and the uploadID.
  3. The submitee CGI carries on dealing with the multipart form data, writing it to the tempfile
  4. Meanwhile , /cgi/uploadstatus.pl is being refreshed every few seconds by the client, supplying each time the uploadID.
  5. Given the uploadID , uploadstatus.pl checks a DB for a corresponding entry, and outputs some sensible information regarding the status of the upload.

Have I totally mis-construed good advice, or is it really that complicated? I appreciate HTTP is stateless. Have any monks made this approach work?


I can't believe it's not psellchecked

Replies are listed 'Best First'.
Re: Apache::Request UPLOAD_HOOK
by Joost (Canon) on May 05, 2003 at 14:44 UTC
    Though I've never used UPLOAD_HOOK myself, I think what you are describing is more or less the easiest way of creating a real progress indicator.

    One thing that may simplify the system a bit is using a session system to store the upload_id, so you don't have to know it before opening the popup. Something like <form ... onclick="window.open('popup.pl','progress');"> will do then.

    You can also fake the whole thing with an animated gif in a popup-window (that's what the Exchange webmail interface does).

    -- Joost downtime n. The period during which a system is error-free and immune from user input.
Re: Apache::Request UPLOAD_HOOK
by cees (Curate) on May 05, 2003 at 18:52 UTC

    have you looked a the source for Apache::UploadMeter? It uses the UPLOAD_HOOK to implement a progress bar.

    And yes, I think does have to be this complicated. It is a limitation of mod_perl 1.x and Apache 1.3.x and the forking model. Remember that the forked http child processes don't share any data, so they need to communicate through an external interface (whether that is Shared memory, a database or just a file on disk).

    If you look at this process from the viepoint of the server it becomes a bit more clear. When you submit the form, two httpd child processes are used to serve the request in this instance. The main connection does the file upload, and may take several minutes to complete. The second connection is the progress meter that appears in a popup and continuously reloads itself. Now the progress meter needs info from the upload connection, but the child processes can't talk directly to each other. This is where the unique ID and external storage comes into play. The upload hook updates the data, and the progress meter displays it.

    Once mod_perl2 becomes stable, there may be better ways of dealing with this. But there will always be the need for two connection from the client, and the processes that serve these 2 requests will need to talk with each other somehow.

    Personally I have always thought that the browser itself should have an upload meter built in. After all they show download meters! And they have all the info to display the upload info. They could limit it to only appear when an input type 'file' is in the form...