IIS服務(wù)器管道進(jìn)行隔離一些局限與不足
在使用過IIS服務(wù)器的過程中，我們來講解下IIS服務(wù)器的知識(shí)。IIS服務(wù)器 5.x和IIS服務(wù)器 6.0下把兩個(gè)管道進(jìn)行隔離至少帶來了下面一些局限與不足，例如相同操作的重復(fù)執(zhí)行：IIS服務(wù)器與ASP.NET之間具有一些重復(fù)的操作，比如身份驗(yàn)證。
動(dòng)態(tài)文件與靜態(tài)文件處理的不一致：因?yàn)橹挥谢贏SP.NET的動(dòng)態(tài)文件（比如.aspx、.asmx、.svc等等）的HTTP請(qǐng)求才能通過ASP.NET ISAPI進(jìn)入ASP.NET管道，而對(duì)于一些靜態(tài)文件（比如.html、.xml、.img等）的請(qǐng)求，則由IIS服務(wù)器直接響應(yīng)，那么ASP.NET管道中的一些功能將不能用于這些基于靜態(tài)文件的請(qǐng)求，比如，我們希望通過Forms認(rèn)證應(yīng)用于基于圖片文件的請(qǐng)求。
IIS服務(wù)器難以擴(kuò)展：對(duì)于IIS服務(wù)器的擴(kuò)展基本上就體現(xiàn)在自定義ISAPI，但是對(duì)于大部分人來說，這不是一件容易的事情。因?yàn)镮SAPI是基于Win32的非托管的API，并非一種面向應(yīng)用的編程接口。
通常我們希望的是諸如定義ASP.NET的HttpModule和HttpHandler一樣，通過托管代碼的方式來擴(kuò)展IIS。 對(duì)于Windows平臺(tái)下的IIS來講，ASP.NET無疑是一等公民，它們之間不應(yīng)該是“井水不犯河水”的關(guān)系，而應(yīng)該是“你中有我，我中有你”的關(guān)系。
為此，在IIS服務(wù)器 7.0中，實(shí)現(xiàn)了兩者的集成。對(duì)于集成模式下的IIS服務(wù)器 7.0，我們獲得如下的好處。
允許我們通過本地代碼（Native Code）和托管代碼（Managed Code）兩種方式定義IIS Module，這些IIS Module注冊(cè)到IIS中形成一個(gè)通用的請(qǐng)求處理管道。由這些IIS Module組成的這個(gè)管道能夠處理所有的請(qǐng)求，不論請(qǐng)求基于怎樣的資源類型。
比如，IIS服務(wù)器可以將FormsAuthenticationModule提供的Forms認(rèn)證應(yīng)用到基于.aspx，CGI和靜態(tài)文件的請(qǐng)求。 將ASP.NET提供的一些強(qiáng)大的功能應(yīng)用到原來難以企及的地方，比如將ASP.NET的URL重寫功能置于身份驗(yàn)證之前。采用相同的方式去實(shí)現(xiàn)、配置、檢測(cè)和支持一些服務(wù)器特性（Feature），比如Module、Handler映射、錯(cuò)誤定制配置（Custom Error Configuration）等。
【編輯推薦】
