One of the most infuriating things about IIS configuration in general is how the Request length is configured in IIS and ASP.NET. There are several places that control how much content you can send to the server and over the years this setting has changed in a number of ways. The places where it's configured is not super obvious and they can be fluid because some of these features are optionally installed IIS features.
So here are the two main places where the request length is set in IIS and ASP.NET:
- IIS Request Filtering
- HttpRuntime maxRequestLength
IIS RequestFiltering requestLimits
Let's start with the IIS level setting, which is also a relatively new setting. It's based around the Request Filtering module in IIS which is an optional IIS component, but that is a required component if you have ASP.NET installed on your server (at least in the latest versions). If you have ASP.NET enabled in IIS the Request Filtering module is also enabled and the following settings apply.
If you don't use ASP.NET you can still install Request Filtering, but it's an optional component. So if you only use ISAPI or CGI scripts and no ASP.NET content Request Filtering may not be enabled in which case the following settings cannot be set and aren't required. Since most people do run ASP.NET at least for some sites, for all intents and purposes we can assume that the Request Filtering module is installed on IIS.
So to configure the posted content size you can use the following web.config based configuration settings:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="500000000" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
The maxAllowedContentLength determines the size of the POST buffer allowed in bytes. Above I've set the value to 500megs.
Or you can do the same thing in the IIS Management console using Request Filtering option in the IIS options:
As is usually the case you can apply the filtering at all levels of the IIS hierarchy – Machine, Site and Virtual/Application. Using web.config as shown above sets the settings at the Application level.
Because these are IIS settings, the value controls the IIS upload settings so they are applied against any and all requests that are fired against IIS, including ASP.NET, ASP, ISAPI extensions, CGI/FASTCGI executables, IISNodeJs requests and so on.
ASP.NET <httpRuntime maxRequestLength>
ASP.NET traditionally has had its own httpRuntime element in the <system.web> section that control ASP.NET runtime settings one of which is the maxRequestLength. This setting controls the ASP.NET pipeline's acceptance of file uploads and it needs to be configured in addition to the Request Filtering settings described above.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime maxRequestLength="500000" executionTimeout="120" />
</system.web>
</configuration>
Note that this value is specified in kilobytes (unlike the the IIS setting which is in bytes – gotta love the inconsistency right?).
You can also use the IIS Management Console and the Configuration Manager option, to view all of the options on the httpRuntime element:
What's interesting is that the settings you see here widely mirror the settings in the Request Filtering section, and they are not inherited. It's your responsibility to make sure the settings are set correctly in both places. I recommend that you take a minute and go through the values you care about and set them correctly in both places. And remember that the IIS value is provided as bytes while the ASP.NET value is provided as kilobytes. It's easy to get tripped up by this!
Other Frameworks use Other Settings
The above describes ASP.NET settings. If you're using another framework, like WCF you may end up with yet another different set of settings on the WCF bindings and Endpoints. Just be aware of the framework you're using and that it too might have specific filters to restrict request size.
Summary
It's a pity that IIS and ASP.NET cannot integrate a bit better and that you effectively have to make these setting changes in two places. I know I hear this from customers all the time: "But I set the values in the httpRuntime element, but my posts still end up getting cut off at 2 megs…". The settings have to be made in both places and the lowest setting wins in either case. It's not a big deal to make these changes once you know, but it can be frustrating if you're searching for the setting find one and then find that you're still not getting the behavior you'd expect because it needs to be set in two places.
Other Posts you might also like