Catching "request entity is too large" error

I am running a web server IIS 8.0 and using ASP.NET and C#.

I have an upload box where the user can upload a file to the server and after a limit of about 50MB, a message appears on a white page:

The page was not displayed because the request entity is too large.

I'd like to display a more user-friendly page with a notification in red that says "Error trying to upload your file, please contact us for help."

In my codebehind file when handling the upload button click event, I added:

try
{
    //try to save the file to server
}
catch(Exception ex)
{
    //otherwise, set the asp:Label tag text to display error
}

However, the code in the catch statement is not being run. My guess is that the error may lie with IIS and can't be caught with that statement of code. Is there any way to intercept that error and display a friendlier error page instead?

Thank you for your help.

Solution 1:

If the uploaded file is larger than allowed by IIS, it will never reach the ASP.NET runtime and your exception handling is useless.

You should set uploadReadAheadSize to much higher than you want to allow, ideally only for the specific URL. And then check for the upload size in your code and display your own message.

If the user uploads a huge file larger than uploadReadAheadSize he/she still gets the IIS message but this case it much less likely if you use a big number.

Solution 2:

There are lots of solutions/comments here, none of which address the fundamental question. What entity is too large? We had the same issue and we eventually identified that the entity in error was a viewstate object in the ASPX page. Just making the size of the maxBufferPoolSize, maxBufferSize and maxReceivedMessageSize to be enormously large is not really the correct solution. It will work but you're only masking the problem and it'll occur at some point in the future.

ViewState A web application is stateless. That means that a new instance of a page is created every time when we make a request to the server to get the page and after the round trip our page has been lost immediately. It only happens because of one server, all the controls of the Web Page is created and after the round trip the server destroys all the instances. So to retain the values of the controls we use state management techniques. View State is the method to preserve the Value of the Page and Controls between round trips. It is a Page-Level State Management technique. View State is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a post-back.

Solution Our webpage was displaying a gridview of records which by user request gave access to every record in the underlying data query view. As records were added to the tables outside of this view, the Gridview Dataset grew to be too large for the ASPX page to save and recall the viewstate object. Our solution was to understand the business reasons why the whole of the dataset was required and as it turned out generally it was only the last 7 days worth of data that was required, any further back in time was catered for by a standing report. Once this was understood then we simply amended the page query to limit to the last 7 days of data, promulgate the change and inform users. Problem fixed.