Funny thing when you forget your nose in spite of your face: 1. I was reading a bit too far on the request, so -- I turned on tracing and it all went pear shaped. ANYONE trying to do this note that you CAN'T turn TRACING ON! Well - I should go back to the noob
threads... :) -Brett
You are near to figuring everything out. But not quite. What you must try to do is to intercept byte by byte the upcoming stream or blocks by blocks. And then you must look for the boundaries with the parameter "filename". If that's the case then you are receiving
the body of a file. You don't just go saving the file on the disk because it will contain the header used by the multipart/form-data protocol. Commercial upload controls implement the RFC 1867 protocol. There are VBScript code that parse form data. Look for
them and port them to .NET.
I tried the code but got the following error : Can you please help?? Configuration Error Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify
your configuration file appropriately. Parser Error Message: File or assembly name HttpUploadApp, or one of its dependencies, was not found. Source Error: Line 21: Line 22: Line 23: Line 24: Line 25: Source File: c:\inetpub\wwwroot\adb\web.config Line: 23
Assembly Load Trace: The following information can be helpful to determine why the assembly 'HttpUploadApp' could not be loaded. === Pre-bind state information === LOG: DisplayName = HttpUploadApp (Partial) LOG: Appbase = file:///c:/inetpub/wwwroot/adb LOG:
Initial PrivatePath = bin Calling assembly : (Unknown). === LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Post-policy reference: HttpUploadApp LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary
ASP.NET Files/adb/820ab95c/40870a47/HttpUploadApp.DLL. LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files/adb/820ab95c/40870a47/HttpUploadApp/HttpUploadApp.DLL. LOG: Attempting download of new URL
file:///c:/inetpub/wwwroot/adb/bin/HttpUploadApp.DLL. LOG: Attempting download of new URL file:///c:/inetpub/wwwroot/adb/bin/HttpUploadApp/HttpUploadApp.DLL. LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET
Files/adb/820ab95c/40870a47/HttpUploadApp.EXE. LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.0.3705/Temporary ASP.NET Files/adb/820ab95c/40870a47/HttpUploadApp/HttpUploadApp.EXE. LOG: Attempting download of new URL file:///c:/inetpub/wwwroot/adb/bin/HttpUploadApp.EXE.
LOG: Attempting download of new URL file:///c:/inetpub/wwwroot/adb/bin/HttpUploadApp/HttpUploadApp.EXE.
I manage to make the code work. i no more get an error . BUT , i cannot see a progress indicator when i upload a larger file. Can anyone please help? thanks
I'm stuck on this too. I started with the code originally posted by coderage but have heavily modified it to try and solve the problem of ReadEntityBody() hanging or returning 0 bytes. First I started (as demonstrated in coderages' post) with small buffer and
tried to call ReadEntityBody() but it only ever returned 0 and no bytes into the buffer. When that didn't work, I tried to allocate a buffer to handle all the remaining bytes in one go, however doing that causes an exception from deep inside the framework.
Even if this had worked, it seems kind of dumb to do it that way since the whole point was to not have to load the entire stream into memory for processing and thus consuming substantial server resources. Finally I decided to try reading one byte at a time.
This also does not work with the call to ReadEntityBody() hanging or returning with 0 bytes read. Can someone at least point me in the right direction? Is there at least a way to know how many bytes are available to be returned by ReadEntityBody() allowing
me to read them and then sleep until more arrive?
Hi all: Man, I've followed this post from the earlier messages, and let me say, you all have done one hell of a job! I was just curious is anyone has made any progress that they'd be willing to share... Thanks!!!
Hi Rob I have a hope that your compliment is partly aimed at my post, so thanks :-) I think a few of us have complete solutions by now - and I also regret, that I cannot share mine. My code has been sold to a company, which is not to pleased with the code-sharing
principle :-). However, I really do believe that the earlier posts, completing with coderage's example code, is really all that is needed. The rest - parsing a request and making a javascript progress bar - is trivial, and the web has many examples of such
practices. I think your post is a pleasant return to the level that this discussion should have: Not a tutorial, but a deep discussion of how to go about this problem. The essential code (really just how to get the HttpWorkerRequest and work the preloaded
data) is in place. Now we can discuss how to structure the solution. The following is my suggestion: I can recommend dividing the solution into a low-level scanner and a high-level parser. The scanner is responsible for filling a byte array, thereby encapsulating
the problems related to reading the contents of the request, using the HttpWorkerRequest. That is, the role of the scanner is primarily to solve the following 2 problems: 1. Some data is located in the preloaded buffer 2. Reading past the end of the request
resolves in a deadlock-like situation. -And to supply the parser with a function that fills a byte array, returning also the number of bytes read. This is exactly what you would expect from any stream reader. This greatly reduces the problems for the parser,
now only responsible for dividing the request into appropriate pieces: -Text fields, posted along with the files -Files Going about this requires the parser to be able to identify the boundary that divides the request into these pieces. This boundary is also
the FIRST LINE in the request, so the first step in dividing the request should be to read this line. So each piece of the request starts and ends with this boundary. Now the nature of these pieces (either text field or file) can be identified by parsing the
line immediately following the boundary. If this line contains something like "filename=XXX", the piece following is a file - otherwise, if it contains "name=XXX", the piece following is a text field. Now that we know the nature of the pieces, we are able
to parse them appropriately. For example, I store the posted text fields in a hash table, and save the files - in chunks - to a predetermined place on the hard drive (supplied by a parameter). This step is pretty simple - we are just reading until we meet
the boundary again. So the parser algorithm has the following form: 1. Identify boundary line 2. Identify type of piece (text field or file) 3. Read piece until next boundary is met 4. Go to 2 That was the the basic building blocks of the solution - a scanner
and a parser. What is left, is adding a class having a lot of "statistics" variables - like bytes read, length of request, and so on. This class should be accessible not only to the scanner, but also to some other process, responsible for displaying upload
progress information to the user, likely in form of a progress bar. This part is really trivial - just remember that you cannot use session variables when dealing with the httpmodule. Instead I've experiemented with a static hashtable, containing instantiations
of these "statistics"-classes, each related to an upload-id (just a really long random number). This upload id should be supplied to both the scanner and the process responsible for displaying the statistics. So they can both look up and write to / read from
the same object in the static hash table. Wiring it all together should be a httpmodule, which implements the scanner (and passes it the httpworkerrequest), the parser, and the so-called settings class, also accessible to the scanner and from the static hash
table. So that was my solution, in steps. No code - but I hope others will comment on the proposed solution. Kind regards, Rasmus
Thanks for that Rasmus. I too have often been in the situation where the code I've written (good or bad) cannot be shared and I appreciate the overview you have provided. In fact, I think you've outlined a very effective solution. I would dearly love to see
your implementation, but understand completely your reasons for not posting it. However, I'm still stuck at the very beginning. That is, reading the full request from the incoming stream, which is the problem that had to initially be solved for this approach
to work. Everything I have tried, mostly based on posts in this thread, has not orked. Reading the bytes that are preloaded is easy and I have that working successfully. Its when I try to read the remainder of the incoming bytes I encounter either the deadlock
that has been described in previous posts or the call simply returns with my buffer empty and 0 bytes read. I just don't see how I can be reading past the end of the buffer if I'm reading one byte at a time. I would really appreciate some help or at least
a push in the right direction. I know that once I have the ability to read all the bytes in the stream, the rest is more or less trivial. Thanks for everything that has been contributed so far! Cheers, Doug
Hi Doug Sounds mighty frustrating. Could you post your code please (or maybe just fragments)? I suppose you redirect to another page after attempting to read, right? Also, what does the ContentLength variable give you? (request.GetKnownRequestHeader(HttpWorkerRequest.HeaderContentLength));
(And a stupid question, but I have to ask : You do use a httpmodule, right? :-)) Regards, Rasmus
goyaman
Member
35 Points
7 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Feb 14, 2003 04:01 AM|LINK
torvix2000
Member
150 Points
30 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Mar 12, 2003 01:57 AM|LINK
aaeda
Member
10 Points
2 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Mar 27, 2003 03:26 AM|LINK
aaeda
Member
10 Points
2 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Mar 27, 2003 08:15 AM|LINK
Cyberfloatie
Member
102 Points
29 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 25, 2003 01:25 AM|LINK
robrichard
Member
418 Points
88 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 28, 2003 09:49 PM|LINK
www.robrichard.com
ups101
Member
205 Points
41 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 29, 2003 12:13 PM|LINK
Cyberfloatie
Member
102 Points
29 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 29, 2003 02:24 PM|LINK
ups101
Member
205 Points
41 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 29, 2003 03:30 PM|LINK
Cyberfloatie
Member
102 Points
29 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 30, 2003 12:33 AM|LINK