次の方法で共有


Large file upload issue in ASP.NET

Off late, I have started getting a lot of complaints why .NET treats files with larger size differently. So, I thought of dedicating some time to do some research on this. What I found out was not something exclusive, but was normal and quite acceptable.

Uploading files via the FileUpload control gets tricky with big files. The default maximum filesize is 4MB - this is done to prevent denial of service attacks in which an attacker submitted one or more huge files which overwhelmed server resources. If a user uploads a file larger than 4MB, they'll get an error message: "Maximum request length exceeded."

Here is what needs to be considered for larger file uploads:

You can upload files with a combined size of up to 2GB, but it requires some modifications in your application configuration files.

Web.config settings:

The following attributes can be assigned to the <httpRuntime> tag in the <system.web> section of the Web.config file.

1. maxRequestLength : Specifies the limit for the input stream buffering threshold, in KB. This limit can be used to prevent denial of service attacks that are caused, for example, by users posting large files to the server. The default value is 4096 (4 MB). To enable large file uploads you need to change the value of this attribute to the largest allowed combined file size for your application. If someone selects and uploads files with total size larger than maxRequestLength, this will result in a "Page not found" error (which is the default error of the Framework).

2. executionTimeout : Specifies the maximum number of seconds that a request is allowed to execute before being automatically shut down by ASP.NET. The value of this setting is ignored in debug mode. The default in .NET Framework 2.0 is 110 seconds. In the .NET Framework 1.0 and 1.1, the default is 90 seconds.

To enable large file uploads, which can take large periods of time, increase the value of this property(executionTimeout).
 
For example: The configuration, allowing uploads of files up to 100MB and upload periods up to 1 hour, should look like the following:

<configuration>

...

<system. web>

<httpRuntime maxRequestLength="102400" executionTimeout="3600" />

...

</system .web>

</configuration>

IIS7 Settings:

You need to add the following lines in the web.config file:

<system.webServer>

...

<security >

<requestFiltering>

<requestLimits maxAllowedContentLength="1024000000" />

</requestFiltering>

</security>

</system.webServer>

Open the applicationHost.config(C:\Windows\System32\inetsrv\Configs) file and set the overrideModeDefault property to Allow for the section name = requestFiltering. So now the line should look like:

<section name="requestFiltering" overrideModeDefault="Allow" />

To know more about requestLimits, please refer: https://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits

Machine.config settings:

The following attributes can be assigned in the <processModel> element of the machine.config file. They must be set at the machine level, not the application level in web.config. 

These properties affect any response deadlock in ASP.NET, not just the application that uploads large files, and should be used with caution.

responseDeadlockInterval

Specifies the time interval, in the format HH:MM:SS, after which the process is restarted if the following conditions are met:

* There are queued requests.

* There has not been a response during this interval. The default is 3 minutes. To allow very large uploads, you may have to increase this value.

responseRestartDeadlockInterval

Specifies the time, in the format HH:MM:SS, that must elapse after the last restart to cure a deadlock before the process is restarted to cure a deadlock again. This prevents thrashing on processes that require a relatively long startup time. The default is 9 minutes. To allow very large uploads, you may have to increase this value.

IIS Metabase Settings:

There is one property on IIS 6.0 metabase called AspMaxRequestEntityAllowed to allow larger file uploads.

The AspMaxRequestEntityAllowed property specifies the maximum number of bytes allowed in the entity body of an ASP request. If a Content-Length header is present and specifies an amount of data greater than the value of AspMaxRequestEntityAllowed, IIS returns a 403 error response. This property is related in function to MaxRequestEntityAllowed, but is specific to ASP request. Whereas you might set the MaxRequestEntityAllowed property to 1 MB at the general World Wide Web Publishing Service (WWW Service) level, you may choose to set AspMaxRequestEntityAllowed to a lower value, if you know that your specific ASP applications handle a smaller amount of data.

I had one such case in my recent past where the customer was getting "HTTP 404: Page Not Found" error when uploading large files on Windows Server 2003 machine.

The exact issue was: Sometimes the upload of large files on a Windows 2003 server does not succeed even though the maxRequestLength configuration property is set to a very large value. The browser displays
"Page Not Found" error.

Resolution that worked in my case: Set the IIS Metabase property AspMaxRequestEntityAllowed to 200000000
(~200MB)

Now, let’s talk about some scenarios where we get such stuffs:

Error message when you visit a Web site that is hosted on a server that is running Internet Information Services 7.0: "HTTP Error 404.13 - CONTENT_LENGTH_TOO_LARGE"

Consider the following scenario. You have a Web site that is hosted on a server that is running Internet Information Services (IIS) 7.0. When a user visits this Web site, the user receives an error message that resembles the following error message:

Server Error in Application "application name"

HTTP Error 404.13 - CONTENT_LENGTH_TOO_LARGE

HRESULT: 0

Description of HRESULT # The operation completed successfully

This problem occurs because the client request contains a Content-Length header that is larger than the value that is specified for this header in the maxAllowedContentLength property in the ApplicationHost.config file.

To resolve this problem, follow these steps:

  1. Click Start. In the Start Search box, type Notepad.
    Right-click Notepad, and then click Run as administrator.

    Note If you are prompted for an administrator password or for a confirmation,
    type the password, or click Continue.

  2. On the File menu, click Open. In the File name box,
    type %windir%\system32\inetsrv\config\applicationhost.config, and then click
    Open.

  3. In the ApplicationHost.config file, locate the
    <requestLimits> node.

  4. Remove the maxAllowedContentLength property. Or, add a
    value that matches the size of the Content-Length header that the client sends
    as part of the request. By default, the value of the maxAllowedContentLength
    property is 30000000.

    For example, modify the following configuration data inside the
    <requestFiltering> section.

           <requestLimits maxAllowedContentLength = "<length>" />

  1. Save the ApplicationHost.config file.

Courtsey: https://support.microsoft.com/kb/942074

You can get some scenarios in the below article, please refer this;

https://forums.iis.net/t/1066272.aspx

Comments

  • Anonymous
    July 12, 2011
    Nice post...

  • Anonymous
    July 13, 2011
    Amazing info!

  • Anonymous
    July 15, 2011
    good.

  • Anonymous
    November 24, 2013
    Hi Prashant, If i want to upload more then 2 GB file like 20 GB i know that is wrong but just for error handling purpose how i catch this error in asp.net that .net understand and tell to user with proper mesaage that you have uploaded to big largr file (20 GB). Kindly Help me and replay to me in jabamit@gmail.com Thanks in advance. Amit

  • Anonymous
    February 02, 2014
    thanks a lot of for the use post...

  • Anonymous
    April 27, 2014
    very good post. I also wrote something on this topic here. blogershub.com/.../Upload-large-file-on-IIS-HTTP-ERROR-404-CONTENT-LENGTH-TOO-LARGE-HRESULT

  • Anonymous
    November 09, 2014
    Thanks. very nice post. very useful information.