在博客程序的日志中經常會出現這樣的錯誤日志：
Url: http://www.cnblogs.com/cmt/p/sokcet_memory_leak.html (這個URL僅是示例)
UserAgent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
System.Web.HttpException (0x80004005)
在 System.Web.CachedPathData.ValidatePath(String physicalPath)
在 System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
從錯誤內容看，應該是請求的URL路徑不對，可是通過Request.Url.AbsoluteUri記錄的URL又是正確的，讓人丈二和尚摸不著頭腦。
這個問題存在已久，之前選擇了默默地忍受。今天又看到這個錯誤，突然覺得甚是煩人，不想再忍受，于是決定查出問題真相，并將之消滅。
。。。
在Stackoverflow上的一個回答中找到了解決方法：
<httpRuntime relaxedUrlToFileSystemMapping="true" />
原來在默認情況下，ASP.NET會對請求的URL路徑進行檢查，如果不符合要求，就會拋出System.Web.HttpException (0x80004005)異常。
而我們遇到的問題場景是URL以空格結尾（%20），不符合ASP.NET的URL路徑驗證規則，于是拋出異常，并返回500錯誤。但是ASP.NET在拋出異常的同時，會自作聰明地將空格從路徑中去掉，從而造成Request.Url得到的是去掉空格的URL，產生了誤導信息，給分析問題形成了干擾。
對于文中開頭的日志內容，Googlebot實際請求的URL是：http://www.cnblogs.com/cmt/p/sokcet_memory_leak.html%20。只要將relaxedUrlToFileSystemMapping設置為true，就能避開ASP.NET的URL路徑合法性檢查，讓ASP.NET直接返回404錯誤。
然后可以通過URL重寫，將錯誤的URL重定向至正確的URL，500錯誤轉身變成了301重定向。URL重寫規則示例如下：
<rule name="html_url_fix" enabled="true" stopProcessing="true"> <match url="([^.]+\.html)[^?#]+" /> <action type="Redirect" url="{R:1}" /> </rule>
既然用了URL重寫，是不是可以不用多此一舉——加relaxedUrlToFileSystemMapping="true"？但事實證明這樣是不可取的，如果不加，訪問時不會自動進行跳轉，而是顯示下面的頁面：
這不知道是ASP.NET還是IIS干的勾當，為什么要出現這樣不友好的提示頁面，這里就不進行探查了。
所以，消滅這個問題的完美解決方法是：relaxedUrlToFileSystemMapping="true" + URL Rewrite。
文章列表
留言列表
