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?

You're not listening.
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.

 
"Disclaimer: Don't blame, it came from inside the void"
#--------------------------------------------- crazyinsomniac

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 :-)

I think that what batmonk is asking for may be possible. (Note that batmonk never asked about resuming file uploads over HTTP; merely about an upload progress report.)

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.

I hope you're not trying to be offensive. There is a difference between not hearing and not seeing that which has not been clearly stated.

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:

• One can submit a form using "HEAD" as the request method and, if so, if that would include the size of the file attempting to be uploaded.
• A creative use of HTTP 1.1's capabilities can lead to a workable solution without requiring plug-in's, browser specific code, or the introduction of new tools (and their requisite expenses/learning curves).
• Query something within Apache itself to detect incoming requests that have not been completed. If so, is it possible to get enough information that can help solve this?
• Combine error codes, redirects, multiple scripts, links, and other standard tools to achieve this effect, perhaps even a carefully controlled proxy request.
• There is an "outside of the box" solution that will unravel this Gordian knot as effectively as Alexander's approach.
• Anyone's already done this and documented it.

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:

• cajun's links are helpful, though it seems overkill to use TCL for just this. If that's the easiest way to do it, though, then so be it.
• I said nothing about resumeable uploads.
• I realize that I'm asking an unusual question, one that will add time to the process. Given the nature of the my intended users (who do not look at the existing feedback devices) and the size of the files being uploaded (2-5MB), I am perfectly willing to spend a few more cycles obtaining those files if it keeps my users from rebooting or stopping the upload.
• baku's approach may be doable, though I would prefer to avoid client-side scripting if possible.
• epoptai post is suggestive, but I wonder if there is a missing link and one or more incomplete sentences.