There are several server configuration settings that factor into supporting large file uploads, and of course, there are external factors such as network reliability and available bandwidth. Other factors include server-side resources such as available memory on the web server and how much traffic or load is being serviced.

httpRuntime

The httpRuntime element in Web.config has 2 important settings, maxRequestLength, and executionTimeout. 

maxRequestLength

maxRequestLength is in kilobytes (kB), so you must set it to a high enough number of KB slightly larger than the maximum file size you would like to support. The example below of 1048576 KB translates to 1 GB
If you search for "kB to MB", most search engines provide a handy calculator for converting Kilobytes to Megabytes, Gigabytes etc. Note, if you want to support file uploads up to 1 GB then we probably should set the kB slightly higher to accommodate the HTML form posted with the file that also is part of the Request payload.

executionTimeout

executionTimeout is in seconds, it determines how much time IIS will allow for completing a web request. It can take a while to upload a large file especially if bandwidth is limited. If the configured number of seconds elapses before the file finishes uploading the request will end with a timeout error. The example below is 3600 seconds which is 60 minutes. 

<system.web >
    <httpRuntime requestValidationMode="2.0" maxRequestLength="1048576" executionTimeout="3600" maxUrlLength="560" maxQueryStringLength="2048" />
</system.web>

Considerations for Integrated Application Pools

When using an Integrated Application pool (as opposed to a "Classic" application pool), there are also the requestFiltering settings in the <system.webServer> section that are needed to support large file uploads. We have an example in comments in the Web.config file that ships with mojoPortal. To use the example, remove the comments from around it and adjust the setting to your requirements. Note, in some environments request filtering may be locked down at a higher level such as from machine.config; un-commenting it in the web.config file in those cases can cause an error.

<system.webServer>
<security>
  <requestFiltering>
    <requestLimits maxAllowedContentLength="1073741824"/> <!-- measured in bytes -->
  </requestFiltering>
</security>
</system.webServer>

Troubleshooting File Upload Problems

When a file upload fails the user will receive a generic error stating that something went wrong. To see the actual error message, view the System Log by logging in as an Administrator and browsing to Administration > System Log. Usually, uploads will fail because one of the above settings isn't configured in a way which will support the size of the file being uploaded. Example errors are: 

When a file upload fails due to exceeding the httpRuntime maxRequestLength, an error will be logged:
"System.Web.HttpException (0x80004005): Maximum request length exceeded"

Similarly, when a file upload fails due to exceeding the httpRuntime executionTimeout, an error will be logged:
"System.Web.HttpException (0x80004005): Request timed out"

When a file upload fails due to exceeding maxAllowedContentLength, nothing will be logged in the mojoPortal system log. The is because,as noted in the IIS documentation, IIS returns a page not found (404) error when the maxAllowedContentLength is exceed. Because of this, the request never reached mojoPortal code so nothing was logged by mojoPortal.

For problems uploading files from the File Manager or from the WYSIWYG editors (CKeditor, TinyMCE), see also the Storage Quotas section in the article Allowing Users To Upload and Browse Files. File uploads will be blocked in those features once the quotas have been reached.

A hosting environment with low memory available to the site may not handle large file uploads. If you see repeated application start and end events being logged when you try to upload large files, the application pool may be reaching the allowed or available memory when it tries to process the request. Recycling the application pool kills the process handling web requests and can cause failed uploads if it happens while uploading whether the file upload caused it due to the memory limit or whether the application pool is recycled for other reasons (manually for example).

In all cases the IIS web logs are useful when you want to know the result of specific web requests or troubleshoot uploading problems, especially if you don't see any clues in the mojoPortal log about file upload related errors. You should check the status code of the file upload web requests in the IIS web logs, and keep in mind the 404.13 status that IIS will return if the file is larger than the maxAllowedContentLength.

Supporing Old Browser Versions

The Drag and Drop and Multifile Selection is only supported in modern web browsers that support HTML 5. If you are supporting mostly users with older web browsers, you might want to hide the drop zone since it won't work and will only confuse those users. To do this, add the following to the theme.skin file found in your skin folder:

<portal:jQueryFileUpload runat="server" UseDropZone="false" />

Advanced Configuration

The settings shown above will get the job done as far as enabling large file uploads but allowing large limits on any URL could make it easier for denial-of-service attacks. Therefore, it can be desirable to keep lower settings there and make more specific settings that apply only to the URLs where we are expecting file uploads. Before we go into how to configure specific URLs it would help to know which URLs exist in mojoPortal that support file uploads. The following URLs are used to upload files in mojoPortal and features that plug into mojoPortal that we know of. Custom features that you make yourself or third-party features may have their own URLs that need to support file uploads.

/fileservice/fileupload

the main URL used for uploads in the File Manager and when uploading files from the WYSIWYG editors

/Blog/upload.ashx

handles media attachment uploads for blog posts

/FolderGallery/upload.ashx

handles uploads for the Folder Gallery feature

/ImageGallery/upload.ashx

handles uploads for the Image Gallery feature

/SharedFiles/upload.ashx

handles uploads for the Shared Files feature

/XmlXsl/uploader.ashx

handles uploads for the Xml/Xsl feature

/WebStore/upload.ashx

handles uploading product files for the WebStore feature

/FormWizard/upload.ashx

handles uploads for Form Wizard Pro

Note: The above list could change so if you are using the methods below to control upload settings be sure to check this list for changes.

There are 2 ways that you can configure the needed settings for specific URLs; using the site web.config  file or using per-folder web.config files.

Site web.config File

Using location elements add the settings to the site's main web.config file within the existing <configuration> element. This example is for the Shared Files feature.

<location path ="SharedFiles/upload.ashx">
    <system.web >
      <httpRuntime requestValidationMode="2.0" maxRequestLength="1048576" executionTimeout="3600" maxUrlLength="560" maxQueryStringLength="2048" />
    </system.web>
    <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="1073741824"/>
      </requestFiltering>
    </security>
    </system.webServer>
  </location>

Per-folder web.config Files

Create a web.config file and put it in the folder containing the service needed for the upload. This method has the advantage of less work when you upgrade to a new version of mojoPortal because you would not need to merge your changes with the new web.config file in the upgrade package. We don't ship any web.config files in other folders of mojoPortal or its features so there is no risk of them being overwritten during upgrades. Using the Shared Files feature as our example, the content of the new web.config would be:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<location path ="upload.ashx">
<system.web >
  <httpRuntime requestValidationMode="2.0" maxRequestLength="1048576" executionTimeout="3600" maxUrlLength="560" maxQueryStringLength="2048" />
</system.web>
<system.webServer>
<security>
  <requestFiltering>
    <requestLimits maxAllowedContentLength="1073741824"/>
  </requestFiltering>
</security>
</system.webServer>
</location>
</configuration>

Legacy Information for versions of mojoPortal Older than 2.3.9.7

In version 2.3.9.7 we removed all use of NeatUpload from mojoPortal. The information below applies only to versions of mojoPortal older than that.

There are a number of features in mojoPortal content management system which allow for uploading files, however the maximum file size that can be uploaded depends upon configuration. In addition to the information on this page, file uploads can be limited by available disk space. Some hosting providers give you a certain amount of disk space but you must allocate it to your sites in order for it to be available. So, in addition to settings mentioned on this page you may need to look around in your hosting control panel for information about available space and allocation of that space to your site(s).

Overview

When running in Full Trust (and using the Web.config file configured for full trust), mojoPortal uses NeatUpload and the file size limits are controlled by the NeatUpload section in Web.config.

Note that we ship 2 versions of Web.config, one is configured for Medium Trust and has NeatUpload disabled, the other is for Full Trust hosting and has NeatUpload enabled. The only difference between the files is whether NeatUpload is enabled. NeatUpload provides a nice progress bar during uploads but it only works in Full Trust hosting. If you see a progress bar when uploading then you are using NeatUpload if you don't then you are not.

<neatUpload xmlns="http://www.brettle.com/neatupload/config/2008"
useHttpModule="true"
maxNormalRequestLength="4096"
maxRequestLength="2097151"
multiRequestUploadHandlerUrl="~/NeatUpload/MultiRequestUploadHandler.ashx"
maxUploadRate="300"></neatUpload>

Whereas, when running in Medium Trust NeatUpload is disabled and file upload limits are controlled by the httpRuntime settings like this:

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

Note that executionTimeout is relevant even when you are using NeatUpload

http://msdn.microsoft.com/en-us/library/e1f13641.aspx

IIS 7

If you use IIS7 you also have to do the following (see discussion at http://forums.iis.net/p/1108662/1702390.aspx):

at an elevated (run as admin) command prompt enter:

%windir%\system32\inetsrv\appcmd set config "MySite/MyApp" -section:requestFiltering -requestLimits.maxAllowedContentLength:104857600 -commitpath:apphost

you can verify that the setting was inserted OK by doing and checking out the output:

%windir%\system32\inetsrv\appcmd list config "MySite/MyApp" -section:requestFiltering

the command is changing the maxAllowedContentLength request limit that IIS7 requestFiltering has introduced

NeatUpload documentation also mentions the following alternative regarding the IIS7 issue:

(Optional) To allow larger uploads than the 30MB default used by IIS7, add the following to your Web.config under the configuration/system.webServer/security/requestFiltering section:

 <requestLimits maxAllowedContentLength="size_in_bytes"></requestLimits>

Example:

<system.webServer>
        <security>
            <requestFiltering><requestLimits maxAllowedContentLength="262144000" /></requestFiltering>

<!-- maxAllowedContentLength is in bytes. Defaults to 30,000,000 -->
        </security>
    </system.webServer>

Note that for such a change to be allowed, you or your hosting provider might need to change the machine's %SystemRoot%/system32/inetserv/config/applicationHost.config file such that the overrideModeDefault attribute for the requestFiltering section is Allow instead of Deny.

Additional Resources:

http://msdn.microsoft.com/en-us/library/aa479405.aspx

http://aspnetresources.com/articles/dark_side_of_file_uploads.aspx