« Previous Next »

Thread: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

Last post 05-18-2009 10:16 PM by lextm. 9 replies.

Average Rating Rate It (5)

RSS

Page 1 of 1 (10 items)

Sort Posts:

  • 05-12-2009, 5:36 PM

    Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Hello,

    Q1

    When IIS7 is running in integrated mode, it automatically registers some of managed Asp.Net modules ( such as FormsAuthenticationModule etc ) defined in <system.web> element of a root web.config file

    A) I understand that in order to use particular managed module with non-Asp.Net application, we would need to register that module with IIS7.

    But why does IIS, for example, automatically register FormsAuthenticationModule, even if we don’t plan to use it for non-Asp.Net applications?

    Q2

    Book claims that ( when IIS7 is running in integrated mode ) settings for specific websites and virtual directories are stored in a separate section of a web.config file called <system.webServer>. Furthermore, if IIS7 finds any modules or handlers defined inside <system.web> element, it throws an exception.

    But then how is then IIS7 able to (by default) register some of Http handlers and Http modules defined in <system.web> element of a root web.config file? Shouldn’t it ignore them or throw an exception?
  • 05-13-2009, 4:23 AM In reply to

    • lextm
    • Top 10 Contributor
    • Joined on 10-22-2008, 4:18 AM
    • Shanghai, PRC
    • Posts 1,413

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    For Q1, since IIS 7 configuration (%windir%\system32\inetsrv\config\applicationHost.config) registers FormsAuthenticationModule for integrated pipeline mode, this module will be loaded automatically. The intention, like you mentioned, makes it possible to use Forms authentication for other applications besides ASP.NET.

    If you don't need that, you can disable this module for your application by overriding <system.webServer> relevant tag. There are other ways available, such as directly edit applicationHost.config.

    For Q2, you may find more information from this article under (1)

    http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/

    Lex Li
    Support Engineer at Microsoft
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • 05-13-2009, 6:17 PM In reply to

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Hello,

     

    lextm:

    For Q1, since IIS 7 configuration (%windir%\system32\inetsrv\config\applicationHost.config) registers FormsAuthenticationModule for integrated pipeline mode, this module will be loaded automatically. The intention, like you mentioned, makes it possible to use Forms authentication for other applications besides ASP.NET.

     

    I’m a bit confused by what you mean with “this module will be loaded automatically”.

    Namely, since this registered FormsAuthenticationModule by default works only with Asp.Net applications, I would think it would be loaded only when request comes for Asp.Net application?!

    And only when we configure it to work with non-Asp.Net applications also ( by un-checking option “Only for requests to Asp.Net applications or managed handlers” ), will it be loaded on each incoming request?!

     

    lextm:

    For Q2, you may find more information from this article under (1)

    http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/

     

    Normal 0 false false false MicrosoftInternetExplorer4

    I read the article but couldn’t find anything that would suggest as to why when running in integrated mode, doesn’t IIS 7 ignore Http modules and Http handlers defined in <system.web> element of a root configuration file. BTW – I realize that we should define modules and handlers inside <system.web> element, when IIS7 is running in classic mode, but why doesn’t root configuration file follow same rules and have handlers defined in either <system.web> or <system.webServer>, depending on the mode IIS 7 is running in?

     

    I don’t want to make a new thread, so may I ask additional question:

    Q3 - When running in integrated mode, IIS7 by default automatically registers FormsAuthenticationModule ( which is defined in root web.config file ), but does the term “Http module being integrated into IIS 7 processing pipeline” refers only to cases where this registered module is also configured to work with non-Asp.Net applications?

    In my opinion if module is not configured to work with non-Asp.Net applications, even if it is automatically registered by IIS 7, then we can’t really claim that it is integrated into IIS 7’s processing pipeline?!

     

    thanx

  • 05-13-2009, 9:15 PM In reply to

    • lextm
    • Top 10 Contributor
    • Joined on 10-22-2008, 4:18 AM
    • Shanghai, PRC
    • Posts 1,413

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Below is my understanding.

    Q1, back to applicationHost.config, there is a line registered as below,

    <location path="" overrideMode="Allow">

    <system.webServer>

    <modules>

    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="managedHandler" />

    </modules>

    </system.webServer>

    </location>

    So we know FormsAuthenticationModule is registered with preCondition=managedHandler.

    But what does it mean? From the following article we note that,

    http://learn.iis.net/page.aspx/121/iis-70-modules-overview/

    "The precondition in the following example (precondition="managedHandler") only enables the forms authentication module for requests that are also handled by a managed handler, such as requests to .aspx or .asmx files"

    As "enables" is used here, I think it's a normal behavior of IIS integrated pipeline to load FormsAuthentication but not enable it for unmanaged handlers.

    A sidenote is that integrated pipeline automatically loads .NET CLR and related pieces when it loads "ManagedEngine" or "ManagedEngine64" from <globalModules> tag, so this pipeline already has managed handlers for ASP.NET contents. If in such a case it does not load FormsAuthentication (whether enabled or not), other users will complain.

    If you want to remove such modules unless for your applications, you can remove them by overriding <modules> tag in your web.config files.

    Q2, in that article, it is documented that if you are using classic pipeline then nothing needs to be changed. If you want to use integrated pipeline, a configuration migration is necessary. Otherwise, you will see exceptions. That's how it was designed and implemented. So, please make a decision first about which pipeline to use, and then make necessary changes.

    Q3, sounds like the book chooses a really cool term. But without any context, it is really hard to comment whether such a saying is right or wrong. Can I have the book name? Actually I know many book authors have dedicated forums or mailing lists for readers to discuss issues, so it is highly recommended that you consult the author or the mailing list to see if there is useful resources.

    Lex Li
    Support Engineer at Microsoft
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • 05-15-2009, 6:39 PM In reply to

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Normal 0 false false false MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

    Normal 0 false false false MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

    Hello,

     Sorry for keep dragging this topic, but this is a really confusing subject for me.

     

    Q1

    A)

    * Both root web.config (c:\Windows\Microsoft.NET\Framework\v2.0.50727\Config. ) and applicationHost.config define module FormsAuthenticationModule. Thus I assume IIS 7 doesn’t read this root web.config file, else it would throw an exception due to FormsAuthenticationModule being defined inside <system.web> of this web.config?!

     

    * Anyways, since both root web.config and IIS 7 define/register this module, doesn’t that mean that two instances of this module will be loaded for each Asp.Net request?

     


     

    Q3,

    lextm:

    sounds like the book chooses a really cool term. But without any context, it is really hard to comment whether such a saying is right or wrong. Can I have the book name? Actually I know many book authors have dedicated forums or mailing lists for readers to discuss issues, so it is highly recommended that you consult the author or the mailing list to see if there is useful resources.



    Name of the book is Pro Asp.Net 3.5 in C# 2008. I searched for mailing list or forums of that particular author, but couldn’t find anything. About a month ago I found some errata in his book and notified him via his publisher, but so far no reply has been sent, so I guess he doesn’t want to be bothered

     

    Anyways, it uses this terms several times throughout his book, but here is the relevant excerpt:

    running IIS 7.0 in ASP.NET integrated mode provides a unified HTTP processing pipeline where native and managed modules are processed within the same HTTP module pipeline. Therefore, you can use any managed HTTP module written

    with the .NET language of your choice to extend the default behavior of IIS 7.0.

    That means you can write your own HTTP modules with .NET and integrate them into the IIS 7.0 processing pipeline. But it also means that you can integrate existing ASP.NET modules such as the FormsAuthentication or even the UrlAuthorization modules directly into the processing pipeline. That enables you to achieve the following two things much more easily compared to previous versions of IIS:

     

    • Protect non-ASP.NET resources as outlined in the previous section

    • Use ASP.NET security for any other web application, even if it’s not written with ASP.NET

     

    Both targets can be achieved the same way—you just need to enable the managed UrlAuthorization module shipping with ASP.NET to be processed in the native pipeline together with other IIS 7.0 modules (and ASP.NET modules) as well.

     

    Anyways, as I’ve already mentioned, if automatically registered FormsAuthenticationModule is not configured to work with non-Asp.Net requests, then I would argue that it's not really integrated into IIS processing pipeline?!

     

    thanx

  • 05-15-2009, 9:54 PM In reply to

    • lextm
    • Top 10 Contributor
    • Joined on 10-22-2008, 4:18 AM
    • Shanghai, PRC
    • Posts 1,413

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Q1, Well, the assumption is not right. IIS will read root web.config which is part of its configuration system now. But as Forms authentication is configured differently inside root web.config and applicationHost.config, there is no conflict.

    Q3, even if automatically registered FormsAuthenticationModule is not configured to work with non-Asp.Net requests, it does not indicate that this is not an integrated pipeline.

    The intention to register Forms authentication module but leave it aside for non-ASP.NET requests is mainly for compatibility, because on IIS 6 this module only works for non-ASP.NET requests.

    Though it sounds boring, I would like to put my understanding altogether like this,

    "This module is loaded into integrated pipelines in IIS worker processes based on default configuration, but is only enabled for ASP.NET requests, which is compatible with IIS 6 behavior."

    Lex Li
    Support Engineer at Microsoft
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • 05-17-2009, 4:47 PM In reply to

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Normal 0 false false false MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Navadna tabela"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

    Hello,

     

    I know I’m taking your time, so I will try to wrap it up

     


    Q1

     

    lextm:

    But as Forms authentication is configured differently inside root web.config and applicationHost.config, there is no conflict.

     

    A)

    How is Forms authentication configured differently in the two files? Meaning, what in their configurations prevents any conflicts(I realize element in web.config doesn’t have preCondition="managedHandler" attribute)?

     

    B) So in other words, IIS 7 “tolerates” FormsAuthenticationModule defined inside <system.web> element of a root web.config, but it doesn’t “tolerate”  if the module is defined inside <system.web> of a web.config located in the root directory of an application?!

     

    C) Anyways, I assume even though FormsAuthenticationModule is defined in two places ( root web.config and applicationHost.config ), only one instance will be called during a web page request?!

     

     

    Q3

    lextm:

    The intention to register Forms authentication module but leave it aside for non-ASP.NET requests is mainly for compatibility, because on IIS 6 this module only works for non-ASP.NET requests.

     

    I’m not quite sure, but I think you’ve made a typo in your above statement?! Namely, shouldn’t the statement be

     

    “…because on IIS 6 this module only works for ASP.NET requests.”

     

     

    I really appreciate it

  • 05-17-2009, 11:34 PM In reply to

    • lextm
    • Top 10 Contributor
    • Joined on 10-22-2008, 4:18 AM
    • Shanghai, PRC
    • Posts 1,413

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Q1)

    A) From root web.config

        <system.web>

            <httpModules>
                <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"/>

    Note that in this file, Forms authentication is configured as a HTTP module.

    From applicationHost.config,

        <location path="" overrideMode="Allow">
            <system.webServer>

                <modules>

                    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="managedHandler" />

    As IIS 7 use system.webServer\modules to register modules, and only modules registered in this tag is loaded into integrated pipeline, my personal guess is that forms authentication registered in root web.config is simply ignored by integrated pipeline. That's how the conflicts are avoided.

    Only if you use classic pipeline I think settings in root web.config system.web\httpModules will be read (but note that it is read by the separate pipeline hosted by aspnet_isapi.dll, not the integrated pipeline itself).

    B) Yes, "tolerate" is a good term and I couldn't find a better myself.

    C) No, I don't think so. If you are running in classic pipeline, then aspnet_isapi.dll will be loaded and a separate ASP.NET pipeline will be created which is exactly the same as IIS 6. Then it is this extra pipeline who loads another instance of FormsAuthenticationModule into memory.

    Please review IIS 6 documentation about the classic pipeline mode, and from a comparison you can gain more insight on both the pipeline modes.

    Q3) Yes, that's a typo. And you already got me right.

    Lex Li
    Support Engineer at Microsoft
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • 05-18-2009, 6:26 PM In reply to

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

     I really appreciate your help and patience

     cheers

  • 05-18-2009, 10:16 PM In reply to

    • lextm
    • Top 10 Contributor
    • Joined on 10-22-2008, 4:18 AM
    • Shanghai, PRC
    • Posts 1,413

    Re: Why does IIS7 automatically register some of Asp.Net’s Http modules and Http handlers?

    Hi,

    After reviewing more documents on IIS 7, I noticed that I was wrong on Q1. Any time there will be only one Forms authentication module loaded into CLR.

    Actually IIS 7 has two modes, where integrated pipeline loads webengine.dll from .NET Framework, while classic pipeline loads aspnet_isapi.dll. (webengine.dll is marked as integrated only, and aspnet_isapi.dll as classic only.)

    My further guess is that webengine.dll will ignore old <httpModules> and <httpHandlers> tags and only read new <modules> and <handlers> tags, while aspnet_isapi.dll reads old content.

    Then integrated pipeline, Forms authentication module is loaded by webengine.dll from applicationHost.config. But in classic pipeline, this module is loaded by aspnet_isapi.dll from root web.config.

    The above can explain why there is no conflict as there is only one copy of CLR is loaded, and the CLR host library only reads part of the configuration system and load a single Forms authentication module from that part of configuration.

    Lex Li
    Support Engineer at Microsoft
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
Page 1 of 1 (10 items)
Microsoft Communities