HOWTO: Use Managed Code to Extend the IIS 6 Request Pipeline, Part 1


Motivation


A lot of people (at least half a dozen individuals within the past couple of weeks) have privately asked me for sample code to extend IIS 6 behavior in the following contexts:



  1. Want to write a protocal handler (such as WebDAV) on IIS in managed code
  2. Want to change/redirect URL processing by IIS using managed code
  3. Want to implement a custom security solution for IIS in managed code

Basically, things that one would usually handle with native ISAPI Filters and ISAPI Extensions, but now using managed code, preferably ASP.Net.


Well, your questions have catalyzed one of the long-standing articles that I have wanted to write – how to extend IIS 6 capabilities using managed code… and contrast how much easier and unified it will be in IIS 7.


This is definitely going to be a series of technical posts where I will try to give lots of sample code and synthesize technical information not found in normal documentation, so I am just going to start brain-dumping. It seems a bit haphazard to me, but I think you probably want the details ASAP in chunks, and not wait for the completely edited article series post a couple of weeks/months later…, so please feel free to immediately post comments if you want more details, different explanations, related ideas, etc, and I will definitely try to accommodate. These posts are to help you.


In the series, I plan to explore the details of extending IIS 6 with managed code, gather up and synthesize concise information from the designers and developers of various parts of IIS 6 and ASP.Net themselves, point out subtle nuances, and in the end, produce a road-map of how to extend IIS6 capabilities using managed code… and then tell you how it is going to be way better in IIS 7. 🙂


Now, where should we begin. Oh, yes, a preliminary outline of what I am considering for topics in the series:



  • Conceptual IIS 6 Request Pipeline (and why managed code extension does not work on earlier IIS versions like IIS 5)
  • Conceptual ASP.Net Request Pipeline (and why managed code extension requires ASP.Net 2.0 to work)
  • Sample Code using managed code to extend IIS 6, showing how to capture and respond to arbitrary HTTP Verbs, change aspects of the request like the URL, and filter incoming requests to control
  • How IIS 7 improves the experience

I will note that all of these behaviors can be handled by ISAPI Extension and ISAPI Filter DLLs written in native code. The reason why managed extensibility requires IIS 6 and ASP.Net 2.0 is due to the timing of IIS Request Pipeline features and ASP.Net exposure/integration of those same features.


Thus, we are going to start by looking at the IIS 6 Request Pipeline.


To be continued…


//David

Comments (5)

  1. Anonymous says:

    Hi David,

    Will definitely look forward to your posts on this subject.

    A few points that I can think of to help understand/relate to these concepts are:

    * Why would managed extensions be better than ISAPI extensions / filters (if they really are) and any exceptions.

    * Is it prudent to migrate existing ISAPI extensions/filters to managed extensions? Are there any benefits?

    * Sample scenarios like adding cross cutting scenarios like logging page / service level metadata transparent to the apps in both scenarios (ISAPI / Managed extensions) and a comparision of both options in terms of maintainability / performance / extensibility etc.

    Regards,

    KR

  2. Anonymous says:

    Thanks for your comments.

    If I understand correctly, the crux of your questions concern the pro/con of extending IIS 6.0 with ISAPI vs Managed Code in the context of writing new and maintaining/migrating old code that extend IIS behaviors.

    That is a great topic all by itself, and it has certainly been asked in newsgroups more than once. I will note this for another future blog entry.

    I am a little confused by what you mean in the cross-cutting scenario. The sentence is a bit too "loaded". Are you asking about a way for native code to access managed metadata (such as ISAPI accessing ASP.Net session context) and vice versa (ASP.Net accessing ISAPI ECB), or something else?

    I can say that in IIS 7.0, native and managed code both extend the IIS Request Pipeline as first-class citizens, so they both share state transparently through IIS. This is definitely not the case with IIS 6.0 and ASP.Net 2.0 where managed code extend the IIS Request Pipeline as a second-class citizen, as an Application ScriptMap.

    //David

  3. Anonymous says:

    Hi David,

    I modified AuthFilt to autheticate a user via Oblix/LDAP. After authentication, a user could access his inbox on a single server. In front-end and back-end environment for Exchange, a cookie should be passed from front-end to back-end after a successful authencation. Do you have any tips to generate a Exchange-compatible IIS cookie named sessionId. I can use InternetSetCookie or ASP Session object to generate a cookie. But what’s in the cookie? Thanks.

    Yang (sunbridge@hotmail.com)

  4. Anonymous says:

    Yang – I do not know what you mean by "Exchange-compatible" cookie. You want to query the Exchange Team’s blog for how to extend its authentication scheme since it is totally application-specific.

    //David

  5. Anonymous says:

    I implement a content management system and what to support WebDAV in IIS, but the content of file is stored in database, is there any resource I can find to implement such WebDAV server using c#?

Skip to main content