A number of configuration settings become very relevant when performing uploads. These can be changed by adding sections or values into the Web.Config file. A typical configuration section is given below.

<system.web>
  <httpModules>
    <add name="Progress" type="WebSupergoo.ABCUpload5.ProgressModule, ABCUpload5, Version=5.3.0.0, Culture=neutral, PublicKeyToken=1f89539196ce5fbf"/>
  </httpModules>

  <compilation>
    <assemblies>
      <add assembly="ABCUpload5, Version=5.3.0.0, Culture=neutral, PublicKeyToken=1f89539196ce5fbf" />
    </assemblies>
  </compilation>

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

  <sessionState
    timeout="60"
  />
  ...

httpModules sub-tag

The Progress Module is required for the Pure HTML Progress Bar, for GigUpload and for Corruption Autofix functionality. The Progress Module is a .NET HTTP Module designed to intercept page requests and preprocess them before passing them on to ASP.NET.

To integrate the Progress Module into your ASP.NET application you need to add it using a line in the httpModules subsection of the web.config file. This is shown in the example web.config file above.

compilation sub-tag

To integrate and use ABCUpload objects into your ASP.NET application you need to add a reference to the assembly (stored in the GAC) using a line in the compilation subsection of the web.config file. This is shown in the example web.config file above

httpRuntime maxRequestLength

This attribute is used to limit the size of uploads by rejecting any which exceed a certain limit. The limit refers to the total size of the HTTP upload in KB (approximately equal to the sum of all the files being upload). You should set a sensible limit here to stop malicious visitors using up your bandwidth by uploading excessively large files.

If the size of an upload is too great the server will refuse to accept it. Because the server is refusing the request the uploading browser will report that the submission page is not available. This is a client side error message rather than a server side error message and it means that you cannot normally provide a sensible error message to users if they submit files which are too large.

However using ABCUpload you can report back a sensible error message via a progress window. If you believe that visitors may attempt to perform uploads greater than the maximum you should use the progress bar and the note on the progress window will inform your visitor why their upload has been rejected.

In the example web.config file above the maxRequestLength is set to 1 GB.

httpRuntime executionTimeout

The execution time-out refers to the number of seconds an ASP.NET page is given before the operation is assumed to have failed and the page terminated. If you are uploading a large file the code that is receiving the transfer may time out before the file has been completely uploaded.

In the example web.config file above the executionTimeout is set to one hour.

sessionState timeout

The session time-out refers to the number of minutes before the user session is aborted. If a large file is being uploaded it is desirable to maintain the session state. The session time-out should always be longer than the amount of time you expect uploads to take. Note that this value is only relevant if you have session state enabled.

In the example web.config file above the sessionState is set to one hour.

processModel responseDeadlockInterval

The responseDeadlockInterval is specified in the machine.config file and defaults to three minutes. It specifies the time interval after which the process will be restarted if no responses have been made and requests are still queued.

Under ASP.NET requests that take longer than the deadlock interval can cause problems under some very specific circumstances. Sometimes a client may make multiple page requests which ASP.NET may queue one after the other. If the first request in the queue takes longer than the deadlock interval then ASP.NET will mistakenly assume the whole process is deadlocked and restart it. These types of situation are very unusual and are more commonly encountered in test environments than real world ones.

For this situation to arise a client must make multiple uploads simultaneously. At least two uploads must take longer than the timeout. The client must make other page requests at the same time which IIS must decide to queue (whether it decides to queue them or not depends on whether IIS thinks they form part of the same session). These queued requests must not time out or be dismissed on the client side. Neither the client nor any other visitors must make other aspx page requests during this time.