1

Suppose someone:

  1. visits and ASPX page (http get request).
  2. sets a "too large" file in a file uploader and clicks the upload button (http post request).

I don't care to have a custom error page served; that's dumb, and disrupts the application.

I want to HANDLE the error programmatically. It can be intercepted (after the entire request has been received, I think) by the Application_BeginRequest handler of global.asax, as posted here.

What I'd like to do is remove the oversized file from the request, set some kind of flag in something like "HttpContext.Current.Items["filetoolarge"] = true", then do a Server.Transfer to the same page, so that the request runs as though the file was never sent, except now there's this error flag that the page would of course check and display a nice error message when found.

Can this be done?

Triynko
  • 18,766
  • 21
  • 107
  • 173
  • so you want to notify the user that the file they are attempting to upload is too large? – BrandonZeider Apr 12 '11 at 21:29
  • Yes. Client-side check is not an option, since JavaScript can't do it, HTML-site is meant as an alternative to Flash so the Flash option is off the table, and ActiveX is MS proprietary. I can execute a custom page with a system.webServer configuration setting, but that executes a page with no chance to run custom code before the transfer takes place. I think I HAVE to read the entire request to avoid having the browser think the connection failed, so I think the Application_BeginRequest handler may be the place to handle this, along with corresponding code in the target page's OnLoad event. – Triynko Apr 12 '11 at 21:35

3 Answers3

0

The only way I know how to do this without using Flash or ActiveX is to set the maxRequestLength to a high value, and then use JavaScript to access the information about the file once it becomes available, and then handle cancelling/error handling. I used the Telerik upload control to do it, but you should be able to do something similar.

BrandonZeider
  • 8,014
  • 2
  • 23
  • 20
  • So, JavaScript does have access to the file length, but only once the upload has started. If it's too big, then the request can be ignored by JavaScript. This seems like it could result in a race condition though, because if the file upload completed and a response was received before the JavaScript code to check the size and cancel the request runs... then it may never run at all. I really think it's best to handle this condition on the server-side at the very least, and also on the client-side to get rid of any cons of the server-side solution. – Triynko Apr 14 '11 at 21:50
  • Yes, as with all validation, I would verify on the server side. I think a combination of validation would be nice for your users though, so that they do not upload the entire file to find out it's too large. – BrandonZeider Apr 15 '11 at 00:46
  • The real problem is that recovering from a "request too large" error on the server-side is not really possible, since the request itself is invalid. That means cookies, session, user identity, etc. are all missing or invalid, so determining the proper action cannot depend on the user being authenticated or authorized, nor can it depend on any session state, view state, form field values, etc. It's really a network communication error like a protocol error, so I'm beginning to think that the server should just ignore the request and the error should be handled well on the client-side. – Triynko Apr 25 '11 at 14:46
0

Set maxRequestLength in your web.config to a big value like this:

<system.web>
        <httpRuntime maxRequestLength="26000" executionTimeout="600"/>
</system.web>

so you can receive the big file. and then process it like this:

        If fileUploader.PostedFile.ContentLength > theSize Then
            'show error'
        else
            'process it'
        End If

Hope it helps.

UPDATE:

maxRequestLength is in KB.

PostedFile.ContentLength is in bytes.

Afshin Gh
  • 7,918
  • 2
  • 26
  • 43
  • I don't want to change the maximum allowed request length or make it artificially high. It must be set in web.config if you truly don't want requests larger than a specific length to pass through your web server. If you set the maximum request length artificially high like that, you risk D.O.S. attacks and you obfuscate where the true limit is by moving it into your page or global application code. Worse yet, if the user uploads a file larger than the artificially high limit you set... you're back to square one. – Triynko Apr 14 '11 at 21:36
0

I posted the solution here: Where do I catch and handle maxAllowedContentLength exceeded in IIS7?

My solution involves overriding the page's OnError handler, and I think it works only in .NET 4.0, because it involves getting the last exception as an HttpException and checking the WebEventCode property, which seems to be new in the .NET 4.0 framework.

There is another solution there that involves intercepting the Application_EndRequest global application handler, where both the StatusCode and SubStatusCode property values are available, but I don't think it works, because the response has probably already been flushed to the client by the time the EndRequest event is raised.

From my experience, both the OnError and Application_EndRequest methods run almost immediately, long before the server could have possibly received the entire request, so it probably gets fired as a result of some early warning about the request size.

I have tested the OnError method, and it works flawlessly, aside from the unavoidable delay where the browser insists on finishing the upload of its request before handling and displaying the server's response.

Information on Web Event Codes can be found here - http://msdn.microsoft.com/en-us/library/ff650306.aspx

Community
  • 1
  • 1
Triynko
  • 18,766
  • 21
  • 107
  • 173