I've been researching this problem further, and there doesn't appear to be a way to stop an in-process upload without returning an error page. The only way to abort an upload would be to cut the connection, which would immediately show the error page on the client. Unless anyone knows a better way to deal with this, there are only two ways I can think of to deal with this:
 
1) Just cancel the upload.
We could get around the error page showing by making the actual upload section of the page an IFrame, and showing a progress page while the upload is in process. We could then detect the error and show a proper message.
 
2) Stream the message out to nothing, then return an error at the end. This would work, but it means we still have to deal with the oversized upload. At least it won't be streaming into memory...
 
Chris


From: rainbowportal-devel-admin@lists.sourceforge.net [mailto:rainbowportal-devel-admin@lists.sourceforge.net] On Behalf Of Chris Hynes
Sent: Tuesday, September 28, 2004 20:38
To: rainbowportal-devel@lists.sourceforge.net; 'Leo Duran'
Subject: RE: [Rainbowportal-devel] RE: Bug

I figured out how to get the maxRequestLength. HttpContext.GetConfig and some reflection magic.
 
Problem is, ASP.NET still blows up. Anybody know how to fool it into thinking it's a new request?
 
Chris


From: rainbowportal-devel-admin@lists.sourceforge.net [mailto:rainbowportal-devel-admin@lists.sourceforge.net] On Behalf Of Chris Hynes
Sent: Tuesday, September 28, 2004 19:23
To: 'Leo Duran'; rainbowportal-devel@lists.sourceforge.net
Subject: [Rainbowportal-devel] RE: Bug

That's a feature I can add to SlickUpload.
 
All I need to know is how to get the maxRequestLength programatically.
 
Because the request is intercepted at the earliest possible point, it should be possible to check the ContentLength HTTP header against the maxRequestLength. If it's not possible to get the maxRequestLength property progamatically, I could at least add another SlickUpload setting.
 
Anyone know how to retrieve the maxRequestLength property?
 
Chris


From: Leo Duran [mailto:leod@classicsport.com]
Sent: Tuesday, September 28, 2004 12:28
To: rainbowportal-devel@lists.sourceforge.net
Subject: Bug

I need to concede defeat. I have been spending a lot of time trying to find a way to fix this bug… http://sourceforge.net/tracker/index.php?func=detail&aid=957922&group_id=66837&atid=515929 but it is beyond my realm of expertise. If anyone else would like to tackle it feel free too.

 

Chris Hynes has offered to let us use his SlickUpload control in order to make the document upload smoother. However, it doesn’t really do anything to help with this particular bug.

 

From the research that I’ve done there are a couple of ways that this bug can be fixed…

  1. Change the <httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="4096" /> setting and increase the maxRequestLength to a much larger number. NOTE: This doesn’t fix the bug; it merely hides it in most circumstances. The main problem with this approach is as follows…
    1. The error is not thrown until the maxRequestLength has actually been exceeded. For example, say the maxRequestLength is 10MB, and the user is uploading a 11MB file over a slow connection. The server would throw the error once the request length hits 10MB which means that the user just wasted a lot of time while s/he tried to upload the file.
  2. (The correct way) Use client side JavaScript to check the maxRequestLength setting in the web.config file. The JavaScript code could then calculate the file size BEFORE the file is uploaded, and it could alert the user that the file is too large to be uploaded to the server.

 

Because I lack the experience with creating client side scripts, and I don’t have the time to learn JavaScript, I am offering this bug back to the Rainbow Community.

 

This link, offered up by David Reed, comes close to getting this feature implemented. The JavaScript will calculate the files size, and offers a good start for a JavaScript programmer to compare that value to the maxRequestLenght.

http://www.faqts.com/knowledge_base/entry/edit/index.phtml?aid=1685

 

If you decide to take this bug over, and still have questions after reading this message, please contact me.

 

Thank you,

 

Leo