Exception handling of "Maximum request length exceeded" in ASP.NET

The writing of this article-notes was inspired by the work on the feedback form, in which it was possible to send files to the server. Naturally, I wanted to limit the size of downloadable files from the server side and give the user a message. The good news was that ASP.NET has built-in tools for this limitation. Bad - there are no easy ways to handle this situation.

The essence of the problem

In ASP.NET, you can set a size limit for a request in web.config:

<system.web> <httpRuntime maxRequestLength="1000"/> 

')
The value is specified in kilobytes, the default is 4096 KB. It is obvious that for each location you can set your own restrictions.

Note: In IIS 7+, there is additionally its own ability to filter queries:

 <system.webServer> <security> <requestFiltering> <!--     --> <requestLimits maxAllowedContentLength="30000000"></requestLimits> 

T.ch. change these two parameters need to be paired.

There is no standard way to intercept and handle exceptions for exceeding this limit in ASP.NET. The first thing that comes to mind is to catch an exception in Global.asax with the Error event handler. But it turned out not to be kosher for 2 reasons:

1. There is no special type of exception, but a common System.Web.HttpException is thrown (wrapped, of course, in HttpUnhandledException) with the message "Maximum request length exceeded." In the English locale. T.ch. We do not have a guaranteed way to get our "client".
2. Experienced, I came across the fact that by the time the exception was caught, the server already had time to send a part of the response to the client, which makes it difficult to use the Response object.

Decision

The decision was peeked here . But it seems to me that the comrade has somewhat become too clever by half. I got easier and, in my opinion, more precisely. In Global.asax, at the very beginning of processing a request, we check its size and redirect the user, if that, to a specially prepared page:

  public override void Init() { base.Init(); this.BeginRequest += GlobalBeginRequest; } private void GlobalBeginRequest(object sender, EventArgs e) { var runTime = (HttpRuntimeSection)WebConfigurationManager.GetSection("system.web/httpRuntime"); var maxRequestLength = runTime.MaxRequestLength * 1024; if (Request.ContentLength > maxRequestLength) { //      Response.Redirect("~/filetoolarge/"); } } 

A couple of explanations.

The first is about

 var runTime = (HttpRuntimeSection)WebConfigurationManager.GetSection("system.web/httpRuntime"); 

The first thought was to remember this parameter in a separate property of the application at the stage of its launch. But this is not correct, because different directories on the site may have their own parameters.

The second is about

 var maxRequestLength = runTime.MaxRequestLength * 1024; 

I did not understand why the source tried to subtract 100 KB. The ASP.NET constraint works on the entire request as a whole (tested on ASP.NET 2, .NET 3.5, IIS 6) along with the form data and all attached files.

Well, that's all I wanted to say about this. Although not. Probably, it is necessary to add that client validation is needed in a good way, incl. and on file size. To do this, you need to use third-party components, because The built-in browser file upload controls are a separate decent smut. It is possible that individual implementations are able to solve the affected problem in a complex.