isapi_rewrite重寫在asp.net4.0+IIS6錯誤的解決方法

　　使用isapi_rewrie 3.x 對網站進行URL重寫，環境為 Asp.net4.0、IIS6.0。

　　RewriteRule ^/([a-z0-9_-]+)/$ /Cate.aspx?N=$1 [NC]

　　但是在實踐中一直顯示404錯誤。

　　原因如下：

　　因為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）。

　　解決方法：

　　開啟登錄檔找到“HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\ASP.NET\\4.0.30319.0”，新增鍵值名為“EnableExtensionlessUrls” 型別為“DWORD”的鍵值，並設定值為“0”。然後在cmd中執行“IISRESET”，重啟IIS以讀取登錄檔修改後的內容。注：此項修改就是關閉 ASP.NET 4‎.0對無擴充套件URL的處理，若將此項鍵值設為“1”則開啟。