IIS7, SSL and "The page was not displayed because the request entity is too large."

We're running an ASP.NET application over SSL on IIS7 on a 64-bit machine.

Now I've found several articles mentioning that to resolve this error, I need to modify the system.webServer/serverRuntime/uploadReadAheadSize. Fine. I tried via appcmd.exe and then just manually editing my web.config to set this:

    other config settings

    -->
    <serverRuntime uploadReadAheadSize="1048576" />
  </system.webServer>

However, when I set this in the site's web.config, I get this error:

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

From there, I Googled and posts said that this config section needs to be 开发者_StackOverflow中文版unlocked. So I ran appcmd.exe to unlock it, but I get an error from appcmd.exe:

C:\Windows\System32\inetsrv>appcmd.exe set config -section:system.webserver/serverruntime/uploadreadaheadsize:1048576 /commit:apphost ERROR (message:Unknown config section "system.webserver/serverruntime/uploadreadaheadsize:1048576". Replace with ? for help. )

I got it opened in notepad 64-bit and modified it:

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

First off, is it wise to allow this to be overidden? If not, what are the alternatives? If it is overridden what are the potential issues with setting this in my web.config so that the uploadreadaheadsize is larger than the default? One site mentioned the potential for a DoS attack.

I would recommend instead just setting it up for the Site that requires that kind of functionality, you can easily do that using AppCmd, here is the syntax for enabling it say for Default Web Site:

appcmd.exe set config "Default Web Site" -section:system.webServer/serverRuntime /uploadReadAheadSize:"1048576"  /commit:apphost

Server runtime allows you to set several other features that depending on the server (like if it hosts 3rd party sites, or other non-trusted content) you might want not to allow that for them, so not delegating it (unlocking) makes sense.