views:

67

answers:

2

Ok, so here's the problem: I'm reading the stream from a FileUpload control, reading in chunks of n bytes and writing the array in a loop until I reach the stream's end.

Now the reason I do this is because I need to check several things while the upload is still going on (rather than doing a Save(); which does the whole thing in one go). Here's the problem: when doing this from the local machine, I can see the file just fine as it's uploading and its size increases (had to add a Sleep(); clause in the loop to actually get to see the file being written).

However, when I upload the file from a remote machine, I don't get to see it until the the file has completed uploading. Also, I've added another call to write the progress to a text file as the progress is going on, and I get the same thing. Local: the file updates as the upload goes on, remote: the token file only appears after the upload's done (which is somewhat useless since I need it while the upload's still happening).

Is there some sort of security setting in (or ASP.net) that maybe saves files in a temporary location for remote machines as opposed to the local machine and then moves them to the specified destination? I would liken this with ASP.net displaying error messages when browsing from the local machine (even on the public hostname) as opposed to the generic compilation error page/generic exception page that is shown when browsing from a remote machine (and customErrors are not off)

Any clues on this?

Thanks in advance.

A: 

FileUpload control renders as an <input type="file"> HTML element; this way, your browser will open that file, read ALL content, encode and send it.

Your ASP.NET request just starts after IIS receives all browser data.

This way, you'll need to code a client component (Flash, Java applet, Silverlight) to send a file in small chunks and rebuild that at server-side.

EDIT: Some information on MSDN:

To control whether the file to upload is temporarily stored in memory or on the server while the request is being processed, set the requestLengthDiskThreshold attribute of the httpRuntime element. This attribute enables you to manage the size of the input stream buffer. The default is 256 bytes. The value that you specify should not exceed the value that you specify for the maxRequestLength attribute.

Rubens Farias
So what you're saying is that even with the delay that I had on the local machine test, the content had already reached IIS entirely and I was just processing internally something that had already arrived.Basically what I'm trying to do is a server/client side upload progress indicator (which would poll another page on the server for the progress with some client side javascript).Thanks.Also, if the default value is already 256 bytes (and we assume that once every 256 bytes data gets written to disk), it means this won't work :(Thanks for the reply.
mtranda
To be honest, I didnt understood that `requestLengthDiskThreshold` property too; but to create an upload progress, you must to send data as chunks
Rubens Farias
What particularly intrigued me and determined me to try the web method was this jQuery library.http://t.wits.sg/misc/jQueryProgressBar/demo.phpI'm trying an upload as we speak and it seems to work for PHP.
mtranda
A: 

I understand that you want to check the file which is being uploaded for it's content. If this is your requirement then why not add a textbox and populate it while you are reading the file from HttpPostedFile.

Ravia
The main problem is that the trigger doesn't activate until the entire content of the request is sent (in this particular case the entire file). What I was trying to do was access the file data as it was still downloading on the server.
mtranda