For security reasons request sizes are limited by default. This is configurable in the web.config file through the httpRuntime sections maxRequestLength attribute. The value is an integer and it’s default value is 4096 (KB) and therefor is 4,153,344 bytes or 4 MB.

The configured values can easily be read using the .NET configuration API:

If an request is larger than this value a HttpException is thrown when the HttpRequest properties Forms, Files or InputStream are accessed. The HttpException class has a property named WebEventCode which contains a value of the WebEventCodes lookup class: RuntimeErrorPostTooLarge which is an integer with the value 3004.

If you catch this exception you can handle the error in your application code and for instance return a custom error message.

But…

When hosted in Internet Information Services (IIS) there might be another barrier: The request filtering module.

This also has a section to configure the maximal length of a request using the requestLimits section and its maxAllowedContentLength property. By default this is set to 30,000,000 (bytes) and therefore is 29.297 KB or 28.61 MB.

If this limit is hit IIS will return a HTTP error 404 with sub status code 13 with the reason phrase “Content Length Too Large”.

The .NET configuration API refuses to load this section. And even if accessed raw using the system.webServer sections SectionInformation property and its GetRawXml method the possible inheritance is not reflected. So values configured on server and not on site level divergent from the default cannot be found here.

IIS at startup create a configuration file located at *{windows drive}\inetpub\temp\appPools{appPoolName}{appPoolName}.config.

image

The IIS application pool identity (the account running our web application) of course has read access to the file.

image

To build up the path we need to get the application pool name at runtime. There is a server variable called APP_POOL_ID that will provide the neccessary information.

The following code get the local overwritten values from the web.config, the server level configured, the default value or null if request filtering is not installed:

At application startup the configuration can now be validated – request filtering schould always have a bigger value when you want to handle these kind of errors in your application code – and the values of a maximal request length can be read and possibly displayed.