讓我們從一個典型的ASP.NET Web請求的生命周期的起點開始。當用戶輸入一個URL，點擊了一個超鏈接或者提交了一個Html表單(form)(一個POST請求，相對於前兩者在一般意義上都是GET請求)。或者一個客戶端程序可能調用了一個基於ASP.NET的WebService(同樣由ASP.NET來處理)。在Web服務器端，IIS5或6，獲得這個請求。在最底層，ASP.NET和IIS通過ISAPI擴展進行交互。在ASP.NET環境中這個請求通常被路由到一個擴展名為.aspx的頁面上，但是這個流程是怎麼工作的完全依賴於處理特定擴展名的HTTP Handler是怎麼實現的。在IIS中。aspx通過’應用程序擴展’(又稱為腳本映射)被映射到ASP.NET的ISAPI擴展DLL-aspnet_isapi.dll。每一個請求都需要通過一個被注冊到aspnet_isapi.dll的擴展名來觸發ASP.Net(來處理這個請求)。
依賴於擴展名ASP.NET將請求路由到一個合適的處理器(handler)上，這個處理器負責獲取這個請求。例如，WebService的。asmx擴展名不會將請求路由到磁盤上的一個頁面，而是一個由特殊屬性(Attribute)標記為WebService的類上。許多其他處理器和ASP.NET安裝，當然你也可以自定義處理器。所有這些HttpHandler在IIS中被配置為指向ASP.NET ISAPI擴展，並在web。config(譯著:ASP.NET中自帶的handler是在Machine。config中配置的，當然可以在web.config中覆蓋配置)被配置來將請求路由到指定的HTTP Handler上。每個handler都是一個處理特殊擴展的。NET類，可以從一個簡單的只包含幾行代碼的Hello World類，到非常復雜的handler如ASP.NET的頁面或者WebService的handler。當前，只要了解ASP.Net的映射機制是使用擴展名來從ISAPI接收請求並將其路由到處理這個請求的handler上就可以了。
對在IIS中自定義Web請求處理來說，ISAPI是第一個也是最高效的入口。
ISAPI連接
ISAPI是底層的非托管Win32 API。ISAPI定義的接口非常簡單並且是為性能做了優化的。它們是非常底層的-處理指針和函數指針表來進行回調-但是它們提供了最底層和面向效率的接口，使開發者和工具提供商可以用它來掛接到IIS上。因為ISAPI非常底層所以它並不適合來開發應用級的代碼，而且ISAPI傾向於主要被用於橋接接口，向上層工具提供應用服務器類型的功能。例如，ASP和ASP.NET都是建立在ISAPI上的，Cold Fusion，運行在IIS上的多數Perl，PHP以及JSP實現，很多第三方解決方案(如我的Wisual FoxPro的Web連接框架)都是如此。ISAPI是一個傑出的工具，可以為上層應用提供高效的管道接口，這樣上層應用可以抽象出ISAPI提供的信息。在ASP和ASP.NET中，將ISAPI接口提供的信息抽象成了類型Request和Response這樣的對象，通過它們來讀取ISAPI請求中對應的信息。將ISAPI想像成管道。對ASP.NET來說，ISAPI dll是非常的”瘦”的，只是作為一個路由機制來將原始的請求轉發到ASP.NET運行時。所有那些沉重的負擔和處理，甚至請求線程的管理都發生在ASP.Net引擎內部和你的代碼中。
作為最為協議，ISAPI同時支持ISAPI擴展和ISAPI過濾器(Filter)。擴展是一個請求處理接口，提供了處理Web服務器的輸入輸出的邏輯-它本質上是一個處理(事物?)接口。ASP和ASP.NET都被實現為ISAPI擴展。ISAPI過濾器是掛接接口，提供了查看進入IIS的每一個請求的能力，並能修改請求的內容或者改變功能型的行為，例如認證等。順便提一下，ASP.Net通過了兩種概念映射了類似ISAPI的功能:Http Handler類似擴展，Http Module類似過濾器。我們將在後面詳細討論它們。
ISAPI是開始一個ASP.NET請求的最初的入口。ASP.Net映射了好幾個擴展名到它的ISAPI擴展，此擴展位於。NET框架的目錄下:
<.Net FrameworkDir>\ASPnet_isapi.dll
你可以在IIS服務管理界面上看到這些映射，如圖1。查看網站根目錄的屬性中的主目錄配置頁，然後查看配置|映射。
