ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress

Question

Scenario:

• User is using IE9 (IE8/10 not affected).
• User has an active session.
• Page starts an AJAX POST (GET not affected) request to a controller with the SessionState(SessionStateBehavior.Required) attribute (ReadOnly not affected). Something keeps this request from being immediately processed (such as another request in progress that has the session locked).
• While that AJAX POST is in progress, the user navigates away from the page (GET or POST - doesn't matter)

Result:

• AJAX POST terminates and returns an HTTP 500 (which the browser has since quit listening for, but you can see it in the IIS logs). IIS Failed Request Tracing shows the error is "The specified network name is no longer available. (0x80070040)."
• The user's session is locked for somewhere between 80 and 120 seconds (usually around 100) before the next request that requires read/write session access can execute.

Further digging in the log created by IIS Failed Request Tracing indicates that the AJAX POST crashes like this after the session state has been locked (during the REQUEST_ACQUIRE_STATE phase), but since the REQUEST_RELEASE_STATE phase doesn't happen, the session lock isn't released. I'm assuming there's some safety mechanism at play that's unlocking the session after 80-120 seconds, but this very long hang is obviously undesired for my users.

I have a simple VS2012/.Net 4.5/MVC4 project demonstrating the issue available at https://github.com/jorupp/Ie9SessionCrash (has one page that makes a series of posts to actions with Sleep calls). The IIS Failed Request Trace showing the issue is in the project at https://github.com/jorupp/Ie9SessionCrash/tree/master/Ie9SessionCrash/TraceOfHttp500.

To work around the issue, we're planning to ensure that we never make any AJAX POST calls to actions that require session, and either:

• Using GET calls where possible
• Using POST calls to controllers that have the SessionState(SessionStateBehavior.ReadOnly) attribute.

Is there a better way to deal with this, or am I missing an IIS/.Net patch in relation to this? Or is this scenario not valid for some other reason? I'm hesitant to blame the framework/IIS for this, but I think I've eliminated my code being at-fault.

Answer 1

This appears to be a regression in ASP.NET 4.5. Our team is working on a patch, but as a temporary workaround try placing this line in Web.config (more info here):

<system.webServer>
  <serverRuntime uploadReadAheadSize="0" />
</system.webServer>

Please let us know if this works for you!

Answer 2

Levi's answer works great in IIS 7.5 or higher. But if you are running Server 2008 R1, the following command will also set the setting:

c:\windows\system32\inetsrv\appcmd.exe set config "sitename" -section:system.webServer/serverRuntime /uploadReadAheadSize:"0" /commit:apphost 

But, a better fix is to apply the hotfix from Microsoft which remedies the issue (#6 in the attached KB article)

http://support.microsoft.com/kb/2828841/EN-US
http://support.microsoft.com/kb/2828842/EN-US