On some of my sites I am using an HttpModule to check for an existing Session value and if not found, redirect to a logon page.
I only to this for *.aspx and other dynamic content pages but not for *.css or *.js files. ASP.NET actually does not provide the session object for those static files anyways.
After installing SP1 on my developer workstation with Windows 7 64Bit I noticed a problem with some of my sites.
On pages where I use Ajax with json to call ASP.NET WebMethods, the HttpModule now kicks in and redirects to the login page, breaking the ajax request. Normal pages and non-webmethod ajax calls continue to work fine.
When I debugged the HttpModule I noticed that the HttpContext.Current.Session object is null when calling the webmethod.
This was working fine before SP1 and as I had no choice but going back. It worked again after I uninstalled the Service Pack.
I did some more investigation and found that before SP1 a hit to a page with some Ajax calls would result in the following
requests processed by the HttpModule:
/default.aspx: yes
/Styles/Site.css: no
/default.js: no
/Scripts/jquery-1.4.1.min.js: no
/service.aspx: yes
/service.aspx: yes
/service.aspx: yes
After installing SP1 the same page would result in these requests:
/default.aspx: yes
/Styles/Site.css: no
/default.js: no
/Scripts/jquery-1.4.1.min.js: no
/service.aspx/WebMethodTest: no
/service.aspx: yes
/service.aspx/WebMethodTest: no
/service.aspx: yes
/service.aspx/WebMethodTest: no
/service.aspx: yes
Notice that for a single Ajax Call to the webMethod there are now two requests and the one with the WebMethod name in
the URL has no session object.
As my logic can not find a session object for an *.aspx request it assumes there is no valid user and displays the logon page.
My workaround is to check for a name after the filename and exclude those requests as well. These URLs are internal
on the server and can not be changed by the browser otherwise a hacker could try to trick me into thinking I don't have
to authenticate this request.
So if you are doing something similar, be aware of this change.
P.S. This happened with ASP.NET 4.0 in integrated Pipeline mode, I don't know whether it affects other configurations as well. Also I could reproduce this on two machines, but not on a third one that did not have Visual Studio installed. I haven't tested this on Server 2008 R2 SP1 yet.
Update 3-March-2011: The ASP.NET team is now aware of this problem and has confirmed to me that this is an issue they will fix in a future service pack for .NET 4. As a workaround they suggest to move the 'ExtensionlessUrl-Integrated-4.0' handler further down in the list of handlers. To do this open the file: C:\Windows\System32\inetsrv\config\applicationHost.config and search for ExtensionlessUrl-Integrated-4.0, move the whole line down within the handlers block just above the last entry (StaticFile).
Thanks to Scott and Stefan for their quick help on this one.