Amen! Finally, someone willing to step up to the plate and not be concerned with putting cash in their pocket! Thanks CyberFloatie!!! Now, for those of us who are of lesser .NET talent, do we put this in it's own application? The reason I ask, is that I used
the previous C# code provdied before, and used the web.config modifications in the project that I wanted to use the upload module in. Then, each form that was submitted gave me an error about the request length being exceeded (in fact, I believe CyberFloatie
actually posted the debug log for the exact error.) How would we go about implementing this awesome solution? THANKS!!!!
robrichard, My code doesn't work! The reason I posted it here was because I needed help with it, however, I do think I figured it out myself last night. The relevant changes are these: Byte[] buffer = new Byte[BUFF_SIZE]; while (bytesRemaining > BUFF_SIZE)
{ bytesRead = request.ReadEntityBody(buffer, BUFF_SIZE); dataFile.Write(buffer, 0, bytesRead); bytesReceived += bytesRead; bytesRemaining = contentLength - bytesReceived; } buffer = new Byte[bytesRemaining]; bytesRead = request.ReadEntityBody(buffer, bytesRemaining);
dataFile.Write(buffer, 0, bytesRead); bytesReceived += bytesRead; You'll also not that this is nowhere near a complete solution. As mentioned in previous posts, you still need to parse the incoming stream to remove the uploaded files (and potentially decode
them), however, you must also pass the unused portion of the stream back out so that the rest of the process has something to do. In other words, you can't just filter out the file and let the request end or your browser will sit there forever with that dumb
look on it's face. Some people have solved this by doing a redirect when their done and ignoring the rest of the stream. Others have managed to replace the incoming stream with their own so that it can still be processed by the .ASPX that it was originally
posted to. Me, well, I'm just happy I got this far. I'll figure out what I'm doing the next time I get motivated. This was supposed to be a fun project but it turned out to be a lot harder than I initially anticipated. I'll keep slogging through it and posting
here.
Hi cyberfloatie Your latest changes look really nice. I would stick to just the one counter, bytesRead, so the call would be something like: while(contentLength - bytesRead > BUFF_SIZE) { bytesRead += request.ReadEntityBody(buffer, BUFF_SIZE); ... ... } buffer
= new Byte[contentLength - bytesRead]; ... ... ... (nothing I have tested...just an idea). Either way should work. So, it sounds like you've got it working now? That sounds great!. Gotta get to bed, early up in the morning. Regards, Rasmus >rob "Amen! Finally,
someone willing to step up to the plate and not be concerned with putting cash in their pocket!". Yes, I need the money. Not exactly a rich life being a student. Also, if I've worked damn hard for this, I don't see any problem with trying to earn a buck on
it. Do you?
Thanks for the code cyberfloatie, your code works great. Does any one know to get the data from the uploadModule to say an asp.net page? So far the only thing i can think of, is to just write out an html file. Also, does anyone know how to parse the mime type
and put the right extention on the file? All im doing right now is using the exention from the file that was posted.
Hi Code Rage, I have a problem when trying to make your code work. The GUID.txt file in the Upload folder contains the name of the file (as a file=filename) and not the the file itself. Is there any additional configuration required? TIA, Marek
XOnic, The post in this thread by dredman on 13 Jan 2003 might help you. Without having tried to do this myself (I will eventually) it looks like you can write back to the stream anything you want allowing any remaining modules and eventually the .aspx to process
it. When I do finally get around to it, the approach I'm thinking about will be to write the files to the disk into a temp location and then rewrite the posted data to include only the non-file fields and some addidtional information that another component
can parse to gain access to the uploaded files in the temp location. Has anyone else tried this approach?
MarekK, Please read this whole thread. You will find that while coderage's code is great, it is not a complete solution. However, there have been enough tidbits posted in this thread that you should be able to develop your own solution from them. As for a "compile
and go" solution, well, you won't find it here.
Cyberfloatie, No, I've stuck to the simple response.redirect. Instead I used a delegate that was called after the upload completed, allowing for post-processing of the non-file fields. The way I read dredmans post, it seems possible to correct the length of
the request, so the worker process wont stall, waiting for bytes we've taken out. However, it doesn't seem he's saying that you can write back to the stream itself? Or did you read that somewhere else? However, your proposed solution seems "cleaner" than mine...even
if you have to introduce a new structure for both the fields and the files. Let us know what you find out :-) kind regards, Rasmus
Rasmus, I'm basing this entirely on dredman's post repeated here for convenience: private byte[] PopulateRequestData(HttpWorkerRequest hwr, byte[] data) { BindingFlags bindingFlags = BindingFlags.Instance | BindingFlags.NonPublic; Type type = hwr.GetType().BaseType;
int i = (int)data.Length; type.GetField("_contentAvailLength", bindingFlags).SetValue(inWR, i); type.GetField("_contentTotalLength", bindingFlags).SetValue(inWR, i); type.GetField("_preloadedContent", bindingFlags).SetValue(inWR, inData); type.GetField("_preloadedContentRead",
bindingFlags).SetValue(inWR, true); } It stands to reason that _preloadedContent is the byte array that GetPreloadedEntityBody() is the accessor for. You can probably figure it out for sure by checking the contents of the variable before the call GetPreloadedEntityBody().
If it turns out that it does contain the preloaded content, there shouldn't be any reason that it can't contain content after the module is done parsing the full stream. Now in dredmans PopulateRequestData() he passes in the worker request and a byte array.
I'm assuming that the variable inData is a typo and should actually be the byte array parameter. If I'm correct, then the contents of the byte array can be the original incoming stream minus the posted file(s). You can then do as I suggested in a previous
post and add a couple of your own fields to the stream, adjust the _contentAvailLength, _contentTotalLength and _preloadedContentRead. Then when the code in the target of the form post is executed, you can instantiate another object that knows how to read
those variables and access the uploaded files. So, why am I wasting time posting all of this speculation rather than trying it myself? I've just bought a house and have to paint it, clean it and then move within the next two weeks and won't be touching any
projects until long after thats done. I'm hoping someone can try what I've suggested here and post their findings (and maybe even some code) so that when I do get back on this I won't have to pick up from where I left off. dw
Cyberflotie> Ahh....nice! I was a bit too fast in judging dredmans code, I can see that now. Thanks for the elaboration. I think you are right about the typo...it's gotta be the array parameter. Congrats on the house! Whereat in the world, may I ask? I am starting
to post again, because it is exam period again...we've actually been posting in this same thread for 2 exam periods now :-). As always, everything else is alot more interesting than studying for the exams. Anyway, I'll also give your solution a try sometime
next month. BTW, any thoughts as to how we can "most cleanly" access the statistics variables (bytes read, file length, etc.)? The problem is, that we need access to these things two places....the place where we write to them, and the place where we read them,
and show them to the user during upload. Another solution that could really use a clean-up, is the progress bar. The standard html progress bar updates itself every 3 second or so, and works just like any asp page. So you've got one frame doing an upload,
and another continously updating...ugly. We've gotta be able to make a cleaner version of this. The culprit of the problem is how to stream the statistics nicely to the user. Here are some starting ideas: 1. Load via XML, as described here : http://webfx.eae.net/dhtml/xmlextras/xmlextras.html
- But does that work in netscape...in older browsers? 2. Load via XML through flash...which is possible, but requires an open port...and everything should really run on port 80. And not everyone has gotten a flash player new enough to support xml loading.
We should keep it in html, if at all possible. 3. Trick the browser into thinking it is downloading an image. You can determine if an image is downloaded or not in javascript...many preload progress bars exist already. Now the server just needs to dish out
these empty images when say 5% is complete, 10% is complete, and so on. The height of the image could be the kilobytes read, the width could be total length...or something like that. Problem is, that we have to settle for pretty low resolution (eg. 5% intervals)
- or have a lot of pictures. 4. Java or ActiveX solutions could easily do it...but too much hassle with Java code signing, too much IE-specific stuff with ActiveX. 5. Somehow send chunks of a page to the user at a time...possible downloading a javascript in
pieces...but how? This one should be possible...but I cannot get it working. I could really use a smoothly increasing progress bar, without the continous refreshing in the background....hope you guys have some thoughts about this? kind regards, Rasmus
robrichard
Member
418 Points
88 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 30, 2003 03:16 AM|LINK
www.robrichard.com
Cyberfloatie
Member
102 Points
29 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
Apr 30, 2003 02:09 PM|LINK
ups101
Member
205 Points
41 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 01, 2003 10:06 PM|LINK
X0nic
Member
10 Points
2 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 08, 2003 04:50 AM|LINK
MarekK
Member
135 Points
27 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 13, 2003 12:45 PM|LINK
Cyberfloatie
Member
102 Points
29 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 13, 2003 03:26 PM|LINK
Cyberfloatie
Member
102 Points
29 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 13, 2003 03:29 PM|LINK
ups101
Member
205 Points
41 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 16, 2003 08:51 AM|LINK
Cyberfloatie
Member
102 Points
29 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 16, 2003 03:05 PM|LINK
ups101
Member
205 Points
41 Posts
Re: HttpHandler or HttpModule for file upload, large files, progress indicator?
May 16, 2003 09:14 PM|LINK