使用isapi_rewrie 3.x 對網(wǎng)站進行URL重寫，環(huán)境為 Asp.net4.0、IIS6.0。

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

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

　　原因如下：

　　因為ASP.NET4.0在安裝的過程中，已經(jīng)在IIS6做了一些手腳，讓它可以原生的支持的無后綴的URL請求，那么它究竟是做了什么事情呢？在實現(xiàn)這個功能的作者Thomas Marquardt的這篇博客上的一段話解釋了它的工作原理，大概是這樣的：

　　ASP.NET 4.0在安裝的時候，會在IIS6注冊一個ISAPI Filter，叫做”aspnet_filter.dll”，ISAPI Filter會先于ISAPI處理程序前執(zhí)行，它會在所有的的無后綴的URL后面加一串字符“/eurl.axd/GUID”， 同時ASP.NET 4.0還會在IIS默認添加一個請求映射規(guī)則“*.axd”，映射到aspnet_isapi.dll。此時，所有的無后綴URL加上“/eurl.axd/GUID”后都會變成帶.axd后綴，這樣就匹配*.axd的映射規(guī)則進行ASP.NET的處理通道。在進入ASP.NET通道后，ASP.NET處理程序會刪除掉“/eurl.axd/GUID”，讓它還原到無后綴的原始情況，并且不會對后續(xù)的請求處理帶來任何影響。此時，所有的無后綴請求，就進入了ASP.NET的處理通道中，在默認情況下，ASP.NET4.0的全局的web.config中配置了DefaultHttpHandler來接收無后綴的URL請求，但是我們也可以隨意更換默認處理程序（比如ASP.NET MVC處理程序）來處理無后綴的URL請求。

　　從上面的解釋中， 我們不難看到，這與IIS7的集成模式有本質(zhì)的不同，它并不是很原生的處理方案。不得不說，這并不是一個非常流暢的解決方案，也許這也是不得以之下的非常之舉。但是其實在沒有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以讀取注冊表修改后的內(nèi)容。注：此項修改就是關閉 ASP.NET 4‎.0對無擴展URL的處理，若將此項鍵值設為“1”則開啟。

標簽：

版權(quán)申明：本站文章部分自網(wǎng)絡，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。