9

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.

Jonathan Rupp
  • 15,522
  • 5
  • 45
  • 61
  • Just so you know, the problem probably affects IE7 and IE8 also. We have a [slow to patch] system where we discovered behavior like this with these two browsers. The problem appears to be caused by an outstanding Ajax request completing after the browser has switched page. We can work around it by explicitly cancelling the request. I can't confirm it's precisely this issue until the ("highly secure") customer patches the systems in question, but it matches the MO of this precisely. – philw Jun 27 '14 at 15:02
  • @philw: the specific way we were getting it to break .Net 4.5 (before the workaround or patch Levi mentions) didn't happen with IE8, but there may be another way to cause that situation (browser terminates the request mid-stream). – Jonathan Rupp Jun 27 '14 at 17:37
  • Understood. However we confirmed this on both IE7 and IE8 now - installing the MS patch fixed it precisely as expected. In our case the issue was precisely: "in flight request returning after the browser has stopped listening for it". We still see that (error 64 in the server logs), but it no longer kills IE7 and IE8, now we patched the server. – philw Jul 11 '14 at 13:22

2 Answers2

7

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!

Levi
  • 32,628
  • 3
  • 87
  • 88
  • I had to update the applicationhost.config file for my IISExpress instance to unlock it, but that did the trick. Thanks for the help. Using classic mode worked as well, but I was hoping I wouldn't have to go that far. – Jonathan Rupp Mar 18 '13 at 20:19
  • BTW, thanks so much for the logs! They really helped us nail down this issue quickly. :) – Levi Mar 18 '13 at 21:25
  • you're welcome - you sure solved it quick for me posting it to SO and not even bothering to open something on Connect for it. It's almost like you guys are bored and out *actively looking* for stuff to fix :) – Jonathan Rupp Mar 18 '13 at 21:57
  • Is this something that can also be an issue in .NET 4.0 or just .NET 4.5? We're seeing a similar thing in .NET 4.0 and have been testing an upgrade to 4.5.1 but not sure if that will fix this issue or not for us since we're not on .NET 4.5 yet. – Bernd Mar 12 '14 at 15:32
  • 1
    Bernd, the particular issue that caused the problems described in this post is 4.5-only. It was fixed in 4.5.1. If you see an issue on 4.0, please open a new SO question. – Levi Mar 12 '14 at 16:07
  • @Levi any update for this issue. The hotfix links are not working. Any updates please. I ve tried the it is not working on IIS 7.5 – Bilgin Kılıç Jan 10 '19 at 07:56
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

Matt J
  • 63
  • 5