Why do web sites in IIS7/7.5 have ASP.NET ISAPI filters enabled by default?

6,190

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.

Share:
6,190

Related videos on Youtube

Andrew Barber
Author by

Andrew Barber

Feel free to follow me on Twitter @AndrewLBarber, if you're into that sort of thing. But please keep in mind: If you have an issue with moderation, you should bring it up on Meta, and not send me Tweets about it. Seriously. I will block you. My profile image was created by my boss' daughter. Thanks, Megan!

Updated on September 17, 2022

Comments

  • Andrew Barber
    Andrew Barber over 1 year

    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/

  • Andrew Barber
    Andrew Barber about 13 years
    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!