ASP.NET 4.0在IIS6原生支援沒有尾碼名的URL請求

看到haack的這篇文章《ASP.NET MVC 3 Extensionless URLs on IIS 6》，我才知道在IIS6的環境下運行ASP.NET4.0程式，我們已經可以原生的支援沒有後續名（副檔名）的URL請求，而不需要再做萬用字元映射，這對我們在IIS6部署ASP.NET MVC網站來說，相當的重要。

在以前，我們要讓ASP.NET MVC程式可以正常工作在IIS6上面，要麼在我們的程式路由中添加*.mvc（或其它任意尾碼），並且在部署時添加isapi映射規則，把*.mvc映射到aspnet_isapi.dll，讓他交由ASP.NET處理常式進行處理，但一般情況下，這種做法我們都不會採用，使用者體驗不好，至少到目前為止，我還沒有見過類似.mvc的網站；要麼，我們可以在部署時，添加萬用字元映射（wildcard mappings），映射到aspnet_isapi.dll，它的作用就是把所有的URL請求都交由ASP.NET程式處理，但是這樣做的使得很多原本不需要經過ASP.NET處理的請求，比如，樣式，指令碼，圖片等靜態資源都需要經過ASP.NET通道處理一遍，後果是可能會帶來一定的效能影響。雖不完美，但大多數人還是會選擇這種方案。

現在如果我們的ASP.NET網站基於ASP.NET 4.0，我們就不需要再做類似的事情了，因為ASP.NET4.0在安裝的過程中，已經在IIS6做了一些手腳，讓它可以原生的支援的無尾碼的URL請求，那麼它究竟是做了什麼事情呢？在實現這個功能的作者Thomas Marquardt的這篇部落格上的一段話解釋了它的工作原理，大概是這樣的：

ASP.NET 4.0在安裝的時候，會在IIS6註冊一個ISAPI Filter，叫做”aspnet_filter.dll”，ISAPI Filter會先於ISAPI處理常式前執行，它會在所有的的無尾碼的URL後面加一串字元“/eurl.axd/GUID”， 同時ASP.NET 4.0還會在IIS預設添加一個請求映射規則“*.axd”，映射到aspnet_isapi.dll。此時，所有的無尾碼URL加上“/eurl.axd/GUID”後都會變成帶.axd尾碼，這樣就匹配*.axd的映射規則進行ASP.NET的處理通道。在進入ASP.NET通道後，ASP.NET處理常式會刪除掉“/eurl.axd/GUID”，讓它還原到無尾碼的原始情況，並且不會對後續的請求處理帶來任何影響。此時，所有的無尾碼請求，就進入了ASP.NET的處理通道中，在預設情況下，ASP.NET4.0的全域的web.config中配置了DefaultHttpHandler來接收無尾碼的URL請求，但是我們也可以隨意更換預設處理常式（比如ASP.NET MVC處理常式）來處理無尾碼的URL請求。

從上面的解釋中， 我們不難看到，這與IIS7的整合模式有本質的不同，它並不是很原生的處理方案。不得不說，這並不是一個非常流暢的解決方案，也許這也是不得以之下的非常之舉。但是其實在沒有ASP.NET MVC以前，對無尾碼的URL請求的支援並不是那麼迫切需要。即使有需要，也是通過一個URL Rewriter組件，而因為首先要進入ASP.NET 處理通道，所以這種URL Rewriter組件也需要ISAPI層級的擴充。當我們在ASP.NET 4.0的程式中，需要用類似的組件的時候，可能就會需跟上面的功能有所衝突，此時，我們可能就會需要禁用ASP.NET4.0對無尾碼URL請求的這個功能。這時候你可能修改註冊表相關索引值（並重啟IIS），或者是刪除aspnet_filter.dll的註冊（因為在這步增加了/eurl.axd/GUID）。

在haack的文章最後還提到，他想要去確認這種行為的時候，出現了一點小問題，而它只是做了幾步就可以很簡單的修複這些問題。可能是在安裝ASP.NET 4.0的時候，某些IIS註冊行為沒有被正確執行才導致的這些錯誤的發生。但我自己目前還沒有IIS6的環境來驗證，但我相信，這個功能對於我們希望在IIS6部署ASP.NET MVC網站來說是非常有意義的。