7

EDIT: Due to the potentially critical nature of the answers to some of my questions below, I am adding this strong warning: Do not remove the filters I speak of here unless you know exactly what it is doing; the security of your application could be put into jeopardy.


I just noticed that a new Win 2008R2 server I am configuring for IIS7.5 use has the ISAPI filters for ASP.NET enabled by default in the root configuration, and therefore on all sites. I also checked one 2008 and one 2008R2 server I have access to, and those also have the same thing.ASP.NET ISAPI Filters

My understanding is that these are only needed when running a web app in Classic mode; my apps all run in Integrated mode. I removed all the ASP.NET-related filters from one ASP.NET site I am moving to the new server, and it does not appear to have caused any problem with the app.

In fact, it did cause a problem before I removed the 32-bit v4 entry on a v2 app. But then I just removed them all, because I don't believe they are needed at all.

So my main question: is the only reason those are in the root configuration by default in order to support Classic mode apps, which would need them to run?

Secondary question: shouldn't I remove them on all the sites operating in integrated mode, on the assumption they are at minimum doing nothing, and at worst, sucking up resources by existing (or worse yet, actually handling the requests!)

Bonus question: Do you think if I revisit my file permissions scheme for the web site content directories on those two previous servers now, I'm going to be surprised or notice some changes due to just finding out the above?


Edit: Note that it's actually probably dangerous to remove the aspnet_filter.dll entries for ISAPI filters. The entry on the IsapiFilterModule at the page URL below points out that filtering of protected content is done through this filter. For example; .config .cs and .vb files. http://learn.iis.net/page.aspx/121/iis-7-modules-overview/

1 Answer 1

4

I originally thought so too, but no - there's actually some bits of functionality provided by the filter across both modes - for example, cookieless session support.

Separate the ISAPI Filter behaviour from the ISAPI Extension behaviour - the Extension is what Integrated mode does away with.

1
  • 1
    I've accepted this answer; I'm kicking myself in the rear-end for not making the distinction between the ISAPI Extension (which should not exist in Integrated mode), and the Filter - which should. Not only does it provide support for cookieless sessions, it also supports filtering of protected URLs. So, removing the appropriate version's filter would likely leave an app open to having unintended URLs being served, which is a very bad idea! Mar 25, 2011 at 19:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .