Global.asax中的URL重寫-IIS7

Question

我有一個相當詳細的問題，希望有人可以提供幫助。 基本上，我在IIS7上托管了一個.NET 4.0網站，該網站包含一些必須重寫URL的頁面。 為了實現這些功能，我在global.asax中添加了一種方法，該方法將無擴展名的URL映射到其正確的ASPX頁面，然后執行context.RewritePath以顯示正確的頁面。

最初，我從application_BeginRequest調用了此方法。 但是，在調用Session_Start時，我們會發生一些業務必需的日志記錄，並且由於在application_BeginRequest中重寫URL的實現，這種記錄似乎並不總是發生-基本上，每個會話都記錄在數據庫中，並且在初始部署后重寫URL后，我們的會話日志減少了約20％，而應用程序日志中沒有相應的錯誤。 同時，我們的IIS日志似乎顯示相對不變的流量，因此在我看來，會話似乎未正確實例化。

作為解決此問題的方法，我將URL重寫從application_BeginRequest移到了application_AcquireRequestState，這樣直到我（主要是）確定Session已啟動之后，此代碼才會觸發。 這在我的本地開發環境和登台服務器（已安裝Windows Server 2008-IIS 7-.NET 4.5 Framework）中有效。 在生產環境（Windows Server 2008-IIS 7-.NET 4.5 Framework）中，嘗試瀏覽到要重寫的無擴展名URL時出現404錯誤。

我完全感到困惑-我已驗證我正在使用集成應用程序池，我的web.config具有“ runAllManagedModulesForAllRequests = true”屬性，我的IIS功能包括HTTP重定向和靜態文件壓縮，但似乎沒有任何作用。 我發現有一個使用Classic應用程序池的黑客，它創建了額外的腳本映射處理程序來處理不帶擴展名的通配符URL，但是我很猶豫將其投入生產。

您能提供的任何幫助將不勝感激。 謝謝！

Answer 1

我將集中討論為何會話日志減少20％。 您確定流量也沒有減少嗎？ 您是否對使用舊版.aspx Urls進入網站的用戶使用重定向？ 也許您收到了更多不會觸發Session_Start的404流量？ UrlRewite啟用后，Google Analytics（分析）是否確認流量保持正常水平？ 您還可以使用IIS Log Parser過濾出靜態文件，並從日志文件中查詢200 vs 404，以更好地了解實際流量。