Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re: Re: Not listening.

by extremely (Priest)
on Feb 10, 2001 at 04:11 UTC ( #57527=note: print w/replies, xml ) Need Help??

in reply to Re: Not listening.
in thread File upload progress?

OK, here's the deal. The way clients implement the upload is rather up to the clients. From my personal experience dealing with much this same request I can tell you that you aren't going to have any fun trying to get this to work.

The best I can recommend is that you look at the javascript option of opening a second window. You're real problem will come from the fact that you have a nasty precedence problem. When you throw up the page for the upload, you need to already know the "temp" name of the upload so that you can watch its progress. But you don't yet know it because you haven't had anything submitted. And, when you get something submitted, the window that gets the submission doesn't show it's response till after the upload is complete so once you know the temp name you can't send the user to running display window.

The solution is to pick a "temp" name first when they go to the page and have the submit button pop a window and send the file (I suppose with javascript, somehow). Alternately, you can interpose an entire exchange where when the user hits the submit button, a javascript send with the file name happens, starts the watcher window then actually submits the file.

Any way you look at it, ugly ugly ugly and browser dependent to boot. Worse, you take the chance of making it completely unusable to people without JS or with JS turned off.

Covering your six points quickly:

  • HEAD: Try it but it doesn't solve your problem anyway. Most clients won't actually let a form send a HEAD request, anyway.
  • HTTP/1.1 sure it has capabilities but not ones you can get at through the client. The client already knows all you need, size of file and how much it has sent. Only the TCP/IP stack knows for a while how much has been ACK'ed though. That is why most clients don't bother. Even FTP clients are a little wonky on upload.
  • Apache and already know what you need, your problem is getting the messages sorted out in the right order. After you start the upload you can't send messages back until you finish and you can't start watching easily until you start uploading...
  • Combine. Javascript and a couple of perl scripts are all you need to do it but as I said you have a nasty communications order problem.
  • "Outside the box?" Yeah, submit a patch to the Mozilla project so they implement a built-into-the-client upload bar. Or have the user use FTP (Perhaps fire up a onetime FTP on a special port with Net::FTP? That might be sexy. There would be a second confirmation box pop up in there though. Maybe write an entire browser in perl so you could add fancy upload progress bars easily.
  • Already done? The closest I've seen to what you want is's "hold on while I ftp to your site" javascript. That is just for seeing if a process on the SERVER finishes. It works, mostly, but it doesn't have your communication issue.

As to the post about TCL on the mailing list, that wasn't what you were looking for. That was a browser plug-in that gets the browser to do the work while the upload happens. It is effectively a browser upgrade so you would have to encourage your users to get and install a plug-in that changes how their client displays uploads. That is fixing the client, not a CGI fix.

$you = new YOU;
honk() if $you->love(perl)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://57527]
and a kettle whistles...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2018-06-21 05:23 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (117 votes). Check out past polls.