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
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
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
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?
That's a feature I can add to
All I need to know is how to get the maxRequestLength
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
Anyone know how to retrieve the maxRequestLength
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
From the research that I’ve done
there are a couple of ways that this bug can be
- 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…
- 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.
- (The correct way) Use
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
am offering this bug back to the Rainbow Community.
This link, offered up by David Reed,
that value to the maxRequestLenght.
If you decide to take this
bug over, and still have questions after reading this message, please contact