in reply to (crazyinsomniac) Re: File upload progress?
in thread File upload progress?
Perl supports while loops; HTTP tells you the length of the content. Certainly there's a way to parse that into digestible (and reportable) chunks...isn't there?
And, to be perfectly frank, TCL confuses me. Hence, my request for shared wisdom. Certes, other members of our Order have posed the same question. Haven't they?
|
---|
Replies are listed 'Best First'. | |
---|---|
(crazyinsomniac) Re: (2) (crazyinsomniac) Re: File upload progress?
by crazyinsomniac (Prior) on Feb 09, 2001 at 11:39 UTC | |
There is no way to accomplish this via a the Common Gateway Interface(a Browser). Meaning client/server communication via a browser is turn based. The browser says something, the server says something back. And then You CAN accomplish this, but it'll require your clients download some kind of plugin or program. I also asked a few monks in the c/b, and chromatic pointed out, like i've been saying, that there is no way having the server send status of the request to the client, within the constraints of the HTTP spec. Which brings me back to what i said before, you can do it if your clients download some kind of program or plugin. I will mention the method that the IndigoPerl folks used, but that would require you have 2 browser windows open, or some kind of frames(HTML frames) configuration, but it still wouldn't provide for resuming(incremental turn based upload like you suggested). chromatic mentioned something like that being possible with Netscape, if the Netscape folks are able to finish it, but don't hold your breath. I would like to apologize in advance to chromatic if i misunderstood or miscommunicated anything. Perl for IE via ActivX sounds like an option, but i don't know too many casual users who have perl installed. Another option might be some kind of java applet, or even a Macromedia Flash(yes it is possible) plugin. | [reply] |
by baku (Scribe) on Feb 09, 2001 at 20:48 UTC | |
Well, that's 99% true :-) If you make the assumption that the user has JavaScript (but code for the case where they don't, as well!), you could open up a new, miniature browser window (with window.open) and set its URL to something like http://www.whatever.fu/upload/upload-status?id=xxx with an HTTP Refresh: header in that script. If you refresh every 3-5 seconds, you could display a 'status bar' and/or percentage/number of bytes/transfer speed... Just link the JavaScript to the form's submit button. (Sorry, my E-262's really rusty or I'd try to offer some sample code, but I'd probably do more harm than good in this case! :-) ) -- I forget which way it goes, but if you return (true | false ? ) from your window.open call in the onClick (?) handler, the form won't submit, but run your code instead, so make sure to RTFM :-) | [reply] [d/l] [select] |
by chipmunk (Parson) on Feb 09, 2001 at 21:17 UTC | |
With a non-parsed-header (nph) CGI script, one can send output directly to the client while the script is still running. (As opposed to a normal CGI script, where the server waits until the script closes its STDOUT before sending the output to the client). Thus, a file upload script with a simple progress report could be implemented by alternately reading a chunk of the uploaded file and printing out a status message. The browser would display all the messages that had been sent. This assumes, however, that the server doesn't read in the whole request itself and then buffer it for the script. That's the part I'm not sure about. | [reply] |
by batmonk (Scribe) on Feb 09, 2001 at 23:27 UTC | |
Please allow me to clarify in an attempt to prevent this conversation from devolving into inflammatory rhetoric. I am aware of the nature of the HTTP communication process, though I did not clearly say so. O'Reilly's "CGI Programming with Perl" provides a pretty clear explanation. I believe chipmunk has sensed the same possibilities that I have, though I'm not completely convinced that non-parsed headers are the right approach. Though I have not tested this, I presume that scripts implemented using CGI.pm do not fire until the server has fully received the client's submission, including the file being uploaded--which means it's too late. However, the book I mentioned goes into great detail about the HTTP and CGI processes, discussing error codes, proxies, content negotiation, and so on. I wonder many things; I wonder if: A friend of mine likes to say, "Programmers use absolutes like 'It's impossible' or 'It can't be done' when they mean 'I don't know how to do that and haven't the slightest idea how (or desire) to learn how to do it.' Let's look at impossibilities as challenges and see what we learn while doing so." In responses to other comments and replies: | [reply] |
by tilly (Archbishop) on Feb 10, 2001 at 11:25 UTC | |
Were I to tackle this project (after appropriate moaning and groaning) I would crack open the source-code to CGI, and look for the file-upload part. That seems to be in a function called read_multipart. I would then create (ick) a private version of the module with a hook in that function to, based on a flag, launch a nph response and stream upload information back. Or to stream upload information back to a predictable place (based on a random ID sent to the client and returned in an obvious place - eg PATH_INFO) so that the client can have the second window going. (That is probably the saner approach to implement. Besides which the server may not be expected the CGI script to reply while the upload is going on, so the second window may be the only easy response.) I would expect that since file uploads can be large, there would be no way that a decent webserver would accumulate the entire upload before starting the CGI. Anyways figuring how to modify the existing CGI module to have the hook is going to be a lot easier (and better) than rolling from scratch, even though the hook will be so ugly that there is little chance it will be accepted back into the module. There may be other ways to do it using HTTP negotiation etc. But the hack I described can probably work. | [reply] |
by extremely (Priest) on Feb 10, 2001 at 04:11 UTC | |
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: 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. -- | [reply] |
by epoptai (Curate) on Feb 10, 2001 at 09:01 UTC | |
You said you have:
| [reply] |
by crazyinsomniac (Prior) on Feb 10, 2001 at 03:53 UTC | |
Sometimes things seem a little different in text, than they do if I were to say them(you can't exactly hear my tone of voice now can you?). Please note that none of the words in the sentance "You're not listening." were CAPITALIZED, in bold or italic type, or a different color. As for me misunderstanding your question in regards to 'resuming', I don't think I did. You said you would like to allow users to upload files in 'in increments, so you can print messages that the user sees?', which seems to indicate to me that you want your users to upload a part of a file, see some kind of message, and then upload another part of a file. | [reply] |